[CMake] Separate object directories on Linux?

[Alexander Neundorf]

On Wednesday 02 April 2008, Hendrik Sattler wrote:
> Am Mittwoch 02 April 2008 schrieb Bill Hoffman:
> > Bryan O'Sullivan wrote:
> > > On Windows and OS X, I notice that object files get put into a
> > > directory prefixed with the current build type, e.g. Debug or Release. 
> > > This doesn't happen on Linux, so I can't have a single build tree with
> > > multiple builds side by side in it.  Is there some reason for this? 
> > > The variation in behaviour across platforms seems peculiar.
> >
> > Basically, this is because on windows we use the default for the native
> > tool visual studio which supports configuration types. On makefile
> > builds we only support a single configuration per build tree as would be
> > expected in a most makefiles.  I guess it is the price we pay for
> > generating to native build tools, there are sometimes inconsistencies.
> > It would be nice if at some point in the future we supported
> > configurations for makefiles, and flat builds for ide's, but this has
> > not yet been done.
>
> The context menu of current Eclipse projects contain a greyed-out build
> types menu. Is this something similar and why is it not used with
> cmake-generated project files?
>
> Additionally, the WIKI entry for Eclipse CDT support suggest an extra
> variable (with a way toooooooo long name) to create the .project file in
> the source tree. However:
>  - the WIKI mentions an invalid command line:
>    cmake -G"Eclipse CDT4 - Unix Makefiles" \
>          -DECLIPSE_CDT4_GENERATE_SOURCE_PROJECT ../certi_src
>    A :BOOL=TRUE is missing here.
Added.

>  - the eclipse project is totally useless without that option as the
> project are about editing the source, not just triggering the build from a
> GUI :-/

Not really. If you build in-source (which is usually not recommended) 
everything is just fine. If you build out-of-source, and the build dir is NOT 
a subdirectory if the source dir, a "linked resource" to the source files is 
created, so that works then too.

> Why aren't there options for generators? They could ask about the Makefile
> type and about creating that .project file in the source dir. The current
> way is really hard to sell to users. The above command line should be: $
> cmake -GEclipse ../certi_src
> The CDT4 is irrelevant and even hurts if JDT support for Java is ever
> added. 

I don't know the details, but wouldn't we need a different generator when 
creating a project file for Java ?

> It is also irrelevant that it uses Makefiles because that may also
> change?!

Well, exactly for the case that this might change it is not irrelevant, 
because then you have to tell cmake what you want, makefiles or ant or 
whatever together with eclipse project files.

> And if no make is available but nmake, why does the user actually
> have to specify that? On Linux, you don't even have a choice and this makes
> the name even more questionable.

Yes, it's a long name, but it's consistent and self-documenting :-)

> Since Makefiles are _very_ often used for generators, can't those be merged
> into _one_ option for -G  (with autodetection of present make variants) and
> adding another option that allow manually choosing one? Again a perfect fit
> for cmake-gui asking the user when needed:
>
> [in a cmake GUI]
> click configure
>  -> a dialog pops up asking for the generator
> choose "Eclipse"
>  -> a 2nd dialog ask for Eclipse project options eventually checking that
> the build directory fits the restrictions

I would have to check, but I think this may be possible in cmake-gui without 
changing the command line interface.

> choose a Makefile project
>  -> since several makes are available, a 3rd dialog pops up with a choice
>     between "nmake" "MSYS make" and "Unix make", maybe even with a help
> button explaining what "Unix make" actually means on Windows.
> That would improve usability of the cmake GUIs a _lot_.

I'd suggest you create feature requests for cmake-gui in the cmake bug tracker 
for that.

> The WIKI Eclipse entry is also hard to understand: in "Accessing the Source
> and Advanced Editing Features", it is not clear wether the extra definition
> is needed or not. It is missing a conclusion like: do it that way and
> you'll can do anything in Eclipse like normal.

It's a wiki, please create an account and improve the wording :-)

Alex