out of source command line flag

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

out of source command line flag

Roman Shtylman
I have been meaning to try and create such a patch for a while. The
idea behind the patch is that you can specify the location of the out
of source build directory on the command line. By itself, this really
isn't all that useful save having to type mkdir 'some dir', cd 'some
dir', and 'cmake ..'

I think the use in this feature comes from being able to do something
like the following from WITHIN the source tree

$> cmake -B ./debug -DDebug=1 .
$> cmake -B ./release -DRelease=1 .

This will create directories 'debug' and 'release' in the source tree
where it will put all of the cmake cache files and whatnot from the
build. Each directory will then be using the appropriate things
triggered by having set the -D ... note... this is just a simple
example

I used the -B flag (as it was already there and I couldn't tell what
else it was currently doing) ... but pardon me if it actually had a
previous purpose.

This patch is not meat to be exhaustive (as I might have missed a
usage scenario with cache files or whatnot), but it does demonstrate
the capability I am looking for.

Feedback is welcome...or if you think this feature is utterly
worthless let me know :) I wanna hear why it can't work (don't just
say...well, you could have just made the directory and done all that
within it...yea...I know...but the point is that I didn't have to :) )

~Roman

_______________________________________________
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

cmake_outofsource.diff (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: out of source command line flag

Alexander Neundorf-3
On Sunday 09 August 2009, Roman Shtylman wrote:

> I have been meaning to try and create such a patch for a while. The
> idea behind the patch is that you can specify the location of the out
> of source build directory on the command line. By itself, this really
> isn't all that useful save having to type mkdir 'some dir', cd 'some
> dir', and 'cmake ..'
>
> I think the use in this feature comes from being able to do something
> like the following from WITHIN the source tree
>
> $> cmake -B ./debug -DDebug=1 .
> $> cmake -B ./release -DRelease=1 .
>
> This will create directories 'debug' and 'release' in the source tree
> where it will put all of the cmake cache files and whatnot from the
> build. Each directory will then be using the appropriate things
> triggered by having set the -D ... note... this is just a simple
> example
>
> I used the -B flag (as it was already there and I couldn't tell what
> else it was currently doing) ... but pardon me if it actually had a
> previous purpose.
>
> This patch is not meat to be exhaustive (as I might have missed a
> usage scenario with cache files or whatnot), but it does demonstrate
> the capability I am looking for.
>
> Feedback is welcome...or if you think this feature is utterly
> worthless let me know :) I wanna hear why it can't work (don't just
> say...well, you could have just made the directory and done all that
> within it...yea...I know...but the point is that I didn't have to :) )

Hmm, from my POV this patch doesn't add functionality to cmake, and it adds a
second way to do one thing. Personally I wouldn't vote for including the
patch.
Don't know what the others say.
Documentation is missing.

Alex
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: out of source command line flag

Hendrik Sattler
Am Freitag 04 September 2009 21:58:02 schrieb Alexander Neundorf:

> On Sunday 09 August 2009, Roman Shtylman wrote:
> > I have been meaning to try and create such a patch for a while. The
> > idea behind the patch is that you can specify the location of the out
> > of source build directory on the command line. By itself, this really
> > isn't all that useful save having to type mkdir 'some dir', cd 'some
> > dir', and 'cmake ..'
> >
> > I think the use in this feature comes from being able to do something
> > like the following from WITHIN the source tree
> >
> > $> cmake -B ./debug -DDebug=1 .
> > $> cmake -B ./release -DRelease=1 .
> >
> > This will create directories 'debug' and 'release' in the source tree
> > where it will put all of the cmake cache files and whatnot from the
> > build. Each directory will then be using the appropriate things
> > triggered by having set the -D ... note... this is just a simple
> > example
> >
> > I used the -B flag (as it was already there and I couldn't tell what
> > else it was currently doing) ... but pardon me if it actually had a
> > previous purpose.
> >
> > This patch is not meat to be exhaustive (as I might have missed a
> > usage scenario with cache files or whatnot), but it does demonstrate
> > the capability I am looking for.
> >
> > Feedback is welcome...or if you think this feature is utterly
> > worthless let me know :) I wanna hear why it can't work (don't just
> > say...well, you could have just made the directory and done all that
> > within it...yea...I know...but the point is that I didn't have to :) )
>
> Hmm, from my POV this patch doesn't add functionality to cmake, and it adds
>  a second way to do one thing. Personally I wouldn't vote for including the
>  patch.
> Don't know what the others say.
> Documentation is missing.

