Re: [CMake] Re: Parsing cmake command line parameters
Gonzalo Garramuño wrote:
Alexander Neundorf wrote:
Yes.
In KDE we have the macro MACRO_OPTIONAL_FIND_PACKAGE(), which adds an
option around the find_package() call:
http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/MacroOptionalFindPackage.cmake?revision=520790view=markup
Beside that, it is really just a matter of syntax whether you do
--enable-build-this
or -DENABLE_BUILD_THIS=TRUE
No, it isn't *just* a matter of syntax (which is also horrible, btw). It
is also a matter of documentation. -DENABLE_BUILD_THIS is documented
nowhere. configure --enable-build-this is documented if you run it
without any flag.
But... what if we have this extreme case?
IF(${CMAKE_BUILD_TYPE} STREQUAL Debug)
add_command_line_parameter(whatever)
ENDIF()
So? You don't get the option if you don't run a debug build. As simple
as that. A better syntax for add_option would be:
add_option( NAME TYPE HELP [OPTS] )
with OPTS being:
CONFIGURATION Debug
REQUIRED someotheroption
That avoids the need for if-thens.
I have (currently) two ideas:
either a special file, e.g. CMakeCustomArgs.txt, which in some way
sets up the custom command line parameters.
Yuck!
Or have a cmake modules, which handles this stuff, and which also
creates a custom target help-args or something like that, which
prints the available args. This would not be available before cmake
has successfully run.
Yuck! Why wouldn't it be available? Have you guys used premake at all?
The premake.lua is ALWAYS read. If no parameter is passed, there's a
dry run of the file, and help with options get spit.
It is gorgeous.
Sure, lua runs 10 times faster than the cmake language does, but that's
a different story.
I don't think this has anything to do with speed. To find all the
options in a project you have to parse the entire project, no way around
it. The speed problem comes in because of try-compile/try-run stuff.
Just parsing cmake is fast. But, if we run the compiler 100 times then
well it has NOTHING to do with language! If we don't run all the try
stuff, then we can not accurately parse the while project as variables
will be set. The real answer is that the command line is a poor
interface to cmake projects. The new QT GUI is a much better way to go.
Due to the iterative nature of the cmake process running cmake once on
a project may run differently than running it twice on the project.
ccmake and the GUI's avoid this problem by not allowing generation of
projects until there are no new options. But, please, please stop
trying to make this a language issue!
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Parsing cmake command line parameters
Bill Hoffman escreveu: will be set. The real answer is that the command line is a poor interface to cmake projects. The new QT GUI is a much better way to go. Don't say that... I think that a command line interface capability should be pursued, even if it's non-optimal. God knows if someone have to call cmake within a shell script. Presenting a ccmake screen in this situation is not acceptable. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Parsing cmake command line parameters
On Dec 19, 2007 9:09 AM, Bill Hoffman [EMAIL PROTECTED] wrote: However, this has been discussed many times over the years, and I still don't think a good solution has been found. Worse Is Better. From a marketing standpoint, this issue could have been solved a long time ago. You want people coming from the Autoconf world to get enough of a warm squishy feeling that they stick with CMake. Over time they learn how to use CMake properly, using CMakeSetup / CCMake, and forget their command line ways. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Parsing cmake command line parameters
James Bigler wrote:
What is it that people want beyond -DBUILD_THIS_THAT_WHATEVER:BOOL=TRUE
could provide?
Do they want: --enable-build_this_that_whatever?
People that work with embedded systems might want a stripped down
version of a library, for instance. So disabling features might be a
strong use case.
I also don't understand why we have to parse the whole CMakeLists.txt
structure. We should treat these command line args like we cache
variables like CPack does when you configure different builds.
But in the first time cmake is run, there's no cache and no way to know
what are the command line parameters. Is must run the whole build to
know that. So the first time 'cmake . --help' runs, the whole build
should be parsed and executed.
But... what if we have this extreme case?
IF(${CMAKE_BUILD_TYPE} STREQUAL Debug)
add_command_line_parameter(whatever)
ENDIF()
That is, the parameter is bound to another parameter? It's not
impossible to imagine a case where each time we run cmake --help, a
different set of parameters is shown. I know, that's stupid, but corner
cases usually are...
Regards,
rod
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Parsing cmake command line parameters
On Tuesday 18 December 2007, Rodolfo Schulz de Lima wrote:
James Bigler wrote:
What is it that people want beyond -DBUILD_THIS_THAT_WHATEVER:BOOL=TRUE
could provide?
Do they want: --enable-build_this_that_whatever?
People that work with embedded systems might want a stripped down
version of a library, for instance. So disabling features might be a
strong use case.
Yes.
In KDE we have the macro MACRO_OPTIONAL_FIND_PACKAGE(), which adds an option
around the find_package() call:
http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/MacroOptionalFindPackage.cmake?revision=520790view=markup
Beside that, it is really just a matter of syntax whether you do
--enable-build-this
or -DENABLE_BUILD_THIS=TRUE
I also don't understand why we have to parse the whole CMakeLists.txt
structure. We should treat these command line args like we cache
variables like CPack does when you configure different builds.
But in the first time cmake is run, there's no cache and no way to know
what are the command line parameters. Is must run the whole build to
know that. So the first time 'cmake . --help' runs, the whole build
should be parsed and executed.
But... what if we have this extreme case?
IF(${CMAKE_BUILD_TYPE} STREQUAL Debug)
add_command_line_parameter(whatever)
ENDIF()
That is, the parameter is bound to another parameter? It's not
impossible to imagine a case where each time we run cmake --help, a
different set of parameters is shown. I know, that's stupid, but corner
cases usually are...
Yes, and they must work too, otherwise there will be bug reports.
I have (currently) two ideas:
either a special file, e.g. CMakeCustomArgs.txt, which in some way sets up the
custom command line parameters.
Or have a cmake modules, which handles this stuff, and which also creates a
custom target help-args or something like that, which prints the available
args. This would not be available before cmake has successfully run.
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Parsing cmake command line parameters
Alexander Neundorf wrote: I have (currently) two ideas: either a special file, e.g. CMakeCustomArgs.txt, which in some way sets up the custom command line parameters. There's a beauty in having everything inside CMakeLists.txt Or have a cmake modules, which handles this stuff, and which also creates a custom target help-args or something like that, which prints the available args. This would not be available before cmake has successfully run. This would be non-intuitive to people not accustomed to cmake. I think that the scope of where argument definitions should be defined should be well defined. The example I gave of each cmake --help evocation returning a different set of arguments shouldn't be allowed. But it's reasonable to create some arguments when cmake is running under Windows or Linux, etc. And let's not forget that maybe 80% of all uses of command line arguments will be the most trivial one, i.e., statically define those arguments, so sticking with like 90% of all use cases would be good enough, IMHO. wxWidgets' configure script throws all possible options, whether they're valid for Windows or Linux. It's really a mess, but it's simple to implement and I've never heard of anyone complaining about it. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Parsing cmake command line parameters
On Dec 18, 2007 12:01 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote: I think that the scope of where argument definitions should be defined should be well defined. The example I gave of each cmake --help evocation returning a different set of arguments shouldn't be allowed. I disagree. Information hiding according to what's selected or possible is a perfectly valid way to interact with the user. Just because Autoconf listed every Tom, Dick, and Harry option flatly doesn't mean that CMake has to do it. The Autoconf listings are usually a bunch of boring boilerplate. The CMake approach is more powerful than what Autoconf provides; there are more ways for the programmer to cut off her fingers. So make the programmer responsible for what she does. Have a Chapter Oriented policy manual on how to implement command line options. Stress that if options are determined by complex conditionals, they're going to appear late in the help output. If the programmer wants the options to be readily apparent, she should determine them unconditionally or with constant conditions. A dry run through the CMake script is sufficient to determine any unconditional options. It's also sufficient for any conditions that are constants, such as the platform, generator, or compiler we're using. Or even variables that are defined early and don't change. Options that are masked by more complex conditionals can certainly be detected, and warnings can be issued about them. I think we need to stop thinking in terms of perfect solution and start thinking in terms of policy, where the programmer is responsible for implementing a policy. And let's not forget that maybe 80% of all uses of command line arguments will be the most trivial one, i.e., statically define those arguments, so sticking with like 90% of all use cases would be good enough, IMHO. Exactly. Anything could happen is a lot of fretting about nothing. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Parsing cmake command line parameters
Rodolfo Schulz de Lima wrote: Alexander Neundorf wrote: I have (currently) two ideas: either a special file, e.g. CMakeCustomArgs.txt, which in some way sets up the custom command line parameters. There's a beauty in having everything inside CMakeLists.txt Not only that, but this becomes a maintenance nightmare. It's too easy to get these out of sync. Or have a cmake modules, which handles this stuff, and which also creates a custom target help-args or something like that, which prints the available args. This would not be available before cmake has successfully run. This would be non-intuitive to people not accustomed to cmake. This isn't a problem if it's documented well. If cmake --help spit out something told the user what to do, they will usually do it. The problem lies when the programs don't behave as expected with no explanation (i.e. Using -DMY_VAR=value instead of -DMY_VAR:STRING=value should be rejected instead silently doing weird things). Having a good README or INSTALL file does wonders. That's the first thing I look for in a project. I think that the scope of where argument definitions should be defined should be well defined. The example I gave of each cmake --help evocation returning a different set of arguments shouldn't be allowed. But it's reasonable to create some arguments when cmake is running under Windows or Linux, etc. And let's not forget that maybe 80% of all uses of command line arguments will be the most trivial one, i.e., statically define those arguments, so sticking with like 90% of all use cases would be good enough, IMHO. wxWidgets' configure script throws all possible options, whether they're valid for Windows or Linux. It's really a mess, but it's simple to implement and I've never heard of anyone complaining about it. So this isn't so much a discussion of being able to parse arguments from the command line, but rather an automated mechanism to detect options in the CMakeLists.txt files and print them out when a user does --help. Many autoconf systems don't do this. To see the real options I have to scan configure.in myself. For autoconf build systems I have generated, I have to manually add the help options. I think it's silly to try and solve this problem, especially when there is a much better way to do it via ccmake. I much prefer using ccmake than having the giant configure line. It seems like CMake already has a good way to configure builds, and those used to autoconf just need a little nudging. I haven't had anyone in my group complain about using ccmake. That being said, if you really want cmake --help-options, then I guess you would just have to parse all the CMakeLists.txt files, find all occurrences of ADD_ARG() regardless of scope, and spit them out. There really isn't a better option outside of just using ccmake. James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Parsing cmake command line parameters
Bill Hoffman wrote: Brandon Van Every wrote: Exactly. Anything could happen is a lot of fretting about nothing. I am thinking a separate file would be the best approach for this. Something like CMakeOptions.cmake, it gets read in and adds command line options to cmake. It can include other options files from inside the project. This idea of a pass on the cmakefiles is going to be very hard technically. We can push the work to the developer of the cmakelist files. When you create a project, you can put the options that you want into a separate file(s). I think this is a reasonable compromise. You already have to do this for autoconf, and if you don't want to mess with this, you could not implement one. The developer could also document that certain flags only have meanings for certain systems. We could also allow a *very* restricted set of system variables, such as WIN32 and APPLE. James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Parsing cmake command line parameters
Alexander Neundorf wrote:
Yes.
In KDE we have the macro MACRO_OPTIONAL_FIND_PACKAGE(), which adds an option
around the find_package() call:
http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/MacroOptionalFindPackage.cmake?revision=520790view=markup
Beside that, it is really just a matter of syntax whether you do
--enable-build-this
or -DENABLE_BUILD_THIS=TRUE
No, it isn't *just* a matter of syntax (which is also horrible, btw).
It is also a matter of documentation. -DENABLE_BUILD_THIS is documented
nowhere. configure --enable-build-this is documented if you run it
without any flag.
But... what if we have this extreme case?
IF(${CMAKE_BUILD_TYPE} STREQUAL Debug)
add_command_line_parameter(whatever)
ENDIF()
So? You don't get the option if you don't run a debug build. As simple
as that. A better syntax for add_option would be:
add_option( NAME TYPE HELP [OPTS] )
with OPTS being:
CONFIGURATION Debug
REQUIRED someotheroption
That avoids the need for if-thens.
I have (currently) two ideas:
either a special file, e.g. CMakeCustomArgs.txt, which in some way sets up the
custom command line parameters.
Yuck!
Or have a cmake modules, which handles this stuff, and which also creates a
custom target help-args or something like that, which prints the available
args. This would not be available before cmake has successfully run.
Yuck! Why wouldn't it be available? Have you guys used premake at all?
The premake.lua is ALWAYS read. If no parameter is passed, there's a
dry run of the file, and help with options get spit.
It is gorgeous.
Sure, lua runs 10 times faster than the cmake language does, but that's
a different story.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
