Removing some things from C++ parser

Matt Rogers mattr at kde.org
Thu Jul 26 16:52:23 UTC 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jul 26, 2007, at 10:33 AM, 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 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.)
>

Static libraries are also out the question, as they don't build  
correctly on x86_64 for starters.

Also of note, we already have precedent for this. Take a look at the  
cmake build manager. IIRC, it's got at least one shared library that  
the plugin links against, if not more than one.
- --
Matt


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFGqNFHA6Vv5rghv0cRAo/OAJ90kU5YyfLlh1WLkJiqcGLcl70zzQCfQfMr
8yuCY9CEdvXW4ojpIQGsKqM=
=wX55
-----END PGP SIGNATURE-----




More information about the KDevelop-devel mailing list