[CMake] Setting the cmake compiler...

[Brandon J. Van Every]

Peter Soetens wrote:
> Quoting Brad King <brad.king at kitware.com>:
>>
>> Any time you change the compiler you have to wipe out the build tree and
>> start from scratch.  Try running CMake like this instead:
>>
>> $ rm -rf build; mkdir build; cd build
>> $ CC=gcc CXX=g++ cmake ..
>>
>
> I had read this comment before, but I couldn't believe it was supposed 
> to be common practice.This erases your complete configuration. Say a 
> developer first uses ccmake to configure the build (paths, 
> options,...) and then discovers the compiler needs to be changed, he 
> has to start all over ?

Well you sure as heck aren't going to intermix compilers, are you?  So 
paths and options are the only loss.  If there aren't many paths or 
options, then it's not a big deal.  The user can type a couple of things 
if they want to diddle dawdle about what compiler they're using.  If 
there are tons of paths and options, that the user is configuring 
manually with CCMake... well, I'd need to see an example of that, before 
pronouncing judgment on whether such a project is well- or ill-formed.


>   What's the rationale behind this ?

In general, it's justified paranoia.  You can often rebuild just 
changing an option, but if it gives you problems, you wipe the whole 
build and start clean.  CMake is pretty good at handling option changes, 
but it isn't perfect, hence the paranoia.

For CXX specifically, I'll wager the generated makefile is using 
hardwired absolute paths for the compiler?  Otherwise if it were using 
${CXX} everywhere, then changing the compiler wouldn't necessarily 
change the build configuration.  If it was a similar enough class of 
compiler, i.e. another GCC variant.

>
> Another 'bug' is that you can edit the CMAKE_CXX_COMPILER field in 
> ccmake, but when you run 'c', the field is overwritten again. All very 
> annoying. Maybe a SET( LOCKED ...) flag could be added such that 
> fields are not user editable.

You could enter a bug in the bugtracker if it's not there already.

>
>
> Aren't these 'little details' a big complaint of beginning cmake users ?


Sure.  But some of 'em only get solved by bugfixes, they're not strictly 
documentation issues.  I'm happiest when CMake ships a new patch 
release, because then there's less to explain to people.


> Especially if <http://www.cmake.org/Wiki/CMake_Useful_Variables> does 
> not mention these 'caveat's.


Well, since it's a wiki, you could add what you think are the caveats.  
Also put a reference to a bug in the bugtracker, whether you entered it 
or someone else.  And, make a link from the bugtracker to the wiki, with 
a statement saying, "I've documented this on the wiki also," so that 
people know when it's fixed / closed they should edit the wiki too.


>
> Thanks for helping me out,
> Peter

No problemo.  I'm into documentation that relieves newbie frustration.  
I'm aware, however, that we frequently have to write it ourselves on the 
wiki.  Or put documentation bugs, or documentation feature requests, in 
the bug tracker.  The mailing list doesn't reposit "good ideas," because 
there are too many of them.  I find that when I actually file bugs about 
these things, they do come to resolution eventually.  For instance, the 
offline docs in CMake CVS now have weblinks to the online docs. (Thanks 
Brad, IIRC.)


Cheers,
Brandon Van Every