The problem with how giving the build-dir/source-dir to cmake is currently too
much dependent on other conditions:
  cmake [options] <path-to-source>
  cmake [options] <path-to-existing-build>

The first only is true if no CMakeCache.txt exists there. This was actually a
bad choice to have that as only possibility.
Being able to do an out-of-source build even if there was a previous in-source
build would be much appreciated.

HS

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: out of source command line flag

Alan W. Irwin
On 2009-09-05 09:38+0200 Hendrik Sattler wrote:

> The problem with how giving the build-dir/source-dir to cmake is currently too
> much dependent on other conditions:
>  cmake [options] <path-to-source>
>  cmake [options] <path-to-existing-build>
>
> The first only is true if no CMakeCache.txt exists there. This was actually a
> bad choice to have that as only possibility.
> Being able to do an out-of-source build even if there was a previous in-source
> build would be much appreciated.

I second that motion to drop the <path-to-existing-build> interpretation
(subject to policy protection, of course, assuming there is at least some
legitimate use case for <patch-to-existing-build>.)

CMake newbie's natural tendency seems to be to try an in-source build first.
Thus, I cannot count how many times PLplot and FreeEOS users out-of-source
build experience has been silently messed up by their first build attempt
which was in source. I have never heard of users actually using the
<path-to-existing-build> interpretation except by mistake.  However,
assuming there is some legitimate use case, I suggest you make a POLICY to
drop the <path-to-existing-build> interpretation. I would be happy to adopt
such a policy for my different software projects simply to drop the volume
of necessary advice to first-time users who keep falling into the trap of
using <path-to-existing-build> by mistake.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: out of source command line flag

Bill Hoffman
Alan W. Irwin wrote:

> On 2009-09-05 09:38+0200 Hendrik Sattler wrote:
>
>> The problem with how giving the build-dir/source-dir to cmake is
>> currently too
>> much dependent on other conditions:
>>  cmake [options] <path-to-source>
>>  cmake [options] <path-to-existing-build>
>>
>> The first only is true if no CMakeCache.txt exists there. This was
>> actually a
>> bad choice to have that as only possibility.
>> Being able to do an out-of-source build even if there was a previous
>> in-source
>> build would be much appreciated.
>
> I second that motion to drop the <path-to-existing-build> interpretation
> (subject to policy protection, of course, assuming there is at least some
> legitimate use case for <patch-to-existing-build>.)
>
> CMake newbie's natural tendency seems to be to try an in-source build
> first.
> Thus, I cannot count how many times PLplot and FreeEOS users out-of-source
> build experience has been silently messed up by their first build attempt
> which was in source. I have never heard of users actually using the
> <path-to-existing-build> interpretation except by mistake.  However,
> assuming there is some legitimate use case, I suggest you make a POLICY to
> drop the <path-to-existing-build> interpretation. I would be happy to adopt
> such a policy for my different software projects simply to drop the volume
> of necessary advice to first-time users who keep falling into the trap of
> using <path-to-existing-build> by mistake.
>

I use this all the time, and so do lots of people that I know. They do this:

cmake .

-Bill
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: out of source command line flag

Eric Noulard
2009/9/5 Bill Hoffman <[hidden email]>:

> Alan W. Irwin wrote:
>>
>> On 2009-09-05 09:38+0200 Hendrik Sattler wrote:
>>
>>> The problem with how giving the build-dir/source-dir to cmake is
>>> currently too
>>> much dependent on other conditions:
>>>  cmake [options] <path-to-source>
>>>  cmake [options] <path-to-existing-build>
>>>
>>> The first only is true if no CMakeCache.txt exists there. This was
>>> actually a
>>> bad choice to have that as only possibility.
>>> Being able to do an out-of-source build even if there was a previous
>>> in-source
>>> build would be much appreciated.
>>
>> I second that motion to drop the <path-to-existing-build> interpretation
>> (subject to policy protection, of course, assuming there is at least some
>> legitimate use case for <patch-to-existing-build>.)
>>
>> CMake newbie's natural tendency seems to be to try an in-source build
>> first.
>> Thus, I cannot count how many times PLplot and FreeEOS users out-of-source
>> build experience has been silently messed up by their first build attempt
>> which was in source.

It would be at least interesting to be able to programmatically
check (from within CMakeLists.txt)
that user does in-source build in order to be able to MESSAGE
a warning for dubious usage, i.e.

