[CMake] Re-configuration, ExternalProjects, etc.

[Cliff Yapp]

On 09/30/2010 01:50 AM, Michael Wild wrote:
>
>> 2.  Because ExternalProject_Add does a full build and install prior to
>> building other targets (which I think is fine) I sometimes put myself
>> in the annoying position of building the whole system, then realizing
>> I forgot to clean an old build out of the install directory prior to
>> performing the build.  Then I do the classic rm -rf to clear it, only
>> to realize I just wiped out all of my ExternalProject install results.
>> This wouldn't be a problem, except I can't find a way to get the
>> build logic to check that the external projects are installed when
>> make install is run and re-do the install if necessary - they think
>> they're done because all steps were completed.  Admittedly this is a
>> minor annoyance, but if there is a way to avoid having to re-do  the
>> whole thing because I messed up clearing out the install directory
>> ahead of time I would be grateful :-)
>>     
> Don't install external projects directly into CMAKE_INSTALL_PREFIX, that's a recipe for disaster (after all, someone might want to use DESTDIR when doing a "make install"!) Instead install somewhere inside CMAKE_BINARY_DIR and then use the standard CMake facilities to install exactly what your project requires to run into CMAKE_INSTALL_PREFIX, e.g. using the BundleUtilities. In my project I have a some macros and functions which handle all of this for me, see here: http://freefoam.git.sourceforge.net/git/gitweb.cgi?p=freefoam/freefoam;f=CMake/FOAMThirdPartyUtilities.cmake;hb=pu (start with the foam_thirdparty_option function).
>   

Hmm, that's a very interesting approach - I hadn't thought of that. 
Three concerns.  One, it ends up creating build and install logic
specific to the external library that has to be maintained each time the
external lib is updated, which is a maintainance burden.  I guess this
might be worked around by copying the install dir wholesale...  Two,
what happens if the library has some awareness of its install location
and is not relocatable?  Can CMake work its RPATH magic on the third
party libraries somehow? Three, FOAMThirdPartyUtilities.cmake is GPL and
BRL-CAD has to stay LGPL-or-freer... - any chance it could be
re-licensed under the same terms as CMake?  (Just the one file
obviously, not all of FOAM...)


>> 3.  I'm in the process of writing CMake macros to replace things like
>> AC_HEADER_STDC, AC_HEADER_DIRENT, etc. - is there already a macro
>> package that defines CMAKE_HEADER_STDC and friends to replace these
>> common autoconf macros?
>>     
> No. Using AC_HEADER_STDC is no longer required, there is virtually no system/compiler which doesn't fulfill that one (the Autoconf manual says "This macro is obsolescent, as current systems have conforming header files. New programs need not use this macro.") The same goes for AC_HEADER_DIRENT. Most of these standard macros can be safely skipped...
>   

Hmm, that's a point - I'll have to ask our project lead about it.

Cheers, and thanks!
CY