RE: [CMake] PRE_BUILD custom commands don't appear to be working....
I'm going to try that today. From: David Cole [mailto:[EMAIL PROTECTED] Sent: 14 December 2007 18:18 To: Bill Hoffman Cc: Josef Karthauser; cmake@cmake.org Subject: Re: [CMake] PRE_BUILD custom commands don't appear to be working But you should be able to put your custom command in its own custom target and then use ADD_DEPENDENCIES to make the custom target build *before* any build steps for the library... Have you tried that? HTH, David On 12/14/07, Bill Hoffman [EMAIL PROTECTED] wrote: Josef Karthauser wrote: I don't suppose anyone had any thought on this one did they? http://www.cmake.org/HTML/Documentation.html ADD_CUSTOM_COMMAND: Add a custom build rule to the generated build system. Note that the PRE_BUILD option is only supported on Visual Studio 7 or later. For all other generators PRE_BUILD will be treated as PRE_LINK. We have tried, and this is next to impossible to do with a makefile, sorry... -Bill ___ 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
[CMake] FIND_FILE Issue
Hello all,
I'm a newbie to Cmake and I'm having trouble in FIND_FILE.
I'm using FIND_FILE in a loop like this.
SET (${THIS_FILE} INTERNAL Temporary Variable FORCE)
# I Tried this one also
# SET (THIS_FILE INTERNAL Temporary variable FORCE). But this one
threw errors.
FOREACH (ofile ${FILES})
FIND_FILE (THIS_FILE ${ofile} PATHS ${path1} ${path2} ${path3})
MESSAGE (${THIS_FILE})
# I've used MARK_AS_ADVANCED (CLEAR THIS_FILE), but the result was the same.
ENDFOREACH (ofile)
FInd_file runs for the first time and if the file is found it sets the
variable THIS_FILE and it is cached. For the second time, FIND_FILE
does not gets executed due to the presence of cached variable
THIS_FILE. So in the end I end up with only one file.
Questions.
1. How do i clear a cached variable ?
2. How do i tell CMAKE not to write the variable to Cache ?
3. How do i use FIND_FILE to locate multiple files (like the one I've
explained above)?
Thanks in advance,
Surya
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] PRE_BUILD custom commands don't appear to be working....
-Original Message- From: Bill Hoffman [mailto:[EMAIL PROTECTED] Sent: 14 December 2007 14:16 To: Josef Karthauser Cc: cmake@cmake.org Subject: Re: [CMake] PRE_BUILD custom commands don't appear to be working Josef Karthauser wrote: I don't suppose anyone had any thought on this one did they? http://www.cmake.org/HTML/Documentation.html ADD_CUSTOM_COMMAND: Add a custom build rule to the generated build system. Note that the PRE_BUILD option is only supported on Visual Studio 7 or later. For all other generators PRE_BUILD will be treated as PRE_LINK. We have tried, and this is next to impossible to do with a makefile, sorry... I was thinking, could you please make cmake generate a warning when PRE_BUILD is used and it knows that it can't implement it? That would go a long way to resolving this. If someone is relying on its behaviour, and then uses a generator that doesn't support it, it's good for them to know at cmake time. Joe ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] premake build system
Filipe Sousa wrote: For those who love lua and want a build system there is premake http://industriousone.com/premake And I know that there is another build system that uses lua but I can't find the link. premake3/4 is tiny and its syntax is *really* nice. What's similar to cmake: - It creates Makefiles or IDE projects. What's better than cmake (imho): - Language syntax. - You can easily add command-line flags like autotools. - Install options match autotools. - Tiny (only a couple of secs to compile it from source). - Written in C (more easily ported than cmake). - Makefiles generated are simple, readable and faster. - C code is very readable and easy to follow. - Uses relative paths. What's worse: - No dependency checking on .h files at all (yuck). - Out-of-source builds is a property of the premake.lua script (yuck). - Verbose builds is a feature of premake, not the Makefile, meaning you need to regenerate the makefile each time to get verbose output (yuck). - No find_path or find_include - No cross-platform modules for better support. - Small language and compiler support. - No coloring of builds. - No testing framework. - No packaging framework. (what they call dopackage is really doinstall) - C code is a tad disorganized. - No listing of make targets (no make help). I really like it much better than the scons derivatives, but the lack of proper dependency checking is a killer. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Xubuntu Gutsy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CPack install directory
Hi, I am using CPack with DEB generator. My install dir is in /work/install/Project and I have a usr and a etc dir installed. But the debian package generated by CPack inserts a usr directory so I get my usr in usr/usr and my etc in /usr/etc. I don't manage to understand why and where is inserted this directory. Any idea how I could remove it? Thanks very much! Raph ps: I am using cmake and cpack version 2.5-20071214. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creation of CMAKE_*_LIBRARY_EXTENSION
On Dec 16, 2007 10:04 PM, Rodolfo Lima [EMAIL PROTECTED] wrote:
I've been playing around with bug #5997 and I've found out the problem,
which lies in the fact that when the user sees the variable
CMAKE_(STATIC|SHARED|IMPORT)_LIBRARY_SUFFIX, he assumes that this is
something to be added to the library name (doesn't involve its
extension). But cmake assumes that this is the library's extension.
Wouldn't it be better to create a CMAKE_*_LIBRARY_EXTENSION to have
either '.lib' or '.a', and let CMAKE_*_LIBRARY_SUFFIX just be what its
name means? For cmake, the library name (including extension) would be:
${CMAKE_*_LIBRARY_PREFIX}${libname}${CMAKE_*_LIBRARY_SUFFIX}${CMAKE_*_LIBRARY_EXTENSION)
Backwards compatibility sez we're stuck with CMAKE_*_LIBRARY_SUFFIX
meaning what it currently means. CMAKE_*_LIBRARY_EXTENSION could be a
documented synonym for it. CMAKE_*_LIBRARY_SUFFIX could be moved to
the depreciated section of the docs, but its behavior would remain
unaltered.
CMAKE_*_LIBRARY_POSTFIX could serve the purpose of _d and so forth.
This is parallel with the meaning of CONFIG_POSTFIX in the docs.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Creation of CMAKE_*_LIBRARY_EXTENSION
Brandon Van Every escreveu: CMAKE_*_LIBRARY_POSTFIX could serve the purpose of _d and so forth. This is parallel with the meaning of CONFIG_POSTFIX in the docs. I didn't know about CONFIG_POSTFIX. The documentation says that it is used for all targets, including libraries, isn't it? So CMAKE_*_LIBRARY_POSTFIX would be a good addition to cmake indeed. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] premake build system
On Dec 17, 2007 5:46 AM, Gonzalo Garramuño [EMAIL PROTECTED] wrote: premake3/4 is tiny and its syntax is *really* nice. What's better than cmake (imho): - Tiny (only a couple of secs to compile it from source). - Written in C (more easily ported than cmake). What's worse: - [lots of stuff] You get what you pay for. These 1 person projects are never going to compete with CMake, frankly. They don't have the engineering resources to ever do it. Show me a tool that does something CMake *can't* do, or does badly. That's what I'm looking for when I ask the OO question. Things that CMake can't do are potential strategic threats. Nicer syntax is not. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] BOOL type
I propose the addition of a BOOL type to the CMake language.
bool(variable [value])
would declare a variable of type BOOL, with an optional value
supplied. Any SET commands performed on the variable in its scope
would be subject to boolean type constraint. A BOOL can take on the
following values. Any other assignment is an error.
TRUE class - TRUE, 1, Y, Yes, YES, y, yes, ON
FALSE class - FALSE, 0, N, n, No, NO, OFF, empty
if(bool_var) would succeed if bool_var is set to a member of the TRUE
class. It would fail if set to a member of the FALSE class. Equality
comparison would be by boolean class, not the specific boolean value.
The following code succeeds:
set(bool_var ON)
[...]
if(bool_var EQUAL Yes)
# this code is executed
The above functionality could be added without affecting legacy CMake
script in any way.
In addition, a variable CMAKE_REQUIRE_BOOL, or some other appropriate
interface, would be provided. If set(CMAKE_REQUIRE_BOOL TRUE) is
performed, then instead of if(some_string) failing when some_string
has a value of:
empty, 0, N, NO, OFF, FALSE, NOTFOUND, or variable-NOTFOUND
it fails when some_string has a value of:
empty, 0, NOTFOUND, or variable-NOTFOUND
The intent is to reduce the level of co-option / pollution in string
processing. Under the current rules, it is fairly easy for a regex to
inadvertently fail:
set(sillystring The rain in spain)
string(REGEX MATCH
.$
lastchar ${sillystring})
if(NOT lastchar)
message(Zero length string)
endif(NOT lastchar)
C:\devel\src\cbugs\trueorfalsecmake -P trueorfalse.cmake
Zero length string
NOTFOUND and variable-NOTFOUND are considered acceptable string
pollutions, because they are significantly longer and unlikely to be
matched in typical string processing. 0 is problematic, as it is a
single character like n. A similar proposal for a NUMBER data type,
and CMAKE_REQUIRE_NUMBER, could be used to eliminate the problem of
the 0.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Adding a header dependency on a generated header file. (was PRE_BUILD custom commands don't appear to be working....)
So, I've created a new target to generate the header, and made the library target depend upon it. How do I now make sure that the generated header is considered in the dependency checks for the objects build from the CPP files that #include it? Joe From: David Cole [mailto:[EMAIL PROTECTED] Sent: 14 December 2007 18:18 To: Bill Hoffman Cc: Josef Karthauser; cmake@cmake.org Subject: Re: [CMake] PRE_BUILD custom commands don't appear to be working But you should be able to put your custom command in its own custom target and then use ADD_DEPENDENCIES to make the custom target build *before* any build steps for the library... Have you tried that? HTH, David On 12/14/07, Bill Hoffman [EMAIL PROTECTED] wrote: Josef Karthauser wrote: I don't suppose anyone had any thought on this one did they? http://www.cmake.org/HTML/Documentation.html ADD_CUSTOM_COMMAND: Add a custom build rule to the generated build system. Note that the PRE_BUILD option is only supported on Visual Studio 7 or later. For all other generators PRE_BUILD will be treated as PRE_LINK. We have tried, and this is next to impossible to do with a makefile, sorry... -Bill ___ 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
[CMake] Re: BOOL type
On Dec 17, 2007 9:17 AM, Brandon Van Every [EMAIL PROTECTED] wrote: Equality comparison would be by boolean class, not the specific boolean value. The following code succeeds: set(bool_var ON) [...] if(bool_var EQUAL Yes) # this code is executed That's not the best example as if(bool_var) would have sufficed. Instead consider: bool(v1 ON) bool(v2 Yes) [...] if(v1 EQUAL v2) # this code is executed Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding a header dependency on a generated header file. (was PRE_BUILD custom commands don't appear to be working....)
Josef,
Here's what I do. The fooCLP.h file is generated by a custom command.
# mark the .clp file as a header file
SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_BINARY_DIR}/${TMP_FILENAME}CLP.h
PROPERTIES HEADER_FILE_ONLY TRUE)
SET_SOURCE_FILES_PROPERTIES(${TMP_FILENAME}.cxx PROPERTIES
OBJECT_DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${TMP_FILENAME}CLP.h)
Bill
On Dec 17, 2007 9:53 AM, Josef Karthauser [EMAIL PROTECTED]
wrote:
So, I've created a new target to generate the header, and made the
library target depend upon it. How do I now make sure that the generated
header is considered in the dependency checks for the objects build from the
CPP files that #include it?
Joe
*From:* David Cole [mailto:[EMAIL PROTECTED]
*Sent:* 14 December 2007 18:18
*To:* Bill Hoffman
*Cc:* Josef Karthauser; cmake@cmake.org
*Subject:* Re: [CMake] PRE_BUILD custom commands don't appear to be
working
But you should be able to put your custom command in its own custom target
and then use ADD_DEPENDENCIES to make the custom target build *before* any
build steps for the library...
Have you tried that?
HTH,
David
On 12/14/07, *Bill Hoffman* [EMAIL PROTECTED] wrote:
Josef Karthauser wrote:
I don't suppose anyone had any thought on this one did they?
http://www.cmake.org/HTML/Documentation.html
ADD_CUSTOM_COMMAND: Add a custom build rule to the generated build system.
Note that the PRE_BUILD option is only supported on Visual Studio 7 or
later. For all other generators PRE_BUILD will be treated as PRE_LINK.
We have tried, and this is next to impossible to do with a makefile,
sorry...
-Bill
___
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
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] premake build system
Brandon Van Every wrote: On Dec 17, 2007 5:46 AM, Gonzalo Garramuño [EMAIL PROTECTED] wrote: premake3/4 is tiny and its syntax is *really* nice. ... Show me a tool that does something CMake *can't* do, or does badly. ... Well, in the quote that you did not keep, I posted that premake *is* a good example of a couple of things cmake cannot do (command-line flags and OO). And syntax is certainly one of the things cmake does badly. Bad support (lack of, really) for relative paths is another weakness in cmake. So premake is definitively a good example for what you want. To be honest, if premake did dependencies right (or at least like waf does), I would certainly consider it as a valid alternative to cmake. When Alex was asking about what for? in another thread, I think my quick eval of other systems proves to me your quest is not in vain. I honestly don't think it will take 10 more years for a tool to match the benefits of cmake with a better syntax. As I have said before, I think it is only 3 or so years away from happening. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Xubuntu Gutsy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: premake build system
Gonzalo Garramuño escreveu: I honestly don't think it will take 10 more years for a tool to match the benefits of cmake with a better syntax. As I have said before, I think it is only 3 or so years away from happening. What bugs me is the fact that cmake achieves like 90% of build system features that I'd consider important to have. Better scripting and autotools's configure parameters (--enable-debug, --without-something) is what I miss the most. So, apart of forking, a build system that wants to be better than cmake should reimplement 90% of cmake's features, just to add those 10% missing? Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Retrieving target's sources and libraries
First of all, thanks for the relatively quick commit of this feature to
cmake-cvs!
Brad King escreveu:
Thanks, we're looking at the patch. We typically have constructed the
set of source files for a target in a variable so they can be used later:
SET(mylib_SOURCES
mylib1.c
mylib2.c
)
ADD_LIBRARY(mylib ${mylib_SOURCES})
SET_SOURCE_FILES_PROPERTIES(${mylib_SOURCES} PROPERTIES ...)
As I'm creating a macro to enable pch support, I cannot force the user
to use a variable to store the target's source, I must get it directly
using the target's name.
There is help for you in CVS CMake. We've added some primitives that
make implementing PCH possible, though there is not yet an interface
making it a first-class feature.
Thank you very much for your pointers. My macro is based on the one
attached to the bug report #1260. The main difference is that my macro
tries to minimize the number of precompiled headers created.
For instance, suppose you have 2 targets that use the same header, and
have the same compiler flags. My solution would create only one
precompiled header for both targets, while the former macro would create
two.
Any further suggestions are welcome.
Regards,
rod
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: premake build system
On Monday 17 December 2007, Rodolfo Schulz de Lima wrote: Gonzalo Garramuño escreveu: I honestly don't think it will take 10 more years for a tool to match the benefits of cmake with a better syntax. As I have said before, I think it is only 3 or so years away from happening. What bugs me is the fact that cmake achieves like 90% of build system features that I'd consider important to have. Better scripting and autotools's configure parameters (--enable-debug, --without-something) is what I miss the most. I see two options: If you can find some spare time, there is a command argument parser in CMake/Source/kwsys/, which is used e.g. by cpack, but not (yet) by cmake. Using this in cmake is the first step in getting better support for custom command line parameters. A patch would be very welcome. Currently I don't have the time. Second idea: maybe it would already help if the command line arguments to cmake would be available via a special cmake variable. Is there anything which speaks against this, Bill ? Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FIND_FILE Issue
On Monday 17 December 2007, Surya Kiran Gullapalli wrote:
Hello all,
I'm a newbie to Cmake and I'm having trouble in FIND_FILE.
I'm using FIND_FILE in a loop like this.
SET (${THIS_FILE} INTERNAL Temporary Variable FORCE)
# I Tried this one also
# SET (THIS_FILE INTERNAL Temporary variable FORCE). But this one
threw errors.
FOREACH (ofile ${FILES})
FIND_FILE (THIS_FILE ${ofile} PATHS ${path1} ${path2} ${path3})
MESSAGE (${THIS_FILE})
# I've used MARK_AS_ADVANCED (CLEAR THIS_FILE), but the result was the
same. ENDFOREACH (ofile)
FInd_file runs for the first time and if the file is found it sets the
variable THIS_FILE and it is cached. For the second time, FIND_FILE
does not gets executed due to the presence of cached variable
THIS_FILE. So in the end I end up with only one file.
Questions.
1. How do i clear a cached variable ?
You can set the variable to NOTFOUND (and FORCE it in the cache) to make
FIND_XXX() run again.
But I think you shouldn't do this, it's a feature.
Why do you use FIND_XXX() multiple times with the same variable ?
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Parsing cmake command line parameters
Alexander Neundorf escreveu: If you can find some spare time, there is a command argument parser in CMake/Source/kwsys/, which is used e.g. by cpack, but not (yet) by cmake. Using this in cmake is the first step in getting better support for custom command line parameters. A patch would be very welcome. Currently I don't have the time. I think I'll have some spare time to do this on this weekend, I'd be glad to help if there's enough coordination to avoid unnecessary work duplication. Second idea: maybe it would already help if the command line arguments to cmake would be available via a special cmake variable. Is there anything which speaks against this, Bill ? IMHO, we should differentiate between --enable/--disable and --with/--without, like it is on autotools' configure. The former used to enable/disable features, the other to compile with/without some external library. There's also the ubiquitous --prefix that should be mapped to CMAKE_INSTALL_PREFIX, and the others that commonly appear when we execute 'configure --help'. It should be nice to have a framework to facilitate working with enable/disable and with/without. The other common arguments that maps to cmake variables should be set up by default. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: premake build system
Rodolfo Schulz de Lima wrote: So, apart of forking, a build system that wants to be better than cmake should reimplement 90% of cmake's features, just to add those 10% missing? Kind of. Not really 90%, but more like 60-70%. It would first have to: * gotten dependencies correct (this is really hard). * be fast in every aspect (hard without coding it in c/c++). * be multi-platform. Without those three, nothing else matters. Once those are okay, you need to: * support a couple of languages (say c++ and java). * have an easy to extend (and well defined) framework. If, say, swig is not supported, but the framework is defined, someone else should be able to write a module for it. * support a couple of common IDEs and compilers (mainly gcc and msvc). Others will appear as need arises. * have support to find files on disk (includes, libs, exes). * have decent docs or at least a bunch of examples. * be well supported with a mailing list (and not a dead one like jam). Getting all that right is *HARD* and can easily be a full-time job. Most of cmake competitors have not yet full-filled all of the above. Ergo, why cmake still rules. Additional components like cpack or ctest are a plus, but they are not a major reason for sticking with cmake. While a large amount of cmake's modules is nice when you start with it, it is not a deal breaker if the framework is good (and a good OO framework should be better than what cmake does with FIND_PACKAGE). Things that would also earn tons of brownie points would be: * smaller than cmake (both to compile and distribute). * good for cross-compilation. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Xubuntu Gutsy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: premake build system
Rodolfo Schulz de Lima wrote: Gonzalo Garramuño escreveu: I honestly don't think it will take 10 more years for a tool to match the benefits of cmake with a better syntax. As I have said before, I think it is only 3 or so years away from happening. It is harder than you think, but maybe you are right. If you look at Ohloh: http://www.ohloh.net/projects/3238?p=CMake It shows CMake as a 51 person year project at a cost of 2.7 million. That may not actually be far from the mark... What bugs me is the fact that cmake achieves like 90% of build system features that I'd consider important to have. Better scripting and autotools's configure parameters (--enable-debug, --without-something) is what I miss the most. Command line options have been a feature request for some time. If someone comes up with a good way to do them, I have no problem putting them in CMake. I guess the problem has always been the iterative nature of the CMakeCache.txt file. --help has to basically run the entire build script to find all the arguments. So, no need to fork on this. If there is something you can not do with the current cmake language that could be done in lua (other than aesthetics), let us know, and provide a patch, or even a report, and most likely we will put it in CMake. So, no need to fork here... So, apart of forking, a build system that wants to be better than cmake should reimplement 90% of cmake's features, just to add those 10% missing? I would say add the 10% to the current CMake. I think we (cmake developers) are very open to adding new and useful things to CMake. Complete tested patches are always welcome. Before wasting time on creating one, it is a good idea to discuss the idea on the list to make sure there is buy in. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FIND_FILE Issue
On 2007-12-17 14:55+0530 Surya Kiran Gullapalli wrote:
Hello all,
I'm a newbie to Cmake and I'm having trouble in FIND_FILE.
I'm using FIND_FILE in a loop like this.
SET (${THIS_FILE} INTERNAL Temporary Variable FORCE)
# I Tried this one also
# SET (THIS_FILE INTERNAL Temporary variable FORCE). But this one
threw errors.
FOREACH (ofile ${FILES})
FIND_FILE (THIS_FILE ${ofile} PATHS ${path1} ${path2} ${path3})
MESSAGE (${THIS_FILE})
# I've used MARK_AS_ADVANCED (CLEAR THIS_FILE), but the result was the same.
ENDFOREACH (ofile)
FInd_file runs for the first time and if the file is found it sets the
variable THIS_FILE and it is cached. For the second time, FIND_FILE
does not gets executed due to the presence of cached variable
THIS_FILE. So in the end I end up with only one file.
Questions.
1. How do i clear a cached variable ?
2. How do i tell CMAKE not to write the variable to Cache ?
3. How do i use FIND_FILE to locate multiple files (like the one I've
explained above)?
Try setting VAR to VAR-NOTFOUND (i.e., set(THIS_FILE THIS_FILE-NOTFOUND)
before each FIND_FILE in the loop. For some additional documentation of
VAR-NOTFOUND see the FIND_FILE documentation.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: premake build system
Gonzalo Garramuño wrote: * good for cross-compilation. CVS CMake (and the coming 2.6 CMake) have extensive support for cross compilation. http://www.cmake.org/Wiki/CMake_Cross_Compiling -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: premake build system
Bill Hoffman escreveu: Command line options have been a feature request for some time. If someone comes up with a good way to do them, I have no problem putting them in CMake. I guess the problem has always been the iterative nature of the CMakeCache.txt file. --help has to basically run the entire build script to find all the arguments. So, no need to fork on this. Maybe not that much... I think it'll suffice to traverse the build tree analyzing the CMakeLists.txt, looking for argument definitions. That's pretty quick in C++. If there is something you can not do with the current cmake language that could be done in lua (other than aesthetics), let us know, and provide a patch, or even a report, and most likely we will put it in CMake. So, no need to fork here... As I've said somewhere, I'm working on a macro to support precompiled headers. To do it properly, cmake should be a little more than a build system language. You might say that if I want something more elaborate, I could do it in C/C++ and add the command to cmake using load_command. But you cannot expect that everyone with a specific need should know a complex language like C++. I right now need some kind of mapping data structure, like C++'s std::map, to record whether I've already created a pch file with certain flags, and what is its output name. I could do it easily with Lua because it supports common programming structures (a map, which it supports natively). But I'm stuck with cmake and must do ugly, non-optimal (speed-wise) things to simulate this behavior. I would say add the 10% to the current CMake. I think we (cmake developers) are very open to adding new and useful things to CMake. Complete tested patches are always welcome. Before wasting time on creating one, it is a good idea to discuss the idea on the list to make sure there is buy in. Thanks Bill, this is the attitude that made me come to cmake, after reading all good things written by KDE people about it and Kitware. In the end, the users will have the best build system ever, and Kitware will have a superb visibility (i.e., money coming in...). Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: premake build system
Bill Hoffman escreveu: CVS CMake (and the coming 2.6 CMake) have extensive support for cross compilation. http://www.cmake.org/Wiki/CMake_Cross_Compiling And I'm using it every day with success. I think there should be some common toolchain files, for instance, to compile to mingw32 target, etc. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: premake build system
Bill Hoffman wrote: Gonzalo Garramuño wrote: * good for cross-compilation. CVS CMake (and the coming 2.6 CMake) have extensive support for cross compilation. http://www.cmake.org/Wiki/CMake_Cross_Compiling I'm still having a lot of problems with it. Even cross-compiling on a 64-bit machine for 32-bit builds is, afaik, not really possible without major hacking of Platform/UnixPaths. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Xubuntu Gutsy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: premake build system
On Monday 17 December 2007, Rodolfo Schulz de Lima wrote:
Bill Hoffman escreveu:
Command line options have been a feature request for some time. If
someone comes up with a good way to do them, I have no problem putting
them in CMake. I guess the problem has always been the iterative nature
of the CMakeCache.txt file. --help has to basically run the entire
build script to find all the arguments. So, no need to fork on this.
Maybe not that much... I think it'll suffice to traverse the build tree
analyzing the CMakeLists.txt, looking for argument definitions. That's
pretty quick in C++.
I don't think so.
analyzing the CMakeLists.txt means executing them basically completely.
See the following pseudocode:
if(WIN32)
define some args
else
define some other args
endif
execute_process(foo result)
if(result)
define more args
endif
find_package(Bar)
if (BAR_FOUND)
add_subdirectory(subdir) more args defined in subdir
endif
If there is something you can not do with the current cmake language
that could be done in lua (other than aesthetics), let us know, and
provide a patch, or even a report, and most likely we will put it in
CMake. So, no need to fork here...
As I've said somewhere, I'm working on a macro to support precompiled
headers. To do it properly, cmake should be a little more than a build
Oh, I think some cmake devs are on that too but there were some problems or it
didn't gain a lot... not sure.
I right now need some kind of mapping data structure, like C++'s
std::map, to record whether I've already created a pch file with certain
flags, and what is its output name. I could do it easily with Lua
because it supports common programming structures (a map, which it
supports natively). But I'm stuck with cmake and must do ugly,
non-optimal (speed-wise) things to simulate this behavior.
Yes, you can get map-like behaviour by using just variables:
SET(MY_MAP_${KEY} myValue)
Bye
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: premake build system
On Monday 17 December 2007, Gonzalo Garramuño wrote: Bill Hoffman wrote: Gonzalo Garramuño wrote: * good for cross-compilation. CVS CMake (and the coming 2.6 CMake) have extensive support for cross compilation. http://www.cmake.org/Wiki/CMake_Cross_Compiling I'm still having a lot of problems with it. Even cross-compiling on a 64-bit machine for 32-bit builds is, afaik, not really possible without major hacking of Platform/UnixPaths. Ok, what are you doing exactly, what are the problems ? Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] BOOL type
To supplement Brandon's Boolean wishlist, I would like to see some way to specify a non-default precedence of Boolean operators. Most languages use parentheses for this, and ideally that would be true for CMake as well. Then a test of Boolean inequality of A and B would be IF((A AND NOT B) OR (NOT A AND B)) and a test for Boolean equality of A and B would be IF((NOT A OR B) AND (A OR NOT B)) Perhaps CMake already has this feature but it is not documented? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: premake build system
Alexander Neundorf escreveu:
I don't think so.
analyzing the CMakeLists.txt means executing them basically completely.
See the following pseudocode:
if(WIN32)
define some args
else
define some other args
endif
You're right, I didn't give it much thought it deserves.
Oh, I think some cmake devs are on that too but there were some problems or it
didn't gain a lot... not sure.
Well, at least on linux I've been working with pch since cmake-2.4.7,
albeit in a not so optimal way.
I right now need some kind of mapping data structure, like C++'s
std::map, to record whether I've already created a pch file with certain
flags, and what is its output name. I could do it easily with Lua
because it supports common programming structures (a map, which it
supports natively). But I'm stuck with cmake and must do ugly,
non-optimal (speed-wise) things to simulate this behavior.
Yes, you can get map-like behaviour by using just variables:
SET(MY_MAP_${KEY} myValue)
That's a good trick, thanks. Those caveats should be written somewhere.
Regards,
rod
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] map structure on cmake script
Alexander Neundorf escreveu:
Yes, you can get map-like behaviour by using just variables:
SET(MY_MAP_${KEY} myValue)
That's fine if ${KEY} doesn't have spaces nor characters that aren't
allowed in variable names. As I'm using a string containing compiler
flags and stuff, this solution isn't possible. A workaround would be
computing a hash from the string and using it as a key, but once again,
it'd be a pain in the *** to do it in cmake script.
Regards,
rod
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: premake build system
Bill Hoffman wrote: It is harder than you think, but maybe you are right. If you look at Ohloh: http://www.ohloh.net/projects/3238?p=CMake It shows CMake as a 51 person year project at a cost of 2.7 million. That may not actually be far from the mark... Well, following the same standard, imagine if you were using a common language like Ruby which is 125 person year project at a cost of 6 million. You'd have had 4 million to spare and 50+ additional year/developers to begin with even before you wrote your first cmake line! -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Xubuntu Gutsy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: premake build system
Gonzalo Garramuño wrote: Bill Hoffman wrote: Gonzalo Garramuño wrote: * good for cross-compilation. CVS CMake (and the coming 2.6 CMake) have extensive support for cross compilation. http://www.cmake.org/Wiki/CMake_Cross_Compiling I'm still having a lot of problems with it. Even cross-compiling on a 64-bit machine for 32-bit builds is, afaik, not really possible without major hacking of Platform/UnixPaths. I will wait for Alex to answer, but I would suggest working with him directly. He has been able to cross compile a bunch of stuff quite well. ParaView/VTK on Cray super computers. FLTK on linux for windows, and other things. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [Spam] Re: [CMake] Re: premake build system
Alexander Neundorf wrote: On Monday 17 December 2007, Gonzalo Garramuño wrote: Bill Hoffman wrote: Gonzalo Garramuño wrote: * good for cross-compilation. CVS CMake (and the coming 2.6 CMake) have extensive support for cross compilation. http://www.cmake.org/Wiki/CMake_Cross_Compiling I'm still having a lot of problems with it. Even cross-compiling on a 64-bit machine for 32-bit builds is, afaik, not really possible without major hacking of Platform/UnixPaths. Ok, what are you doing exactly, what are the problems ? First, trying simple 32-bit compiles on a 64-bit machine (Ubuntu OS). For 32-bit compiles on a 64-bit machine, the problem is that UnixPaths does not change the location where it searches for files. First, CMAKE_SYSTEM_LIBRARY_PATH is set incorrectly to always search lib/ paths instead of lib32/ or lib64/ paths. This will create warnings for the most part as the linker is usually smart. However, if a library is not present on 32-bits, the 64-bits file will get picked up and the problem will only appear show up when linking, not during configuration. CMAKE_SYSTEM_PROGRAM_PATH also suffers from a similar issue. This is an issue with modules that use pkgconfig, for example or that set settings from finding executables like ruby. It isn't entirely clear to me if there is a standard location for 32-bit bin files (not libs) in Linux, thou. CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES is also wrong, adding both 64 and 32 bits paths. Afaik, there's no variable indicating whether to compile for 32bits or not. And cmake does not check for the -m32 flag at all. I have my own UnixPaths and modules to work around most of the above, but it would be good to have this working out of the box. Recent versions of cmake seem to have also added this: # Enable use of lib64 search path variants by default. SET_PROPERTIES(GLOBAL PROPERTIES FIND_LIBRARY_USE_LIB64_PATHS TRUE) which seems highly undesirable or a so far undocumented feature. --- For cross-compiling, I was trying to do some compiles from my Unix box to windows using a unix-mingw32 to windows toolchain. I was utterly unsuccessful. I just kept fixing one error only to find another one. I had followed the cmake wiki for cross-compiling, but there were still many issues with paths in modules and the like. If you want to walk me thru it, I'll start a new thread with the errors I find as I go thru it again. Mind you, the stuff I want to compile has many dependencies, so it is a hard thing to do. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Xubuntu Gutsy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [Spam] Re: [CMake] Re: premake build system
Gonzalo Garramuño wrote: Alexander Neundorf wrote: On Monday 17 December 2007, Gonzalo Garramuño wrote: Bill Hoffman wrote: Gonzalo Garramuño wrote: * good for cross-compilation. CVS CMake (and the coming 2.6 CMake) have extensive support for cross compilation. http://www.cmake.org/Wiki/CMake_Cross_Compiling I'm still having a lot of problems with it. Even cross-compiling on a 64-bit machine for 32-bit builds is, afaik, not really possible without major hacking of Platform/UnixPaths. Ok, what are you doing exactly, what are the problems ? First, trying simple 32-bit compiles on a 64-bit machine (Ubuntu OS). For 32-bit compiles on a 64-bit machine, the problem is that UnixPaths does not change the location where it searches for files. Are you using setarch i386 cmake ? That should help by forcing uname to advertise the architecture as 32-bit. David ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] BOOL type
On Dec 17, 2007 2:19 PM, Alan W. Irwin [EMAIL PROTECTED] wrote: To supplement Brandon's Boolean wishlist, I would like to see some way to specify a non-default precedence of Boolean operators. Most languages use parentheses for this, and ideally that would be true for CMake as well. Perhaps CMake already has this feature but it is not documented? No it doesn't. CMake doesn't accept sub-parentheses in conditionals. I found this out when automatically translating a pile of parentheses from Autoconf. Aside from being convenient to programmers, it would make migrations from Autoconf easier. I had to write a substantial body of code to do it. If the feature were present, translation would be much more 1:1 and easier to implement. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] map structure on cmake script
On Dec 17, 2007 2:29 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote: A workaround would be computing a hash from the string and using it as a key, but once again, it'd be a pain in the *** to do it in cmake script. I wouldn't shy away from trying it though. I wrote a regex negation operator in CMake script to work around CMake's limitations. The algorithm for negation construction had some complications, but it wasn't rocket science. The code wasn't that long in the scheme of things, and the speed was just fine. You might not expect acceptable performance from a mere scripting language, but on a 2 GHz machine it mostly doesn't matter. I've also been surprised at how many regexes I can throw at a variable over and over and over again, without degrading performance too badly. You can use a homebrew hash as a prototypical basis for a more official CMake capability someday. In my case, because I wrote the regex negation operator and other string handling extensions, I have a pretty good idea what a PCRE-based regex interface should look like. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: premake build system
On Monday 17 December 2007, you wrote: Alexander Neundorf wrote: On Monday 17 December 2007, Gonzalo Garramuño wrote: Bill Hoffman wrote: Gonzalo Garramuño wrote: * good for cross-compilation. CVS CMake (and the coming 2.6 CMake) have extensive support for cross compilation. http://www.cmake.org/Wiki/CMake_Cross_Compiling I'm still having a lot of problems with it. Even cross-compiling on a 64-bit machine for 32-bit builds is, afaik, not really possible without major hacking of Platform/UnixPaths. Ok, what are you doing exactly, what are the problems ? First, trying simple 32-bit compiles on a 64-bit machine (Ubuntu OS). I'm not sure this really counts as cross compiling. Two basic assumptions were -the executables for the target cannot run (in general) on the build host -the target environment is completely different from the build host environment, i.e. with its own set of libraries and headers located in a separate subtree (as it is the case for embedded linux, Win CE, eCos, sdcc, AD compilers, Cray compilers etc.) This is not really the case here. I think there is a bug report about chosing these variants you need correctly. For 32-bit compiles on a 64-bit machine, the problem is that UnixPaths does not change the location where it searches for files. First, CMAKE_SYSTEM_LIBRARY_PATH is set incorrectly to always search lib/ paths instead of lib32/ or lib64/ paths. This will create warnings for the most part as the linker is usually smart. However, if a library is not present on 32-bits, the 64-bits file will get picked up and the problem will only appear show up when linking, not during configuration. CMAKE_SYSTEM_PROGRAM_PATH also suffers from a similar issue. This is an issue with modules that use pkgconfig, for example or that set settings from finding executables like ruby. It isn't entirely clear to me if there is a standard location for 32-bit bin files (not libs) in Linux, thou. CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES is also wrong, adding both 64 and 32 bits paths. Afaik, there's no variable indicating whether to compile for 32bits or not. And cmake does not check for the -m32 flag at all. CMAKE_SIZEOF_VOID_P Maybe this should be honored more extensive ? But this is an issue more for Brad (or Bill) ? I have my own UnixPaths and modules to work around most of the above, Can you please post it ? but it would be good to have this working out of the box. Yes. Recent versions of cmake seem to have also added this: # Enable use of lib64 search path variants by default. SET_PROPERTIES(GLOBAL PROPERTIES FIND_LIBRARY_USE_LIB64_PATHS TRUE) which seems highly undesirable or a so far undocumented feature. Brad, Bill ? --- For cross-compiling, I was trying to do some compiles from my Unix box to windows using a unix-mingw32 to windows toolchain. I was utterly unsuccessful. I just kept fixing one error only to find another one. I had followed the cmake wiki for cross-compiling, but there were still many issues with paths in modules and the like. If you want to walk me thru it, I'll start a new thread with the errors I find as I go thru it again. Yes, please. It should work and I'm happy about feedback. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: map structure on cmake script
Brandon Van Every escreveu: On Dec 17, 2007 2:29 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote: A workaround would be computing a hash from the string and using it as a key, but once again, it'd be a pain in the *** to do it in cmake script. I wouldn't shy away from trying it though. I wrote a regex negation operator in CMake script to work around CMake's limitations. The No... too difficult for not so much gain. I can live with a braindead solution (using lists) until cmake supports *cough* lua *cough*. :) Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] BOOL type
On Monday 17 December 2007, Brandon Van Every wrote: On Dec 17, 2007 2:19 PM, Alan W. Irwin [EMAIL PROTECTED] wrote: To supplement Brandon's Boolean wishlist, I would like to see some way to specify a non-default precedence of Boolean operators. Most languages use parentheses for this, and ideally that would be true for CMake as well. Perhaps CMake already has this feature but it is not documented? No it doesn't. CMake doesn't accept sub-parentheses in conditionals. I found this out when automatically translating a pile of parentheses from Autoconf. Aside from being convenient to programmers, it would Yes, this would indeed be very nice. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [Spam] Re: [CMake] Re: premake build system
David C Thompson wrote: Gonzalo Garramuño wrote: Alexander Neundorf wrote: On Monday 17 December 2007, Gonzalo Garramuño wrote: Bill Hoffman wrote: Gonzalo Garramuño wrote: * good for cross-compilation. CVS CMake (and the coming 2.6 CMake) have extensive support for cross compilation. http://www.cmake.org/Wiki/CMake_Cross_Compiling I'm still having a lot of problems with it. Even cross-compiling on a 64-bit machine for 32-bit builds is, afaik, not really possible without major hacking of Platform/UnixPaths. Ok, what are you doing exactly, what are the problems ? First, trying simple 32-bit compiles on a 64-bit machine (Ubuntu OS). For 32-bit compiles on a 64-bit machine, the problem is that UnixPaths does not change the location where it searches for files. Are you using setarch i386 cmake ? That should help by forcing uname to advertise the architecture as 32-bit. No, I'm not. But using it does not seem to improve things that much. Still lots of paths get picked up wrong due to bad UnixPaths.cmake. In my case, X11 and GL get picked from the 64-bit paths instead of 32-bits (and yes, I have 32-bits versions in /usr/lib32). For example: -- Found X11: /usr/lib64/libX11.so--- It is impossible to order the linker search path in such a way that libraries specified as full paths will be picked by the linker. Directories and libraries involved are: Directory: /usr/lib32 contains: Library: /usr/lib64/libGL.so Library: /usr/lib64/libGLU.so Directory: /usr/lib64 contains: Library: /usr/lib32/libz.so Library: /usr/local/lib32/libHalf.a Library: /usr/local/lib32/libIex.a Library: /usr/local/lib32/libIlmImf.a Library: /usr/local/lib32/libImath.a -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Xubuntu Gutsy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] BOOL type
On Monday 17 December 2007, Brandon Van Every wrote:
I propose the addition of a BOOL type to the CMake language.
bool(variable [value])
would declare a variable of type BOOL, with an optional value
supplied. Any SET commands performed on the variable in its scope
would be subject to boolean type constraint. A BOOL can take on the
following values. Any other assignment is an error.
TRUE class - TRUE, 1, Y, Yes, YES, y, yes, ON
FALSE class - FALSE, 0, N, n, No, NO, OFF, empty
Attached is a patch which removes Y and N from the recognized values for
true/false.
This patch may break stuff. I don't know if there are many people who rely
on N and Y.
Alex
Index: cmSystemTools.cxx
===
RCS file: /cvsroot/CMake/CMake/Source/cmSystemTools.cxx,v
retrieving revision 1.356
diff -b -u -p -r1.356 cmSystemTools.cxx
--- cmSystemTools.cxx 13 Dec 2007 22:56:49 - 1.356
+++ cmSystemTools.cxx 17 Dec 2007 20:19:46 -
@@ -352,7 +352,7 @@ bool cmSystemTools::IsOn(const char* val
{
*c = toupper(*c);
}
- return (v == ON || v == 1 || v == YES || v == TRUE || v == Y);
+ return (v == ON || v == 1 || v == YES || v == TRUE);
}
bool cmSystemTools::IsNOTFOUND(const char* val)
@@ -386,7 +386,7 @@ bool cmSystemTools::IsOff(const char* va
*c = toupper(*c);
}
return (v == OFF || v == 0 || v == NO || v == FALSE ||
- v == N || cmSystemTools::IsNOTFOUND(v.c_str()) || v == IGNORE);
+ cmSystemTools::IsNOTFOUND(v.c_str()) || v == IGNORE);
}
//
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: map structure on cmake script
On Dec 17, 2007 3:00 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote: Brandon Van Every escreveu: On Dec 17, 2007 2:29 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote: A workaround would be computing a hash from the string and using it as a key, but once again, it'd be a pain in the *** to do it in cmake script. I wouldn't shy away from trying it though. I wrote a regex negation operator in CMake script to work around CMake's limitations. The No... too difficult for not so much gain. I can live with a braindead solution (using lists) until cmake supports *cough* lua *cough*. :) What's so hard about writhing a hash function using only MATH(EXPR ...) ? Geez, once upon a time there were guys who wrote this using punch cards. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: premake build system
Alexander Neundorf wrote:
I have my own UnixPaths and modules to work around most of the above,
Can you please post it ?
Sure. It is really two pieces. FindBuildDir.cmake which is called
first and Platforms/UnixPaths.cmake.
FindBuildDir does the hard check of setting up a couple of variables.
It sets CMAKE_NATIVE_ARCH to 32 or 64.
And sets the OS_32_BITS and OS_64_BITS variables to represent whether
the machine can compile for that.
User calls (optionally) cmake with -DCMAKE_BUILD_ARCH=32 to build in 32
bits.
Currently, I only have it working for Linux (tested) and Sun (not
tested). Windows and OSX are todo, as I don't have access to 64-bit
versions of them.
UnixPaths.cmake is then set to search for
/usr/local/lib${CMAKE_BUILD_ARCH} before it searches for any
/usr/local/lib and other.
This is still kind of screwy now because try-compile will call
UnixPaths.cmake without calling my FindBuildDir, which is a bug in how
cmake deals with variables.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
#-*-cmake-*-
#
# This simple CMake extension makes sure that builds get
# created inside a BUILD/os-osversion-arch directory
# and that executables, obj files and lib files get placed
# correctly in subdirectories.
#
#
# Macro to check architecture
#
MACRO( CHECK_ARCHITECTURE )
IF( NOT CMAKE_BUILD_ARCH )
SET( CMAKE_BUILD_ARCH $ENV{CMAKE_BUILD_ARCH} )
IF( NOT CMAKE_BUILD_ARCH )
SET( CMAKE_BUILD_ARCH Native )
ENDIF( NOT CMAKE_BUILD_ARCH )
ENDIF( NOT CMAKE_BUILD_ARCH )
IF( NOT CMAKE_BUILD_ARCH MATCHES ^(Native|64|32)$ )
MESSAGE( FATAL_ERROR
CMAKE_BUILD_ARCH set but invalid.
Only Native, 64 and 32 are valid settings )
ENDIF( NOT CMAKE_BUILD_ARCH MATCHES ^(Native|64|32)$ )
#
# Set Native architecture based on void* size
#
INCLUDE(CheckTypeSize)
CHECK_TYPE_SIZE(void* SIZEOF_VOID_PTR)
IF( ${SIZEOF_VOID_PTR} MATCHES ^8$ )
SET( OS_32_BITS 0 )
SET( OS_64_BITS 1 )
SET( CMAKE_NATIVE_ARCH 64 )
ELSE( ${SIZEOF_VOID_PTR} MATCHES ^8$ )
SET( OS_32_BITS 1 )
SET( OS_64_BITS 0 )
SET( CMAKE_NATIVE_ARCH 32 )
ENDIF( ${SIZEOF_VOID_PTR} MATCHES ^8$ )
MESSAGE( FATAL_ERROR void size: ${SIZEOF_VOID_PTR} )
IF( UNIX )
EXECUTE_PROCESS(
COMMAND uname -a
OUTPUT_VARIABLE OS_ARCH
)
#
# For Linux
#
IF( OS_ARCH MATCHES .*Linux.* )
IF( OS_ARCH MATCHES .*x86_64.* )
SET( OS_32_BITS 1 )
ELSEIF( OS_ARCH MATCHES .*ia64.* )
SET( OS_32_BITS 0 )
ELSEIF( OS_ARCH MATCHES .*i686.* )
SET( OS_32_BITS 1 )
ENDIF( OS_ARCH MATCHES .*x86_64.* )
ENDIF( OS_ARCH MATCHES .*Linux.* )
#
# For SUN
#
IF( OS_ARCH MATCHES .*SunOS.* )
EXECUTE_PROCESS(
COMMAND isainfo -v
OUTPUT_VARIABLE SUNOS_ARCH
)
IF ( SUNOS_ARCH MATCHES .*64-bit.* )
SET( OS_32_BITS 1 )
ENDIF( SUNOS_ARCH MATCHES .*64-bit.* )
ENDIF( OS_ARCH MATCHES .*SunOS.* )
IF( APPLE )
#
# @todo: add Apple 64-bit OS detection here
#
ENDIF( APPLE )
ELSE( UNIX )
#
# @todo: add windows 64-bit OS detection here
#
ENDIF( UNIX )
IF ( CMAKE_BUILD_ARCH STREQUAL Native )
SET( CMAKE_BUILD_ARCH ${CMAKE_NATIVE_ARCH} )
ENDIF( CMAKE_BUILD_ARCH STREQUAL Native )
IF( CMAKE_BUILD_ARCH EQUAL 32 )
IF( NOT OS_32_BITS )
MESSAGE( FATAL_ERROR
Sorry, but this platform cannot compile 32-bit applications )
ENDIF( NOT OS_32_BITS )
IF( NOT CMAKE_NATIVE_ARCH EQUAL 32 )
IF( WIN32 )
ELSE( WIN32 )
IF( CMAKE_COMPILER_IS_GNUCXX )
ADD_DEFINITIONS( -m32 )
SET( LINK_FLAGS -m32 ${LINK_FLAGS} )
ELSE( CMAKE_COMPILER_IS_GNUCXX )
#
# @todo: add 32-bit compile flags for non-GNU compilers here
#
ENDIF( CMAKE_COMPILER_IS_GNUCXX )
ENDIF( WIN32 )
ENDIF( NOT CMAKE_NATIVE_ARCH EQUAL 32 )
ENDIF( CMAKE_BUILD_ARCH EQUAL 32 )
ENDMACRO( CHECK_ARCHITECTURE )
CHECK_ARCHITECTURE()
#
# Store build type
#
IF(NOT CMAKE_BUILD_TYPE)
SET(CMAKE_BUILD_TYPE Release CACHE STRING
Choose the type of build, options are: None Debug Release RelWithDebInfo
MinSizeRel.
FORCE)
ENDIF(NOT CMAKE_BUILD_TYPE)
IF( CMAKE_BUILD_TYPE STREQUAL Debug )
ADD_DEFINITIONS( -DDEBUG )
ENDIF( CMAKE_BUILD_TYPE STREQUAL Debug )
IF( NOT CMAKE_SYSTEM )
MESSAGE( FATAL_ERROR CMAKE_SYSTEM was not set )
ENDIF( NOT CMAKE_SYSTEM )
#
# @bug in cmake2.5 in windows (workaround)
#
IF( NOT CMAKE_SYSTEM_VERSION )
SET( CMAKE_SYSTEM_VERSION 5.1 )
SET( CMAKE_SYSTEM ${CMAKE_SYSTEM}-${CMAKE_SYSTEM_VERSION} )
ENDIF( NOT CMAKE_SYSTEM_VERSION )
IF( NOT CMAKE_BUILD_TYPE )
MESSAGE( FATAL_ERROR CMAKE_BUILD_TYPE was not set )
ENDIF( NOT CMAKE_BUILD_TYPE )
IF( NOT CMAKE_BUILD_ARCH )
MESSAGE( FATAL_ERROR CMAKE_BUILD_ARCH was not set )
ENDIF( NOT CMAKE_BUILD_ARCH )
SET( BUILD_DIR
[CMake] Re: map structure on cmake script
Brandon Van Every escreveu: What's so hard about writhing a hash function using only MATH(EXPR ...) ? Geez, once upon a time there were guys who wrote this using punch cards. I have a life, I live in Copacabana, Rio de Janeiro/Brazil, it's summer, those stuff, you know :) Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: premake build system
Rodolfo Schulz de Lima wrote: If there is something you can not do with the current cmake language that could be done in lua (other than aesthetics), let us know, and provide a patch, or even a report, and most likely we will put it in CMake. So, no need to fork here... As I've said somewhere, I'm working on a macro to support precompiled headers. To do it properly, cmake should be a little more than a build system language. You might say that if I want something more elaborate, I could do it in C/C++ and add the command to cmake using load_command. But you cannot expect that everyone with a specific need should know a complex language like C++. Something like PCH support is a native build feature that CMake should support. As such, it should be done in C++, and built into CMake. Some work has been done to support this. The hard stuff for CMake should be done in C++. That is the implementation language of CMake. Ideally, there would be a few commands you would call to enable PCH's in a cross platform way. Brad King has looked into this, and because it is done so different with so many compilers it is hard in any language. If you really are interested in adding support for this, I would recommend you work with Brad and try to pick up where he left off. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] packaging technologies
On Dec 17, 2007 1:22 PM, Gonzalo Garramuño [EMAIL PROTECTED] wrote: Additional components like cpack or ctest are a plus, but they are not a major reason for sticking with cmake. They aren't *yet*. They certainly could be in the future. I lost the Chicken Scheme project to a bunch of Linux Autoconf packagers. Ease of Linux packaging was perceived as more important than MSVC support and the complications of CMake. Where complications means having to lift a finger to learn how CMake works. The point is, packaging technologies introduced a choice, a fork in the road for people to take. Since the Chicken Scheme community is almost entirely a bunch of Unix-heads, they chose to stick with Unix-oriented stuff. To the point of jettisoning all complicated build systems and going back to hand-rolled Makefiles. They completely dumped MSVC. So, my perspective is that packaging technologies definitely matter. I'm glad that CMake is working on that. I also learned that it's not enough for project leads to be interested in CMake. They have to be fully committed to cross-platform development, and looking for the best solution to that problem. Otherwise, you give them a great build system, and they'll balk the minute they have to lift a finger to maintain it. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: premake build system
Bill Hoffman escreveu: Something like PCH support is a native build feature that CMake should support. As such, it should be done in C++, and built into CMake. Some work has been done to support this. The hard stuff for CMake should be done in C++. That is the implementation language of CMake. Ideally, there would be a few commands you would call to enable PCH's in a cross platform way. Brad King has looked into this, and because it is done so different with so many compilers it is hard in any language. If you really are interested in adding support for this, I would recommend you work with Brad and try to pick up where he left off. Ok, thanks for the input. But I'm not trying something magical or too difficult. I'm just setting up compiler parameters and trying to compile the least headers I can, based on compiler flags assigned to each source. And this is just one use case... what if someone happens to need some processing cmake cannot provide easily? Should we touch cmake's code? You know, I could program a windows application in assembly, but C++ makes it easier for me. When I code in cmake script, sometimes I feel like programming in assembly due to the lack of programming primitives. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] map structure on cmake script
On Monday 17 December 2007, Rodolfo Schulz de Lima wrote:
Alexander Neundorf escreveu:
Yes, you can get map-like behaviour by using just variables:
SET(MY_MAP_${KEY} myValue)
That's fine if ${KEY} doesn't have spaces nor characters that aren't
allowed in variable names. As I'm using a string containing compiler
flags and stuff, this solution isn't possible. A workaround would be
The following code works for me:
# create a strange variable name and put it into tmp
set(tmp - - / ' hallo welt)
#assign a value to that strange var
set(${tmp} blub)
# print the value
message(STATUS value: -${${tmp}}-)
#assign it to another var
set(tmp2 ${${tmp}})
message(STATUS tmp2: -${tmp2}-)
After all, inside cmake the variables are simple a std::mapstd::string,
std::string .
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: map structure on cmake script
On Dec 17, 2007 3:33 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote: Brandon Van Every escreveu: What's so hard about writhing a hash function using only MATH(EXPR ...) ? Geez, once upon a time there were guys who wrote this using punch cards. I have a life, I live in Copacabana, Rio de Janeiro/Brazil, it's summer, those stuff, you know :) Hmm, I wrote writhing a hash function, I wonder if that was a Freudian slip? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Waf build tool
On Dec 16, 2007 1:11 PM, Gonzalo Garramuño [EMAIL PROTECTED] wrote: In summary, thanks. But, no thanks. With all those problems I did not even bother checking the speed. I got a chuckle out of their self-description on http://www.ohloh.net/tags/build/make , which one might view as a short list of open source build tools. Though it comes last in the arena of the build systems, we believe that Waf is a vastly superior alternative to its competitors (Autotools, Scons, Cmake, Ant, etc) for building software, and especially for open-source projects Yep, that's why it's in the top tier of Popular tools! :-) There's something to be said for tooting your own horn, but not to the extent of making oneself soft or complacent about a competitor's capabilities. I think the day that CMake has really won the build tool wars, we'll be seeing shelfs full of books at Barnes Noble and tons of jobs listing it as a must have skill. I wonder where Waf thinks it is, relative to all of that. Happy with the $0 we really don't have to bother with Windows open source market? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] OO and/or IDEs
On Dec 16, 2007 2:55 PM, Brandon Van Every [EMAIL PROTECTED] wrote: On Dec 16, 2007 1:54 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: On Sunday 16 December 2007, Brandon Van Every wrote: Meanwhile I just keep expanding my search radius, asking various build system communities the OO question. What's the purpose ? CMake is kind-of going OO. The purpose is to understand what benefits OO has, if any, for build systems. Then to understand whether Lua, Python, or Ruby offer those benefits. Then to understand whether CMake kinda implementing something like OO also provides those benefits. Possible futures for build systems in general: 1) OO approaches really don't matter. Make-style tools were the right way to do things all along. In industrial practice, nobody ever moves away from Make, because the industrial continuity of Make-style development is paramount over any marginal benefit that OO provides. 2) OO approaches do prove to matter in some arenas. Perhaps integration with IDEs or XML or some such, as the Waf author seems to think? Or whatever. Make-style systems and OO systems exist side by side, each in their own areas of greatest applicability. 3) OO approaches prove to matter greatly as software reaches a certain level of complexity. Industry moves en masse to OO build systems, retiring their 1990s legacy Make systems. Which future do you think it will be? If you assume (1), then in 10 years you could get left behind. So my goal is not to assume, but to go out there and understand. Alternately, if (1) really is the future, we can learn how to make CMake be the best possible (1). We should not, however, assume that we're great and that everyone who's trying something else is dumb. Possibility (4) has occurred to me. The OO question, and the somewhat related syntax nicety / maturity question, may not be nearly as important as supporting the correct IDEs well. For instance, Eclipse. In that world view, the choice of extension language(s) is a political decision, not a technical one. When I peruse http://www.ohloh.net/tags/make I notice that most of the Popular! make-like tools have a particular implementation language associated with them. If you want a make written in Java, you use Ant. If you want it in Ruby, you use Rake. If you want it in C/C++, you use either CMake or GNU Autoconf + GMake. And so on for PHP, Python, etc. For any given implementation language, there's not a lot of variety. Maven 2 seems to have deliberately excluded itself from the make-like tool category, so that will be the subject of another post. Anyways; political decisions for supporting Eclipse. How do you avoid offending a Java programmer? Well, if you're not going to write anything in Java, perhaps there is no way. Perhaps instead you cast your lot with the C/C++ Eclipse users and support it that way. Which makes scripting languages moot / orthogonal / detrimental? Or maybe you look to see whether Python, Ruby, or Lua is winning the Eclipse support wars. If none of those are winning, perhaps you wait for a winner to emerge before committing. It doesn't always pay to be in the vanguard of capabilities. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Java, Ant, JRuby, and JRake
http://martinfowler.com/bliki/JRake.html Now that JRuby is getting more and more mature, several people are thinking of finally doing something to improve the world of build scripts by replacing ant with rake. My former colleague Matt Foemmel has starting doing this for real and is writing up progress on his FoemBlog. Matt's written more build scripts than most and around 2000 we both made the mistake of thinking an XML based build file was the way to go. We also both now believe you need a full scripting language. The thing with build scripts is that you need both declarative and procedural qualities. The heart of a build file is defining tasks and the dependencies between them. This is the declarative part, and is where tools like ant and make excel. The trouble is that as builds get more complex these structures aren't enough. You begin to need conditional logic; in particular you need the ability to define your own abstractions. (See my rake article for examples.) Rake's strength is that it gives you both of these. It provides a simple declarative syntax to define tasks and dependencies, but because this syntax is an internal DomainSpecificLanguage, you can seamlessly weave in the full power of Ruby. Well, CMake certainly allows for conditional logic. I've even proven that you can use CMake script for inappropriate tasks like GNU Autoconf + GMake translation. :-) Really, all that's needed to do that, is variables + conditional logic + a regex engine. The question, of course, is whether people want to learn CMake script, use a scripting language they already know, or use a scripting language they have less of an objection to learning. This isn't really about OO per se. This is about the learning curve of Yet Another Scripting Language, and strategies for reducing that learning curve. As I've noted before, superior documentation and tutorial technologies is a completely different way to tackle the problem. http://www.martinfowler.com/articles/rake.html#UsingRakeToBuildNon-rubyApplications Although I've not done this personally we have had some experience of using ruby as a build language on one of our bigger Java projects. The build got to a point where it was painful to script it using ant, so we ended up building a custom build system in ruby. It worked out rather well, and it's certainly an option we would use again for more complex projects. One the reasons we liked it was because having a full (and malleable) language allowed us to describe the build in the terminology used by developers: tiers, modules, jars, ears. It also ended up being a good bit faster. CMake CVS currently has some sorta OO capabilities. It has Properties, which can be applied to the following scope_values: GLOBAL, DIRECTORY, TARGET, SOURCE_FILE, or TEST. A scope_value could be viewed as a synonym for a Class; CMake CVS currently has 6 hardwired classes available. What is lacking, however, is a way for the user to define his own classes. Maybe this isn't needed. Maybe CMake will simply add new hardwired classes as the need for them becomes apparent. But, maybe this won't be fast enough for people's custom / vertical applications. I think it is important to monitor the Ruby building Java trend. I would note, however, that http://www.ohloh.net/projects/747?p=Rake puts Rake as a 1 person-year project. Not sure about JRake, which runs on JRuby. I've also noticed that some language communities, like Ruby, generally don't need to compile stuff. The following article explains to the Ruby community why Rake even exists. http://www.railsenvy.com/2007/6/11/ruby-on-rails-rake-tutorial Strategically, it is possible that language communities like Ruby will never produce industrial quality build tools, because there simply aren't enough Ruby programmers who need to compile something. So the use of Ruby to solve build problems, will depend upon Ruby living symbiotically with other languages that do need to be compiled (C/C++, Java, C#). Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Waf build tool
I took a close look to Waf some months ago while searching for the ideal build tool for the projects I had to port. I used to talk a lot with the author and found out that the Waf build system isn't superior at all to other alternatives like CMake. Also, the author just don't care about other OS than Linux (that is partly why KDE haven't made the switch to Waf). In continuation with this idea, the MSVC support is very (very) poor. Also, the author isn't very mind opened (to new ideas). And he don't like CMake ;). The author might have good ideas although but I don't like the way it is implemented. Regards, Félix C. Morency Date: Mon, 17 Dec 2007 19:38:28 -0500 From: Brandon Van Every [EMAIL PROTECTED] Subject: Re: [CMake] Waf build tool To: cmake@cmake.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 On Dec 16, 2007 1:11 PM, Gonzalo Garramuño [EMAIL PROTECTED] wrote: In summary, thanks. But, no thanks. With all those problems I did not even bother checking the speed. I got a chuckle out of their self-description on http://www.ohloh.net/tags/build/make , which one might view as a short list of open source build tools. Though it comes last in the arena of the build systems, we believe that Waf is a vastly superior alternative to its competitors (Autotools, Scons, Cmake, Ant, etc) for building software, and especially for open-source projects Yep, that's why it's in the top tier of Popular tools! :-) There's something to be said for tooting your own horn, but not to the extent of making oneself soft or complacent about a competitor's capabilities. I think the day that CMake has really won the build tool wars, we'll be seeing shelfs full of books at Barnes Noble and tons of jobs listing it as a must have skill. I wonder where Waf thinks it is, relative to all of that. Happy with the $0 we really don't have to bother with Windows open source market? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Gant
I've wondered, how does one script in Java? Same as in the C/C++ universe: with something else. Ergo the JRuby / JRake stuff I just posted about. Well, some people in the Java universe wanted to script, and they came up with Groovy. http://groovy.codehaus.org/ They put it on top of Ant and called it Gant. http://gant.codehaus.org/ This provides the layer of conditional logic that the straight declarative Ant / XML approach lacks. The main benefit I see in Groovy, is it paves over all that despicable XML syntax. At least, that's my bigoted anti-XML never-tried-XML don't-wanna-try-XML perspective. I could see myself using Groovy. I've never been able to fathom writing verbosecrapsmall item/verbosecrap over and over again, at least not by hand. I've wondered if the entire XML universe is driven by program editors instead of human beings. Sorta like the Postscript of programming? The Java universe has a lot of JVM-based scripting languages. I'm trying to figure out whether any are more popular than the others. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
On 2007-12-17 20:30-0500 Brandon Van Every wrote: When I peruse http://www.ohloh.net/tags/make I notice that most of the Popular! make-like tools have a particular implementation language associated with them. If you want a make written in Java, you use Ant. If you want it in Ruby, you use Rake. If you want it in C/C++, you use either CMake or GNU Autoconf + GMake. Correction about Autoconf with some additional comments about autotools. Autoconf requires m4 and shell scripting (both of which are exposed to the user), automake requires perl (hidden from the user with the public interface a unique extension of make), libtool is implemented as a giant (and slow!) shell script with a small number of command-line options for that shell script. autotools tries to use the lowest common denominator of all make systems so it will work on any Unix platform rather than the unique capabilities of native make systems such as GNU make. In sum, as virtually everyone on the Linux side of things realizes by now, autotools is a technical mess. BUT autotools were first to market in the Linux world so there are still a large number of Linux projects that continue with autotools. However, my guess based on obvious technical superiority, the possibility of porting to windows (not all Linux projects are like Chicken!), and the huge advertisement the KDE adoption gave to CMake is that the current CMake share of Linux projects is strongly growing at the expense of autotools. Furthermore, it is obvious from traffic on this list that a large and growing number of windows projects are beginning to use CMake as well. Brandon, because of this strong growth, I disagree with your emphasis on the importance of strategic decisions now for CMake. Those were done a long time ago, and people and projects are strongly voting with their feet despite (and this is an extremely important consideration) virtually everybody absolutely hating to change build systems. So long as the CMake developers steer a steady course and don't shoot themselves in the foot with some stupid decision, their strong growth will continue, and as a result I think they we be _the_ major build system in the decades to come. Thus, my own feeling is CMake developers and users can quit worrying about market share since the future is bright indeed on that score almost regardless of what they do. Instead, they should totally concentrate on technical improvements that don't disturb things too much and which make CMake build systems simply easier to design and maintain. I am talking about such things as cross-compiling, module improvements (including standardization), scoping, improved regex, and even Boolean precedence. The first three are already in the CVS version of CMake and the rest have been recently discussed positively on list with at least a chance to get into CVS. In sum, the CMake developers have something they can be proud of, that pride will continue to drive them to make some modest improvements like listed above, and so long as they don't make any irrevocable mistakes in such changes their current large growth rate assures them of world domination for both Linux and windows build systems. :-) Just my $0.02. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Gant
On Dec 17, 2007 10:32 PM, Brandon Van Every [EMAIL PROTECTED] wrote: The main benefit I see in Groovy, is it paves over all that despicable XML syntax. Here's an example of that. http://www.javaworld.com/javaworld/jw-10-2004/jw-1004-groovy.html Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
On Dec 17, 2007 10:35 PM, Alan W. Irwin [EMAIL PROTECTED] wrote: BUT autotools were first to market in the Linux world so there are still a large number of Linux projects that continue with autotools. However, my guess based on obvious technical superiority, the possibility of porting to windows (not all Linux projects are like Chicken!), and the huge advertisement the KDE adoption gave to CMake is that the current CMake share of Linux projects is strongly growing at the expense of autotools. Plus, if I had a better pattern matching technology and another 6 months of either willpower or funding, I could implement completely automagical conversion from GNU Autoconf + GMake to CMake. Including the nasty awk + grep + egrep + sed tools that Unixen like to use. Haven't decided if I really want to take it on though. I need the better pattern matching technology. Brandon, because of this strong growth, I disagree with your emphasis on the importance of strategic decisions now for CMake. Those were done a long time ago, and people and projects are strongly voting with their feet despite (and this is an extremely important consideration) virtually everybody absolutely hating to change build systems. So long as the CMake developers steer a steady course and don't shoot themselves in the foot with some stupid decision, their strong growth will continue, and as a result I think they we be _the_ major build system in the decades to come. I'm not that bullish. I live in a Windows + console game development universe where plenty of people try out CMake and tell me it sucks. Not necessarily for well-measured reasons, but initial impressions do count. A lot of these people end up rolling their own because custom-built NIH is endemic to the game industry. I think it has to do with game projects not lasting long enough to be reused. There's a huge burnout rate for game developers, with entire programming and art teams getting swapped mid-project. So nobody knows what's going on, nobody likes what was done before, and projects tend to be rewritten from scratch. I also don't see how you could read all those articles I just posted, and assume that CMake is going to sweep the table in decades to come. A far more likely scenario is some Java or C# technology spills over into the C/C++ universe and becomes a checkbox item. Thus, my own feeling is CMake developers and users can quit worrying about market share since the future is bright indeed on that score almost regardless of what they do. Instead, they should totally concentrate on technical improvements that don't disturb things too much and which make CMake build systems simply easier to design and maintain. I guess you have no fear of a Disruptive Technology biting you in the ass. http://en.wikipedia.org/wiki/Disruptive_technology I prefer to keep my eye on the 8-ball. http://web.ics.purdue.edu/~ssanty/cgi-bin/eightball.cgi Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
On Dec 17, 2007 11:02 PM, Brandon Van Every [EMAIL PROTECTED] wrote: I guess you have no fear of a Disruptive Technology biting you in the ass. http://en.wikipedia.org/wiki/Disruptive_technology I prefer to keep my eye on the 8-ball. http://web.ics.purdue.edu/~ssanty/cgi-bin/eightball.cgi Related to Disruptive Technology is Kuhn's concept of a Paradigm Shift. http://en.wikipedia.org/wiki/Paradigm_shift I find the following passage compelling with respect to young bucks, who haven't necessarily grown up with crappy make tools, plain C, or even C++. Sometimes the convincing force is just time itself and the human toll it takes, Kuhn said, using a quote from Max Planck: a new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it. Technology generations in computerdom are capable of being exceedingly long or exceedingly short. It really depends. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
On 2007-12-17 23:02-0500 Brandon Van Every wrote: I guess you have no fear of a Disruptive Technology biting you in the ass. That is correct. Disruptive technology by definition is overwhelmingly superior, and I like such technology and don't fear it in the least. Also, I am comfortable with change so therefore I tend to be an early adopter of disruptive technology. But life is short so I don't adopt new technology unless there is a real and overwhelming case (not just marketspeak) that it is _much_ better than what I am using. For me, CMake was disruptive technology (overwhelmingly superior) compared to autotools, and therefore it was a no-brainer decision for me because of my comfort with change. If/when I adopt my next build system it must be similarly overwhelmingly superior to CMake. But right now, I am pretty satisfied with CMake and cannot imagine when the next build-system revolution will strike. Some here have guessed three years, but my own feeling is it will be _much_ longer. Anyhow, changing your strategy to deal with disruptive technological changes is a waste of time at best; by definition disruptive technology changes are extremely hard to predict and therefore there is no change in strategy that will stop them. OTOH, discussing possible incremental changes to CMake such as improved regex is well worthwhile because of better service to users and the pride that goes with that. But I don't think such changes are going to affect when the CMake tipping point occurs. I think that tipping point has already happened based on the rate of CMake adoption in a software area (build systems) where everybody ordinarily dislikes change. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
On Dec 17, 2007 10:35 PM, Alan W. Irwin [EMAIL PROTECTED] wrote: people and projects are strongly voting with their feet despite (and this is an extremely important consideration) virtually everybody absolutely hating to change build systems. Here, I think it's more important to concentrate on the lifecycle of build systems, rather than people's emotions about them. The vast majority of software developers don't like build systems no matter what stage of the lifecycle they're at. Most engineers want the build to go away. They don't think it's real code, they think it's pure overhead. They resent having to maintain it. Only when the complexity of their business gets to a certain point, and the inevitable relationship between their build system and their profitability emerges, do they grudgingly take steps to address it. Then after cutting off their fingers some more with half-measures, they grudgingly hire a dedicated build engineer. If a software project continues to grow in complexity and requirements, the build dies. Then there's a (forced) opportunity to replace it with something better. As builds die, engineers look at the available products and decide what the next build is going to be. They may choose something incrementally conservative, i.e. CMake over GNU Automake, which are broadly of the same style. Or they may choose something apparently cutting edge, if they think it may give them a competitive advantage. Or if the risk is manageable, i.e. they can afford to change their minds again, if the new build doesn't work out. I don't take it as a given that CMake will inherit all GNU Autoconf / GMake projects. Especially not indefinitely, as the next 10 years unfold. It's important to look at competitors and determine what engineers think is attractive in a build tool. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
On Dec 17, 2007 11:51 PM, Alan W. Irwin [EMAIL PROTECTED] wrote: On 2007-12-17 23:02-0500 Brandon Van Every wrote: I guess you have no fear of a Disruptive Technology biting you in the ass. That is correct. Disruptive technology by definition is overwhelmingly superior, I'm not sure you read the Wikipedia link I provided. See the description of low-end disruption. That corresponds to all those guys out there rolling up things like Waf and Premake. Things we laugh at now, but may not be laughing at later. Some of those low-end things like JRake are even getting traction. There's a constellation of blog entries about them. It performs significant work despite not having 51 person-years into it. But right now, I am pretty satisfied with CMake and cannot imagine when the next build-system revolution will strike. Whereas I can, and have been providing you with articles about it from the Java universe. Anyhow, changing your strategy to deal with disruptive technological changes is a waste of time at best; by definition disruptive technology changes are extremely hard to predict They're even harder to predict if you're unwilling to pay attention to competitors and notice the facts on the ground. OTOH, discussing possible incremental changes to CMake such as improved regex is well worthwhile because of better service to users Not much to discuss. It's already to the point of action. :-) I don't have anything against low hanging fruit. Despite Bill's misgivings about CMake competing with Python / Ruby / Perl, beefing up CMake with PCRE and a few more string processing routines is an obvious and easy improvement to the product. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OO and/or IDEs
On Dec 18, 2007 12:42 AM, Brandon Van Every [EMAIL PROTECTED] wrote: Some of those low-end things like JRake are even getting traction. There's a constellation of blog entries about them. It performs significant work despite not having 51 person-years into it. It occurs to me that Java and C# do not have the same portability problems as C/C++. Sure, Java has some, but any Java-oriented build system can rely on Java being nearly the same on all platforms. Meanwhile, C# is primarily a Windows thing. Hmm, what aspects of target OSes do Java and C# fail to pave over? If CMake handles those better than competing build systems Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] community swelling due to standard languages
Reading http://blog.aslakhellesoy.com/tags/jruby/ I get the impression that the Ruby + Java universe has a *lot* of developers banging on things. The things banged out may not all be good, but there's a variety of offerings, and a continuous outpouring of energy and cross-pollenation. The CMake community does pretty well in its own right. One of the things that attracted me to CMake early on, was Kitware's responsiveness to the community, and its ability to turn community input into actual product. But I do wonder what would happen if an order of magnitude more developers was inserted into the CMake improvement process. Maybe it wouldn't all be good! :-) Maybe too many cooks spoil the broth and one ends up with community schisms on build tool approaches. Maybe one gets a bit of paralysis as I've seen in some large open source communities, where there's a perceived need to fairly consider the input of too many people. Maybe there are herd mentalities in large communities that make it difficult to turn some things around. For instance, everyone seemed to think XML was a good idea for Java build systems once upon a time. So Ant got very popular and is terribly pervasive. Now there's a movement that thinks XML wasn't such a hot idea, that you really do need scripting in a build system after all, and that it's advantageous to get rid of the XML. This notion seems to have gained steam for about the past 4 years. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
