Removing some things from C++ parser
Andreas Pakulat
apaku at gmx.de
Thu Jul 26 10:14:25 UTC 2007
On 25.07.07 23:29:57, Matt Rogers wrote:
> On Jul 25, 2007, at 9:28 PM, Andreas Pakulat wrote:
> > On 26.07.07 00:53:50, David Nolden wrote:
> >> Am Donnerstag, 26. Juli 2007 00:39:02 schrieb Andreas Pakulat:
> >>> David: Do you mind if I do that change this weekend - would mean
> >>> having 1
> >>> CMakeLists.txt in the cpp folder, not sure yet how to do the
> >>> tests then,
> >>> either separate files or also in the main 1. If you think this might
> >>> disturb you too much in your SoC I can postpone it after that.
> >>> (CC'ing
> >>> you as you said you don't get any list-mails)
> >>
> >> I probably won't be working on it in the weekend, so I don't mind.
> >
> > Oh, cool (I actually expected the opposite answer :)
> >
> >> The question is how we do make the tests continue working. Maybe
> >> static-linking them against the c++ plugin would be the easiest way.
> >
> > Thats going to be a no-brainer: use different CMake variables for all
> > "parts" and then the tests include their test + the needed parts.
> > Something like this:
> >
> > set(duchainbuilder_SRCS .... )
> > set(parser_SRCS ... )
> >
> > kde4_add_unit_test(duchaintest ${duchaintest_SRCS} $
> > {duchain_SRCS} ...)
> >
> > Well, you get the idea.
>
> I'd recommend having a shared library that contains all the parser
> stuff which the tests can link against rather than pulling in the
> sources for the particular things to test. You would also be able to
> link the plugin against the shared library as well. There's nothing
> saying that any installed shared library has to have public headers,
> so we can just not install those and be ok.
This is not just about the parser lib, but a general problem. The thing
with installing a shared library is that whenever somebody changes the
code in a BIC manner the version has to be increased (AFAIK at least),
which might be forgotten easily. I'm wondering wether there's a way to
tell cmake to not recompile the sources for the tests, which IMHO is the
only benefit of using a shared lib for the parts of the plugin.
Andreas
--
Abandon the search for Truth; settle for a good fantasy.
More information about the KDevelop-devel
mailing list