[CMake] What about...

[Brandon J. Van Every]

Thomas Zander wrote:
>
> Its because it slows me down a lot.
> When I change a couple of header files I suddenly see it reconfiguring for 
> no apparent reason.
> Its when I type 'make' it takes upto a minute before it actually starts 
> with the first gcc, even if I typed make moments before. (I just typed 
> 'make | less' this time).
>   

I saw your other post about massive slowdowns.  I haven't experienced 
that sort of thing myself, but Chicken is a small project so it's not 
likely I would.  Best to keep that issue separate in its own thread.

> Its that there is no feedback on what I am doing wrong when I alter the 
> CMakeLists.txt file,

When I type something wrong in CMakeLists.txt, and then I run CMakeSetup 
or CCMake again, I get dialog boxes telling me there's some error on 
such-and-such a line.  The errors have usually been helpful, if not always.

>  that combined with the 5 minutes it takes between 
> edit and output me frustrated when I need to add something.
>   

At times I have wanted file-level dependency targets for this reason.  I 
don't find myself inconvenienced if I'm building a main target, like 
"make silex."

Incidentally, my typical debugging technique is to look at the generated 
Makefiles to see what's wrong with them.  Usually there's a path 
qualification error.  Usually it's my error; sometimes I've found a bona 
fide CMake bug. 

> Its the constant looking for words like VERBOSE=1 which are not easy to 
> find.
>   
I consider the freely available documentation to be weak.  Meaning, it's 
not integrated, it's scattered across official documentation, the FAQ, 
and the wiki.  The $$ documentation might be better, I don't know.  The 
free help on this list is second to none, which is why I became a CMake 
pundit.  CMake may have problems, but the CMake team is really good at 
providing solutions.  I'd work on improving the CMake documentation 
myself, but my time is currently limited and what little I have goes 
towards improving the Chicken build.

>   
>>> cmake --projecthelp
>>> To print all 'make' targets the user can choose from.  Makes it easy
>>> to find things like 'make dox'.
>>>       
>> What build system uses this? 
>>     
> Java's ant (and I think maven as well).
>   

Not my universe.  --projecthelp may be a commonplace in Javaland, but 
CMake is C/C++ land for the most part.  I doubt that Ant conventions are 
familiar to this crowd.  Familiarity with ./configure conventions are 
far more likely.  CMake is designed to be a ./configure replacement, in 
the sense that it does the same jobs and does a much better job at 
cross-platform than ./configure does.  When seeking converts, "How does 
./configure do it?" is more apropos than "How does Ant do it."

>   
>> Although it could be a useful feature, 
>> I've never typed this before.  I have no natural training, inclination,
>> or habit to type this sort of thing.  I have typed "./configure --help"
>> plenty of times.
>>     
>
> Sure; but do note that this is not the same.  Configure is about 
> configuration options; I'm talking about make targets. Like 'all'. 
> 'install', 'check', 'docs' etc.
> Note that ant has a comment field for the custom targets that should be 
> shown so you only see those.
>   
I think it's a good idea, I just don't know that it should be called 
--projecthelp.  --targets seems a lot more logical to me.  Also, "cmake 
--help" should list the "--targets" command.  That way, people find 
information in a workflow that they're used to.  If CMakeSetup had a 
menu option to display the targets, that would be useful.  Incidentally, 
you can use graphviz to generate a graph of all the top-level targets.  
It won't show file-level dependencies though, and it's not a great 
interface for just getting in there on the command line.  Very useful 
when you're at the head-scratching stage of your project though, and you 
need to mull over all your dependencies at once.


>   
>>> (c)make /usr/local/foo/bar/baz.la
>>> will compile the sources needed only for that lib and link/install
>>> it. Tends to be faster then a 'make all install'.
>>>       
>> Top-level targets do have names.   For instance I can type "make
>> libchicken" or "make libchicken-static".  File-level dependencies don't
>> have convenient names, though.
>>     
>
> How can I find out what those targets are?
>   

