Re: Re: Re: [CMake] What about...
Hi, > Von: Amitha Perera <[EMAIL PROTECTED]> > > On Mon 29 May 2006, William A. Hoffman wrote: > > There is a wxWidgets GUI in CVS. The question is, would a GUI make > > the configure command line people happy, or will there always be a > > group that wants a -- style command line like configure. > > A command-line configure is always important. Often, things are run as > batch jobs, with no user intervention, not even for the setup. (This > is often to exercise from-scratch builds.) Yes, and this is already possible right now. IMO when writing a script to do something it is more acceptable if the variable names are a bit long and a bit hard to type, compared to when entering the command manually on the command line. The main point here was about setting variables when invoking cmake manually. Bye Alex -- Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: Re: [CMake] What about...
On Mon 29 May 2006, William A. Hoffman wrote: > There is a wxWidgets GUI in CVS. The question is, would a GUI make > the configure command line people happy, or will there always be a > group that wants a -- style command line like configure. A command-line configure is always important. Often, things are run as batch jobs, with no user intervention, not even for the setup. (This is often to exercise from-scratch builds.) I realize that this wasn't the thrust of this thread, but wanted to quash this meme before it escapes. Of course, this is not to say that a GUI is not important. Amitha. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
On Monday 29 May 2006 18:00, William A. Hoffman wrote: > >There is ccmake on UNIX and (the more powerful) cmakesetup on Windows for > > this job. What is missing is something like a "qcmake", which would add a > > nice GUI to all available options. > > There is a wxWidgets GUI in CVS. The question is, would a GUI make the > configure command line people happy, or will there always be a group that > wants a -- style command line like configure. I'd say I would not profit from a GUI at all. There is no gain compared to ccmake. You will not be able to use it in shell scripts it and you cannot run it without interaction from the buildtool! -- Axel Roebel IRCAM Analysis/Synthesis Team ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: Re: [CMake] What about...
At 02:42 AM 5/29/2006, Alexander Neundorf wrote: >There is ccmake on UNIX and (the more powerful) cmakesetup on Windows for this >job. What is missing is something like a "qcmake", which would add a nice GUI >to all available options. There is a wxWidgets GUI in CVS. The question is, would a GUI make the configure command line people happy, or will there always be a group that wants a -- style command line like configure. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: Re: [CMake] What about...
> Von: Thomas Zander <[EMAIL PROTECTED]> > > On Friday 26 May 2006 17:55, you wrote: > > >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 am not sure about what you want here. > > Do you want something that will convert a configure script into cmake > > files? Do you want to convert cmake files into a configure script? > > What is the goal with this question? > > I have helped a set of people on irc to get started with koffice compiling > using cmake. They all had a lot of problems with the arcane variables > like the CMAKE_INSTALL_PREFIX and most people find that D in front a bit > weird a well. > > So; instead of letting the user (not only a developer!!) type > cmake ../../project -DCMAKE_INSTALL_PREFIX=$KDEDIR > there would be a command line tool (which I want to call configure, I > don't care if its shell script or perl or whatever) and that tool would > parse: > ./configure --prefix=foo > and execute the cmake equivalent that I typed above. > > Again; this is all focussed on making cmake more usable for the KDE > community; but I guess a lot of cmake users will benefit from it as well. > You have to remember that there are a lot of end users downloading the > sources and I can't in all honesty tell them its something better if they > have to type the above cmake PREFIX thing instead of using the configure > thing we had before. There is ccmake on UNIX and (the more powerful) cmakesetup on Windows for this job. What is missing is something like a "qcmake", which would add a nice GUI to all available options. Bye Alex -- Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
At 10:56 AM 5/28/2006, Thomas Zander wrote: >On Sunday 28 May 2006 15:39, James Mansion wrote: >> >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). >> >> That looks like make's performance problem doesn't it? > >I don't see how (but I'm no expert); cmake is the one scanning the whole >120Mb-sources project for some reason. See bug report: 2389 There are target/fast targets in the makefiles now that run without depend checking. They are currently only in the top level makefile, but they should do what you want. CMake has to make sure all the depend files exist, because make will fail if one of them is removed. >> Can I ask - you seem to be using command -line CMake only. Is there a >> reason why not to use one of the GUI apps that allow the user to >> specify the options etc? >I've tried ccmake; it helps a little. >There are no other GUI tools for unix, at least none that I know of. There is a wxWindows GUI, but it is not well tested. ccmake is the standard "GUI" for UNIX. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
On Sunday 28 May 2006 15:39, James Mansion wrote: > >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). > > That looks like make's performance problem doesn't it? I don't see how (but I'm no expert); cmake is the one scanning the whole 120Mb-sources project for some reason. See bug report: 2389 > Can I ask - you seem to be using command -line CMake only. Is there a > reason why not to use one of the GUI apps that allow the user to > specify the options etc? I've tried ccmake; it helps a little. There are no other GUI tools for unix, at least none that I know of. -- Thomas Zander pgp2z8WMzxqmh.pgp Description: PGP signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] What about...
>When I change a couple of header files I suddenly see it reconfiguring for >no apparent reason. Is the generated makefile thinking that there is a change in CMakeLists.txt somewhere? Surely cmake is actually out of the picture unless you tell it to rebuild the makefiles? >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). That looks like make's performance problem doesn't it? I seem to remember that the gcj team found a pathological case and had a fix for it. When I started to use bjam I was initially disturbed by the 'thinking' time at the start, but if you really want to model all the header dependencies of a big project then it seems somewhat unavoidable. Can I ask - you seem to be using command -line CMake only. Is there a reason why not to use one of the GUI apps that allow the user to specify the options etc? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
Thomas Zander wrote: But, to directly answer your assertion; the most human feeling of me feeling lost when there is something new to learn is not the reason for my emails here. I honestly find it counter productive of you to go for that excuse. Its soo easy. The suggestions I made here are an attempt to make cmake (which I _am_ using daily) get better. To make it the best by learning from all the build systems I have had to use over the years. Some of your suggestions, about ./configure interfaces, I've raised on CMake-Promote. Others, like "why can't I avoid make?" show a basic flaw in your thinking. CMake is a build system generator; that means the drill is always going to be CMake + some other build system. It's never going to be CMake by itself. So you will always be getting your hands dirty, even if CMake evolves to become the squeakiest cleanest thing around. If there's a build system out there that you think is really really cool, and you want to do a lot of work, you could write a CMake generator for it. Otherwise, you may have to face the reality that most build systems are not all that cool. I mean, there's nothing particularly great about Visual Studio .sln files. I just happen to have invested in that skill. Ditto Makefiles, for that matter. Ant didn't get me excited; I seem to have allergic reactions to XML. Once upon a time it came down to SCons vs. CMake, and CMake won. I won't be bothering with SCons until it's time to convert a SCons project, or SCons people. IIRC the KDE guys dumped SCons because it was too much of a PITA There is always the temptation to write a build system from scratch, in the paradigm of one's choice. For instance, a Chicken Scheme native build system. I've toured a lot of boutique open source languages... there are a lot of half-finished, half-assed build systems out there. Typically they're done by 1 guy who's just sorta poking along at his personal project. The list of build systems with a team, a community, and product maturity is rather short. In other words, I think you grouse about CMake because there isn't anything better out there. Otherwise you'd be using that Other Better Build System [TM]. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
On Friday 26 May 2006 21:00, Brandon J. Van Every wrote: > > 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? You have to understand where I come from; I'm a core developer of KWord; an application that doesn't even run on Windows (due to legal as well as technical reasons). I don't even have a Windows installation. (Haven't use the system in years, actually). > I think what you're > really saying is you like Ant and you want things to be like you > already know. Not ant; I just proposed one feature from it; the others came from unsermake. A python based tool KDE used before. But it still had to much auto*-isms so we removed that. But, to directly answer your assertion; the most human feeling of me feeling lost when there is something new to learn is not the reason for my emails here. I honestly find it counter productive of you to go for that excuse. Its soo easy. The suggestions I made here are an attempt to make cmake (which I _am_ using daily) get better. To make it the best by learning from all the build systems I have had to use over the years. CMake is not perfect, its still growing and I wish to help you guys by providing a list of things I would really appreciate to see. With that cleared up; you may want to go back to my initial mail in this thread and look at it anew :-) -- Thomas Zander pgpaI5sRBJggM.pgp Description: PGP signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
On Friday 26 May 2006 21:42, Brandon J. Van Every wrote: > Another issue is that an autoconf ./configure script typically relies > on libtool. You don't wanna go there. Read my other mails in this thread please; its the NAME ONLY I suggested to use. If the configure script is just 4kb and does nothing but provide a familiar front end to the cmake command (which I asserted earlier is not user friendly enough) then I'm happy. Nobody was suggesting to go back to auto* > As for functionality: the point of an autoconf ./configure is that you > don't need any special tool installed to run it. Actually; the point of configure is to provide a usable way to alter settings, especially in a project you have never compiled before. Otherwise we could all go back to editing config or even Makefiles. Any idea how much time was gained in total (over the last years) by not having users come and ask how to install it in /opt instead of the default /usr/local ? :-) -- Thomas Zander pgpnjlJGoXzey.pgp Description: PGP signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
At 05:03 PM 5/26/2006, Axel Roebel wrote: >cmake --help >"cmake variables" > --build_type Choose the type of build, options are: ... > --install_prefix Install path prefix, prepended onto install directories > --verbose_make If this value is on, makefiles will be > >project options >--USE_FOOBAR "use the foobar package" (FALSE) > >project variables >MYPROJECT_INSTALL_PREFIX /myinstall/location So, I guess cmake --help would run cmake in some sort of run but do not do anything mode. It would read all the list files and collect up all the cache variables, but not write the cache, or any build files. It would read any cache that was there, to get the current state of things. >If cmake is run and the options did change it could >return with error and display a warning: > >cmake --prefix=/myopt --USE_FOOBAR=1 >... snip >warning: configuration options changed >see new choices with cmake --help The warning is not a bad idea, and the logic is in cmake -i. >Which means the help should take into account the current >settings. > >-- >Axel Roebel >IRCAM Analysis/Synthesis Team >___ >CMake mailing list >CMake@cmake.org >http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
On Friday 26 May 2006 21:48, [EMAIL PROTECTED] wrote:
> I think it's a very good idea to add "cmake --prefix=foo" because 1
> gazillion ./configure users would get warm squishy feelings from such
> functionality. Although, it could become an Uncanny Valley problem.
> The closer you get to representing ./configure, the more complaints
> about how it's not ./configure! So it may not be as good an idea as one
> would think. It might be better to train people to use CMakeSetup and
> CCMake. But that I admit is a GUI vs. command line battle. Maybe it's
> advisable to beef up CMake's command line usability, if only for
> marketing purposes.
I think
configure --prefix=
has become so standardized and is triggering reflexes, that it would be a good
idea to make use of these customs
As well I am personally rather accustomed to the command line
so I would prefere a better command line support.
So instead of
> $ ./cconfigure --help
> --cmake_build_type Choose the type of build, options are: ...
> --cmake_install_prefix Install path prefix, prepended onto install
>
> directories
> --cmake_verbose_makefile If this value is on, makefiles will be
> generated ...
and given that
>option(USE_FOOBAR "use the foobar package" FALSE)
>if(USE_FOOBAR)
> option(USE_FOOBAR_SUBTASK "use the foobar subtask option" FALSE)
>endif(USE_FOOBAR)
and
>set(MYPROJECT_INSTALL_PREFIX /myinstall/location CACHE PATH)
>set(CMAKE_INSTALL_PREFIX ${MYPROJECT_INSTALL_PREFIX} CACHE INTERNAL)
how about
cmake --help
"cmake variables"
--build_type Choose the type of build, options are: ...
--install_prefix Install path prefix, prepended onto install directories
--verbose_make If this value is on, makefiles will be
project options
--USE_FOOBAR "use the foobar package" (FALSE)
project variables
MYPROJECT_INSTALL_PREFIX /myinstall/location
If cmake is run and the options did change it could
return with error and display a warning:
cmake --prefix=/myopt --USE_FOOBAR=1
... snip
warning: configuration options changed
see new choices with cmake --help
Which means the help should take into account the current
settings.
--
Axel Roebel
IRCAM Analysis/Synthesis Team
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
Filipe Sousa wrote: There is always ccmake and cmakeseup. Another option is to create a tool called "cconfigure" for those who like configure scripts. That shouldn't be to hard to implement. cconfigure --help would show the same options as ccmake: $ ./cconfigure --help --cmake_build_type Choose the type of build, options are: ... --cmake_install_prefix Install path prefix, prepended onto install directories --cmake_verbose_makefile If this value is on, makefiles will be generated ... [more options] $ ./configure --cmake_build_type=release --cmake_install_prefix=/usr --cmake_verbose_make_file=true ~/projects/my_project $ make $ make install "cconfigure" strikes me as a really bad naming choice. People will forever be typing "configure" and wondering what's wrong. You even did it yourself! As for functionality: the point of an autoconf ./configure is that you don't need any special tool installed to run it. If you have a Bourne shell, that's all you need. Now, I suppose CMake could generate a ./configure script of sorts, that expects a Makefile on a Unixy system and doesn't need any additional tools to run. Like, CMake itself isn't needed. This would be entirely comparable to what autoconf actually does. You use autoconf to generate ./configure, then you throw autoconf away during the actual build. The problem is, I bet CMake can't do all of the detection stuff with just Bourne shell code. It's going to need to interpret CMake code, which means you'll need to have CMake installed, which means you've defeated the purpose of not needing any special tool installed. If the user has got CMake, might as well train them to type "cmake --whatever". Another issue is that an autoconf ./configure script typically relies on libtool. You don't wanna go there. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
Thomas Zander wrote: I have helped a set of people on irc to get started with koffice compiling using cmake. They all had a lot of problems with the arcane variables like the CMAKE_INSTALL_PREFIX and most people find that D in front a bit weird a well. So; instead of letting the user (not only a developer!!) type cmake ../../project -DCMAKE_INSTALL_PREFIX=$KDEDIR You know there are CMakeSetup and CCMake... to quote Boromir, are you sure you do not suffer needlessly? there would be a command line tool (which I want to call configure, I don't care if its shell script or perl or whatever) and that tool would parse: ./configure --prefix=foo and execute the cmake equivalent that I typed above. I think better policy is to have a ./configure that does nothing and tells the user this is a CMake build, not a ./configure build. Also, you can't just claim the ./configure namespace gratuitously. It is entirely valid to have both a CMake and a ./configure build of the same project. Chicken is currently in that position now. I'm working on killing ./configure, but I'm far from there yet. The transition will take many months. The new build has to prove itself to be 100% reliable, and then some, before old build goes away. I think it's a very good idea to add "cmake --prefix=foo" because 1 gazillion ./configure users would get warm squishy feelings from such functionality. Although, it could become an Uncanny Valley problem. The closer you get to representing ./configure, the more complaints about how it's not ./configure! So it may not be as good an idea as one would think. It might be better to train people to use CMakeSetup and CCMake. But that I admit is a GUI vs. command line battle. Maybe it's advisable to beef up CMake's command line usability, if only for marketing purposes. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
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 al
Re: [CMake] What about...
On Friday 26 May 2006 18:02, frederic heem wrote: > Actually, I wonder why CMAKE_VERBOSE_MAKEFILE is not set to TRUE by > default, each time, I have to set it manually and I find it quite > annoying. Everyone I know gave a sigh of relieve when unsermake (2 years ago) introduced the concept of showing minimal output. Unsermake does have a really good feature I'd like to see in cmake/make, though. It shows the full commandline of the last command when the build fails. This means that if you are missing an include dir it doesn't require you to restart the build with the verbose flag on since it shows the actual command that failed and thus the include flags etc. Best of both worlds. -- Thomas Zander pgp78AWYw8drG.pgp Description: PGP signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
At 12:13 PM 5/26/2006, Thomas Zander wrote:
>On Friday 26 May 2006 17:55, you wrote:
>> >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 am not sure about what you want here.
>> Do you want something that will convert a configure script into cmake
>> files? Do you want to convert cmake files into a configure script?
>> What is the goal with this question?
>
>I have helped a set of people on irc to get started with koffice compiling
>using cmake. They all had a lot of problems with the arcane variables
>like the CMAKE_INSTALL_PREFIX and most people find that D in front a bit
>weird a well.
>
>So; instead of letting the user (not only a developer!!) type
> cmake ../../project -DCMAKE_INSTALL_PREFIX=$KDEDIR
>there would be a command line tool (which I want to call configure, I
>don't care if its shell script or perl or whatever) and that tool would
>parse:
>./configure --prefix=foo
>and execute the cmake equivalent that I typed above.
>
>Again; this is all focussed on making cmake more usable for the KDE
>community; but I guess a lot of cmake users will benefit from it as well.
>You have to remember that there are a lot of end users downloading the
>sources and I can't in all honesty tell them its something better if they
>have to type the above cmake PREFIX thing instead of using the configure
>thing we had before.
>
>Hope that explains it better :)
Sure, that does explain it better. And to be honest, the command line
was not how cmake was intended to be used. ccmake, cmake -i, or CMakeSetup
on windows provides a much better user experience. Part of the problem
is the ability of a cmake run to create new options each time an option is
changed.
It is more of an iterative process. Before cmake is run on a project, there
is really no way to tell all of the options. Even standard options like
CMAKE_INSTALL_PREFIX could have been changed by the project.
Something like this:
set(MYPROJECT_INSTALL_PREFIX /myinstall/location CACHE PATH)
set(CMAKE_INSTALL_PREFIX ${MYPROJECT_INSTALL_PREFIX} CACHE INTERNAL)
In which case changing CMAKE_INSTALL_PREFIX on the command line will not
do anything, but what you really need to change MYPROJECT_INSTALL_PREFIX.
All of this works with ccmake or CMakeSetup, or even cmake -i. But,
you can also have the case that by turning on a variable, it creates more
variables.
option(USE_FOOBAR "use the foobar package" FALSE)
if(USE_FOOBAR)
option(USE_FOOBAR_SUBTASK "use the foobar subtask option" FALSE)
endif(USE_FOOBAR)
Until USE_FOOBAR is TRUE, the option USE_FOOBAR_SUBTASK is not even an option.
Maybe a better way to tell folks to use cmake, is to use ccmake.
I agree that the -DFOO=VALUE is awkward, and I never use it myself, prefering
ccmake or CMakeSeutp.
I use make edit_cache most of the time.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
Lloyd Hilaiel wrote: > Yo Thomas, > > We use cmake to build a large project (10 or so different SDKs). > > In our case, we too wanted a cmakebuild tool, so we wrote one. > It wraps the native build tools with a higher level of commands > "build debug" "build release" "run tests" "package SDKs" etc. > > Some of the commands for this build tool are very specific to our > product and our problems others are perhaps generalizable. I had > never thought this was something that cmake would provide, as I as a > developer usually use native build tools directly, while the consumers > of our software use the lightweight wrapper to build our stuff. > > As an interim solution you could provide a similar tool for people > consuming KDE, and perhaps while writing the tool it would crystallize > a set of features that would go into a generic "cmakebuild" tool. > > I'm still curious if there's enough there in the universal appeal bucket > to make a general tool out of it, and am not familiar with what > features/code cmake (ctest) already have built in to facilitate this. > > I would be willing to contrast our "cmakebuild" tool with what you > come up with to try to identify the overlap and sketch out the > commands of such a general tool as an experiment... > > best, > lloyd > There is always ccmake and cmakeseup. Another option is to create a tool called "cconfigure" for those who like configure scripts. That shouldn't be to hard to implement. cconfigure --help would show the same options as ccmake: $ ./cconfigure --help --cmake_build_type Choose the type of build, options are: ... --cmake_install_prefix Install path prefix, prepended onto install directories --cmake_verbose_makefile If this value is on, makefiles will be generated ... [more options] $ ./configure --cmake_build_type=release --cmake_install_prefix=/usr --cmake_verbose_make_file=true ~/projects/my_project $ make $ make install -- Filipe Sousa signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
Filipe Sousa wrote: frederic heem wrote: On Friday 26 May 2006 17:52, Craig Bradney wrote: Actually, I wonder why CMAKE_VERBOSE_MAKEFILE is not set to TRUE by default, each time, I have to set it manually and I find it quite annoying. If CMAKE_VERBOSE_MAKEFILE was set to TRUE by default it would be quite annoying to others that like the way it is. Add to your CMakeLists.txt SET(CMAKE_VERBOSE_MAKEFILE TRUE) Setting CMAKE_VERBOSE_MAKEFILE to true in our top level CMakeLists.txt file is what we do for our project. Then if you don't want all the chatter from make, you simply add a -s "for silent". The makefiles this only tell you what it is doing "Building YYY.o" or "Linking ZZZ.so" etc.. Setting it up as a cached variable will also allow it to be exposed in the configurator (ccmake or what not). "gmake -s" is your friend. When you need or want the extra chatter, just remove the -s. James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
Yo Thomas, We use cmake to build a large project (10 or so different SDKs). In our case, we too wanted a cmakebuild tool, so we wrote one. It wraps the native build tools with a higher level of commands "build debug" "build release" "run tests" "package SDKs" etc. Some of the commands for this build tool are very specific to our product and our problems others are perhaps generalizable. I had never thought this was something that cmake would provide, as I as a developer usually use native build tools directly, while the consumers of our software use the lightweight wrapper to build our stuff. As an interim solution you could provide a similar tool for people consuming KDE, and perhaps while writing the tool it would crystallize a set of features that would go into a generic "cmakebuild" tool. I'm still curious if there's enough there in the universal appeal bucket to make a general tool out of it, and am not familiar with what features/code cmake (ctest) already have built in to facilitate this. I would be willing to contrast our "cmakebuild" tool with what you come up with to try to identify the overlap and sketch out the commands of such a general tool as an experiment... best, lloyd /-- Around 6 PM on [05/26/06] ([EMAIL PROTECTED]) "said" -- >On Friday 26 May 2006 17:55, you wrote: >> >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 am not sure about what you want here. >> Do you want something that will convert a configure script into cmake >> files? Do you want to convert cmake files into a configure script? >> What is the goal with this question? > >I have helped a set of people on irc to get started with koffice compiling >using cmake. They all had a lot of problems with the arcane variables >like the CMAKE_INSTALL_PREFIX and most people find that D in front a bit >weird a well. > >So; instead of letting the user (not only a developer!!) type > cmake ../../project -DCMAKE_INSTALL_PREFIX=$KDEDIR >there would be a command line tool (which I want to call configure, I >don't care if its shell script or perl or whatever) and that tool would >parse: > ./configure --prefix=foo >and execute the cmake equivalent that I typed above. > >Again; this is all focussed on making cmake more usable for the KDE >community; but I guess a lot of cmake users will benefit from it as well. >You have to remember that there are a lot of end users downloading the >sources and I can't in all honesty tell them its something better if they >have to type the above cmake PREFIX thing instead of using the configure >thing we had before. > >Hope that explains it better :) >-- >Thomas Zander >___ >CMake mailing list >CMake@cmake.org >http://www.cmake.org/mailman/listinfo/cmake -- [EMAIL PROTECTED] | the of the organization appreciate within http://docs.yahoo.com/info/values/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
frederic heem wrote: > On Friday 26 May 2006 17:52, Craig Bradney wrote: > Actually, I wonder why CMAKE_VERBOSE_MAKEFILE is not set to TRUE by default, > each time, I have to set it manually and I find it quite annoying. If CMAKE_VERBOSE_MAKEFILE was set to TRUE by default it would be quite annoying to others that like the way it is. Add to your CMakeLists.txt SET(CMAKE_VERBOSE_MAKEFILE TRUE) -- Filipe Sousa signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
On Friday 26 May 2006 17:55, you wrote: > >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 am not sure about what you want here. > Do you want something that will convert a configure script into cmake > files? Do you want to convert cmake files into a configure script? > What is the goal with this question? I have helped a set of people on irc to get started with koffice compiling using cmake. They all had a lot of problems with the arcane variables like the CMAKE_INSTALL_PREFIX and most people find that D in front a bit weird a well. So; instead of letting the user (not only a developer!!) type cmake ../../project -DCMAKE_INSTALL_PREFIX=$KDEDIR there would be a command line tool (which I want to call configure, I don't care if its shell script or perl or whatever) and that tool would parse: ./configure --prefix=foo and execute the cmake equivalent that I typed above. Again; this is all focussed on making cmake more usable for the KDE community; but I guess a lot of cmake users will benefit from it as well. You have to remember that there are a lot of end users downloading the sources and I can't in all honesty tell them its something better if they have to type the above cmake PREFIX thing instead of using the configure thing we had before. Hope that explains it better :) -- Thomas Zander pgpfuA41RkeWL.pgp Description: PGP signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
At 12:02 PM 5/26/2006, frederic heem wrote: >Actually, I wonder why CMAKE_VERBOSE_MAKEFILE is not set to TRUE by default, >each time, I have to set it manually and I find it quite annoying. It is a matter of taste. Some folks like to see pages and pages of output even if it builds nothing. Some folks only want to see what is being compiled and do not care about how it is being compiled. I think it is usually developers that like to see everything, and they are more likely to know how to change a setting. But users that just want to build the software, only want to build it and don't really care what is going on. It was felt that there are more users than developers, so that is why the default is off. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
On Friday 26 May 2006 17:52, Craig Bradney wrote: > On Friday 26 May 2006 17:05, Thomas Zander wrote: > > On Friday 26 May 2006 16:24, you wrote: > > > I am not sure I understand what you want to type to do the build? > > > > williamMake would do; of wmake if you want. :) > > Bottom line; I don't care what the name is as long as it _can_ be made > > more usable. Which is impossible with make. > > > > You apparently are completely used to the idea of having to type really > > long, non intuitive (at least I would never come up with them) and all > > capitals variable names; but I don't like um. > > And as I know a little about usability I know that the best way to solve > > the issue is to make it easier to find and type them. > > My first solution there would be to have to most used ones part of a new > > imaginary command; > > wmake > > with options like: > > wmake -v > > which ends up doing the same as 'make VERBOSE=true' but be easier to find > > since its visible when the user types 'wmake --help' > > You can set this in the CMakeLists.txt file if you want so you dont have > type it on cmd line.. > set(CMAKE_VERBOSE_MAKEFILE TRUE) > Actually, I wonder why CMAKE_VERBOSE_MAKEFILE is not set to TRUE by default, each time, I have to set it manually and I find it quite annoying. > Craig > ___ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake -- * - * - * Frederic Heem Software Designer R&D - Telsey SpA Telecommunications Viale Industria, 1 31055 Quinto di Treviso (TV) ITALY Tel. direct phone: (+39) 0422 377819 Tel. (+39) 0422 377711 Fax. (+39) 0422 470920 website ==> www.telsey.it ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
At 11:05 AM 5/26/2006, Thomas Zander wrote: >On Friday 26 May 2006 16:24, you wrote: >> I am not sure I understand what you want to type to do the build? > >williamMake would do; of wmake if you want. :) >Bottom line; I don't care what the name is as long as it _can_ be made >more usable. Which is impossible with make. OK, so what you want is a cmake front end to the build process. CMake is not a build tool, it just generates build files for various build tools, and make happens to be one of them. However, it would be possible to add a layer to cmake that actually does the build. Currently we do run build processes from ctest, so we have the code to do that. I have thought it might not be a bad addition to cmake. I mistakenly thought you wanted to know how to get things done with 2.4.2, and I was trying to help you. However, this is really a feature request. You want a new tool (say cmakebuld) that works something like this: cmakebuild help // list all the targets cmakebuild install// run the install target cmakebuild build // build all targets cmakebuild build -verbose // build all with VERBOSE set to true cmakebuild build target // build a target That is all not very hard to do, and would work with all of the generators, even the IDE generators. However, this request: >cmake --compile-jobs=n >similar to -j but only for compile jobs, so it will not make multiple >link/etc jobs be run at the same time. is much harder. Since cmake is not a build tool, it never builds a file, it only generates the build files for other tools, we are limited to the capabilities of the tools we are using. Some of the generators do not support parallel builds. gmake does with -j, and we are looking into making it not link multiple things at the same time, and do have some ideas on how to do that. So, cmakebuild -jobs N could be made to work if you were using gmake. So, it would be possible to create cmakebuild. The question is how useful would it be. People that are used to the standard configure; make projects most likely are somewhat comfortable with the command line of make. People that do not like the command line of make, can currently use Kdevelop, Xcode or MS Visual studio generators for CMake. The advantage of creating a tool like this, would be that you could create a single set of docs that would work on any platform, with any build tool. >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 am not sure about what you want here. Do you want something that will convert a configure script into cmake files? Do you want to convert cmake files into a configure script? What is the goal with this question? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
On Friday 26 May 2006 17:05, Thomas Zander wrote: > On Friday 26 May 2006 16:24, you wrote: > > I am not sure I understand what you want to type to do the build? > > williamMake would do; of wmake if you want. :) > Bottom line; I don't care what the name is as long as it _can_ be made > more usable. Which is impossible with make. > > You apparently are completely used to the idea of having to type really > long, non intuitive (at least I would never come up with them) and all > capitals variable names; but I don't like um. > And as I know a little about usability I know that the best way to solve > the issue is to make it easier to find and type them. > My first solution there would be to have to most used ones part of a new > imaginary command; > wmake > with options like: > wmake -v > which ends up doing the same as 'make VERBOSE=true' but be easier to find > since its visible when the user types 'wmake --help' You can set this in the CMakeLists.txt file if you want so you dont have type it on cmd line.. set(CMAKE_VERBOSE_MAKEFILE TRUE) Craig ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
Thomas Zander wrote: On Friday 26 May 2006 16:24, you wrote: I am not sure I understand what you want to type to do the build? williamMake would do; of wmake if you want. :) Bottom line; I don't care what the name is as long as it _can_ be made more usable. Which is impossible with make. [snip] And as I know a little about usability I know that the best way to solve the issue is to make it easier to find and type them. My first solution there would be to have to most used ones part of a new imaginary command; wmake with options like: wmake -v which ends up doing the same as 'make VERBOSE=true' but be easier to find since its visible when the user types 'wmake --help' [snip] The suggestion is to have a command, cmake in the quoted part, wmake in the suggestion above, that allows the developer to have a more usability friendly front end. CMake is a build system *generator*, not a build tool. It generates files for *native* build tools that do not come with CMake. The most common native tool on unix is..."make"! We have put some effort into making the Makefile interface nicer but as you said it is somewhat hopeless to make "make" pretty. If you do not like the command line interface provided by make then you have two choices: 1.) Use another interface such as KDevelop and the corresponding generator in CMake. 2.) Find or write your own native build tool with the command line interface of your choice and contribute a generator for it to CMake. This could be an unsermake generator for example. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
On Friday 26 May 2006 16:24, you wrote: > I am not sure I understand what you want to type to do the build? williamMake would do; of wmake if you want. :) Bottom line; I don't care what the name is as long as it _can_ be made more usable. Which is impossible with make. You apparently are completely used to the idea of having to type really long, non intuitive (at least I would never come up with them) and all capitals variable names; but I don't like um. And as I know a little about usability I know that the best way to solve the issue is to make it easier to find and type them. My first solution there would be to have to most used ones part of a new imaginary command; wmake with options like: wmake -v which ends up doing the same as 'make VERBOSE=true' but be easier to find since its visible when the user types 'wmake --help' If you read my email again you can see that you misinterpreted almost all my suggestions as they are all about this concept and not request for 'how do I accomplish task X in cmake lingo' For example: > >cmake install > >to call 'make install' (naturally this goes for all targets) > > cmake -P cmake_install.cmake > (that is what is run when you do make install) Its not *just* about 'install' Read my question again. And your answer hardly is easier to discover. (I bet you had to look that up! :) The suggestion is to have a command, cmake in the quoted part, wmake in the suggestion above, that allows the developer to have a more usability friendly front end. Since make currently is, well, I won't start cursing here :-) Thanks -- Thomas Zander pgpLWIxQTUAAP.pgp Description: PGP signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
At 07:30 AM 5/26/2006, Thomas Zander wrote: >Hiya; >In KDE (including KOffice) we switched to cmake, as you are probably >aware. I naturally like the speedups we got in linking etc. but I like >the less then stellar usability of the cmake solution a lot less. (at >this point I would gladly go back to the slower linking, to be honest) > >I'm wondering if you guys can look over some features I have seen/used in >other make systems and see if you can steal some ideas. I would love to >know what you guys think of these and if/when you can get them in cmake. > >cmake --projecthelp >To print all 'make' targets the user can choose from. Makes it easy to >find things like 'make dox'. After cmake is run, you can do make help It will show all the targets to choose from. >cmake install >to call 'make install' (naturally this goes for all targets) cmake -P cmake_install.cmake (that is what is run when you do make install) >cmake --compile-jobs=n >similar to -j but only for compile jobs, so it will not make multiple >link/etc jobs be run at the same time. This is hard to do, but is on the TODO list. Currently, make -j is our only parallel approach. >cmake -v >for make VERBOSE=1 cmake -DCMAKE_VERBOSE_MAKEFILE=TRUE should do the trick. >(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'. make help will show the targets available. There are now also, fast targets that do not do the whole check. make library/fast >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 ;) That is very hard to do as configure scripts can have almost anything in them. >Finally; I searched the FAQ / docs but I found no answer to a nagging >question of mine. Why oh why did you guys choose to use make as the >command the developer has to type. That decision leaves you without any >options to make the user experience any better. I honestly can't tell >people to type 'make VERBOSE=1' and not apologize in the same sentence >about the horrible usability of that. I am not sure I understand what you want to type to do the build? If you build a makefile based project you run make to build it. If you build an Xcode project your run the Xcode GUI, if you build Kdevelop, you run that GUI, and if you do visual studio, you run that GUI. With autoconf, you run make. What would you want to type to build? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
On Friday 26 May 2006 14:03, Brandon J. Van Every wrote: > Thomas Zander wrote: > > Hiya; > > In KDE (including KOffice) we switched to cmake, as you are probably > > aware. I naturally like the speedups we got in linking etc. but I > > like the less then stellar usability of the cmake solution a lot > > less. (at this point I would gladly go back to the slower linking, to > > be honest) > > Is this because the CMake workflow is deficient, or because it's not > what you're already used to? I don't think it's reasonable to say, "I > don't like learning anything new." 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). Its that there is no feedback on what I am doing wrong when I alter the CMakeLists.txt file, that combined with the 5 minutes it takes between edit and output me frustrated when I need to add something. Its the constant looking for words like VERBOSE=1 which are not easy to find. > > 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). > 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. > > (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? I agree its not the most convenient name, but as a developer you tend to know what library you are working on. Anyway; typing 'make kwordprivate' does not install it; and make install links all libs again so thats not a solution currently. > > 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. > 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 :) > > Finally; I searched the FAQ / docs but I found no answer to a nagging > > question of mine. Why oh why did you guys choose to use make as the > > command the developer has to type. That decision leaves you without > > any options to make the user experience any better. I honestly can't > > tell people to type 'make VERBOSE=1' and not apologize in the same > > sentence about the horrible usability of that. > > I don't understand your question. CMake generates several different > types of native build files, i.e. make, nmake, Visual Studio .sln > files, and others. The .sln files can be run from inside Visual > Studio, or they can be run on the command line with "devenv." I > believe if your make is actually gmake, and you have an appropriate > link for that on your system (Windows may not), you could type "gmake." 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. The problem with the use-(g)make decision is that you are stuck with using unintuitive variable names to alter the build process. -- Thomas Zander pgpR1ChzpzKNg.pgp Description: PGP signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What about...
Thomas Zander wrote: Hiya; In KDE (including KOffice) we switched to cmake, as you are probably aware. I naturally like the speedups we got in linking etc. but I like the less then stellar usability of the cmake solution a lot less. (at this point I would gladly go back to the slower linking, to be honest) Is this because the CMake workflow is deficient, or because it's not what you're already used to? I don't think it's reasonable to say, "I don't like learning anything new." I'm wondering if you guys can look over some features I have seen/used in other make systems and see if you can steal some ideas. I would love to know what you guys think of these and if/when you can get them in cmake. 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? 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. cmake install to call 'make install' (naturally this goes for all targets) I don't understand the purpose of this in a CMake workflow. Generally, one runs either CMakeSetup or CCMake. Unless you are primarily concerned with batch jobs, and you're very confident they'll build. (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. 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. 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. Finally; I searched the FAQ / docs but I found no answer to a nagging question of mine. Why oh why did you guys choose to use make as the command the developer has to type. That decision leaves you without any options to make the user experience any better. I honestly can't tell people to type 'make VERBOSE=1' and not apologize in the same sentence about the horrible usability of that. I don't understand your question. CMake generates several different types of native build files, i.e. make, nmake, Visual Studio .sln files, and others. The .sln files can be run from inside Visual Studio, or they can be run on the command line with "devenv." I believe if your make is actually gmake, and you have an appropriate link for that on your system (Windows may not), you could type "gmake." Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] What about...
Hiya; In KDE (including KOffice) we switched to cmake, as you are probably aware. I naturally like the speedups we got in linking etc. but I like the less then stellar usability of the cmake solution a lot less. (at this point I would gladly go back to the slower linking, to be honest) I'm wondering if you guys can look over some features I have seen/used in other make systems and see if you can steal some ideas. I would love to know what you guys think of these and if/when you can get them in cmake. cmake --projecthelp To print all 'make' targets the user can choose from. Makes it easy to find things like 'make dox'. cmake install to call 'make install' (naturally this goes for all targets) cmake --compile-jobs=n similar to -j but only for compile jobs, so it will not make multiple link/etc jobs be run at the same time. cmake -v for make VERBOSE=1 (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'. 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 ;) Finally; I searched the FAQ / docs but I found no answer to a nagging question of mine. Why oh why did you guys choose to use make as the command the developer has to type. That decision leaves you without any options to make the user experience any better. I honestly can't tell people to type 'make VERBOSE=1' and not apologize in the same sentence about the horrible usability of that. -- Thomas Zander pgpTOrdnhOJhr.pgp Description: PGP signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