1) "Look like an attempt to do out-of-source but your
     build will be in-source because of an existing CMakeCache.txt"

    CMake may setup a CMAKE_BUILDING_INSOURCE
    when CMakeCache.txt is inside CMAKE_SOURCE_DIR
    or Working Dir == CMAKE_SOURCE_DIR

    Thus if
        Working Dir != CMAKE_SOURCE_DIR
                     AND
        CMAKE_BUILDING_INSOURCE

    Then the user may not be doing what he wants.

2) In the same way I did file a

>> I have never heard of users actually using the
>> <path-to-existing-build> interpretation except by mistake.  However,
>> assuming there is some legitimate use case, I suggest you make a POLICY to
>> drop the <path-to-existing-build> interpretation. I would be happy to
>> adopt
>> such a policy for my different software projects simply to drop the volume
>> of necessary advice to first-time users who keep falling into the trap of
>> using <path-to-existing-build> by mistake.
>>
> I use this all the time, and so do lots of people that I know. They do this:
>
> cmake .



--
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
Reply | Threaded
Open this post in threaded view
|

Re: out of source command line flag

Eric Noulard
In reply to this post by Bill Hoffman
Continued....

2) In the same way I did file a bug report for being able to enforce
    out-of-source if necessary.
    http://public.kitware.com/Bug/view.php?id=6672

2009/9/5 Bill Hoffman <[hidden email]>:

>
> I use this all the time, and so do lots of people that I know. They do this:

Yes right I do that too.

However it may be easy to follow Roman initial idea and replace:

cmake -B ./debug -DDebug=1 .

cmake -DDebug=1 ./debug .

i.e keep current usage:
cmake [options] <path-to-source>
cmake [options] <path-to-existing-build>

and add:
cmake [options] <path-to-build> <path-to-source>
cmake [options] <path-to-source> <path-to-build>

if you call cmake with 2 paths arguments then
one argument should be the source tree
other argument should be the build tree.
Note however that in this case <path-to-build> may not exist at all.

CMake may guess which one is the build tree using this algorithm.

1) If there is a CMakeCache.txt in the dir then this is a build tree
2) If the path does not exists then this is a "to be created" build tree

error cases are:

E1) One gives two existing dir with none containing a CMakeCache.txt
      ==> send an error message explaining that and abort.

E2) One gives two directories
          E21) both contains a CMakeCache.txt
      or E22) one contains a CMakeCache.txt and the other does not exists.

          E21 is plain wrong
          E22 the source tree may have been polluted with a previous
in-source config.

E3) One gives a build tree which does not correspond to the given source tree
         This is easy to check because CMakeCache.txt contains
                 <PROJECT>_SOURCE_DIR

      If this appear CMake should abort and send a message telling
      the source tree/build tree mismatch.

This does not look like that complicated and will keep full backward
compatibilty without adding extra "-B" option.

To be clear I'm not wanting to apply for providing a patch but may
be Roman would like to try ?

May be worth trying if other find the idea interesting.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: out of source command line flag

Alan W. Irwin
In reply to this post by Bill Hoffman
On 2009-09-05 10:59-0400 Bill Hoffman wrote:

> Alan W. Irwin wrote:
>> On 2009-09-05 09:38+0200 Hendrik Sattler wrote:
>>
>>> The problem with how giving the build-dir/source-dir to cmake is currently
>>> too
>>> much dependent on other conditions:
>>>  cmake [options] <path-to-source>
>>>  cmake [options] <path-to-existing-build>
>>>
>>> The first only is true if no CMakeCache.txt exists there. This was
>>> actually a
>>> bad choice to have that as only possibility.
>>> Being able to do an out-of-source build even if there was a previous
>>> in-source
>>> build would be much appreciated.
>>
>> I second that motion to drop the <path-to-existing-build> interpretation
>> (subject to policy protection, of course, assuming there is at least some
>> legitimate use case for <patch-to-existing-build>.)
>>
>> CMake newbie's natural tendency seems to be to try an in-source build
>> first.
>> Thus, I cannot count how many times PLplot and FreeEOS users out-of-source
>> build experience has been silently messed up by their first build attempt
>> which was in source. I have never heard of users actually using the
>> <path-to-existing-build> interpretation except by mistake.  However,
>> assuming there is some legitimate use case, I suggest you make a POLICY to
>> drop the <path-to-existing-build> interpretation. I would be happy to adopt
>> such a policy for my different software projects simply to drop the volume
>> of necessary advice to first-time users who keep falling into the trap of
>> using <path-to-existing-build> by mistake.
>>
>
> I use this all the time, and so do lots of people that I know. They do this:
>
> cmake .

Well, I have a modern shell (bash) with quick access (up arrow or "!cmake")
to previous commands so I normally just repeat the exact previous cmake
command.  Thus, I had completely forgotten about the "cmake ." possibility.

The fact remains some projects would like to drop the
<path-to-existing-build> interpretation altogether (for the reasons I
mentioned) and other projects will want to preserve it (for the reasons you
mentioned).

Can't the needs of both groups be served by a policy?

If you would prefer not to have policy about this issue, is there some
technical means of detecting when the cmake invocation directory is not the
same as the build directory?  The combination of cmake invocation directory
!= build directory AND build_directory == source directory is the one I want
to avoid (by erroring out with appropriate message) since that is the
combination that appears to get newbies into trouble.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: out of source command line flag

Hendrik Sattler
In reply to this post by Bill Hoffman
Am Samstag 05 September 2009 16:59:09 schrieb Bill Hoffman:
> I use this all the time, and so do lots of people that I know. They do
>  this:
>
> cmake .

I also use this. But being able to force a specific build dir (instead of cmake
trying to be smart) may be a good thing, like ignoring the in-source build
files.
It may cause other problem though, like "-I<source-dir> -I<build-dir>" and a
generated header file.

HS
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: out of source command line flag

Alexander Neundorf-3
In reply to this post by Eric Noulard
On Saturday 05 September 2009, Eric Noulard wrote:
> Continued....
...

> CMake may guess which one is the build tree using this algorithm.
>
> 1) If there is a CMakeCache.txt in the dir then this is a build tree
> 2) If the path does not exists then this is a "to be created" build tree
>
> error cases are:
>
> E1) One gives two existing dir with none containing a CMakeCache.txt
>       ==> send an error message explaining that and abort.
>
> E2) One gives two directories
>           E21) both contains a CMakeCache.txt
>       or E22) one contains a CMakeCache.txt and the other does not exists.
>
>           E21 is plain wrong
>           E22 the source tree may have been polluted with a previous
> in-source config.
>
> E3) One gives a build tree which does not correspond to the given source
> tree This is easy to check because CMakeCache.txt contains
>                  <PROJECT>_SOURCE_DIR
>
>       If this appear CMake should abort and send a message telling
>       the source tree/build tree mismatch.

I think it could be easier than that.
E1) none of the two directories contains a CMakeLists.txt
E2) both directories contain a CMakeLists.txt

In all other case, one directory contains a CMakeLists.txt, this is the source
dir. The other directory does not contain a CMakeLists.txt, so it is not a
source dir. It may contain a CMakeCache.txt, then it is already a build dir.
If it does not, it will become the build dir.

Alex
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: out of source command line flag

Eric Noulard
2009/9/5 Alexander Neundorf <[hidden email]>:
> On Saturday 05 September 2009, Eric Noulard wrote:
[...]

>> E3) One gives a build tree which does not correspond to the given source
>> tree This is easy to check because CMakeCache.txt contains
>>                  <PROJECT>_SOURCE_DIR
>>
>>       If this appear CMake should abort and send a message telling
>>       the source tree/build tree mismatch.
>
> I think it could be easier than that.
> E1) none of the two directories contains a CMakeLists.txt
> E2) both directories contain a CMakeLists.txt
>
> In all other case, one directory contains a CMakeLists.txt, this is the source
> dir. The other directory does not contain a CMakeLists.txt, so it is not a
> source dir. It may contain a CMakeCache.txt, then it is already a build dir.
> If it does not, it will become the build dir.

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.

Moreover the problem raised by Alan:

"If you would prefer not to have policy about this issue, is there some
technical means of detecting when the cmake invocation directory is not the
same as the build directory?  The combination of cmake invocation directory
!= build directory AND build_directory == source directory is the one I want
to avoid (by erroring out with appropriate message) since that is the
combination that appears to get newbies into trouble."

is important to me too.

In the current one arg cmake invocation we should have a way to
detect/avoid an unvoluntary in-source build.
Currently we cannot.


--
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
Reply | Threaded
Open this post in threaded view
|

Re: out of source command line flag

Brad King
In reply to this post by Alan W. Irwin
Alan W. Irwin wrote:
> The fact remains some projects would like to drop the
> <path-to-existing-build> interpretation altogether (for the reasons I
> mentioned) and other projects will want to preserve it (for the reasons you
> mentioned).

The path-to-existing-build interpretation is not the cause of the problems
with trying out-of-source builds after trying an in-source build.  The problem
is that files generated in the source tree by an in-source build attempt,
such as generated header files, can break out-of-source builds.  I have
another solution in mind which I'll post elsewhere in this thread shortly.

> Can't the needs of both groups be served by a policy?

Policies are only meant for fixing behavior while maintaining compatibility.
They are not meant for switching between two supported behaviors.  The OLD
behavior is always unsupported (except for compatibility) and the NEW one
is always supported.

-Brad
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: out of source command line flag

Brad King
In reply to this post by Eric Noulard
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.  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".

-Brad
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: out of source command line flag

Eric Noulard
2009/9/7 Brad King <[hidden email]>:

> 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
Reply | Threaded
Open this post in threaded view
|

Re: 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<[hidden email]> wrote:

> 2009/9/7 Brad King <[hidden email]>:
>> 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
>
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: out of source command line flag

Brad King
Roman Shtylman wrote:

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

That's a good point.  While it might be obvious to CMake which
directory is build and which is source, it might not to the human
reading the command line.  I'll vote for the explicit switch.

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

A lot of things happen before CMakeLists.txt even starts running,
and files will have already been written to the build tree.

> If you start
> adding other files (i.e. InSource.cmake) you add more places where
> people need to look for configuration options.

Eric's point is good.  The file could be used for other things too.
A *long* time ago we tried to create a PreLoad.cmake file for some
purpose I can't remember.  We never got it working well, but it was
not quite the same thing we are discussing here.

An important clarification is that any kind of PreConfigure.cmake
file would be loaded without any build tree or cache.  Anything it
does won't make it into the real CMakeLists.txt processing...no
variables or cache settings.  The file would be an interface to
tell CMake about some project information or preferences.  This
could include things like:

1.) Default build directory for attempted in-source builds

2.) Eric's option C...default cache entries.  For the CMake
    GUI they could appear before the first Configure starts.

3.) A mapping from "--prefix"-style options to cache entries.
    The output of "cmake --help <src-tree|bld-tree>" could
    include these options as project-specific help.

Idea #3 is a long-requested feature anyway.

-Brad
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: out of source command line flag

Alan W. Irwin
In reply to this post by Brad King
On 2009-09-07 08:43-0400 Brad King wrote:

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

Projects can obviously do (1) already by the appropriate IF(CMAKE_BINARY_DIR
STREQUAL "${CMAKE_SOURCE_DIR}") logic.  However, I suspect most projects
prefer to give their users the flexibility to choose in-source builds.

Instead of (2) which requires users of a particular project that adopts it
to never have access to in-source builds, I far prefer the idea of giving
build systems access to the path where cmake was invoked as a CMake variable
(say CMAKE_INVOCATION_DIR). That allows projects to demand (if they like) to
error out IF(NOT CMAKE_BINARY_DIR STREQUAL "${CMAKE_INVOCATION_DIR}" AND
CMAKE_BINARY_DIR STREQUAL "${CMAKE_SOURCE_DIR}") which would disallow _just_
the problematic case where users try an in-source build, then attempt to
invoke cmake from a different location other than the top of the existing
build == source tree.

Alan





That would allow users to use
"cmake ."

or to error out when users
are attempting to follow an in-source build with a possible out-of-source
build.




detect the problematic case
(invocation path != build-tree path AND build-tree path == source-tree path)
where an attempt is made to do an in-source build from some other location
using the <path-to-existing-build> interpretation.  It's this problematic
case (which can only occur if there is an in-source build followed by an
out-of-source build attempt) that I believe most projects want to avoid
rather than precluding in-source builds altogether as in (1).

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: out of source command line flag

Roman Shtylman
In reply to this post by Brad King
> An important clarification is that any kind of PreConfigure.cmake
> file would be loaded without any build tree or cache.  Anything it
> does won't make it into the real CMakeLists.txt processing...no
> variables or cache settings.  The file would be an interface to
> tell CMake about some project information or preferences.  This
> could include things like:

I like this idea as it provides a good place to put any *init* related
config. Providing a default build directory seems very reasonable to
me and I think that many project would actually benefit from such a
feature. IMHO in-source builds interfere too much with the source tree
(obviously) and out of source builds (and all the intermediate files)
are much easier to ignore with version control systems.

On top of the PreConfigure.cmake file I still think the -B <build dir>
flag might have be of benefit... unless the PreConfigure.cmake allows
you to setup more than one build directory and the options that will
be defined in it? That would be rather useful as you could setup debug
and release directories and specify the default directory all from one
file. Maybe this starts becoming more of a project preferences or
setup file...

~Roman

On Mon, Sep 7, 2009 at 11:28 AM, Brad King<[hidden email]> wrote:

> Roman Shtylman wrote:
>> 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.
>
> That's a good point.  While it might be obvious to CMake which
> directory is build and which is source, it might not to the human
> reading the command line.  I'll vote for the explicit switch.
>
>> 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.
>
> A lot of things happen before CMakeLists.txt even starts running,
> and files will have already been written to the build tree.
>
>> If you start
>> adding other files (i.e. InSource.cmake) you add more places where
>> people need to look for configuration options.
>
> Eric's point is good.  The file could be used for other things too.
> A *long* time ago we tried to create a PreLoad.cmake file for some
> purpose I can't remember.  We never got it working well, but it was
> not quite the same thing we are discussing here.
>

>
> 1.) Default build directory for attempted in-source builds
>
> 2.) Eric's option C...default cache entries.  For the CMake
>    GUI they could appear before the first Configure starts.
>
> 3.) A mapping from "--prefix"-style options to cache entries.
>    The output of "cmake --help <src-tree|bld-tree>" could
>    include these options as project-specific help.
>
> Idea #3 is a long-requested feature anyway.
>
> -Brad
>
_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: out of source command line flag

Eric Noulard
In reply to this post by Alan W. Irwin
2009/9/7 Alan W. Irwin <[hidden email]>:
> On 2009-09-07 08:43-0400 Brad King wrote:
>>
>> 1.) Simply error-out and tell the user to build out-of-source.
>>   The source tree will remain clean.
>>
>
> Projects can obviously do (1) already by the appropriate IF(CMAKE_BINARY_DIR
> STREQUAL "${CMAKE_SOURCE_DIR}") logic.

Yes you can do that but when you reach that point in your CMakeLists.txt
the source tree is **ALREADY** cluttered with unwanted files including
a CMakeCache.txt.

This is precisely the point of bug:
http://public.kitware.com/Bug/view.php?id=6672

> However, I suspect most projects prefer to give their users the
> flexibility to choose in-source builds.

Yes you are right I do support in-source for my CMake-powered project
but I'd rather be able to warn my user about
the evilness of in-source build when they can simply avoid it :-)
I may require  -DFORCE_IN_SOURCE in order to make the
user fully aware of what he is doing.
That way I may be able to avoid the explanation for cleaning
a "use as build tree source tree".

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

> Instead of (2) which requires users of a particular project that adopts it
> to never have access to in-source builds,

Agreed,
there should a way for the user to **explicitely** tells that he wants
an in-source
build and authorize it with some -DFORCE_IN_SOURCE.

I just dislike the default behavior which makes me unable to
warn about in-source build efficiently.

> I far prefer the idea of giving
> build systems access to the path where cmake was invoked as a CMake variable
> (say CMAKE_INVOCATION_DIR). That allows projects to demand (if they like) to
> error out IF(NOT CMAKE_BINARY_DIR STREQUAL "${CMAKE_INVOCATION_DIR}" AND
> CMAKE_BINARY_DIR STREQUAL "${CMAKE_SOURCE_DIR}") which would disallow _just_
> the problematic case where users try an in-source build, then attempt to
> invoke cmake from a different location other than the top of the existing
> build == source tree.

Yes that's a good point,
but at that point your user discovers that he has already done an
in-source build
(may be because he overlooked the written build procedure) and ends up asking
on his favorite mailing list how he can clean his source tree.

If he has previously **explicitely** required in-source build he won't
be puzzled
by the latest message. If he has done the first in-source config. by mistake
he will be puzzled by the error message.
However your idea is good I can error out a big explanation
on the in-source vs out-of-source think using your test:
IF(NOT CMAKE_BINARY_DIR STREQUAL "${CMAKE_INVOCATION_DIR}" AND
CMAKE_BINARY_DIR STREQUAL "${CMAKE_SOURCE_DIR}")


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