Re: [CMake] Re: a ./configure shell script stub (William A. Hoffman)
At 03:16 PM 5/29/2006, Axel Roebel wrote: >My idea was that there would be the special short cuts that are most often >used: >--prefix=* -DCMAKE_INSTALL_PREFIX=* >--verbose -DCMAKE_VERBOSE_MAKEFILE >--build=* -DCMAKE_BUILD_TYPE=* Ok, is that the list of short cuts in total? >and besides that >--foo_bar=* always maps into -DTOTO_FOO_BAR=* You lost me here, where did the TOTO go/come from? CMake variables are case sensitive, so having the command line map to all lower case could cause trouble. >It could be nice to additionally have > >--enable_foo_bar -> maps to the option FOO_BAR >--disable_foo_bar -> maps to the option FOO_BAR This does not sound to hard. >> Maybe something like: >> >> set_variable_property(CMAKE_INSTALL_PREFIX COMMNAD_LINE_OPT "--prefix") > >I don't think a configurable behavior is needed here. It is my opinion that >there is no need for freedom for these things. It is more important to >create standards. It should be as easy to type and as standardized as >possible! I just don't like to have a hard coded list of "short cuts" as soon as you have one, someone will complain that they want one as well, and to add one, you will have to wait for a new version of cmake to come out if it is hard coded. We could have a standard options file that is stored in the modules directory of cmake, but it seems like people will want to add options. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: a ./configure shell script stub (William A. Hoffman)
Hi, Why not having it configurable in a file so new mapping can be added without recompiling. It's much easier and shorter to remember ./configure --prefix=/usr instead of cmake -DCMAKE_INSTALL_PREFIX=/usr or ./configure --verbose instead of cmake -DCMAKE_VERBOSE_MAKEFILE Millions of people have already used configure and giving up habits is very difficult. As a developer, I prefer Cmake but a user a prefer the configure cli. On Tuesday 30 May 2006 08:47, Alexander Neundorf wrote: > Hi, > > > Von: William A. Hoffman <[EMAIL PROTECTED]> > > ... > > > I just don't like to have a hard coded list of "short cuts" as soon > > as you have one, someone will complain that they want one as well, and > > to add one, you will have to wait for a new version of cmake to come out > > if it is hard coded. We could have a standard options file that is > > stored in the modules directory of cmake, but it seems like people will > > want to add options. > > I think so too. I'm sure if you add two or three, there will be somebody > proclaiming that just another very important variable absolutely needs the > shortcut. A way to make this adjustable would help everybody I think. > (yes, typing -DCMAKE_INSTALL_PREFIX=/blah/foo) is sometimes a bit lot of > work) > > Bye > Alex -- * - * - * 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] Re: a ./configure shell script stub (William A. Hoffman)
On Tuesday 30 May 2006 03:30, William A. Hoffman wrote: > >> set_variable_property(CMAKE_INSTALL_PREFIX COMMNAD_LINE_OPT > >> "--prefix") > > > >I don't think a configurable behavior is needed here. It is my opinion > > that there is no need for freedom for these things. It is more > > important to create standards. It should be as easy to type and as > > standardized as possible! > > I just don't like to have a hard coded list of "short cuts" as soon > as you have one, someone will complain that they want one as well, and > to add one Maybe a little change in approach will solve some hard-to-crack issues. If the project manager just runs 'cmake --create-configure' after he made some changes in the build system, which in turn will generate a configure script with the projects options then you can put that generated file in the project svn and the distributed tarballs. This sticks better with the concept of CMake which is a generator and it sidesteps ugliness of having one script that should work for everyone. When you take that approach then you can think about how to expose features to the configure script at script-generation time. This can range from options passed to adding a command in the CMakeLists.txt like 'expose FOO_BAR "foo bar" [toggle|string]' -- Thomas Zander pgphYcOMLSOe1.pgp Description: PGP signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: a ./configure shell script stub (William A. Hoffman)
At 04:05 AM 5/30/2006, Thomas Zander wrote: >Maybe a little change in approach will solve some hard-to-crack issues. >If the project manager just runs 'cmake --create-configure' after he made >some changes in the build system, which in turn will generate a configure >script with the projects options then you can put that generated file in >the project svn and the distributed tarballs. > >This sticks better with the concept of CMake which is a generator and it >sidesteps ugliness of having one script that should work for everyone. > >When you take that approach then you can think about how to expose >features to the configure script at script-generation time. This can >range from options passed to adding a command in the CMakeLists.txt like >'expose FOO_BAR "foo bar" [toggle|string]' >-- I don't think we want to generate a configure script since it will only run on systems with a unix shell. However, I like the idea of making the command line to cmake configurable. I think we all agree that avoiding cmake -DSOME_REALLY_LONG_CAP_NAME=/some/path is a good thing. The question now, is what is the best way to provide better, configurable options to cmake. I think some file in the projects top level directory would not be a bad idea. It would be easy to implement, (no extra pass that only parses.) It would be up to the project maintainer to make sure it was reflected in the variables of the project. We could also have a default one that could be included to give a standard set of options like --prefix. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: a ./configure shell script stub (William A. Hoffman)
On Tuesday 30 May 2006 14:58, you wrote: > I don't think we want to generate a configure script since it will only > run on systems with a unix shell. But the 'configure' idea is exactly for that set of people who are used to doing so. And, honestly, unix shell (sh) are available everywhere. For those that run Windows (and don't have the unixtools installed) the preferred interface is a GUI anyway. I don't see much basis to abandon this idea based on those concerns. -- Thomas Zander pgpGNZBpVnGNb.pgp Description: PGP signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: a ./configure shell script stub (William A. Hoffman)
On Tuesday 30 May 2006 16:48, Alexander Neundorf wrote: > > But the 'configure' idea is exactly for that set of people who are > > used to doing so. And, honestly, unix shell (sh) are available > > everywhere. For those that run Windows (and don't have the unixtools > > installed) the preferred interface is a GUI anyway. > > Maybe two things: > -it adds one level of indirection A requirement to get the "./configure --help" to respond instantaneous and not after first checking all CMake*.txt files. > -it hides (at least a bit) the fact that there is cmake running An understandable concern; it is one that can be solved by adding some output where it tells the user the version etc. Correct me if I misunderstood; but AFAICS the current idea was to parse all config files (which in case of KOffice takes several minutes with clean caches) and present the options based on that. If you want to do that I suggest to not show in anyway that its cmake, as the user will hate cmake immediately ;) -- Thomas Zander pgpAvmUMXK5W0.pgp Description: PGP signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Re: a ./configure shell script stub (William A. Hoffman)
>For those that run Windows (and don't have the unixtools installed) the >preferred interface is a GUI anyway. I don't think that's a good assumption. Windows has a command interpreter (and in my experience people erroneously believe CMD.EXE is as limited as COMMAND.COM without having looked at recent enhancements) plus the WSH stuff which works well enough too. Its quite handy to drive things from timmed commands or remotely via a web or RPC interface. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: a ./configure shell script stub (William A. Hoffman)
James Mansion wrote: For those that run Windows (and don't have the unixtools installed) the preferred interface is a GUI anyway. I don't think that's a good assumption. Windows has a command interpreter (and in my experience people erroneously believe CMD.EXE is as limited as COMMAND.COM without having looked at recent enhancements) plus the WSH stuff which works well enough too. Its quite handy to drive things from timmed commands or remotely via a web or RPC interface. Well, I use MSYS. Me no speaka CMD.EXE. For many years, there was no point as generally one needed one's .bat files to run everywhere. Maybe now command.com is finally at death's door? Still, I'm having a hard time believing there's any "command line culture" on Windows. It may not be a strictly correct assumption, but I'd wager that 99% of Windozian programmers don't do any CMD.EXE scripting. Compare that to Unix where almost everyone knows some shell scripting. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: a ./configure shell script stub (William A. Hoffman)
At 07:20 PM 5/30/2006, Brandon J. Van Every wrote: >James Mansion wrote: >>> >>>For those that run Windows (and don't have the unixtools installed) the >>>preferred interface is a GUI anyway. >>> >> >> >>I don't think that's a good assumption. Windows has a command interpreter >>(and in my experience people erroneously believe CMD.EXE is as limited as >>COMMAND.COM without having looked at recent enhancements) plus the WSH >>stuff which works well enough too. >> >>Its quite handy to drive things from timmed commands or remotely via >>a web or RPC interface. >> > >Well, I use MSYS. Me no speaka CMD.EXE. For many years, there was no point >as generally one needed one's .bat files to run everywhere. Maybe now >command.com is finally at death's door? Still, I'm having a hard time >believing there's any "command line culture" on Windows. It may not be a >strictly correct assumption, but I'd wager that 99% of Windozian programmers >don't do any CMD.EXE scripting. Compare that to Unix where almost everyone >knows some shell scripting. Whether it is command.com or msys or cygwin, there are a number of developers on windows that will use the command line. If we can provide a consistent interface across unix and windows, without using shell all the better. If a project wants to create a shell script that calls cmake, they can do that right now with no changes needed to cmake. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: a ./configure shell script stub (William A. Hoffman)
William A. Hoffman wrote: > At 07:20 PM 5/30/2006, Brandon J. Van Every wrote: > Whether it is command.com or msys or cygwin, there are a number of developers > on > windows that will use the command line. If we can provide a consistent > interface across I'm one of them :) > unix and windows, without using shell all the better. If a project wants to > create > a shell script that calls cmake, they can do that right now with no changes > needed > to cmake. I've been using a configure perl script that call cmake. I have this script compiled to configure.exe on windows. But I always use ccmake or cmakesetup because there are options that are enabled depending on other options and that can't be done in my scripts. I have these scripts for those who are used to configure && 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: Re: [CMake] Re: a ./configure shell script stub (William A. Hoffman)
Hi, > Von: William A. Hoffman <[EMAIL PROTECTED]> ... > I just don't like to have a hard coded list of "short cuts" as soon > as you have one, someone will complain that they want one as well, and > to add one, you will have to wait for a new version of cmake to come out > if it is hard coded. We could have a standard options file that is > stored in the modules directory of cmake, but it seems like people will > want to add options. I think so too. I'm sure if you add two or three, there will be somebody proclaiming that just another very important variable absolutely needs the shortcut. A way to make this adjustable would help everybody I think. (yes, typing -DCMAKE_INSTALL_PREFIX=/blah/foo) is sometimes a bit lot of work) 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] Re: a ./configure shell script stub (William A. Hoffman)
Hi, > Von: William A. Hoffman <[EMAIL PROTECTED]> ... > to cmake configurable. I think we all agree that avoiding > cmake -DSOME_REALLY_LONG_CAP_NAME=/some/path is a good thing. > The question now, is what is the best way to provide better, > configurable options > to cmake. I think some file in the projects top level directory would > not be a bad idea. It would be easy to implement, (no extra pass that > only parses.) > It would be up to the project maintainer to make sure it was reflected > in the > variables of the project. We could also have a default one that could > be included to give a standard set of options like --prefix. Yes, sounds good. So it will be possible to map OPTION()'s and cmake cache variables to command line switches ? like MAP(CMAKE_INSTALL_PREFIX prefix) and maybe some special switch to offer enable/disable ? Do OPTION()'s have to be handled differently than variables ? 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] Re: a ./configure shell script stub (William A. Hoffman)
Hi Thomas, > Von: Thomas Zander <[EMAIL PROTECTED]> > > On Tuesday 30 May 2006 14:58, you wrote: > > I don't think we want to generate a configure script since it will only > > run on systems with a unix shell. > > But the 'configure' idea is exactly for that set of people who are used to > doing so. And, honestly, unix shell (sh) are available everywhere. > For those that run Windows (and don't have the unixtools installed) the > preferred interface is a GUI anyway. Maybe two things: -it adds one level of indirection -it hides (at least a bit) the fact that there is cmake running 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] Re: a ./configure shell script stub (William A. Hoffman)
Hi, > Von: Thomas Zander <[EMAIL PROTECTED]> > > On Tuesday 30 May 2006 16:48, Alexander Neundorf wrote: > > > But the 'configure' idea is exactly for that set of people who are > > > used to doing so. And, honestly, unix shell (sh) are available > > > everywhere. For those that run Windows (and don't have the unixtools > > > installed) the preferred interface is a GUI anyway. > > > > Maybe two things: > > -it adds one level of indirection > > A requirement to get the "./configure --help" to respond instantaneous > and not after first checking all CMake*.txt files. > > > -it hides (at least a bit) the fact that there is cmake running > > An understandable concern; it is one that can be solved by adding some > output where it tells the user the version etc. > > Correct me if I misunderstood; but AFAICS the current idea was to parse > all config files (which in case of KOffice takes several minutes with > clean caches) and present the options based on that. > If you want to do that I suggest to not show in anyway that its cmake, as > the user will hate cmake immediately ;) If I understood Bill correctly, the idea is to provide a special file which is read by cmake and which provides mappings between full cmake variable names and short command line parameters. Like: CMAKE_MAP(CMAKE_INSTALL_PREFIX prefix) so that cmake will be able to translate cmake --prefix=/opt/kde4 to cmake -DCMAKE_INSTALL_PREFIX=/opt/kde4 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] Re: a ./configure shell script stub (William A. Hoffman)
At 11:11 AM 5/30/2006, Alexander Neundorf wrote: >If I understood Bill correctly, the idea is to provide a special file which is >read by cmake and which provides mappings between full cmake variable names >and short command line parameters. >Like: >CMAKE_MAP(CMAKE_INSTALL_PREFIX prefix) > >so that cmake will be able to translate >cmake --prefix=/opt/kde4 to cmake -DCMAKE_INSTALL_PREFIX=/opt/kde4 Yes, that is what I am talking about. I don't think it will be hard to implement, and I am sure any hard coded approach will be regretted a few months later. Also, cmake --help (will print the help for the given project) -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: Re: [CMake] Re: a ./configure shell script stub (William A. Hoffman)
On Wednesday 31 May 2006 01:44, William A. Hoffman wrote: > Yes, that is what I am talking about. I don't think it will be hard to > implement, and I am sure any hard coded approach will be regretted a few > months later. > > Also, > > cmake --help (will print the help for the given project) I understand that you don't like the hardcoded approach, still this is what made the configure interface so standardizing that now we discuss it here. There were hardly any configure scripts that would not provide some of the basic flags (at least --prefix) and the --enable/--disable syntax for the options. I understand as well that you want to make it as easy as possible and it obviously the handling of the OPTION variables requires parsing the CMakeLists.txt and the CMakeCache.txt, which would require some more effort than reading only the command line shortcut option file. So I would suggest to make the mapping --prefix -> -DCMAKE_INSTALL_PREFIX --verbose -> -DCMAKE_VERBOSE_MAKEFILE --build -> -DCMAKE_BUILD_TYPE the default mapping which can be changed only if the user supplies a local configuration file which can only be used to extend the shortcut list. The option syntax using --enable-toto... is in fact a bit longer than -Dtoto= so we may live without it. And for the help we may rely on ccmake or cmake -i I think we have extensively discussed the issues and I will create a feature request such that you will not forget these suggestions. Kind regards -- Axel Roebel IRCAM Analysis/Synthesis Team ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
