[CMake] out of source command line flag

[Eric Noulard]

2009/9/7 Brad King <brad.king at kitware.com>:
> Eric Noulard wrote:
>> Fair enough,
>> my tortuous mind was tracking the build tree yours
>> is tracking the source tree, this is obviously a
>> better choice.
>>
>> My E3) case still remains, you really  don't want to mess-up
>> an existing build tree with a unrelated source tree.
>>
>> I know however that my proposal does not solve the other problem
>> regarding ignoring "<path-to-existing-build>" raised in this thread.
>
> That use case will not be dropped.  I think the two-path auto-magic
> command line interpretation approach will work well if implemented
> correctly, and will happily review a patch.

I personnally won't be able to provide a patch soon,
just to be clear that other may try it without fear :-)

> However, see my other suggestion below.
>
>> In the current one arg cmake invocation we should have a way to
>> detect/avoid an unvoluntary in-source build.
>> Currently we cannot.
>
> This is the key idea.  I've thought about possible solutions to this
> in the past but never found time to implement any.  My idea is to
> have an optional "InSource.cmake" file written by the project in the
> source tree.  If CMake sees an attempt to build in-source, it can
> load this file before touching the source tree at all.  The file
> could do one of the following:
>
> 1.) Simply error-out and tell the user to build out-of-source.
>    The source tree will remain clean.
> 2.) Compute the path to a build tree for CMake to auto-magically
>    substitute for an in-source build.  Likely it would be just
>    "<source-tree>/build" or some convention the project prefers.
> 3.) Other ideas?
>
> One gotcha with action #2 is that CMake knows nothing about the
> target platform at the point the file is loaded, so projects
> would be unable to compute a path like "build-x86_64".

I like the idea, however could you explain why you would rather
add an optional InSource.cmake file and not  a new CMake macro
that may be called before PROJECT in a CMakeLists.txt?

If you were to implement the extra-file thing why would
you limit its usage to the InSource check?

Let's say that we call it
PreCMakeTimeChecks.cmake or something better:

If it exists the file will be loaded by CMake in
something like "CMake -P" processing mode:

   A) BUT some vars needs to be defined, at least
           CMAKE_SOURCE_DIR
           CMAKE_BINARY_DIR
       (in fact currently in processing mode those var seems
        to be defined to working directory)

   B) The source tree won't be touched during this step
        (thus any SET will ignore CACHE argument
          i.e. no CMakeCache.txt interaction)

   C) The variable SET in this file may be passed to the current
       CMake process as if there were provided by -D <var>:<type>=<value>.
       including the "may-be-overwritten" CMAKE_BINARY_DIR which
       specify the wanted build tree.

"3) Other ideas?" yes, like I said project (or user) may give some
"typical" (but many ) PreCMakeTimeChecks.cmake files in order
ease 1 liner configuration.
This is just the same as "CMake ." default behavior but in this case
you may have several defaults at hand.

These kind of files may even be generated by cmake-gui:
http://www.cmake.org/pipermail/cmake/2009-September/031727.html

Summary is: we can introduce (optional) Pre CMake processing capability
which may not be restricted to the InSource handling case.


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org