[CMake] HOW TO: build development versions, plus proper INSTALL setup?

[kent williams]

Thanks for the suggestions.  I believe that if you force all your test
programs to get thrown into ${XXX_BINARY_DIR}, you could do the
ADD_TEST without specifying ${XXX_BINARY_DIR}/testname -- just
testname would suffice.

Oh and when someone says "If you can wade through the boost sources" I
draw my revolver.  Boost is one of those things that has all sorts of
great goodies, but when you look at actually using it, the
build/config/etc system is a deal breaker.  And you can never just use
one thing from Boost -- everything in Boost has itself been Boosted,
so it doesn't seem to ever decompose into independent modules.

Not trying to give you grief, just an observation. ;-)

On Mon, Mar 9, 2009 at 3:27 PM, Michael Jackson
<mike.jackson at bluequartz.net> wrote:
> The other items in your list looks like you have figured out so I'll just
> make a suggestion for #3:
>
> I tried the following and it does work:
>
>
> # All the following in its own CMakeLists.txt file that
> # will be called with add_subdirectory() from the top level
> # CMakeLists.txt file.
> project(UnitTests)
> add_executable(foo_test foo_test.c)
> target_link_Libraries(foo_test ...... )
> set_target_properties(foo_test PROPERTIES
>                RUNTIME_OUTPUT_DIRECTORY ${UnitTests_BINARY_DIR})
> add_test(foo_test ${UnitTests_BINARY_DIR}/foo_test)
>
>
> If you can wade through the Boost sources there is an experimental CMake
> build system that I believe does a lot of this. You could probably distill
> all of this down to a Macro that you could invoke to do all of the above
> with just a few arguments.
>
> Hope that helps.
> _________________________________________________________
> Mike Jackson                  mike.jackson at bluequartz.net
> BlueQuartz Software                    www.bluequartz.net
> Principal Software Engineer                  Dayton, Ohio
>
>
>
> On Mar 9, 2009, at 2:49 PM, kent williams wrote:
>
>> 3. Test programs should NOT get thrown in with the actual 'product'
>> programs, and ideally stay in ${LOCALDIR_BINARY_DIR} for the local
>> project.
>
>