Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt!
On Monday 14 January 2008 04:04, Bill Hoffman wrote:
Brandon Van Every wrote:
On Jan 13, 2008 4:23 PM, Bill Hoffman [EMAIL PROTECTED] wrote:
Martin Lütken wrote:
That's great then. Do you know who to address in order to get the patch
into the CVS code ?
Actually, what about something like this:
# CMakeLists.txt
INCLUDE(${CMAKE_CURRENT_SOURCE_DIR}/${CML_NAME})
cmake /path/to/proj -DCML_NAME:STRING=mycmake1.txt
cmake /path/to/proj -DCML_NAME:STRING=mycmake2.txt
No changes needed to CMake at all
Not needing to change CMake may be useful for my own purposes, as I
have to ship with production versions of CMake, and I was planning to
wrap command line ugliness in a script anyways. But CMake is changed
all the time in order to better it. I don't see how let's leave well
enough alone is an argument in this case. In terms of command line
elegance, your solution leaves much to be desired over
cmake -f mycmake1.txt
cmake -f mycmake2.txt
Especially in the eyes of the Autoconf + GMake crowd, whom we'd like
to convert. Do you have a serious objection to CMake having a -f
flag?
There is already a way to do the same thing. Martin, perhaps if you
discussed the use case better so we could understand what you are trying
to do. Many people will run CMake from a GUI and will not be giving a
-f flag. With the patch there would be no way to build a project via
one of the GUI's if it required changing the name of the file. If you
had two or more sets of cmake files in the same source tree, how would
that work?
-Bill
My patch would work fine with two sets of makefiles.
And can't see why you could nor set that option from the GUI also
Before generating the makefiles.
I need it since I am trying to make a sort of Common Build System using
CMake as make generator.
The idea is to have a simple uniform way of building existing opensource SW.
I know CMake allready goes a long way in this goal, but I want to go further
by providing uniform CBS/CMake files for often used SW projects. Also I want
it to be easy to create new buildfiles which works with the system so
hopefully
the project owners would keep them updated by themselves.
Some projects might have their own CMake files allready (like KDE) and I am
not interrested in intefering with these - at least not at first.
-Martin
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt!
On Monday 14 January 2008 18:42, Brandon Van Every wrote: On Jan 14, 2008 12:16 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Brandon Van Every wrote: Example: I have a legacy handwritten GMake client.mk that acquires the build tree from CVS before the main Autoconf generated Makefile is run. The tree is grabbed from CVS and built by typing make -f client.mk. The simplest translation to a CMake system would be cmake -f client.txt. Nobody would be doing a different drill, the client would perceive this as nice, to not have to learn much of anything different. Once the build tree has been acquired, we don't need client.mk anymore. The equivalent of Autoconf's Makefile should always be CMakeLists.txt. But that is not all the patch does. If you do cmake -f client.txt, then every add_subdirectory and subdirs will now look for client.txt. I don't want that. I have trouble seeing sense in that, as I think system differences should be handled with if(APPLE) and so forth, not separate files. Martin could try to explain. And, cmake -f client.txt would not be the same thing as make -f client.mk, as make -f client.mk would actually do a build. For the cmake, one you would have cmake -f client.txt, make (with no -f). Hm. I guess what *I* need is a way to output a different Makefile name. Oh well, back to the drawing board. I wonder what Autoconf does? Or I could translate client.mk to client.txt and make people type cmake -P client.txt. Cheers, Brandon Van Every That would really be nice if we could autoconvert like that :-) ___ 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] Patch to apply! Changing the default nameCMakeLists.txt! Introduction to Common Build System
If you do cmake -f client.txt, then every add_subdirectory and subdirs will now look for client.txt. That is not the way make -f works. If you do make -f it just changes the initial makefile that is read into make, after that it is up to the makefile writer to use include, or recursive make to specify additional makefiles that are included. And, cmake -f client.txt would not be the same thing as make -f client.mk, as make -f client.mk would actually do a build. For the cmake, one you would have cmake -f client.txt, make (with no -f). I am still not convinced this is a good idea. -Bill That might work too. I also does not understand why You are soo resistant to a minor feature which couldn't really hurt anyone? Actually i could do with if just CMake also accepted CMakeLists.cbs as makefiles, since that's what I intended to use for the project I mentioned. With my project you would be able to easily use common SW librairies in you project. I am simply trying to make it much much easier for people to write cross platform C++ code reusing existing libraries and ofcourse cmake. To that end I could really use just a tiny bit of help from the cmake-team. I am still a least one half year from releasing something, but I can try to explain the basic idea. Simple example from my actual codebase. CBS (Common Build System) makefiles for zlib and libpng, which depends on zlib (install stuff not included): --- z.cbs --- TARGET_DEFAULT_VERSION ( 1 2 3 ) ADD_SOURCE_FILE ( adler32.c ) ADD_SOURCE_FILE ( compress.c) ... ADD_SOURCE_FILE ( inffast.c ) --- png.cbs --- TARGET_DEFAULT_VERSION ( 1 2 16 ) ADD_DEPENDS_ON ( z ) ADD_SOURCE_FILE ( png.c ) ADD_SOURCE_FILE ( pngerror.c) ... ADD_SOURCE_FILE ( pngwutil.c) Note the ADD_DEPENDS_ON ( z ) for png. This single line takes care of all needed includes, linkdirs/libraries etc. thats neeeded to compile and link libpng. For additional include use ADD_INCLUDE_DIR. In the (in time hopefully rare) cases where you depend on external libraries you use ADD_LINK_DIR, ADD_LINK_LIBRARY In case you need to add defines you can do ADD_DEFINE or ADD_PUBLIC_DEFINE I even made an ADD_SOURCE_FILE_QT which adds a C++ file for normal compilation and if there's and associated header call the moc compiler on that and adds the generated source file to the list of sources. Have also easy handling of flex,bison and in the cbs-files for Mozilla also support for their IDL files using the IDL compiler built in same pass using CBS/CMake. There are currently a cbmake.py script which simplifies the generation of makefiles for out of source build for all targets. Simply write: 'cbmake.py -g kdev -b debug -l static' (debug in KDevelop. Libs static ) OR 'cbmake.py -g vc8 -l shared' (Create VC8 files all libs default DLL's) Also shellscripts/bat files for the most common uses so you at least in Windows never need to see the command line: Just doubleclick a bat file and go open you project in Visual Studio. About the command line script I do plan for it to also have a GUI at some point similar to VisualStudios Solution Explorer, where you can set your build options add files etc. To make a GUI tool as easy as possible to create I strive to keep the source makefiles really simple like lines of ADD_XX () so parsing and manipulating them from a GUI tool can be done. --- Main configuration file --- Lastly I should mention some of the cool stuff you can do in the main configuration file, by this example from (again from my actual codebase): SET ( z_USE SYSTEM ) # Use system version (currently not Windows) SET ( png_USE BUILD) # Build from sources in this project SET ( bz2_USE PREBUILT ) # Prebuilt (with CBS) from othter source tree. SET ( z_LINK_TYPE STATIC ) # Build/use zlib static event though current default for project as a whole is to make shared libs/DLLs. As you can see it's possible to intermix the usage of shared/static, own built with a system installed library etc. all from one central place. One hassle for instance getting gcc to use and link with a static version of a system installed library like z(lib) in the example configuratiob file is also solved since I simply copy static librairies from system dirs to own link dir and directs the linker to look there first - This way gcc is forced to use the static version since the shared one is not present in the same dir. Well hope that gave you an impression of what it is. So the reason I need an anternative name for the CMakeLists.txt file is that I wan't CBS makefiles to be able to live side by side with a projects own CMake files. So far the only project I am considering creating CBS files for, which allready uses CMake is KDE, but that might change and I would like allready now to be able to rename my files in preparation and also because I might try and convert KDE in the not too far future. -Regards
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt! Introduction to Common Build System
Martin Lutken wrote: That might work too. I also does not understand why You are soo resistant to a minor feature which couldn't really hurt anyone? I just want to make sure it is a feature that we want. I will be one of the ones supporting it for as long as CMake is around. As it is your patch has some issues. For example, if you changed a CMakeLists.txt file, and ran make on the build tree, it would fail as it is. This is because the command to rerun cmake would also need to have the -f flag as well, and does not. Of course, that can be fixed. So, I guess the process for getting stuff into CMake should be stated somewhere. So, here it is: 1. Have the idea approved on the cmake mailing list. Basically get buy in from the CMake community and developers for the feature. 2. Create a bug / feature request in the bug tracker. 3. Submit a patch to the bug tracker, complete with a test case that has good coverage on the new code being added. (3 is optional, but should speed things up. If it is a must have feature, then the cmake developers will eventually get around to adding it. However, it it is a solid well tested patch, it will more more likely to be added as-is.) My concerns for this feature are as follows: It will confuse users of CMake. They will download a project and have to use extra command line arguments to get things to work. If they just run CMakeSetup, cmake, or ccmake as stated in the usual CMake documentation it will not work. Basically, I think it may make cmake based builds harder to understand and support. I would think that the existence of two complete cmake build systems in any one source tree, would be one two many. It is hard enough to maintain one build system, much less two flavors of cmake. Seems like something that would only be used as a temporary stop gap. The new build stuff would either be accepted or rejected by the project, and the co-existing stuff would go away. For a temporary thing, it could be done with includes, and parallel source trees. I don't mean to offend, and I appreciate your use and extensions to CMake, and look forward to your future contributions. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt! Introduction to Common Build System
On Tuesday 15 January 2008 16:40, you wrote: Martin Lutken wrote: That might work too. I also does not understand why You are soo resistant to a minor feature which couldn't really hurt anyone? I just want to make sure it is a feature that we want. I will be one of the ones supporting it for as long as CMake is around. As it is your patch has some issues. For example, if you changed a CMakeLists.txt file, and ran make on the build tree, it would fail as it is. This is because the command to rerun cmake would also need to have the -f flag as well, and does not. Of course, that can be fixed. So, I guess the process for getting stuff into CMake should be stated somewhere. So, here it is: 1. Have the idea approved on the cmake mailing list. Basically get buy in from the CMake community and developers for the feature. 2. Create a bug / feature request in the bug tracker. 3. Submit a patch to the bug tracker, complete with a test case that has good coverage on the new code being added. (3 is optional, but should speed things up. If it is a must have feature, then the cmake developers will eventually get around to adding it. However, it it is a solid well tested patch, it will more more likely to be added as-is.) My concerns for this feature are as follows: It will confuse users of CMake. They will download a project and have to use extra command line arguments to get things to work. If they just run CMakeSetup, cmake, or ccmake as stated in the usual CMake documentation it will not work. Basically, I think it may make cmake based builds harder to understand and support. I would think that the existence of two complete cmake build systems in any one source tree, would be one two many. It is hard enough to maintain one build system, much less two flavors of cmake. Seems like something that would only be used as a temporary stop gap. The new build stuff would either be accepted or rejected by the project, and the co-existing stuff would go away. For a temporary thing, it could be done with includes, and parallel source trees. I don't mean to offend, and I appreciate your use and extensions to CMake, and look forward to your future contributions. -Bill Hmm well I see It can wait anyway. I allready do the include-trick from the general Makefile, but in the transitional phase for a large project it would be much easier to be able do it that way. Maybe it's because I never really used CMake GUI frontends Only tried them briefly. Since I am trying to construct a system in which you can build and configure many (possibly a complete Linux Distribution) in one build, while still workinbg perfectly for the individual subprojects I have neeeds which are a bit special But I might add the request to the feature request list... -Martin ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt! Introduction to Common Build System
Martin Lutken wrote: Hmm well I see It can wait anyway. I allready do the include-trick from the general Makefile, but in the transitional phase for a large project it would be much easier to be able do it that way. Maybe it's because I never really used CMake GUI frontends Only tried them briefly. Since I am trying to construct a system in which you can build and configure many (possibly a complete Linux Distribution) in one build, while still workinbg perfectly for the individual subprojects I have neeeds which are a bit special But I might add the request to the feature request list... Sounds good. If you are using the patch you sent, you should be aware that the parts of the makefile that invoke cmake when input files change need to be updated with the correct -f option. You may also be interested in the import/export library stuff that is going on in CMake CVS. We are adding the ability to export a target from a cmake build so that it can be imported into another project. So, you can treat libraries external to your project just like the internal ones. Something like this: find_package(bar REQUIRED) add_executable(foo foo.cxx) target_link_libraries(foo bar) -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt! Introduction to Common Build System
On Jan 15, 2008 7:03 AM, Martin Lutken [EMAIL PROTECTED] wrote:
Simple example from my actual codebase. CBS (Common Build System) makefiles
for zlib and libpng, which depends on zlib (install stuff not included):
--- z.cbs ---
TARGET_DEFAULT_VERSION ( 1 2 3 )
ADD_SOURCE_FILE ( adler32.c )
ADD_SOURCE_FILE ( compress.c)
...
ADD_SOURCE_FILE ( inffast.c )
Why do I want ADD_SOURCE_FILE? In CMake I just do:
SET(mysources adler32.c compress.c inffast.c)
ADD_LIBRARY(mysharedlib SHARED ${mysources})
ADD_LIBRARY(mystaticlib STATIC ${mysources})
--- png.cbs ---
TARGET_DEFAULT_VERSION ( 1 2 16 )
ADD_DEPENDS_ON ( z )
Why do I want ADD_DEPENDS_ON? In CMake I just do:
TARGET_LINK_LIBRARIES(mysharedlib z)
TARGET_LINK_LIBRARIES(mystaticlib z)
Note the ADD_DEPENDS_ON ( z ) for png. This single line takes care of all
needed includes, linkdirs/libraries etc. thats neeeded to compile and link
libpng.
From your description, I don't understand what this is doing extra.
In the (in time hopefully rare) cases where you depend on external libraries
you use ADD_LINK_DIR, ADD_LINK_LIBRARY
CMake's TARGET_LINK_LIBRARIES doesn't care if you hand it external
link libraries or internal library target names. It just deals with
them. Why do you need a 2nd command?
In case you need to add defines you can do
ADD_DEFINE or ADD_PUBLIC_DEFINE
CMake has ADD_DEFINITIONS. What would ADD_PUBLIC_DEFINE do?
--- Main configuration file ---
Lastly I should mention some of the cool stuff you can do in the main
configuration file, by this example from (again from my actual codebase):
SET ( z_USE SYSTEM ) # Use system version (currently not Windows)
So you are implementing cross-compiling support? CMake CVS has that.
SET ( png_USE BUILD) # Build from sources in this project
CMake can do this, but it has to be handled by the consumers of the
png library, not the png library itself.
if(use_myzlib)
TARGET_LINK_LIBRARY(mylib myzlib)
else(use_myzlib)
TAGET_LINK_LIBRARY(mylib z)
endif(use_myzlib)
SET ( bz2_USE PREBUILT ) # Prebuilt (with CBS) from othter source tree.
I don't have a lot of experience with using CMake builds that wrap
other CMake builds. CMake does have mechanisms for 3rd party builds.
SET ( z_LINK_TYPE STATIC ) # Build/use zlib static event though current
default for project as a whole is to make shared libs/DLLs.
CMake already has that. ADD_LIBRARY(mylibname [SHARED | STATIC |
MODULE] blah blah blah) where the stuff in [ ] is optional.
Well hope that gave you an impression of what it is.
I'm unclear. What is the strategic purpose of CBS?
Are you trying to do CMake projects, but at what you consider to be a
higher level of abstraction than CMake provides? If so, then it's
probably worth going over each of those features above individually.
Some of them, I think CMake does just fine already. Others, perhaps
you have a more elegant approach. But community buy-in is important
here. Nobody's looking for new things to learn, unless there are
clear benefits. One of the biggest detriments I see in adding new,
supposedly better ways of doing the same thing, is that CMake is
already woefully under-documented as is. So it really should do a
different or clearly better thing, not just a variation on the thing.
It's way easier for CMake developers to function as a community when
they're all speaking the same language.
Are you trying to make it possible to generate CMake projects, or
other build tool projects (SCons? Ant?) using a common build tool?
If so, that's already what CMake is trying to do. We don't want a
common build tool, we think we are the common build tool. We would
want a generator for SCons or Ant or whatever.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt! Introduction to Common Build System
On 15.01.08 11:37:12, Brandon Van Every wrote: I'm unclear. What is the strategic purpose of CBS? If I understood correctly, the purpose is to (at some point) build foobar, including all deps completely with cbs. To me this totally sounds like Gentoo with cmake files as emerge replacement. Andreas -- Avoid reality at all costs. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt! Introduction to Common Build System
On Jan 15, 2008 11:46 AM, Andreas Pakulat [EMAIL PROTECTED] wrote: On 15.01.08 11:37:12, Brandon Van Every wrote: I'm unclear. What is the strategic purpose of CBS? If I understood correctly, the purpose is to (at some point) build foobar, including all deps completely with cbs. But is it a higher level CMake variant, or is it a completely new build tool that sees CMake as merely 1 of many possible output targets? To me this totally sounds like Gentoo with cmake files as emerge replacement. I'm reading http://linuxreviews.org/man/emerge/ and I don't understand how CMake could serve as an Emerge replacement. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt! Introduction to Common Build System
On 15.01.08 12:05:36, Brandon Van Every wrote: On Jan 15, 2008 11:46 AM, Andreas Pakulat [EMAIL PROTECTED] wrote: On 15.01.08 11:37:12, Brandon Van Every wrote: I'm unclear. What is the strategic purpose of CBS? If I understood correctly, the purpose is to (at some point) build foobar, including all deps completely with cbs. But is it a higher level CMake variant, or is it a completely new build tool that sees CMake as merely 1 of many possible output targets? No, AFAIU its using the CMake language to express how to build foo, including building also bar, baz and boo which are direct or indirect deps of foo. To me this totally sounds like Gentoo with cmake files as emerge replacement. I'm reading http://linuxreviews.org/man/emerge/ and I don't understand how CMake could serve as an Emerge replacement. What I meant is, it looks like cbs wants to use CMake to replace the normal package manager in a source-based distro. Andreas -- You don't become a failure until you're satisfied with being one. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt! Introduction to Common Build System
On Jan 15, 2008 2:54 PM, Andreas Pakulat [EMAIL PROTECTED] wrote: What I meant is, it looks like cbs wants to use CMake to replace the normal package manager in a source-based distro. I still don't quite get it, perhaps because I have no practical experience preparing packages for distribution. I'll let Martin comment on the questions I've raised. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt! Introduction to Common Build System
On Tuesday 15 January 2008, Martin Lutken wrote: ... Well hope that gave you an impression of what it is. So the reason I need an anternative name for the CMakeLists.txt file is that I wan't CBS makefiles to be able to live side by side with a projects own CMake files. I'm not sure this is a good idea, I agree with Bill. Adding a layer written in cmake on top of cmake doesn't sound good IMO. I think my main problem with autotools was that they were a set of tools, you had to learn and know each of them, and if one of them failed I was completely lost. Let's not go this route with cmake. So far the only project I am considering creating CBS files for, which allready uses CMake is KDE, but that might change and I would like allready now to be able to rename my files in preparation and also because I might try and convert KDE in the not too far future. Would be nice if you let us (KDE developers) know in advance ;-) Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt! Introduction to Common Build System
On Jan 15, 2008 7:39 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: Adding a layer written in cmake on top of cmake doesn't sound good IMO. I think my main problem with autotools was that they were a set of tools, you had to learn and know each of them, and if one of them failed I was completely lost. Let's not go this route with cmake. I dislike Automake + Autoconf + Make + Libtool because they're fragile. So was Xlib / Xt / Motif back when I was doing that many years ago. Layers break easily, especially when the layers are not based on any kind of type safety, but are just layer upon layer of macro stuff. CMake is definitely better integrated than the Automake toolchain. I would encourage Martin to help with further CMake integrations and improvements. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt!
Brandon Van Every wrote: On Jan 13, 2008 10:04 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Many people will run CMake from a GUI and will not be giving a -f flag. With the patch there would be no way to build a project via one of the GUI's if it required changing the name of the file. cmakesetup and ccmake would also need -f flags. Command line users and scripts could invoke -f flags just fine. Shortcuts on Windows can be made with -f flags in them if people want to present their builds that way. If you had two or more sets of cmake files in the same source tree, how would that work? The same way it works now. Generally, such files are a case of CMake invoking CMake. No offense Brandon, but I would like to here from Martin about how he plans to use this feature. I am not sure why you would want to have to co-existing source trees. Also, I am not sure the same thing can't be done with if and include. I am not saying that I won't apply the patch, I just want to understand the requirement/use case before I do. I also don't see people invoking cmakesetup with any flags, it is a gui program. I would like to here from Martin on how he expects this to be used from the GUI interfaces to CMake. Thanks. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt!
Quoting Bill Hoffman [EMAIL PROTECTED]: Brandon Van Every wrote: On Jan 13, 2008 10:04 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Many people will run CMake from a GUI and will not be giving a -f flag. With the patch there would be no way to build a project via one of the GUI's if it required changing the name of the file. cmakesetup and ccmake would also need -f flags. Command line users and scripts could invoke -f flags just fine. Shortcuts on Windows can be made with -f flags in them if people want to present their builds that way. If you had two or more sets of cmake files in the same source tree, how would that work? The same way it works now. Generally, such files are a case of CMake invoking CMake. No offense Brandon, but I would like to here from Martin about how he plans to use this feature. I am not sure why you would want to have to co-existing source trees. Also, I am not sure the same thing can't be done with if and include. I am not saying that I won't apply the patch, I just want to understand the requirement/use case before I do. I also don't see people invoking cmakesetup with any flags, it is a gui program. I would like to here from Martin on how he expects this to be used from the GUI interfaces to CMake. I don't specially like the idea of different names for CMakeLists.txt and I don't see the use case, either. It makes sense for 'make' to have a '-f' parameter because you have make, gmake, nmake, with slightly or totally incompatible syntaxes but there is only one and great CMake (and we can even ask for a minimum versior, of condition execution of some parts depending on CMake's version). Anyway I think it'd be easy to integrate this feature in the Windows GUI: instead of choosing a folder and automagically search for CMakeLists.txt in it, let's make the user choose a file (CMakeLists.txt or whatever the developer decided to call it). Assuming instead of CMakeLists.txt a developer decided to call it GreatCMakeLists.txt, cmake would then go and search for GreatCMakeLists.txt instead of CMakeLists.txt in every SUBDIRS'ed or ADD_DIRECTORY'ed directory. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt!
On Jan 14, 2008 11:44 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote: I don't specially like the idea of different names for CMakeLists.txt and I don't see the use case, either. It makes sense for 'make' to have a '-f' parameter because you have make, gmake, nmake, with slightly or totally incompatible syntaxes but there is only one and great CMake (and we can even ask for a minimum versior, of condition execution of some parts depending on CMake's version). My perspective is that legacy Autoconf + GMake build systems do have multiple Makefiles in the same directory for various reasons. When converting such systems, it is easier to preserve their case uses. And politically, people coming from an Autoconf + GMake background will like cmake -f blah.txt. It's familiar. It's not asking them to learn anything new. I advocate -f half for technical reasons, half for marketing reasons. Anyway I think it'd be easy to integrate this feature in the Windows GUI: instead of choosing a folder and automagically search for CMakeLists.txt in it, let's make the user choose a file (CMakeLists.txt or whatever the developer decided to call it). Assuming instead of CMakeLists.txt a developer decided to call it GreatCMakeLists.txt, cmake would then go and search for GreatCMakeLists.txt instead of CMakeLists.txt in every SUBDIRS'ed or ADD_DIRECTORY'ed directory. The slick way to do it, would be to scan all files in the directory, make an educated guess at which ones are CMake files, and offer a menu of files to choose from. If only CMakeLists.txt is available then no menu is generated. The guess would need some intelligence to discern between a main buildfile and sundry support scripts. Lack of a target *and* lack of an include might indicate that it's a support script, for instance. It would be substantial work to implement such a slick feature, it would require ongoing testing and maintenance, and it's overkill for the problem at hand. Adding -f to CMake, CCMake, and CMakeSetup is sufficient. It's simple to implement and requires almost no maintenance. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt!
Brandon Van Every wrote: Example: I have a legacy handwritten GMake client.mk that acquires the build tree from CVS before the main Autoconf generated Makefile is run. The tree is grabbed from CVS and built by typing make -f client.mk. The simplest translation to a CMake system would be cmake -f client.txt. Nobody would be doing a different drill, the client would perceive this as nice, to not have to learn much of anything different. Once the build tree has been acquired, we don't need client.mk anymore. The equivalent of Autoconf's Makefile should always be CMakeLists.txt. But that is not all the patch does. If you do cmake -f client.txt, then every add_subdirectory and subdirs will now look for client.txt. That is not the way make -f works. If you do make -f it just changes the initial makefile that is read into make, after that it is up to the makefile writer to use include, or recursive make to specify additional makefiles that are included. And, cmake -f client.txt would not be the same thing as make -f client.mk, as make -f client.mk would actually do a build. For the cmake, one you would have cmake -f client.txt, make (with no -f). I am still not convinced this is a good idea. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt!
On Jan 14, 2008 9:01 AM, Bill Hoffman [EMAIL PROTECTED] wrote: Brandon Van Every wrote: On Jan 13, 2008 10:04 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Many people will run CMake from a GUI and will not be giving a -f flag. With the patch there would be no way to build a project via one of the GUI's if it required changing the name of the file. cmakesetup and ccmake would also need -f flags. Command line users and scripts could invoke -f flags just fine. Shortcuts on Windows can be made with -f flags in them if people want to present their builds that way. If you had two or more sets of cmake files in the same source tree, how would that work? The same way it works now. Generally, such files are a case of CMake invoking CMake. No offense Brandon, but I would like to here from Martin about how he plans to use this feature. I imagine he will get around to answering for himself, but since I have my own case uses, I will explain mine. I am not sure why you would want to have to co-existing source trees. Example: I have a legacy handwritten GMake client.mk that acquires the build tree from CVS before the main Autoconf generated Makefile is run. The tree is grabbed from CVS and built by typing make -f client.mk. The simplest translation to a CMake system would be cmake -f client.txt. Nobody would be doing a different drill, the client would perceive this as nice, to not have to learn much of anything different. Once the build tree has been acquired, we don't need client.mk anymore. The equivalent of Autoconf's Makefile should always be CMakeLists.txt. This idiom of handwritten GMake files that provide isolated services to a large build tree is endemic to the large codebase I'm working on. cmake -f weirdfile.txt is a nice interface for that. Asking people to learn what CML_NAME means, when it isn't documented anywhere, is not a nice interface. I didn't think it would be unreasonable to expect CMake to use the same command line conventions as nearly every other tool out there. Who *doesn't* use -f for file? I'm surprised at the level of resistance you're offering for a minor feature that's standard design in hundreds of tools. Also, I am not sure the same thing can't be done with if and include. This requires the user to learn a CMake specific idiom, an example of which is not documented anywhere. Do enough of these inelegant workarounds, requiring people to hunt and peck for the answer, and people will rightly turn away from CMake over syntax issues, just not liking how it works, etc. Comprehensive chapter-oriented documentation can mitigate such problems, but it is better to simply do what everyone else does. I also don't see people invoking cmakesetup with any flags, it is a gui program. Scripts may invoke it on behalf of people. People may invoke it if the README.TXT tells them to do so. As I said, in my current codebase the standard way of pulling the source tree from CVS and starting a build is make -f client.mk. I think part of the disconnect here, is you're failing to recognize there's a whole breed of hackers out there that lives and dies by the command line. Sure they'll invoke a gui tool. By typing something on the command line. Please just throw the command line guys a bone. All the cool tools are doing it. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt!
On Jan 14, 2008 12:16 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Brandon Van Every wrote: Example: I have a legacy handwritten GMake client.mk that acquires the build tree from CVS before the main Autoconf generated Makefile is run. The tree is grabbed from CVS and built by typing make -f client.mk. The simplest translation to a CMake system would be cmake -f client.txt. Nobody would be doing a different drill, the client would perceive this as nice, to not have to learn much of anything different. Once the build tree has been acquired, we don't need client.mk anymore. The equivalent of Autoconf's Makefile should always be CMakeLists.txt. But that is not all the patch does. If you do cmake -f client.txt, then every add_subdirectory and subdirs will now look for client.txt. I don't want that. I have trouble seeing sense in that, as I think system differences should be handled with if(APPLE) and so forth, not separate files. Martin could try to explain. And, cmake -f client.txt would not be the same thing as make -f client.mk, as make -f client.mk would actually do a build. For the cmake, one you would have cmake -f client.txt, make (with no -f). Hm. I guess what *I* need is a way to output a different Makefile name. Oh well, back to the drawing board. I wonder what Autoconf does? Or I could translate client.mk to client.txt and make people type cmake -P client.txt. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Patch to apply! Changing the default nameCMakeLists.txt!
It's fine by me to use -f and --file. And if thats what make does then there's even more reason to do so. Should I make that change and make a new patch ? Or if you can put it into cvs it's also fine by me if you make that search / replace. -Martin -Original Message- From: [EMAIL PROTECTED] on behalf of Brandon Van Every Sent: Sun 1/13/2008 6:57 PM To: cmake@cmake.org Subject: Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt! On Jan 13, 2008 12:13 PM, Martin Lütken [EMAIL PROTECTED] wrote: It's a long time since I said I might do this feature. But with the supplied patch it's now possible to use the option '--cmakelists-file-name' to specify another filename to look for instead of 'CMakeLists.txt'. Is a short form single letter version of this command also available? I would recommend -f as it's parallel with Make. I also think --cmakelists-file-name is excessively verbose. --file would be sufficient, although you could retain the longer name also. Here's what Make does: -f FILE, --file=FILE, --makefile=FILE Read FILE as a makefile. I think it's important to respect these nuances / niceties / conventions for command line options. CMake is not a terribly command line oriented tool, but there's a lot of command line oriented people out there that we'd like to convert to CMake. So it would be good if we give them the kinds of things they expect, to the degree that it's easy for us to do so. I think in this case -f is quite easy. Cheers, Brandon Van Every ___ 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] Patch to apply! Changing the default nameCMakeLists.txt!
Ok heres a new patch using '-f' as the option!
-Martin Lütken
-Original Message-
From: [EMAIL PROTECTED] on behalf of Brandon Van Every
Sent: Sun 1/13/2008 6:57 PM
To: cmake@cmake.org
Subject: Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt!
On Jan 13, 2008 12:13 PM, Martin Lütken [EMAIL PROTECTED] wrote:
It's a long time since I said I might do this feature. But with the
supplied
patch it's now possible to use the option '--cmakelists-file-name' to
specify
another filename to look for instead of 'CMakeLists.txt'.
Is a short form single letter version of this command also available?
I would recommend -f as it's parallel with Make. I also think
--cmakelists-file-name is excessively verbose. --file would be
sufficient, although you could retain the longer name also. Here's
what Make does:
-f FILE, --file=FILE, --makefile=FILE
Read FILE as a makefile.
I think it's important to respect these nuances / niceties /
conventions for command line options. CMake is not a terribly command
line oriented tool, but there's a lot of command line oriented people
out there that we'd like to convert to CMake. So it would be good if
we give them the kinds of things they expect, to the degree that it's
easy for us to do so. I think in this case -f is quite easy.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
diff -cr CMake/Source/cmake.cxx CMakeNew/Source/cmake.cxx
*** CMake/Source/cmake.cxx 2008-01-03 13:28:12.0 +0100
--- CMakeNew/Source/cmake.cxx 2008-01-13 17:25:32.0 +0100
***
*** 110,115
--- 110,117
#include memory // auto_ptr
+ const char* cmake::CMAKELISTS_FILE_NAME = CMakeLists.txt;
+
static bool cmakeCheckStampFile(const char* stampName);
void cmNeedBackwardsCompatibility(const std::string variable,
***
*** 644,650
std::string cacheFile = path;
cacheFile += /CMakeCache.txt;
std::string listFile = path;
! listFile += /CMakeLists.txt;
if(cmSystemTools::FileExists(cacheFile.c_str()))
{
cachePath = path;
--- 646,652
std::string cacheFile = path;
cacheFile += /CMakeCache.txt;
std::string listFile = path;
! listFile += std::string(/) + cmake::CMAKELISTS_FILE_NAME;
if(cmSystemTools::FileExists(cacheFile.c_str()))
{
cachePath = path;
***
*** 1723,1736
{
// Make sure the Start directory contains a CMakeLists.txt file.
std::string srcList = this-GetHomeDirectory();
! srcList += /CMakeLists.txt;
if(!cmSystemTools::FileExists(srcList.c_str()))
{
cmOStringStream err;
if(cmSystemTools::FileIsDirectory(this-GetHomeDirectory()))
{
err The source directory \ this-GetHomeDirectory()
!\ does not appear to contain CMakeLists.txt.\n;
}
else if(cmSystemTools::FileExists(this-GetHomeDirectory()))
{
--- 1725,1738
{
// Make sure the Start directory contains a CMakeLists.txt file.
std::string srcList = this-GetHomeDirectory();
! srcList += std::string(/) + cmake::CMAKELISTS_FILE_NAME;
if(!cmSystemTools::FileExists(srcList.c_str()))
{
cmOStringStream err;
if(cmSystemTools::FileIsDirectory(this-GetHomeDirectory()))
{
err The source directory \ this-GetHomeDirectory()
!\ does not appear to contain cmake::CMAKELISTS_FILE_NAME \n;
}
else if(cmSystemTools::FileExists(this-GetHomeDirectory()))
{
***
*** 1753,1761
{
std::string cacheStart =
this-CacheManager-GetCacheValue(CMAKE_HOME_DIRECTORY);
! cacheStart += /CMakeLists.txt;
std::string currentStart = this-GetHomeDirectory();
! currentStart += /CMakeLists.txt;
if(!cmSystemTools::SameFile(cacheStart.c_str(), currentStart.c_str()))
{
std::string message = The source \;
--- 1755,1763
{
std::string cacheStart =
this-CacheManager-GetCacheValue(CMAKE_HOME_DIRECTORY);
! cacheStart += std::string(/) + cmake::CMAKELISTS_FILE_NAME;
std::string currentStart = this-GetHomeDirectory();
! currentStart += std::string(/) + cmake::CMAKELISTS_FILE_NAME;
if(!cmSystemTools::SameFile(cacheStart.c_str(), currentStart.c_str()))
{
std::string message = The source \;
***
*** 3533,3539
std::string inFile = modulesPath;
inFile += /SystemInformation.cmake;
std::string outFile = destPath;
! outFile += /CMakeLists.txt;
// Copy file
if(!cmSystemTools::cmCopyFile(inFile.c_str(), outFile.c_str()))
--- 3535,3541
std::string inFile = modulesPath;
inFile += /SystemInformation.cmake;
std::string outFile = destPath;
! outFile += std::string(/) + cmake::CMAKELISTS_FILE_NAME;
// Copy
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt!
On Jan 13, 2008 1:58 PM, Martin Lütken [EMAIL PROTECTED] wrote: Ok heres a new patch using '-f' as the option! Excellent, thanks! I could actually see a use for this, if it were available in a production version of CMake. The source tree I'm working on has multiple layers of Makefiles in the same directories. Many have names ending in *.mk. The main Makefile is generated by Autoconf, and the *.mk files seem to be used as non-Autoconf subroutines. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Patch to apply! Changing the default nameCMakeLists.txt!
That's great then. Do you know who to address in order to get the patch into the CVS code ? -Martin -Original Message- From: [EMAIL PROTECTED] on behalf of Brandon Van Every Sent: Sun 1/13/2008 8:38 PM To: cmake@cmake.org Subject: Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt! On Jan 13, 2008 1:58 PM, Martin Lütken [EMAIL PROTECTED] wrote: Ok heres a new patch using '-f' as the option! Excellent, thanks! I could actually see a use for this, if it were available in a production version of CMake. The source tree I'm working on has multiple layers of Makefiles in the same directories. Many have names ending in *.mk. The main Makefile is generated by Autoconf, and the *.mk files seem to be used as non-Autoconf subroutines. Cheers, Brandon Van Every ___ 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] Patch to apply! Changing the default nameCMakeLists.txt!
Martin Lütken wrote:
That's great then. Do you know who to address in order to get the patch
into the CVS code ?
Actually, what about something like this:
# CMakeLists.txt
INCLUDE(${CMAKE_CURRENT_SOURCE_DIR}/${CML_NAME})
cmake /path/to/proj -DCML_NAME:STRING=mycmake1.txt
cmake /path/to/proj -DCML_NAME:STRING=mycmake2.txt
No changes needed to CMake at all
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt!
On Jan 13, 2008 4:23 PM, Bill Hoffman [EMAIL PROTECTED] wrote:
Martin Lütken wrote:
That's great then. Do you know who to address in order to get the patch
into the CVS code ?
Actually, what about something like this:
# CMakeLists.txt
INCLUDE(${CMAKE_CURRENT_SOURCE_DIR}/${CML_NAME})
cmake /path/to/proj -DCML_NAME:STRING=mycmake1.txt
cmake /path/to/proj -DCML_NAME:STRING=mycmake2.txt
No changes needed to CMake at all
Not needing to change CMake may be useful for my own purposes, as I
have to ship with production versions of CMake, and I was planning to
wrap command line ugliness in a script anyways. But CMake is changed
all the time in order to better it. I don't see how let's leave well
enough alone is an argument in this case. In terms of command line
elegance, your solution leaves much to be desired over
cmake -f mycmake1.txt
cmake -f mycmake2.txt
Especially in the eyes of the Autoconf + GMake crowd, whom we'd like
to convert. Do you have a serious objection to CMake having a -f
flag?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt!
Brandon Van Every wrote:
On Jan 13, 2008 4:23 PM, Bill Hoffman [EMAIL PROTECTED] wrote:
Martin Lütken wrote:
That's great then. Do you know who to address in order to get the patch
into the CVS code ?
Actually, what about something like this:
# CMakeLists.txt
INCLUDE(${CMAKE_CURRENT_SOURCE_DIR}/${CML_NAME})
cmake /path/to/proj -DCML_NAME:STRING=mycmake1.txt
cmake /path/to/proj -DCML_NAME:STRING=mycmake2.txt
No changes needed to CMake at all
Not needing to change CMake may be useful for my own purposes, as I
have to ship with production versions of CMake, and I was planning to
wrap command line ugliness in a script anyways. But CMake is changed
all the time in order to better it. I don't see how let's leave well
enough alone is an argument in this case. In terms of command line
elegance, your solution leaves much to be desired over
cmake -f mycmake1.txt
cmake -f mycmake2.txt
Especially in the eyes of the Autoconf + GMake crowd, whom we'd like
to convert. Do you have a serious objection to CMake having a -f
flag?
There is already a way to do the same thing. Martin, perhaps if you
discussed the use case better so we could understand what you are trying
to do. Many people will run CMake from a GUI and will not be giving a
-f flag. With the patch there would be no way to build a project via
one of the GUI's if it required changing the name of the file. If you
had two or more sets of cmake files in the same source tree, how would
that work?
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt!
On Jan 13, 2008 10:04 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Many people will run CMake from a GUI and will not be giving a -f flag. With the patch there would be no way to build a project via one of the GUI's if it required changing the name of the file. cmakesetup and ccmake would also need -f flags. Command line users and scripts could invoke -f flags just fine. Shortcuts on Windows can be made with -f flags in them if people want to present their builds that way. If you had two or more sets of cmake files in the same source tree, how would that work? The same way it works now. Generally, such files are a case of CMake invoking CMake. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
