Removing some things from C++ parser
apaku at gmx.de
Thu Jul 26 15:53:07 UTC 2007
On 26.07.07 10:33:04, Matthew Woehlke wrote:
> Andreas Pakulat wrote:
> > On 25.07.07 23:29:57, Matt Rogers wrote:
> >> 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.
> Even when the only thing linking against it is always distributed at the
> same time?
I'm not sure. I think that when a shared library (wether used or not)
breaks ABI it needs to increas its soversion. But I'm really no expert
> > 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.
> The "convenience library" thing comes up frequently, last I checked
> there is no easy way to do it (so said the wiki anyway). Is it possible
> to make a static library instead? (Only the plugin and test apps use it,
> right? In which case the increased code size is not an issue.)
No, static libs are a no-go - AFAIK. It needs -fPIC on 64bit systems in
various places... Tried that for the python plugin, didn't work very
This life is yours. Some of it was given to you; the rest, you made yourself.
More information about the KDevelop-devel