[CMake] Installing CMake for multiple platforms
I have checked in the CMake binaries in our cvs repositories, because that makes it easier to set up the proper build environment on new machines. I have currently checked in version 2.0.6, but I want to upgrade to the latest version to support VS 2005 64 bit builds. I noticed though that the structure of the installation dir changed slightly. Here's what I currently checked in: \BUILDTOOLS\CMAKE ├───EdmTemplates ├───hpux │ ├───bin │ ├───include │ ├───Modules │ │ └───Platform │ └───Templates └───Win32 ├───bin ├───include ├───Modules │ └───Platform └───Templates As you may have noticed, we currently use CMake on HPPUX and Win32, with probably more platforms to come. We also developed a large set of CMake macros to simplify CMakeLists.txt configuration. The "nasty" thing about this tree is that the platform independent include, Modules and Templates directories are located in each platform's directory and have to be copied in each platform dir. This is also the case for our macro files, because INCLUDE(EDMTools) will search in the Modules sub-dir. In order to prevent maintaining the same file in several directories, the actual macro file is in \BuildTools\CMake and the platform specific EDMTools.cmake contains: STRING(REGEX REPLACE "/CMake.*" "" BUILDTOOLS_DIR "${CMAKE_ROOT}") MESSAGE(STATUS "BUILDTOOLS_DIR = ${BUILDTOOLS_DIR}") INCLUDE("${BUILDTOOLS_DIR}/CMake/EDMTools.cmake") Now, after installing CMake 2.4.2 locally, I noticed the directory structure now looks like this: D:\APPS\CMAKE 2.4 ├───bin ├───doc │ └───CMake ├───man │ └───man1 └───share └───CMake ├───include ├───Modules │ └───Platform └───Templates How will CMake locate the Modules directory and is there now an easy way to have multiple platform specific binaries with a single Modules and Templates dir? Best regards, Kris +-+-+- Email Confidentiality Footer +-+-+- Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not print, retain, copy nor disseminate this message or any part of it to anyone and you should notify the sender by reply email and destroy this message. Neglecting this clause could be a breach of confidence. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that are not related to the official business of my firm shall be understood as neither given nor endorsed by it. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Forcing C++: What Causes VC Warning D4025 : overriding /TP with /TC
Code is a mix of .c and .cpp files. Some of the directories contain only .c files. ... SET(CMAKE_C_COMPILER ${CMAKE_CXX_COMPILER}) SET_TARGET_PROPERITES( PROPERTIES LINKER_LANGUAGE CXX) Warning D4025 : overriding /TP with /TC I reported the same bug (05.06.2006 21:33), too. Will already fixed it in CVS. Jan, Thank you for this info. I'm now looking at something that seems relevant, but this look has raised more questions in my mind. I am currently running the binary distro of 2-4-2 Inside: cmLocalVisualStudio7Generator.cxx Revision: 1.125.2.3, Sun May 14 19:22:42 2006 UTC (6 weeks, 4 days ago) by hoffman Branch: CMake-2-4 CVS Tags: CMake-2-4-2 Changes since 1.125.2.2: +107 -62 lines I find: // if the source file does not match the linker language // then force c or c++ if(linkLanguage && lang && strcmp(lang, linkLanguage) != 0) { if(strcmp(lang, "CXX") == 0) { // force a C++ file type compileFlags += " /TP "; } else if(strcmp(lang, "C") == 0) { // force to c compileFlags += " /TC "; } } If I'm reading this right (?), this is the CAUSE of the problem - i.e. this is where the trailing " /TC" gets added at the end of the build command, when lang == "C", which is when the file has a .c extension. Is this right so far? then I find, in this later version, ( later than 2-4-2, meaning it's not in my CMake executable, yes?) : cmLocalVisualStudio7Generator.cxx Revision 1.135 - (view) (download) (as text) (annotate) - [select for diffs] Tue Jun 6 16:01:23 2006 UTC (3 weeks, 2 days ago) by hoffman Branch: MAIN ENH: fix /TP for c code Is this the fix you refer to? I looked at the diff for these two versions, and see that 1.135 adds code down around line 1167 dealing with flags in some way that I can't quickly decipher, but which has no immediately recognizable reference to "/TC " or "/TP ". If this is the fix, and it works, I'd be interested to understand how it works. If this is not the fix, I'm sorry for getting it wrong, and I'd welcome a pointer to the correct revision. Finally, it seems that binary distros are prepared relatively infrequently. Is getting this: SET(CMAKE_C_COMPILER ${CMAKE_CXX_COMPILER}) SET_TARGET_PROPERITES( PROPERTIES LINKER_LANGUAGE CXX) to work as intended in these circumstances not judged important enough to warrant a 2-4-3 build? It would be helpful, if possible, to be able to refer my development partner(s) to a binary distro of CMake that handles this situation. If I have to bite the bullet and start compiling CMake's own source code, and getting partner(s) to do same, I imagine we can and will, but if generating a 2-4-3 binary at "home base" is not hard, perhaps it would be worthwhile and save some people from extra work and possible issues in the field. - Steve ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Installing CMake for multiple platforms
The directory stucture in your email has font issues or something. Can you re-post in plain text? >\BUILDTOOLS\CMAKE >ââââEdmTemplates >ââââhpux >â ââââbin >â ââââinclude >â ââââModules >â â ââââPlatform >â ââââTemplates >ââââWin32 >ââââbin >ââââinclude >ââââModules >â ââââPlatform >ââââTemplates > -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Installing CMake for multiple platforms
Hi Bill, I actually posted it in plain text (from Outlook 2003). It's probably a Windows OEM font since I copied it from a cmd window's tree output. Looks like it was UTF8 translated in your mail. Anyway, here's the original without the line characters: I have checked in the CMake binaries in our cvs repositories, because that makes it easier to set up the proper build environment on new machines. I have currently checked in version 2.0.6, but I want to upgrade to the latest version to support VS 2005 64 bit builds. I noticed though that the structure of the installation dir changed slightly. Here's what I currently checked in: \BUILDTOOLS\CMAKE +---EdmTemplates +---hpux | +---bin | +---include | +---Modules | | +---Platform | +---Templates +---Win32 +---bin +---include +---Modules | +---Platform +---Templates As you may have noticed, we currently use CMake on HPUX and Win32, with probably more platforms to come. We also developed a large set of CMake macros to simplify CMakeLists.txt configuration. The "nasty" thing about this tree is that the platform independent include, Modules and Templates directories are located in each platform's directory and have to be copied in each platform dir. This is also the case for our macro files, because INCLUDE(EDMTools) will search in the Modules sub-dir. In order to prevent maintaining the same file in several directories, the actual macro file is in \BuildTools\CMake and the platform specific EDMTools.cmake contains: STRING(REGEX REPLACE "/CMake.*" "" BUILDTOOLS_DIR "${CMAKE_ROOT}") MESSAGE(STATUS "BUILDTOOLS_DIR = ${BUILDTOOLS_DIR}") INCLUDE("${BUILDTOOLS_DIR}/CMake/EDMTools.cmake") Now, after installing CMake 2.4.2 locally, I noticed the directory structure now looks like this: D:\APPS\CMAKE 2.4 +---bin +---doc | +---CMake +---man | +---man1 +---share +---CMake +---include +---Modules | +---Platform +---Templates How will CMake locate the Modules directory and is there now an easy way to have multiple platform specific binaries with a single Modules and Templates dir? Best regards, Kris -- The bottom line is: how can I install cmake in a directory structure with different exes but a single Modules, Templates, etc tree? > -Original Message- > From: William A. Hoffman [mailto:[EMAIL PROTECTED] > Sent: vrijdag 30 juni 2006 14:18 > To: Kris Dekeyser; 'cmake@cmake.org' > Subject: Re: [CMake] Installing CMake for multiple platforms > > The directory stucture in your email has font issues or something. > Can you re-post in plain text? > > >\BUILDTOOLS\CMAKE > >â"oeâ"EURâ"EURâ"EUREdmTemplates > >â"oeâ"EURâ"EURâ"EURhpux > >â"' â"oeâ"EURâ"EURâ"EURbin > >â"' â"oeâ"EURâ"EURâ"EURinclude > >â"' â"oeâ"EURâ"EURâ"EURModules > >â"' â"' â""â"EURâ"EURâ"EURPlatform > >â"' â""â"EURâ"EURâ"EURTemplates > >â""â"EURâ"EURâ"EURWin32 > >â"oeâ"EURâ"EURâ"EURbin > >â"oeâ"EURâ"EURâ"EURinclude > >â"oeâ"EURâ"EURâ"EURModules > >â"' â""â"EURâ"EURâ"EURPlatform > >â""â"EURâ"EURâ"EURTemplates > > > > > -Bill > +-+-+- Email Confidentiality Footer +-+-+- Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not print, retain, copy nor disseminate this message or any part of it to anyone and you should notify the sender by reply email and destroy this message. Neglecting this clause could be a breach of confidence. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that are not related to the official business of my firm shall be understood as neither given nor endorsed by it. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Installing CMake for multiple platforms
William A. Hoffman wrote: The directory stucture in your email has font issues or something. Reading it in character encoding "Uncode" (instead of western works here. Jan. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] VS 8 & CMake 2.4.2
Hi, Previously problems using CMake with Visual Studio 8 were reported. They were reported with Visual Studio 2005 Express, but I encountered them too with the full Visual Studio 8 version. CMake failed to compile the test program and the output showed that OLDNAMES.lib could not be found. What happened is the following: When installing VS8 I removed the static runtime libraries from the installer selection since we always link against the runtime DLLs. Apparently this is not supported by CMake. The solution is to either add the static runtime libs to your installation or add /ignorlib:OLDLIBNAMES.lib to the compiler flags. I choose the first solution, because it's the easiest. Changing the default compiler flags requires some fiddling with cmake files in the installation. Best regards, Kris +-+-+- Email Confidentiality Footer +-+-+- Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not print, retain, copy nor disseminate this message or any part of it to anyone and you should notify the sender by reply email and destroy this message. Neglecting this clause could be a breach of confidence. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that are not related to the official business of my firm shall be understood as neither given nor endorsed by it. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Regex changes between cmake 2.0.6 and 2.4.2 ??
Hi, I was running my build macros in the latest CMake (2.4.2) and encountered very strange errors. With some debug printing I discovered that the new CMake version behaves differently regarding RegEx testing compared to the version 2.0.6 that we currently use. This is a summary of what we do: SET(RegexAbsoluteDir "^([a-zA-Z][:])?[/]") #--- Make directories absolute SET(DirList) PRINT_MESSAGE(9 "WordList ${WordList}") FOREACH(word ${WordList}) PRINT_MESSAGE(9 "word ${word}") IF(${word} MATCHES ${RegexAbsoluteDir}) PRINT_MESSAGE(9 "word ${word} matches ${RegexAbsoluteDir}") SET(DirList ${DirList} ${word}) ELSE(${word} MATCHES ${RegexAbsoluteDir}) PRINT_MESSAGE(9 "word ${word} does not match ${RegexAbsoluteDir}") SET(DirList ${DirList} "${${ProjectName}_SOURCE_DIR}/${word}") ENDIF(${word} MATCHES ${RegexAbsoluteDir}) PRINT_MESSAGE(9 "DirList ${DirList}") ENDFOREACH(word) With Cmake 2.4.2 I got this output: -- WordList D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include -- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include -- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include does not match ^([a-zA-Z][:])?[/\] -- DirList D:/Workspace/EDA/1.1/Packages/EDA_Interface/D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include With Cmake 2.0.6 I got: -- WordList D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include -- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include -- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include matches ^([a-zA-Z][:])?[/\] -- DirList D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include So, is this: a) a bug ? b) a fixed bug ? If b), how should I modify my RegEx expression to get the desired result? I have to work with the Cmake book for version 1.8 for now. +-+-+- Email Confidentiality Footer +-+-+- Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not print, retain, copy nor disseminate this message or any part of it to anyone and you should notify the sender by reply email and destroy this message. Neglecting this clause could be a breach of confidence. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that are not related to the official business of my firm shall be understood as neither given nor endorsed by it. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] ExceptionHandling in VC8
Hello CMake users, I have noticed that the ExceptionHandling flag is not fully handled for VC8 projects. Namely, in VC7 this option could only be set to TRUE or FALSE. In VC8, we have the following options: Enable C++ exceptions : No - ExceptionHandling="0" Yes (/EHsc) - ExceptionHandling="1" Yes with SEH Exceptions (/EHa) - ExceptionHandling="2" The /EHa option is not handled by the generator and ends up in the AdditionalOptions line. This results for us in a warning (/EHsc replaced with /EHa) for every file we compile in our projects. It would be nice to have this option fully supported by CMake, especially since VC8 seems to become the new IDE of choice for Windows C++ development. Cheers, Laurentiu -- Laurentiu Nicolae Senior Software Engineer Quintiq Tel: +31 (0)73 691 07 39 Fax: +31 (0)73 691 07 54 www.quintiq.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CTest Question
At 04:51 PM 6/29/2006, Scott Amort wrote: >William A. Hoffman wrote: >> make test should do the trick. >> You can also run ctest directly in the build tree. >> What you have should work. You might have to move the >> ENABLE_TESTING to the top of the project. Also you can >> look for the DartTesting. You can look for this file >> in your build tree and make sure it looks good: >> DartTestfile.txt > >Thanks Bill - I just needed to move ENABLE_TESTING up to the project >root. Works now! > >However, it does compile the testing executables during the `make' >command, and only runs them during the `make test'. If I make a change >to one of the tests, I have to run `make' again, then `make test'... >`make test' alone doesn't see that changes were made to the sources. >Certainly only a minor complaint, but is there a way to restrict the >compiling/link/executing of tests to the `make test' command? You may want to look at the ctest --build-and-test option. We use it in cmake itself. It will run cmake and do a build on a test that is not include in the parent build tree. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] automagically generated header hell
I have a similar problem, except that using ADD_DEPENDENCIES to make the library with generated files a dependency of the targets that use it, causes the target libraries to include a copy of the dependent library when built as static libraries with VC71 (this is a long standing (mis)feature of visual studio). Since my generated library is large, the resulting build ends up being huge. Anyway, strictly speaking the (non-generated) targets only depend on the generated header files to compile. (For linking it will be handled correctly anyway via TARGET_LINK_LIBRARIES.) Looking at a make-based build it seems that if the generated header files exist, they are included in the dependencies of the source files using them, however in a clean build they don't exist yet, so aren't listed as dependencies. Since the generated header files have the GENERATED property set to true would it be possible for the dependency scan to include these files as dependencies even though they don't yet exist? It would then correctly go an generate the header files before compiling files that include them. Mike David Somers wrote: In a project I'm workking on I use makeheaders (http://www.cvstrac.org/cvstrac/dir?d=cvstrac) to automagically generate the h files for my c files. I'm using ADD_CUSTOM_TARGET to generate the headers, and some ADD_DEPENDENCIES magic to ensure they're generated before the code is compiled. All works quite well. However, as the cmake wiki says "Note that generated headers can often cause unnecessary rebuilds and should be avoided if possible." And I've run into this problem :-( I have a library that depends on an application being done first (so that the library can pull in some of the headers that are generated when the app is made). Using ADD_DEPENDENCIES this is working automagically, but the problem I've hit is that the library has rebuild problems (i.e. it make will rebuilt it even when everything in it is up-to-date). Is there some way to 'persuade' cmake that in my library when foo.c does #include that it shouldn't add into the dependencies (because I've manually taken care of that elsewhere)? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] out-of-source build and generated files
Alexander Neundorf wrote: > If you generate files using ADD_CUSTOM_COMMAND(), you should always use full > paths for the generated files, i.e. > ${CMAKE_CURRENT_BINARY_DIR}/generatedsource.cpp , both in the > ADD_CUSTOM_COMMAND() and in the list of source files. Perfect... that did it. Thanks Alexander! Best, Scott ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CTest Question
William A. Hoffman wrote: > You may want to look at the ctest --build-and-test option. > We use it in cmake itself. It will run cmake and do a build on > a test that is not include in the parent build tree. Hi Bill, I will look into this. Thanks again for your assistance! Best, Scott ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] automagically generated header hell
At 05:58 PM 6/29/2006, David Somers wrote: >In a project I'm workking on I use makeheaders >(http://www.cvstrac.org/cvstrac/dir?d=cvstrac) to automagically generate the >h files for my c files. > >I'm using ADD_CUSTOM_TARGET to generate the headers, and some ADD_DEPENDENCIES >magic to ensure they're generated before the code is compiled. > >All works quite well. > >However, as the cmake wiki says "Note that generated headers can often cause >unnecessary rebuilds and should be avoided if possible." And I've run into >this problem :-( > >I have a library that depends on an application being done first (so that the >library can pull in some of the headers that are generated when the app is >made). Using ADD_DEPENDENCIES this is working automagically, but the problem >I've hit is that the library has rebuild problems (i.e. it make will rebuilt >it even when everything in it is up-to-date). Why would make do that? Are you changing the generated .h files each run? >Is there some way to 'persuade' cmake that in my library when foo.c does >#include that it shouldn't add into the dependencies (because >I've manually taken care of that elsewhere)? I am not sure I understand why you would want to do this. If the .h file has changed, you should rebuild any .c file that includes it. You might be able to use INCLUDE_REGULAR_EXPRESSION to make cmake skip some files. >-- >David Somers >___ >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] automagically generated header hell
On Friday 30 June 2006 17:41, you wrote: > Why would make do that? Are you changing the generated .h files each run? Dammit! I was accidentally changing a file... doing cp instead of cp -p. G. > >Is there some way to 'persuade' cmake that in my library when foo.c does > >#include that it shouldn't add into the dependencies > > (because I've manually taken care of that elsewhere)? > > I am not sure I understand why you would want to do this. If the .h file > has changed, you should rebuild any .c file that includes it. You might > be able to use INCLUDE_REGULAR_EXPRESSION to make cmake skip some files. I had a situation where a tool would always regenerate a h file... I fudge the issue now by caching the file and only replace it if diff says the file really is different (opposed to just being newer). BTW, one hiccup I still have is this: for the COMMENT, how can I get it to print out the $ character? Thanks, David Somers typographer/programmer/whatever ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] automagically generated header hell
At 12:26 PM 6/30/2006, David Somers wrote: >BTW, one hiccup I still have is this: for the COMMENT, how can I get it to >print out the $ character? \$ should work. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Regex changes between cmake 2.0.6 and 2.4.2 ??
Kris Dekeyser wrote: Hi, I was running my build macros in the latest CMake (2.4.2) and encountered very strange errors. With some debug printing I discovered that the new CMake version behaves differently regarding RegEx testing compared to the version 2.0.6 that we currently use. This is a summary of what we do: SET(RegexAbsoluteDir "^([a-zA-Z][:])?[/]") #--- Make directories absolute SET(DirList) PRINT_MESSAGE(9 "WordList ${WordList}") FOREACH(word ${WordList}) PRINT_MESSAGE(9 "word ${word}") IF(${word} MATCHES ${RegexAbsoluteDir}) PRINT_MESSAGE(9 "word ${word} matches ${RegexAbsoluteDir}") SET(DirList ${DirList} ${word}) ELSE(${word} MATCHES ${RegexAbsoluteDir}) PRINT_MESSAGE(9 "word ${word} does not match ${RegexAbsoluteDir}") SET(DirList ${DirList} "${${ProjectName}_SOURCE_DIR}/${word}") ENDIF(${word} MATCHES ${RegexAbsoluteDir}) PRINT_MESSAGE(9 "DirList ${DirList}") ENDFOREACH(word) With Cmake 2.4.2 I got this output: -- WordList D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include -- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include -- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include does not match ^([a-zA-Z][:])?[/\] -- DirList D:/Workspace/EDA/1.1/Packages/EDA_Interface/D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include With Cmake 2.0.6 I got: -- WordList D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include -- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include -- word D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include matches ^([a-zA-Z][:])?[/\] -- DirList D:/Workspace/EDA/1.1/Packages/EDA_Interface/export/include I just ran your example with 2.4.2 and got the latter output. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] subdirectories INSTALL(FILES "subdir/foo.h" ...)
Jan Woetzel wrote: Hi, I expected INSTALL(FILES "subdir/foo.h" DESTINATION include ) to install "foo.h" into include/subdir but it installs into: include Thus the subdirectory structure is lost. (1) This is a bug or am I missing something ? It works if I put the approppritae DESTINATION into each subdirectories CMakeLists.txt it works. But I want to use a globbing expression to install all headers keeping their subdirectory structure to avoid forgetting to ad dthem. I'm using Cmake 2.4.2 on Windows (with MSVS 7.1 generator). This is the expected behavior. The FILES option is meant to list the exact files that should be installed to the given destination regardless of source location. You can probably do what you want in CMake code with a combination of FILE(GLOB) and IF(IS_DIRECTORY). What is missing is an INSTALL(DIRECTORY ...) option. There is a feature request already in the bug tracker for this but it has not yet been implemented. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ExceptionHandling in VC8
Laurentiu Nicolae wrote: Hello CMake users, I have noticed that the ExceptionHandling flag is not fully handled for VC8 projects. Namely, in VC7 this option could only be set to TRUE or FALSE. In VC8, we have the following options: Enable C++ exceptions : No - ExceptionHandling="0" Yes (/EHsc) - ExceptionHandling="1" Yes with SEH Exceptions (/EHa) - ExceptionHandling="2" The /EHa option is not handled by the generator and ends up in the AdditionalOptions line. This results for us in a warning (/EHsc replaced with /EHa) for every file we compile in our projects. It would be nice to have this option fully supported by CMake, especially since VC8 seems to become the new IDE of choice for Windows C++ development. There is a table in the generator used to map command line options to GUI settings in the generated project files. The /EHa option is missing from this table. You can submit a bug report here: http://www.cmake.org/Bug -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] subdirectories INSTALL(FILES "subdir/foo.h" ...)
Brad King wrote: INSTALL(FILES "subdir/foo.h" DESTINATION include ) This is the expected behavior. ...You can probably do what you want in CMake code with a combination of FILE(GLOB) and IF(IS_DIRECTORY). Thanks for the information. I will write a macro to emulate this with GET_FILENAME_COMPONENT(... PATH) to do the job. Jan. -- Dipl.-Ing. Jan Woetzel -- University of Kiel Institute of Computer Science and Applied Mathematics Hermann-Rodewald-Str. 3 [room 310] 24098 Kiel/Germany -- Phone +49-431-880-4477 Fax +49-431-880-4054 Mob. +49-179-2937346 -- Url www.mip.informatik.uni-kiel.de/~jw Email [EMAIL PROTECTED] ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ExceptionHandling in VC8
At 01:31 PM 6/30/2006, Brad King wrote: >Laurentiu Nicolae wrote: >>Hello CMake users, >>I have noticed that the ExceptionHandling flag is not fully handled for >>VC8 projects. Namely, in VC7 this option could only be set to TRUE or >>FALSE. In VC8, we have the following options: >>Enable C++ exceptions : >>No - ExceptionHandling="0" Yes (/EHsc) - ExceptionHandling="1" >>Yes with SEH Exceptions (/EHa) - ExceptionHandling="2" >>The /EHa option is not handled by the generator and ends up in the >>AdditionalOptions line. This results for us in a warning (/EHsc replaced >>with /EHa) for every file we compile in our projects. It would be nice >>to have this option fully supported by CMake, especially since VC8 seems >>to become the new IDE of choice for Windows C++ development. > >There is a table in the generator used to map command line options to GUI >settings in the generated project files. The /EHa option is missing from this >table. You can submit a bug report here: > >http://www.cmake.org/Bug Don't bother, I just commited a fix. Checking for path: /cvsroot/CMake/CMake/Source Unrestricted user: hoffman /cvsroot/CMake/CMake/Source/cmLocalVisualStudio7Generator.cxx,v <-- cmLocalVis ualStudio7Generator.cxx new revision: 1.139; previous revision: 1.138 Please try cvs cmake if you get a chance. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] subdirectories INSTALL(FILES "subdir/foo.h" ...)
Brad King wrote: You can probably do what you want in CMake code with a combination of FILE(GLOB) and IF(IS_DIRECTORY). INSTALL(DIRECTORY ...) option. There is a feature request already in the bug tracker for this but it has not yet been implemented. For the records - this works: FILE(GLOB_RECURSE BIAS_HEADER RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} *.h* ) FOREACH(VAR ${BIAS_HEADER}) # drop headers from Example dir and .in files IF (${VAR} MATCHES ".*Example.*|.*\\.in") REMOVE(BIAS_HEADER "${VAR}") ELSE (${VAR} MATCHES ".*Example.*|.*\\.in") # extract directoy for DESTINATION subdir tree until INSTALL(DIRECTORY exists) GET_FILENAME_COMPONENT(DIR ${VAR} PATH) INSTALL(FILES ${BIAS_HEADER} DESTINATION include/BIAS/${DIR} ) ENDIF(${VAR} MATCHES ".*Example.*|.*\\.in") ENDFOREACH(VAR) Jan. -- Dipl.-Ing. Jan Woetzel -- University of Kiel Institute of Computer Science and Applied Mathematics Hermann-Rodewald-Str. 3 [room 310] 24098 Kiel/Germany -- Phone +49-431-880-4477 Fax +49-431-880-4054 Mob. +49-179-2937346 -- Url www.mip.informatik.uni-kiel.de/~jw Email [EMAIL PROTECTED] ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: fixed - Re: [CMake] Forcing C++: What Causes VC Warning D4025 : overriding /TP with /TC
I reported the same bug (05.06.2006 21:33), too. Will already fixed it in CVS. BTW, I've been looking in the Bug Tracker, and I can't find this. I don't see a 'by date reported' search, nor a 'by submittor' search. What would be the best way to find what's already been written on this subject in the Bug Tracker? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: fixed - Re: [CMake] Forcing C++: What Causes VC Warning D4025 : overriding /TP with /TC
At 02:46 PM 6/30/2006, Steve Johns wrote: >>I reported the same bug (05.06.2006 21:33), too. >>Will already fixed it in CVS. > >BTW, I've been looking in the Bug Tracker, and I can't find this. > >I don't see a 'by date reported' search, nor a 'by submittor' search. > >What would be the best way to find what's already been written on this subject >in the Bug Tracker? This problem should be fixed in CVS. It no longer adds both /TP and /TC. Please try cvs before reporting a new bug, or opening an old one. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] automagically generated header hell
On Friday 30 June 2006 19:07, William A. Hoffman wrote: > At 12:26 PM 6/30/2006, David Somers wrote: > >BTW, one hiccup I still have is this: for the COMMENT, how can I get it to > >print out the $ character? > > \$ should work. That's what I would have expected too... but it doesn't :-( I'm doing this from within a MACRO ... so perhaps there is something else I need to do? -- David Somers ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] automagically generated header hell
David Somers wrote: On Friday 30 June 2006 19:07, William A. Hoffman wrote: At 12:26 PM 6/30/2006, David Somers wrote: BTW, one hiccup I still have is this: for the COMMENT, how can I get it to print out the $ character? \$ should work. That's what I would have expected too... but it doesn't :-( I'm doing this from within a MACRO ... so perhaps there is something else I need to do? The COMMENT is placed directly in the makefile as @echo "" In order to get make to echo a dollar you need this: @echo "\$$" Try this: SET(COMMENT_DOLLAR "\\$$") ADD_CUSTOM_COMMAND( ... COMMENT "Here is a dollar: ${COMMENT_DOLLAR} !!!" ) Other generators will also put the comment literally in the build file, and may require different escaping, so you may need to set COMMENT_DOLLAR differently in those cases. Really it should be CMake's job to figure out how to get the comment to display as the user specified. You can submit a bug report here: http://www.cmake.org/Bug but it may not get attention for a while as this is pretty obscure IMHO. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: fixed - Re: [CMake] Forcing C++: What Causes VC Warning D4025 : overriding /TP with /TC
Bill, Thanks for responding. This problem should be fixed in CVS. It no longer adds both /TP and /TC. Please try cvs before reporting a new bug, or opening an old one. OK, that's what I did, hence my earlier message (quoted below). Since that one got no replies, I figured I was being subtly encouraged to check out the history/status of the bug/resolution via the Bug Tracker. So, at this point, protocol-wise, I'm confused about the best and proper way to a) investigate the status/resolution of a previously reported bug b) understand where and how a fix was made, both generally and for this specific bug c) understand when and why patch releases are prepared, or not Maybe I've created a hairball of questions by this point, which wasn't my intent. I want to use the available resources efficiently and curteously - I'm asking questions to understand how to do so. I would welcome guidance on any/all of a) - c), in whole or in part. Thanks! - Steve Earlier post: Thank you for this info. I'm now looking at something that seems relevant, but this look has raised more questions in my mind. I am currently running the binary distro of 2-4-2 Inside: cmLocalVisualStudio7Generator.cxx Revision: 1.125.2.3, Sun May 14 19:22:42 2006 UTC (6 weeks, 4 days ago) by hoffman Branch: CMake-2-4 CVS Tags: CMake-2-4-2 Changes since 1.125.2.2: +107 -62 lines I find: // if the source file does not match the linker language // then force c or c++ if(linkLanguage && lang && strcmp(lang, linkLanguage) != 0) { if(strcmp(lang, "CXX") == 0) { // force a C++ file type compileFlags += " /TP "; } else if(strcmp(lang, "C") == 0) { // force to c compileFlags += " /TC "; } } If I'm reading this right (?), this is the CAUSE of the problem - i.e. this is where the trailing " /TC" gets added at the end of the build command, when lang == "C", which is when the file has a .c extension. Is this right so far? then I find, in this later version, ( later than 2-4-2, meaning it's not in my CMake executable, yes?) : cmLocalVisualStudio7Generator.cxx Revision 1.135 - (view) (download) (as text) (annotate) - [select for diffs] Tue Jun 6 16:01:23 2006 UTC (3 weeks, 2 days ago) by hoffman Branch: MAIN ENH: fix /TP for c code Is this the fix you refer to? I looked at the diff for these two versions, and see that 1.135 adds code down around line 1167 dealing with flags in some way that I can't quickly decipher, but which has no immediately recognizable reference to "/TC " or "/TP ". If this is the fix, and it works, I'd be interested to understand how it works. If this is not the fix, I'm sorry for getting it wrong, and I'd welcome a pointer to the correct revision. Finally, it seems that binary distros are prepared relatively infrequently. Is getting this: SET(CMAKE_C_COMPILER ${CMAKE_CXX_COMPILER}) SET_TARGET_PROPERITES( PROPERTIES LINKER_LANGUAGE CXX) to work as intended in these circumstances not judged important enough to warrant a 2-4-3 build? It would be helpful, if possible, to be able to refer my development partner(s) to a binary distro of CMake that handles this situation. If I have to bite the bullet and start compiling CMake's own source code, and getting partner(s) to do same, I imagine we can and will, but if generating a 2-4-3 binary at "home base" is not hard, perhaps it would be worthwhile and save some people from extra work and possible issues in the field. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: fixed - Re: [CMake] Forcing C++: What Causes VC Warning D4025 : overriding /TP with /TC
At 03:39 PM 6/30/2006, Steve Johns wrote: >Bill, > >Thanks for responding. > >>This problem should be fixed in CVS. It no longer adds both /TP and /TC. >>Please try cvs before reporting a new bug, or opening an old one. > > >OK, that's what I did, hence my earlier message (quoted below). Since that >one got no replies, I figured I was being subtly encouraged to check out the >history/status of the bug/resolution via the Bug Tracker. > >So, at this point, protocol-wise, I'm confused about the best and proper way to > >a) investigate the status/resolution of a previously reported bug >b) understand where and how a fix was made, both generally and for this >specific bug >c) understand when and why patch releases are prepared, or not We are working on 2.4.3 and it should be out in a week or so. It will have this fix. I know I fixed this issue, but I am not able to point you to the exact lines of code that made the fix work. (I do not have time to explain how the fix was made, as I don't remember the details myself of hand.) So, my short answer would be: 1. if you have a problem with a release report it to the list or bug tracker 2. if a developer claims it is fixed in cvs, try a cvs copy of cmake and see if it works for you. 3. either use the cvs version from 2, or wait for the next binary release. 4. if you do not try the cvs version, then you will have to wait for the next binary release and hope the fix works for you. There are a handful of issues that will be fixed in 2.4.3, and to avoid creating to many releases we wait. Also, it takes time to create a list. If there was a very serious problem, the release would come quicker. In this case, it is a warning, but the code still builds, and there is a work around so the problem is not considered severe enough to make a release for. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: fixed - Re: [CMake] Forcing C++: What Causes VC Warning D4025 : overriding /TP with /TC
Thanks, Bill! ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] dependencies on auto-generated files and VC-8.0
Hello, We are porting a fairly large C++ project from linux/gcc to win32/vc-80. We are using cmake 2.4.2. Everything is ok except for dependencies between targets and auto-generated files. Before going into details I want to ask a general question about a paragraph on p.16 of Mastering CMake book which says "CMake has built-in dependency analysis capabilities for C and C++ source code files. Since IDE's support and maintain dependency information, CMake skips this step for those build systems." Does it mean that CMake does not communicate any dependency information to Visual Studio? If so, then there is no point in trying to relate the dependency structure to CMake. Thanks a lot, Alex Makarenko ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake