[CMake] out of source command line flag

[Alan W. Irwin]

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
__________________________