Any toplevel target has the same name as in CMakeLists.txt, i.e. 
ADD_EXECUTABLE(chicken ${sourcefiles}) means you can type "make 
chicken".  ADD_LIBRARY(libchicken SHARED ${sourcefiles}) means you can 
type "libchicken".  You could also find out by inspecting the generated 
Makefiles.

>   
>>> A 'configure' script generator that will just convert between the
>>> (good old) configure and the cmake foo.  Makes it actually possible
>>> to discover what features there are without consulting online
>>> documentation ;)
>>>       
>> I'd like the whole autoconf toolchain to die. 
>>     
> This is not about autoconf!!
> Its just reusing (abusing?) a well known filename. Thats all.
>   
What I'm saying is, I don't want the CMake team to waste their time 
trying to chase ./configure's tail.  I'm not interested in converting 
scripts.  Myself, I'm interested in converting *people*.  The Right 
Thing To Do is to drop ./configure entirely.  I believe someone has some 
aides de porte floating around, but you have to understand a lot of 
stuff to do a conversion from ./configure to CMake.  I just don't see 
the point in trying to automate it, since it's all going to break 
anyways, and it's a huge task for no payoff.

>   
>> I don't want to read 
>> autoconf docs, or sort through Makefile.am or ./configure or its
>> bletcherous Makefile output anymore.   Forgive my underwhelming
>> enthusiasm for anything that makes a ./configure-oriented person's life
>> easier.  I'd rather you learn how to use CMake.
>>     
>
> This is not for the cmake loving people; this is for the millions of 
> people that have learned how to compile. And when they are stuck they 
> type './configure --help' to alter options.
> Only if you really want all those people to learn CMake as well; you have 
> a point.  Its obvious I would disagree with that :)
>   

I instigated the CMake-Promote mailing list.  I think ./configure is 
junk and I'm not interested in mollycoddling their habits beyond the 
superficial and easily doable.  Typing "cmake --help" is a good idea.  
Automagically allowing them to not learn anything about CMake is 
stupid.  It'll never work, and it doesn't improve CMake's technology or 
support.

The leverage is, you wants real cross-platform build support, then you 
learns some CMake.  There is a price to pay.  ./configure can't do the 
job.  If it could, nobody would learn anything else, CMake wouldn't 
exist.  But it does exist, because the GNU Project actively hates 
Microsoft and is deliberately unwilling to make it easy to use VC++ in 
their toolchain.  I've offered to collect up the sources from 2 VC++ 
front-ends to make it usable from autoconf.  They said, "Please go 
away.  It harms the GNU Project."  The advantage of CMake is it doesn't 
have GNU politics, as much as anything else.

> You indeed misunderstood me.
> The question is simply; why rely on make. (gmake or whatever). Why not 
> have a command that I type every time I want to start a build which has 
> nice commandline options and nice output specifically made for cmake.
>   

Because CMake is a build system generator, not a build system.  It 
generates *NATIVE* build systems, in many flavors.  It's up to you to 
use your native build system properly after it is generated.  It's 
beyond the scope of CMake to be a one stop interface for every build 
system imaginable.  As it stands, it does an awfully good job of 
generating consistent behavior across build systems.  For instance, in 
VC++ it produces an INSTALL project.  I click on that and hey voila, 
things install in Unixy fashion.  Even though most Windows developers 
don't do that and create their own installer programs.


> The problem with the use-(g)make decision is that you are stuck with using 
> unintuitive variable names to alter the build process.
>   

Then dump it and develop with VC++.  Or some other compiler with a 
better (or just different ;-) *NATIVE* build system.  I mean really, if 
you don't like gmake, how is that CMake's problem?  I think what you're 
really saying is you like Ant and you want things to be like you already 
know.  Meanwhile, huge numbers of people using GCC also use gmake, or 
their own kind of system-specific make.  As an Ant developer you might 
find any "make" repugnant, and probably rightly so.  But can your Ant 
generate Makefiles and native VC++ .sln files?  CMake can.


Cheers,
Brandon Van Every

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20060526/5e5e54e1/attachment.htm