[CMake] Need advice for unit test structure

Robert Dailey rcdailey at gmail.com
Thu Apr 9 12:47:42 EDT 2009


On Wed, Apr 8, 2009 at 5:33 PM, Paul Oppenheim (Poppy Linden) <
poppy at lindenlab.com> wrote:

> Robert Dailey wrote:
>
>> Obviously this creates a lot of clutter in the solution explorer window in
>> Visual Studio. Is there a more recommended practice for structuring unit
>> tests in CMake? Personal advice is also welcome. One approach I'd like to
>> take is where we only have two projects:
>>
>>  ...
>
>>
>> If we include these source files in the same project, then it interrupts
>> the whole compilation process. They have to be separate in order to work
>> properly.
>>
>>
> thank goodness! someone else!
>
> I'm currently dealing with the same issue for a large number of reasons
>
> * clutters IDEs
> * tests add long compile / link time
> * some developers interested in TDD (test-driven development)
> * etc
>
> The solution the CMake project itself uses is sub-projects. Since we're
> only interested in unit tests at the moment, the process of adding targets
> and tests is quite mechanical, so I have a CMake macro that auto-generates
> sub-build CMakeFiles.txt files.
>
> I'm currently in mid-development, so this hasn't merged back to trunk yet.
> Otherwise I'd have a link to the source for you (Second Life is open
> source). The current good but project-cluttering solution is here:
>
> http://svn.secondlife.com/trac/linden/browser/trunk/indra/cmake/LLAddBuildTest.cmake
>
> (the new stuff will be in the same file)
>
> I'm *really* interested in hearing what you wind up doing!


Do you have unit tests that require failure to compile in order to be
successful? If you do, placing these particular unit tests in a project with
other tests that must compile to succeed will interrupt the process,
depending on the order of compilation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090409/ba4efba4/attachment.htm>


More information about the CMake mailing list