[CMake] Building two binaries from common source: different defines required
I have a project consisting of two binaries build from same source (they do differ in one .cpp file though). Is it possible to set ADD_DEFINITIONS on per-executable basis somehow? I need to add a define specifying which binary type is being built. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] intltool and cmake?
Tim, exactly what I was looking for. thanks! Chris http://www.acurana.de/ Am Montag 14 Januar 2008 05:00:04 schrieb Timothy M. Shead: On Sun, 2008-01-13 at 12:00 +0100, Christopher Lang wrote: Hi, I am just converting a mid size autotools project to cmake. It works very nicely so far, but: there are all kinds of files that I need intltool for (.glade files etc.) so gettext alone will not do. Is there some example on how to integrate intltool cmake? I've enclosed just such an example, from the K-3D po directory. Should be fairly straightforward to adjust to your project. Cheers, Tim ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Why is CMakeOutput.log created for one project but not another?
In the CMake source tree, in Utilities/cmcurl/CMakeLists.txt, there is this:
CHECK_SYMBOL_EXISTS(strcasecmp${CURL_INCLUDES} HAVE_STRCASECMP)
That would be one thing that would do it...
grep for strcasecmp in both source trees.
HTH,
David
On 1/13/08, Christian Convey [EMAIL PROTECTED] wrote:
Hi guys,
Someone pointed out that when we cmake one of our projects, a file
CMakeOutput.log and a directory CMakeTmp/ get created. It looks like
they're being used to see if the function strcasecmp() works on this
platform.
But we have another project that this doesn't happen at all for, even
when we build it on the same computer.
Can anyone tell me what in a CMakeLists.txt file causes CMake to run
this compilation test?
Thanks,
Christian
___
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] Building two binaries from common source: different defines required
2008/1/14, Vladimir Pouzanov [EMAIL PROTECTED]: I have a project consisting of two binaries build from same source (they do differ in one .cpp file though). Is it possible to set ADD_DEFINITIONS on per-executable basis somehow? I need to add a define specifying which binary type is being built. Look at SET_TARGET_PROPERTIES i.e. the COMPILE_FLAGS for example ADD_EXECUTABLE(first source1.cpp source2.cpp) SET_TARGET_PROPERTIES(first PROPERTIES COMPILE_FLAGS -D_FIRST) ADD_EXECUTABLE(second source1.cpp source2.cpp) SET_TARGET_PROPERTIES(second PROPERTIES COMPILE_FLAGS -D_SECOND) should be OK. SET_SOURCE_FILES_PROPERTIES may be useful too if the compile flags may be attached to the source and not to the target. This is not the case you described but I found it usefull too. -- Erk ___ 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
[CMake] CMake 2.6 - Runtime Error on OS X (10.4.11 Intel)
I just built the latest CVS head of CMake and tried running on OS X (10.4.11 Intel) and noticed a few things. 1: CMake Error: CMake executable cannot be found at /Users/Shared/ Toolkits/CMake-ICC/bin/QtDialog.app/Contents/MacOS/cmake Probably just a path issue between the .app bundle and the internal call to cmake. 2: ADD_LIBRARY for library MXADataModel is used with the SHARED option, but the target platform supports only STATIC libraries. Building it STATIC instead. This may lead to problems. This seems to work fine with CMake 2.4.7 on the same project. I compiled CMake 2.6 CVS Head with both GCC (Xcode 2.5 tools) and ICC/ ICPC (version 9.x) and saw this problem. Not sure if the two are related or not. Otherwise, the Qt Dialog is looking really nice. -- Mike Jackson imikejackson gmail * com ___ 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] CMake 2.6 - Runtime Error on OS X (10.4.11 Intel)
On Monday 14 January 2008 10:20:18 am Bill Hoffman wrote: Mike Jackson wrote: I just built the latest CVS head of CMake and tried running on OS X (10.4.11 Intel) and noticed a few things. 1: CMake Error: CMake executable cannot be found at /Users/Shared/Toolkits/CMake-ICC/bin/QtDialog.app/Contents/MacOS/cmake Probably just a path issue between the .app bundle and the internal call to cmake. This needs to be fixed, the QtDialog is not very tested right now, please create a bug entry for this. Mike, did you change your copy of the code? QtDialog should be looking for /Users/Shared/Toolkits/CMake-ICC/bin/cmake instead of /Users/Shared/Toolkits/CMake-ICC/bin/QtDialog.app/Contents/MacOS/cmake QCMake.cxx has #elif defined(Q_OS_MAC) appDir.cd(../../../); this-CMakeExecutable = appDir.filePath(cmake); ... to find cmake outside the bundle. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6 - Runtime Error on OS X (10.4.11 Intel)
Mike Jackson wrote: I just built the latest CVS head of CMake and tried running on OS X (10.4.11 Intel) and noticed a few things. 1: CMake Error: CMake executable cannot be found at /Users/Shared/Toolkits/CMake-ICC/bin/QtDialog.app/Contents/MacOS/cmake Probably just a path issue between the .app bundle and the internal call to cmake. This needs to be fixed, the QtDialog is not very tested right now, please create a bug entry for this. 2: ADD_LIBRARY for library MXADataModel is used with the SHARED option, but the target platform supports only STATIC libraries. Building it STATIC instead. This may lead to problems. What is MXADataModel? This seems to work fine with CMake 2.4.7 on the same project. I compiled CMake 2.6 CVS Head with both GCC (Xcode 2.5 tools) and ICC/ICPC (version 9.x) and saw this problem. What did 2.4.7 do? Not sure if the two are related or not. Don't think so. -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] Re: Get full output library filename
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf
Of Rodolfo Lima
Sent: 12 January 2008 01:42
To: cmake@cmake.org
Subject: [CMake] Re: Get full output library filename
Rodolfo Lima escreveu:
Hi, is there a way to get the full library name of a library target?
I just found target's property LOCATION, I always thought it would be
the directory where the target would be created, but it includes the
target file name. Sorry for the noise.
Does it correctly include the contents of ${BUILD_TYPE}_POSTFIX? I'm
using 2.4.7, and reported a few weeks ago that the value of LOCATION
doesn't include the postfix. Andreas Pakulat confirmed that he was
seeing the same thing. Are you saying that it works for you?
Thanks,
Joe
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6 - Runtime Error on OS X (10.4.11 Intel)
On Jan 14, 2008, at 12:20 PM, Bill Hoffman wrote:
Mike Jackson wrote:
I just built the latest CVS head of CMake and tried running on OS
X (10.4.11 Intel) and noticed a few things.
1: CMake Error: CMake executable cannot be found at /Users/Shared/
Toolkits/CMake-ICC/bin/QtDialog.app/Contents/MacOS/cmake
Probably just a path issue between the .app bundle and the
internal call to cmake.
This needs to be fixed, the QtDialog is not very tested right now,
please create a bug entry for this.
OK.
2: ADD_LIBRARY for library MXADataModel is used with the SHARED
option, but the target platform supports only STATIC libraries.
Building it STATIC instead. This may lead to problems.
What is MXADataModel?
It is the name of my project. Sorry about not explaining that.
This seems to work fine with CMake 2.4.7 on the same project. I
compiled CMake 2.6 CVS Head with both GCC (Xcode 2.5 tools) and
ICC/ICPC (version 9.x) and saw this problem.
What did 2.4.7 do?
Well, since there is no GUI to test with 2.4.7, the command line
cmake did the correct thing.
Not sure if the two are related or not.
Don't think so.
Actually, they are. If I copy cmake into the QtDialog.app/Contents/
MacOS then everything works correctly.
I don't really know how to do a patch but this is what I have
found. The QtDialog correctly sets the absolute path to the cmake
executable (Yes, Clinton, I did change my code slightly) BUT the
problem is in cmake.cxx in the AddPaths() method:
int cmake::AddCMakePaths()
{
// Find the cmake executable
std::cout cmake::AddCMakePaths() this-CMakeCommand: this-
CMakeCommand std::endl;
std::string cMakeSelf = cmSystemTools::GetExecutableDirectory();
cMakeSelf += /cmake;
cMakeSelf += cmSystemTools::GetExecutableExtension();
std::cout cmake::AddCMakePaths() this-cMakeSelf:
cMakeSelf std::endl;
in this method the assumption I guess is that this-CMakeCommand has
NOT been set so the algorithm recalculates it. Normally this probably
is not a problem, with OS X app bundles this is going to be WRONG. By
using the above added lines to look at some values I get the
following output:
cmake::AddCMakePaths() this-CMakeCommand: /Users/Shared/Toolkits/
CMake-ICC/bin/QtDialog.app/Contents/bin/cmake
cmake::AddCMakePaths() this-cMakeSelf: /Users/Shared/Toolkits/CMake-
ICC/bin/QtDialog.app/Contents/MacOS/cmake
You can see that the values are different. I am not sure how the
internals of cmake work BUT it would seem at first glance that a test
is needed to see if this-CMakeCommand is actually set, that the file
does exist and use the value for cMakeSelf if it DOES exist.. or
something to that effect.
--
Mike Jackson Senior Research Engineer
Innovative Management Technology Services
OS X Build Specialist
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Get full output library filename
Josef Karthauser wrote:
Does it correctly include the contents of ${BUILD_TYPE}_POSTFIX? I'm
using 2.4.7, and reported a few weeks ago that the value of LOCATION
doesn't include the postfix. Andreas Pakulat confirmed that he was
seeing the same thing. Are you saying that it works for you?
Well, I'm using cmake-cvs (as of 2008/01/14) and it works correctly, and
also includes ${BUILD_TYPE}_POSTFIX.
Regards,
Rodolfo Lima.
___
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] Re: Get full output library filename
It must have been fixed in the repository then. Hmm, ok I'd better go
track the patch down :).
Thanks for the confirmation.
Joe
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf
Of Rodolfo Schulz de Lima
Sent: 14 January 2008 17:40
To: cmake@cmake.org
Subject: [CMake] Re: Get full output library filename
Josef Karthauser wrote:
Does it correctly include the contents of ${BUILD_TYPE}_POSTFIX?
I'm
using 2.4.7, and reported a few weeks ago that the value of LOCATION
doesn't include the postfix. Andreas Pakulat confirmed that he was
seeing the same thing. Are you saying that it works for you?
Well, I'm using cmake-cvs (as of 2008/01/14) and it works correctly,
and
also includes ${BUILD_TYPE}_POSTFIX.
Regards,
Rodolfo Lima.
___
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*.cmake variable naming
Hi, I'd like to comment on the Find*.cmake variable naming procedure adopted by cmake. Right now I have to look at some Find*.cmake files to see what are the output variables they create. Some packages create a *_LIBRARY, others *_LIBRARIES, others *_INCLUDE_DIRS and others *_INCLUDE_DIR. The Modules/readme.txt procedure isn't being used for some packages. Also the vast majority creates upcased (is this an adjective?) variable names, BUT Boost and wxWidgets. There two define Boost_FOUND, Boost_LIBRARIES, wxWidgets_FOUND, wxWidgets_LIBRARIES. It should be better if they were BOOST_FOUND, WXWIDGETS_FOUND etc. This gets annoying when you're trying to create a macro that accepts a package name, finds it and use their output variables. This requires an uniformity that is lacking on Find*.cmake's. I'll try to summarize below the discrepancies I've found (just a few of them) Aspell: outputs ASPELL_INCLUDE_DIR instead of ASPELL_INCLUDE_DIRS AVIFile: outputs AVIFILE_INCLUDE_DIR instead of AVIFILE_INCLUDE_DIRS Boost: variable names should be upcase. Bzip2: outputs BZIP2_INCLUDE_DIR instead of BZIP2_INCLUDE_DIRS Cable: outputs CABLE_TCL_LIBRARY instead of CABLE_TCL_LIBRARIES, and CABLE_INCLUDE_DIR instead of CABLE_INCLUDE_DIRS Cups: outputs CUPS_INCLUDE_DIR instead of CUPS_INCLUDE_DIRS Curses: outputs CURSES_INCLUDE_DIR instead of CUPS_INCLUDE_DIRS DCMTK: outputs DCMTK_INCLUDE_DIR instead of DCMTK_INCLUDE_DIRS ... and there's a lot more. It seems that the majority uses *_INCLUDE_DIR instead of *_INCLUDE_DIRS Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Re: Get full output library filename
Hmm, I can't see where it would have been fixed. Can one of the
developers please comment?
Thanks,
Joe
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf
Of Josef Karthauser
Sent: 14 January 2008 17:44
To: Rodolfo Schulz de Lima; cmake@cmake.org
Subject: RE: [CMake] Re: Get full output library filename
It must have been fixed in the repository then. Hmm, ok I'd better go
track the patch down :).
Thanks for the confirmation.
Joe
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf
Of Rodolfo Schulz de Lima
Sent: 14 January 2008 17:40
To: cmake@cmake.org
Subject: [CMake] Re: Get full output library filename
Josef Karthauser wrote:
Does it correctly include the contents of ${BUILD_TYPE}_POSTFIX?
I'm
using 2.4.7, and reported a few weeks ago that the value of
LOCATION
doesn't include the postfix. Andreas Pakulat confirmed that he
was
seeing the same thing. Are you saying that it works for you?
Well, I'm using cmake-cvs (as of 2008/01/14) and it works correctly,
and
also includes ${BUILD_TYPE}_POSTFIX.
Regards,
Rodolfo Lima.
___
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] Find*.cmake variable naming
On Jan 14, 2008, at 1:01 PM, Rodolfo Schulz de Lima wrote: Hi, I'd like to comment on the Find*.cmake variable naming procedure adopted by cmake. Right now I have to look at some Find*.cmake files to see what are the output variables they create. Some packages create a *_LIBRARY, others *_LIBRARIES, others *_INCLUDE_DIRS and others *_INCLUDE_DIR. The Modules/readme.txt procedure isn't being used for some packages. Also the vast majority creates upcased (is this an adjective?) variable names, BUT Boost and wxWidgets. There two define Boost_FOUND, Boost_LIBRARIES, wxWidgets_FOUND, wxWidgets_LIBRARIES. It should be better if they were BOOST_FOUND, WXWIDGETS_FOUND etc. This gets annoying when you're trying to create a macro that accepts a package name, finds it and use their output variables. This requires an uniformity that is lacking on Find*.cmake's. I'll try to summarize below the discrepancies I've found (just a few of them) Aspell: outputs ASPELL_INCLUDE_DIR instead of ASPELL_INCLUDE_DIRS AVIFile: outputs AVIFILE_INCLUDE_DIR instead of AVIFILE_INCLUDE_DIRS Boost: variable names should be upcase. Bzip2: outputs BZIP2_INCLUDE_DIR instead of BZIP2_INCLUDE_DIRS Cable: outputs CABLE_TCL_LIBRARY instead of CABLE_TCL_LIBRARIES, and CABLE_INCLUDE_DIR instead of CABLE_INCLUDE_DIRS Cups: outputs CUPS_INCLUDE_DIR instead of CUPS_INCLUDE_DIRS Curses: outputs CURSES_INCLUDE_DIR instead of CUPS_INCLUDE_DIRS DCMTK: outputs DCMTK_INCLUDE_DIR instead of DCMTK_INCLUDE_DIRS ... and there's a lot more. It seems that the majority uses *_INCLUDE_DIR instead of *_INCLUDE_DIRS Regards, rod Nothing much to add except, I Agree. Consistency in any API/ Language is essential for people to learn quickly. I would also think that the jump from 2.4.x to 2.6.x is _perfect_ time to change the variables. There may be other major changes API breakage, so getting this done also makes sense in my little utopian world. -- Mike Jackson imikejackson gmail * com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.8 RC 10
On Jan 9, 2008 9:23 PM, Bill Hoffman [EMAIL PROTECTED] wrote: David Thulson wrote: Hello, This is my first post to the cmake mailing list, so I hope it works... I downloaded the 2.4.8 RC 11 for OS X and for what it is worth it appears to work just as well as 2.4.7. In both 2.4.7 and 2.4.8 RC 11 I have some serious issues with the Xcode generator. I just bought my first Mac (MacBook Pro running Leopard) a few months ago, so I am unfamiliar with Xcode and even OS X in general. However, my project ( http://www.crownandcutlass.com) has a unit test framework that has worked well for us on several versions and distributions of Linux as well as Windows XP. The project is set up as a static library and the unit test framework is a separate CMake project that uses that library. Code compiled in OS X using the Makefile generator appears to work fine. I still have a few quirks to work out for OS X, but overall it is very much as I expected. However, if I use the Xcode generator, I have several issues. FIrst off, we have a config.cpp.in http://config.cpp.in file that is used to generate config.cpp as a part of the build. The Xcode project includes a reference to a file config.cpp.rule which does not exist. That generates this warning: warning: no rule to process file '/(my path)/Protocce/src/config.cpp.rule' of type file for architecture i386 I can just remove that from the project and it seems to be fine until next time I regenerate the project. No big deal, but it is a little annoying. The bigger issue is that the resulting binary has issues catching exceptions. Some units can catch exceptions fine, but others cannot at all. At first, I thought I was having issues due to the visibility flags, but I am using a static lib and I believe the visibility issues only apply to dynamic libs. The exceptions that I cannot catch pass through a catch(...) so I believe even with visibility issues that at least should catch the exception. You can see my CMakeFiles here: Static lib - http://crownandcutlass.svn.sourceforge.net/viewvc/crownandcutlass/trunk/Protocce/src/CMakeLists.txt?revision=1020view=markuppathrev=1027 http://crownandcutlass.svn.sourceforge.net/viewvc/crownandcutlass/trunk/Protocce/src/CMakeLists.txt?revision=1020view=markuppathrev=1027 Unit test app - http://crownandcutlass.svn.sourceforge.net/viewvc/crownandcutlass/trunk/Protocce/test/src/CMakeLists.txt?revision=1020view=markuppathrev=1027 http://crownandcutlass.svn.sourceforge.net/viewvc/crownandcutlass/trunk/Protocce/test/src/CMakeLists.txt?revision=1020view=markuppathrev=1027 Like I said, the same code base works fine in XP, LInux, and if I use the Makefiles it works in OS X. I may just be doing something stupid. This is my first CMake project, and like I said I just got a Mac so I have never used Xcode outside of this attempt. I am not sure this is worth delaying 2.4.8 since the behavior is the same as 2.4.7. Also, I have not had time to try building a new CMake binary from CVS, sorry. However, I thought I should report what I'm experiencing before too much longer. Let me know what I can do to help. Sounds like flag differences. You should do a make VERBOSE=1 with the makefile, then use cmakexbuild to build the project file. Find a common .cxx file being compiled by both, and compare the compile lines. You can post the compile lines to the list, and I might be able to help. Either way it is not a regression in RC 11 but perhaps a new bug. -Bill Here are some example build lines. Using Xcode: CompileC ProtocceTest.build/Debug/Test.build/Objects-normal/i386/EventTest.o /Users/davidthulson/Documents/Code/crownandcutlass/trunk/Protocce/test/src/EventTest.cpp normal i386 c++ com.apple.compilers.gcc.4_0 cd /Users/davidthulson/Documents/Code/crownandcutlass/trunk/Protocce/test/bin/osx /Developer/usr/bin/gcc-4.0 -x c++ -arch i386 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -mdynamic-no-pic -DCMAKE_INTDIR=Debug -fmessage-length=0 -gdwarf-2 -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -O0 -F/Users/davidthulson/Documents/Code/crownandcutlass/trunk/Protocce/test/bin/osx/Debug -F/Library/Frameworks -F/Users/davidthulson/OgreSDK/Dependencies -F/Users/davidthulson/OISv1_0_Mac_SDK -F/System/Library/Frameworks -I/Users/davidthulson/Documents/Code/crownandcutlass/trunk/Protocce/test/bin/osx/Debug/include -I/Users/davidthulson/Documents/Code/crownandcutlass/trunk/Protocce/test/src/../../include -I/Users/davidthulson/Documents/Code/crownandcutlass/trunk/Protocce/test/src/../include -I/usr/local/include/boost-1_34_1 -I/System/Library/Frameworks/OpenAL.framework/Headers -I/Users/davidthulson/OgreSDK/Dependencies/Ogre.framework/Headers -I/Users/davidthulson/OISv1_0_Mac_SDK/OIS.framework/Headers -I/Users/davidthulson/OgreSDK/Dependencies/CEGUI.framework/Headers
[CMake] Re: Get full output library filename
Josef Karthauser wrote: Hmm, I can't see where it would have been fixed. Can one of the developers please comment? If you look at Sources/cmTarget.cxx:1987, you'll read: // Append the per-configuration postfix. outBase += configPostfix?configPostfix:; before that configPostfix is set to the correct value (if CMAKE_BUILD_TYPE is set). cvs annotate says that this modification was made on revision 1.81 by Brad King on 13-Jan-06. I think that this is it. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Help:Using CMake with Eclipse
On Saturday 12 January 2008, Yang, Y. wrote: Hi, All. I follow the instructions of the link: http://www.cmake.org/Wiki/CMake:Eclipse. I successfully build my application. However, when I try to use CMake as external tool, the eclipse call it and show cmake cannot find qmake. CMake Error: Qt qmake not found! How to configure eclipse's external tool enviroment and make cmake can find qmake when it be called by eclipse? Make sure that Qt4 qmake is available over PATH environment variable, i.e. the environment from which Eclipse was started. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Find*.cmake variable naming
On Jan 14, 2008 2:01 PM, Rodolfo Schulz de Lima wrote: Hi, I'd like to comment on the Find*.cmake variable naming procedure adopted by cmake. Right now I have to look at some Find*.cmake files to see what are the output variables they create. Some packages create a *_LIBRARY, others *_LIBRARIES, others *_INCLUDE_DIRS and others *_INCLUDE_DIR. The Modules/readme.txt procedure isn't being used for some packages. snip As Mike commented... I agree! I would like to see consistency among the Find*.cmake modules. However, keep in mind that compatibility issues make it hard to fix sometimes. In many cases the appropriate thing to do is to follow the Modules/readme.txt and then create a compatibility layer which assigns the correct style names to whatever there was before. About upcased names vs mixed case... there was a thread in which it was mentioned (I believe Brad King, but I might be wrong) that there was a desire to move to mixed cased names. That is, if a module is named FindBzip2.cmake, then the variables should be prefixed with Bzip2. If it is named FindBZIP2.cmake then they should be prefixed with BZIP2. This was do to the fact that cmake creates a set of variables (e.g., XXX_FIND_COMPONENTS) when entering the module that follows the case of the module's name. I don't know if things have changed, but I would like to see consistency. At least, modules being added these days should conform to the readme.txt. Having a list of standard-compliant modules appended to the readme.txt might help new module writers. --Miguel PS - Brad, I'm copying you directly since I sort of quote you. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Help:Using CMake with Eclipse
2008/1/13, Yang, Y. [EMAIL PROTECTED]: Thanks. cmake can find qmake when use terminal. Then as Alex suggested this should be an environment problem. Could you launch Eclipse from the very same terminal you succeed to run CMake from and retry ? What is your platform? Linux? Windows? What version of CMake and Eclipse do you use? So maybe the best way is using eclipse as an Editor. I can assure you you may do more than that _CURRENTLY_. But I hope in the futher, the CMake could be perfectly incorporated into the eclipse. It is reall a good tool. Thanks for you help. -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Find*.cmake variable naming
On Monday 14 January 2008, Mike Jackson wrote: On Jan 14, 2008, at 1:01 PM, Rodolfo Schulz de Lima wrote: Nothing much to add except, I Agree. Consistency in any API/ Language is essential for people to learn quickly. I would also think Yes. that the jump from 2.4.x to 2.6.x is _perfect_ time to change the variables. There may be other major changes API breakage, No, there may not, at least it is the goal to have CMake 2.6 completely compatible. If something is working with CMake 2.4 but doesn't work with 2.6 this is considered a bug (maybe except for undocumented functions/variables, and maybe except things where one could argue about which behaviour is correct). The documentation how the variables should be named is in CMake/Modules/readme.txt. The documentation for the modules coming with cmake is on the man page, with cmake cvs it is possible to also create documentation for modules in CMAKE_MODULE_PATH. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Find*.cmake variable naming
On Jan 14, 2008, at 4:03 PM, Alexander Neundorf wrote: The documentation for the modules coming with cmake is on the man page, with cmake cvs it is possible to also create documentation for modules in CMAKE_MODULE_PATH. Actually, no, that does not work on my CVS HEAD from this morning. ./cmake --help-module-list | mate cmake version 2.5-20080114 Internal error: Modules list is empty. -- Mike Jackson Senior Research Engineer Innovative Management Technology Services ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Find*.cmake variable naming
On Monday 14 January 2008, Miguel A. Figueroa-Villanueva wrote: ... I don't know if things have changed, but I would like to see consistency. At least, modules being added these days should conform to the readme.txt. Having a list of standard-compliant modules appended to the readme.txt might help new module writers. Good idea :-) Can you go through the modules, compare them with the current readme.txt and come up with the list ? Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Find*.cmake variable naming
On Monday 14 January 2008, Mike Jackson wrote: On Jan 14, 2008, at 4:03 PM, Alexander Neundorf wrote: The documentation for the modules coming with cmake is on the man page, with cmake cvs it is possible to also create documentation for modules in CMAKE_MODULE_PATH. Actually, no, that does not work on my CVS HEAD from this morning. ./cmake --help-module-list | mate cmake version 2.5-20080114 Internal error: Modules list is empty. Fixed. (-help-modules and -help-module FindFoo were working). If you find more problems please let us know. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Find*.cmake variable naming
Rodolfo Schulz de Lima wrote: Hi, I'd like to comment on the Find*.cmake variable naming procedure adopted by cmake. Right now I have to look at some Find*.cmake files to see what are the output variables they create. Some packages create a *_LIBRARY, others *_LIBRARIES, others *_INCLUDE_DIRS and others *_INCLUDE_DIR. The Modules/readme.txt procedure isn't being used for some packages. Also the vast majority creates upcased (is this an adjective?) variable names, BUT Boost and wxWidgets. There two define Boost_FOUND, Boost_LIBRARIES, wxWidgets_FOUND, wxWidgets_LIBRARIES. It should be better if they were BOOST_FOUND, WXWIDGETS_FOUND etc. For much better FindBoost.cmake module take a look at http://cmake-modules.googlecode.com/svn/trunk/Modules/Boost/FindBoost.cmake -- andreas -- http://www.cynapses.org/ - cybernetic synapses signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] running FIND_PROGRAM twice
I just filed bug http://cmake.org/Bug/view.php?id=6241 , FindPerlLibs should use FindPerl. My assumption is that if FIND_PROGRAM is run twice with the same output variable (in this case PERL_EXECUTABLE), the 2nd invocation will wipe out the value from the 1st invocation. Is that a correct assumption? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] running FIND_PROGRAM twice
On Jan 14, 2008 7:18 PM, Brandon Van Every wrote: I just filed bug http://cmake.org/Bug/view.php?id=6241 , FindPerlLibs should use FindPerl. My assumption is that if FIND_PROGRAM is run twice with the same output variable (in this case PERL_EXECUTABLE), the 2nd invocation will wipe out the value from the 1st invocation. Is that a correct assumption? As I understand it, the second time will only execute if the first attempt is failed. That is, FIND_PROGRAM(output_var ...) sets output_var as a cache variable. If it is set to a XXX-NOTFOUND value then the second time it is invoked it will search again. If it is found the first time, then the second time it won't search for it (since it is found). This limitation has to do with not overiding values that the user sets in the GUI. Well, I hope that makes sense. --Miguel ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Find*.cmake variable naming
On Jan 14, 2008, at 5:08 PM, Alexander Neundorf wrote: On Monday 14 January 2008, Mike Jackson wrote: On Jan 14, 2008, at 4:03 PM, Alexander Neundorf wrote: The documentation for the modules coming with cmake is on the man page, with cmake cvs it is possible to also create documentation for modules in CMAKE_MODULE_PATH. Actually, no, that does not work on my CVS HEAD from this morning. ./cmake --help-module-list | mate cmake version 2.5-20080114 Internal error: Modules list is empty. Fixed. (-help-modules and -help-module FindFoo were working). If you find more problems please let us know. Alex Great, it works now. My script that builds Qt Assistant documentation works completely now. Awesome. As I perused the generated documentation there are some typos, and some documentation that is just plain wrong. I'll post information on those a bit later. Thanks for the quick fix. -- Mike Jackson Senior Research Engineer Innovative Management Technology Services ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] running FIND_PROGRAM twice
On Jan 14, 2008 6:55 PM, Miguel A. Figueroa-Villanueva [EMAIL PROTECTED]
wrote:
On Jan 14, 2008 7:18 PM, Brandon Van Every wrote:
I just filed bug http://cmake.org/Bug/view.php?id=6241 , FindPerlLibs
should use FindPerl. My assumption is that if FIND_PROGRAM is run
twice with the same output variable (in this case PERL_EXECUTABLE),
the 2nd invocation will wipe out the value from the 1st invocation.
Is that a correct assumption?
As I understand it, the second time will only execute if the first
attempt is failed. That is, FIND_PROGRAM(output_var ...) sets
output_var as a cache variable. If it is set to a XXX-NOTFOUND value
then the second time it is invoked it will search again. If it is
found the first time, then the second time it won't search for it
(since it is found).
This limitation has to do with not overiding values that the user sets
in the GUI.
I should clarify. I mean FIND_PROGRAM is run twice in the same
invocation of CMakeLists.txt, with different parameters. Example:
FIND_PROGRAM(PERL_EXECUTABLE
perl
C:/Perl/bin
[HKEY_LOCAL_MACHINE\\SOFTWARE\\ActiveState\\ActivePerl\\804]/bin
[HKEY_LOCAL_MACHINE\\SOFTWARE\\ActiveState\\ActivePerl\\628]/bin
${CYGWIN_INSTALL_PATH}/bin
)
FIND_PROGRAM(PERL_EXECUTABLE perl )
Let's say the 1st FIND_PROGRAM finds a perl using HKEY. Will the 2nd
FIND_PROGRAM come up with NOTFOUND?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Find*.cmake variable naming
On Jan 14, 2008 1:01 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote: Some packages create a *_LIBRARY, others *_LIBRARIES, Sometimes a library, like PNG, creates both, and the meanings are distinct. *_LIBRARY is the PNG library alone. *_LIBRARIES includes all of the link libraries you need to actually make PNG work, such as zlib. The only way I've found to use the Modules in practice, is to read their source code. There's not just a consistency problem, there's a documentation problem. Is there any way to automate the documentation of modules? Like require the use of functions that will spit out their input and output variables in a document format? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] running FIND_PROGRAM twice
Brandon Van Every wrote: I just filed bug http://cmake.org/Bug/view.php?id=6241 , FindPerlLibs should use FindPerl. My assumption is that if FIND_PROGRAM is run twice with the same output variable (in this case PERL_EXECUTABLE), the 2nd invocation will wipe out the value from the 1st invocation. Is that a correct assumption? No, it is not correct. Once something is found, it can not be set to NOTFOUND by another find command. If that were true, then cmake would keep looking for things over and over. It is perfectly valid and expected to call find_* more than once in a find module. The first one that finds it will stop the searching. This is all documented in the find_* commands. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] running FIND_PROGRAM twice
On Jan 14, 2008 9:14 PM, Bill Hoffman [EMAIL PROTECTED] wrote: No, it is not correct. Once something is found, it can not be set to NOTFOUND by another find command. If that were true, then cmake would keep looking for things over and over. It is perfectly valid and expected to call find_* more than once in a find module. The first one that finds it will stop the searching. Ok. This is all documented in the find_* commands. I don't think the docs are entirely clear about different invocations of FIND_PROGRAM that use the same variable. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] running FIND_PROGRAM twice
On Jan 14, 2008 10:13 PM, David Cole [EMAIL PROTECTED] wrote: And from the middle of the same text: is created to store the result of this command. If the program is found the result is stored in the variable and the search will not be repeated unless the variable is cleared. If nothing is found, the result will be VAR-NOTFOUND, and the search will be attempted again the next time FIND_PROGRAM is invoked with the same variable. The Score: pretty-clear 2 / not-so-clear 0 No, this is the unclear part. 2 different invocations of FIND_PROGRAM that share the same variable, but with different search parameters, are not the same search. I missed the clear example at the very very end of the FIND_PROGRAM entry. Presumably because it's separated from the above snippet by a lot of text. Putting the clear example right after the above snippet would help. Or a slight wordsmithing would help. I will provide that when I'm more alert. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] running FIND_PROGRAM twice
And from the middle of the same text: is created to store the result of this command. If the program is found the result is stored in the variable and the search will not be repeated unless the variable is cleared. If nothing is found, the result will be VAR-NOTFOUND, and the search will be attempted again the next time FIND_PROGRAM is invoked with the same variable. The Score: pretty-clear 2 / not-so-clear 0 On 1/14/08, David Cole [EMAIL PROTECTED] wrote: On 1/14/08, Brandon Van Every [EMAIL PROTECTED] wrote: On Jan 14, 2008 9:14 PM, Bill Hoffman [EMAIL PROTECTED] wrote: This is all documented in the find_* commands. I don't think the docs are entirely clear about different invocations of FIND_PROGRAM that use the same variable. C:\Documents and Settings\DavidC:\Program Files\CMake 2.4\bin\cmake --help-command FIND_PROGRAM cmake version 2.4-patch 6 most of the documentation omitted for brevity -- except for these last 6 lines: in the locations specified by their environment. Projects may override this behavior by simply calling the command twice: FIND_PROGRAM(VAR NAMES name PATHS paths NO_DEFAULT_PATH) FIND_PROGRAM(VAR NAMES name) Once one of these calls succeeds the result variable will be set and stored in the cache so that neither call will search again. Last two lines pretty much say the result is stored in the cache and subsequent calls will not search. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] running FIND_PROGRAM twice
On 1/14/08, Brandon Van Every [EMAIL PROTECTED] wrote: On Jan 14, 2008 9:14 PM, Bill Hoffman [EMAIL PROTECTED] wrote: This is all documented in the find_* commands. I don't think the docs are entirely clear about different invocations of FIND_PROGRAM that use the same variable. C:\Documents and Settings\DavidC:\Program Files\CMake 2.4\bin\cmake --help-command FIND_PROGRAM cmake version 2.4-patch 6 most of the documentation omitted for brevity -- except for these last 6 lines: in the locations specified by their environment. Projects may override this behavior by simply calling the command twice: FIND_PROGRAM(VAR NAMES name PATHS paths NO_DEFAULT_PATH) FIND_PROGRAM(VAR NAMES name) Once one of these calls succeeds the result variable will be set and stored in the cache so that neither call will search again. Last two lines pretty much say the result is stored in the cache and subsequent calls will not search. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Adding Custom Build Types
Hi I have a requirement in which I need to have custom build types in my project. CMake provides the below mentioned build types by default: Debug Release RelWithDebInfo MinSizeRel Now In my project I don't want these build types. I want custom build types like MD, MT, MDd, MTd, ML etc (for Visual Studio 6 and Visual Studio 8 2005 both). These build types are required to set the appropriate runtime library. Is there any provision in CMake through which this can be achieved? Thanks and Regards Anupam Malhotra The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to generate compiler error files with CMake
When compiling an individual file (file.cpp), I would like to have an error file (file.err) containing all errors generated during the compilation. Is there an easy way to generate a compiler error file (next to the stdout) for each individual file compiled using CMake? Thankk you, Dieter ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] OSX universal binary support
Hi I see a mention of support for OSX universal binary in the release notes. However, from running cmake --help-html, I was unable to find any explanation on how to use the feature. I am building on the command line using make. However, if I need to use XCode build to get the feature working, that's fine too. Regards -- Nicholas Yue BSc (Hons) MACM Need help with software development process? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Find*.cmake variable naming
On Tuesday 15 January 2008 03:29:40 Brandon Van Every wrote: On Jan 14, 2008 1:01 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote: Some packages create a *_LIBRARY, others *_LIBRARIES, Sometimes a library, like PNG, creates both, and the meanings are distinct. *_LIBRARY is the PNG library alone. *_LIBRARIES includes all of the link libraries you need to actually make PNG work, such as zlib. Plus, if the problem discussed is just naming of some variables in some modules that is breaking a commonly decided naming scheme then they can be fixed by adding those proper variable names and still leaving the old variable names for compatibility which will be removed in time (this at least should work for the wrong case variables). -- Mihai RUSU Email: [EMAIL PROTECTED] Linux is obsolete -- AST ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
