[CMake] Re-configuration, ExternalProjects, etc.

[Michael Wild]

On 29. Sep, 2010, at 20:09 , Clifford Yapp wrote:

> After working for a while at converting a project to CMake, I would
> like to ask a question/suggest a feature for CMake.
> 
> The project I am working on (BRL-CAD) includes various external
> libraries that it relies on on a subdirectory, with a variety of
> options for enabling and disabling use of the local and system copies.
> One of my biggest challenges when expressing our build logic in CMake
> was supporting the ability to "turn on" and "turn off" these third
> party builds cleanly and robustly.  I have (more or less) managed to
> get this working with macros (although I have yet to set it up for
> MSVC - gulp), but I have a few quirks I'd like to ask for opinions on:
> 
> 1. CMake has an extremely annoying habit of looking for libraries in
> the CMAKE_INSTALL_PREFIX directory after it is defined and picking up
> old versions of libraries from previous make install results in those
> directories.  In order to get it not to do this I literally had to
> force CMAKE_INSTALL_PREFIX to be empty in the Cache file, which
> doesn't feel right.  I'd MUCH rather set some option that tells CMake
> to not look for anything in the CMAKE_INSTALL_PREFIX directory (which
> for BRL-CAD is often different from system paths) with any of it's
> Find* commands. If this is supported I have yet to spot the option -
> can anyone enlighten me?  Am I making some obvious mistake?  It seems
> like a problem people would have had to solve before this, but maybe
> I'm doing something wrong.

I too would like an answer to that question. Also, it seems to be undocumented behavior. Of course, you could use NO_DEFAULT_PATH or some such (would be interesting to see which of the NO_* options turns this off), but that is rather kludgy...

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

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

I hope this helps a bit.

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/a3bcbe89/attachment.pgp>