[CMake] out of source command line flag

[Roman Shtylman]

Well...I didn't foresee such a discussion on the topic but have actually
heard some interesting new things brought up...so I guess I can chime in too.

1. Being able to call cmake with
       $> cmake <build dir> <source dir>
    Although it is better than what we have now, I like the explicit
nature of the -B <build dir> (or other flag) coming before the
directory specification. It makes it very clear what is going to
happen. It also doesn't tie you to a particular ordering of the
command line arguments.

2. I really like the idea of being able to specify a *default* out of
source directory to prevent in source builds altogether. From a
developer standpoint...if you could have that option be in the
CMakeLists.txt file (maybe before PROJECT) then I think that would be
the most obvious place for future maintainers to look. If you start
adding other files (i.e. InSource.cmake) you add more places where
people need to look for configuration options. Now, having said
that...I don't know enough about the caching system to know if it is
reasonable to even have such an option in a CMakeLists.txt file before
the build directory is known. Note, that this option (as I see it)
still does not handle the use case I showed initially where you can
create various build directories with different build flags...I see
this option as only providing a default build directory.

~Roman

On Mon, Sep 7, 2009 at 10:06 AM, Eric Noulard<eric.noulard at gmail.com> wrote:
> 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
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>