Removing some things from C++ parser

Matt Rogers mattr at
Thu Jul 26 16:51:10 UTC 2007

Hash: SHA1

On Jul 26, 2007, at 5:14 AM, Andreas Pakulat wrote:

> 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

You don't have to version shared libraries. Especially ones that are  
internal to KDevelop anyways.
- --

Version: GnuPG v1.4.6 (Darwin)


More information about the KDevelop-devel mailing list