[CMake] Re-configuration, ExternalProjects, etc.

[Michael Wild]

On 30. Sep, 2010, at 15:24 , Cliff Yapp wrote:

> 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.

But with your current setup the following will fail:

cmake -DCMAKE_INSTALL_PREFIX=/usr /path/to/source
make # BOOM - tries to install into /usr where you're not allowed to write
make install DESTDIR=/path/to/destdir # BOOM - the external stuff is not in DESTDIR 

About the maintenance, I wouldn't worry too much. If you update the external library, you're probably going to change a lot more than just the CMake code...

> 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?

If you're external libraries are shared objects, BundleUtilities takes care of everything, even adjusting the RPATH (or install_name on Mac). Only sad thing is that the documentation of that very useful and powerful module is currently utterly lacking..

> 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...)
> 

You'd need a bit more than just that single file (some functions are in FOAMUtilites.cmake). If you want to, I don't see any problem with you copying CMake-code from the FreeFOAM project. It's all been written by me, so go ahead. The only thing I ask you to do is to rename the functions, macros, variables and properties (mainly removing the FOAM and foam prefixes) and if you don't rework the stuff significantly include a comment attributing me and FreeFOAM (e.g. "inspired by ..."). If you simply use my code as an inspiration on how to approach things, don't bother with that ;-)

> 
>>> 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.

Otherwise it's pretty simple to emulate those checks with the CheckIncludeFiles module.

> 
> Cheers, and thanks!
> CY


Cheers

Michael

--
There is always a well-known solution to every human problem -- neat, plausible, and wrong.
H. L. Mencken

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100930/d9aa4c25/attachment.pgp>