[cmake-developers] [CMake 0012576]: CHECK_C_COMPILER_FLAG is inflexible for FAIL_REGEX
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12576
==
Reported By:Hans Johnson
Assigned To:
==
Project:CMake
Issue ID: 12576
Category: Modules
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2011-11-12 09:19 EST
Last Modified: 2011-11-12 09:19 EST
==
Summary:CHECK_C_COMPILER_FLAG is inflexible for FAIL_REGEX
Description:
The end user that wants to use a new compiler has no way to add a new FAIL_REGEX
option to the
CHECK_C_COMPILER_FLAG macro.
In ITK we created a custom ITK_CHECK_C_COMPILER_FLAG that adds only one line in
order to properly handle the intel compiler.
It would be very nice if this macro were refactored so that one could append new
FAIL_REGEX strings from end-user build environments without the need to copy and
alter this macro set.
Hans
Steps to Reproduce:
MACRO (ITK_CHECK_C_COMPILER_FLAG _FLAG _RESULT)
26 SET(SAFE_CMAKE_REQUIRED_DEFINITIONS ${CMAKE_REQUIRED_DEFINITIONS})
27 SET(CMAKE_REQUIRED_DEFINITIONS ${_FLAG})
28 CHECK_C_SOURCE_COMPILES(int main(void) { return 0; } ${_RESULT}
29 # Some compilers do not fail with a bad flag
30 FAIL_REGEX warning: command line option .* is valid for .* but
not for
C
31 # Apple gcc
32 FAIL_REGEX unrecognized .*option # GNU
33 FAIL_REGEX unknown .*option # Clang
34 FAIL_REGEX ignoring unknown option # MSVC
35 FAIL_REGEX warning D9002 # MSVC, any
lang
36 FAIL_REGEX [Uu]nknown option # HP
37 FAIL_REGEX [Ww]arning: [Oo]ption # SunPro
38 FAIL_REGEX command option .* is not recognized # XL
39 FAIL_REGEX warning
http://public.kitware.com/Bug/view.php?id=10156:
ignoring option # INTEL compilers
40 )
==
Issue History
Date ModifiedUsername FieldChange
==
2011-11-12 09:19 Hans Johnson New Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH 2/3] Add support for executable with exports flags to cmLocalGenerator::GetTargetFlags
On Sat, Nov 12, 2011 at 10:45:04AM -0500, David Cole wrote: Looks like PATCH 3/3 didn't come through... (too large for the mailing list?) It apparently requires moderator approval due to its size: Your mail to 'cmake-developers' with the subject [PATCH 3/3] Add the Ninja generator Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 108985 bytes with a limit of 80 KB Thanks, -- Peter -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Making Config.cmake files safer
On Saturday 12 November 2011, Alexander Neundorf wrote: Hi, I added a branch CheckImportedFileExistenceInConfigDotCMakeFiles cmake stage. This is the commit: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=1b12babe0cef55a0d5531a9d0d453a15598eb467 Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] NSIS auto-uninstall old before installing new
Hi, can someone have a look at my patch at [1]? The version version is now about an year (!) old. Are there any plans to use Gerrit at [2] for CMake too, so there is a central place for all open patches? [1] http://public.kitware.com/Bug/view.php?id=9946 [2] http://review.source.kitware.com/ - Patrick -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] Added very basic Windows CE Makefile support
Hi, I've created a very simple patch to add the basic support for WindowsCE to CMake. I does not provide any automatically architecture detection or so on, but enables user to use a vanilla CMake for compiling Windows CE projects. If the patch gets accepted I'll write a few lines into the wiki. - Patrick 0001-Added-very-basic-Windows-CE-Makefile-support.patch Description: Binary data -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] cdt generator and subclipse?
On Friday 11 November 2011, Dan Kegel wrote: On Fri, Nov 11, 2011 at 9:42 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: So you imported the source project (and the build project), and now svn works for the source project ? Right (I think). The symptom was that the source project would not import. Now it does, reliably. Or does it also work in the build project, e.g. in the [Source directory] linked resource ? Nope, wasn't using the linked resource. I'm running into a new problem related to multiple source projects, though; I'll post about that soon. - Dan Btw. yesterday I closed the last open Eclipse-related bug in the cmake bug tracker, so 2.8.7 will be nice for Eclipse users :-) Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple source directory scenario and cdt generator
On Saturday 12 November 2011, Dan Kegel wrote: In http://www.cmake.org/pipermail/cmake/2011-November/047250.html I wrote I can't reorganize the source tree on the developers, so I'm making do by putting the enclosing CMakeLists.txt next to all the projects: toplevel/trunk/CMakeLists.txt which is checked out to toplevel/CMakeLists.txt It does add_subdirectory(../libfoo libfoo) add_subdirectory(../libbar libbar) add_subdirectory(../baz baz) This has the possible advantage that one can have multiple top levels (say, one for server code, and one for client). I don't know how many shops suffer from this svn layout, but I'll probably add an example covering it anyway for completeness once I'm sure it doesn't explode in practice. Right, well, I found out where it explodes in practice. Here's an example: http://code.google.com/p/winezeug/source/browse/trunk/cmake_examples/ex7/ The problem comes when using the cdt generator. We can't use -DECLIPSE_CDT4_GENERATE_SOURCE_PROJECT=TRUE since there are more than one source project, but the source project that generates is really trivial, so I generate one for each source directory myself with a bit of shell: for dir in demo libsrc do sed s/PROJNAME/_$dir/ ../skeleton.project ../$dir/.project done before or after running cmake. It all works great, the source projects all show up, the project builds... BUT when you edit a source file and tell eclipse to rebuild, it just sits there. It doesn't know that the source projects are related to the build project. It looks like adding a link does the trick: --- .project.old 2011-11-11 22:51:56.797674441 + +++ .project 2011-11-11 22:52:25.380913484 + @@ -113,5 +113,11 @@ type2/type location/home/dank/winezeug/cmake_examples/ex7/demo/location /link + link + name[Source directory 2]/name + type2/type + location/home/dank/winezeug/cmake_examples/ex7/libsrc/location + /link + /linkedResources /projectDescription After I add those lines to the .project, saved changes in libsrc do seem to cause a rebuild the next time you click build project. So, I guess to support this style of project, the cdt generator should call cmExtraEclipseCDT4Generator::AppendLinkedResource() once for each call in my outer CMakeLists.txt like add_subdirectory(../libsrc libsrc). Ok. So two things: * please give current cmake master a try, it has several improvements. * please create a ticket in the cmake bug tracker for this, improved source- project generator for Eclipse, or something like this. My goal is to have no open bugs for Eclipse when 2.8.7 wil be released. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Workflow of a collaborative project in Visual Studio+CMake
For reference, the bug Mike refers to is this one: http://public.kitware.com/Bug/view.php?id=11258 I always use the manual technique of shutting down VS, running CMake, and then re-opening VS. It's really not that bad, once you get used to it. David C. On Fri, Nov 11, 2011 at 5:48 PM, Michael Jackson mike.jack...@bluequartz.net wrote: It is worse and better. 1: CMake will generate the VS projects and solutions every time it needs to run. DO NOT EDIT the generated VS projects and solutions. Add the requirements to the CMake files. 2: If you are on VS2007/VS2008 and you do a git pull and then switch to VS and click build a cmake check is run FIRST. If anything is different the new solution and project files are generated and then the build continues. You will get a dialog asking if you want to reload all of the projects. Things are pretty nice. 3: If you are on VS2010 there is now a long standing bug that seems to have no solution where you basically have to do the following: Close the VS solution git pull run cmake to regenerate the solution and projects Open the Solution and Compile. Yep. Sucks. Purchased VS2010 last year and have yet to use it because of that bug. If we (the cmake community**) were to actually figure out how to solve the problem then VS2010 would be as seamless as VS2008. Here is hoping for the future. ** I have kept track of the bug. Kitware and others have put a lot of time into trying to fix the bug. It just seams to be one of those elusive fixes that there just may not be a solution to. -- Mike Jackson www.bluequartz.net On Nov 11, 2011, at 5:30 PM, David Doria wrote: I typically work in KDevelop which has CMake support, so if another developer pushes some new files and changes to the CMakeLists.txt of my project, I simply 'git pull' the project and then click Build and it knows exactly what to do - it runs CMake and then builds the project. However, when working with Visual Studio, do I have to 'git pull', then go open cmake-gui from the VS2010E terminal, re-configure and re-generate the project, then reimport the VS2010E project, then build? This seems horribly awkward. And the reverse appears to have the same problem - if working inside VS I add a file to the VS project, how do I 'export' this addition back to the git repo? Thanks, David -- -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QtCreator generator?
On Fri, Nov 11, 2011 at 6:05 PM, David Doria daviddo...@gmail.com wrote: On Fri, Nov 11, 2011 at 5:56 PM, John Drescher dresche...@gmail.com wrote: There should have been a *.sln file that you open.? Not for a Code Blocks -NMake Makefile project. John Ok, I guess I am getting my two threads confused. To use QtCreator The consensus is to use the Code Blocks - NMake Generator. This has generated successfully a .cbp file (Code Block Project, I'm assuming). However, QtCreator seems unaware that this is a project and just opens it as plain text? How do I now open this project in QtCreator? To use Visual Studio 2010 Express If the VS PlatformSDK that David Cole mentioned is installed properly, does a Visual Studio 2010 Express generator appear in the list of generators? If not, which one am I supposed to use? Thanks, David -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake There is no difference in the generator w.r.t. Express vs. non-Express -- just use Visual Studio 10 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] /usr/bin/gcc -o tcl2c++ -rdynamic \n gcc: fatal error: no input files
I do an cmake program, but encount an stranger problem. 1. mkdir tmp; cd tmp 2. tar -zxvf ../cmake-test.tar.gz 3. mkdir build; cd build 4. cmake ..; make I got an error: /usr/bin/gcc-o tcl2c++ -rdynamic gcc: fatal error: no input files Then 1. cd .. 1. head -51 CMakeLists.txt CMakeLists.txt.tmp 2. mv CMakeLists.txt.tmp CMakeLists.txt 3. cd build 4. rm -fr * 5. cmake ..; make It works now. Why? -- YunQiang Su cmake-test.tar.gz Description: GNU Zip compressed data -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Workflow of a collaborative project in Visual Studio+CMake
On 12 November 2011 12:39, David Cole david.c...@kitware.com wrote: For reference, the bug Mike refers to is this one: http://public.kitware.com/Bug/view.php?id=11258 I always use the manual technique of shutting down VS, running CMake, and then re-opening VS. It's really not that bad, once you get used to it. Actually, there is no need to completely shut down VS. File - Close Solution or quick keyboard shortcut/accelerators use: Alt + F - t then run cmake then File - Recent Projects - reopen yours or quick shortcut Alt + F - j - 1 Using keyboard makes this operation unnoticeable effort. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Workflow of a collaborative project in Visual Studio+CMake
That's what we do to. It basically comes down to the inconvenience of having to do that with Visual Studio being outweighed (considerably!) by the cross-platform benefits of CMake. (It does help that none of our developers use Windows as their primary development platform, so it only comes up when we make sure things are working on Windows...) I really wish Microsoft would integrate support for CMake projects into Visual Studio the way KDevelop has, although I suppose that's right up there probability wise with hoping they'll integrate clang... Cheers, CY On Sat, Nov 12, 2011 at 7:39 AM, David Cole david.c...@kitware.com wrote: For reference, the bug Mike refers to is this one: http://public.kitware.com/Bug/view.php?id=11258 I always use the manual technique of shutting down VS, running CMake, and then re-opening VS. It's really not that bad, once you get used to it. David C. On Fri, Nov 11, 2011 at 5:48 PM, Michael Jackson mike.jack...@bluequartz.net wrote: It is worse and better. 1: CMake will generate the VS projects and solutions every time it needs to run. DO NOT EDIT the generated VS projects and solutions. Add the requirements to the CMake files. 2: If you are on VS2007/VS2008 and you do a git pull and then switch to VS and click build a cmake check is run FIRST. If anything is different the new solution and project files are generated and then the build continues. You will get a dialog asking if you want to reload all of the projects. Things are pretty nice. 3: If you are on VS2010 there is now a long standing bug that seems to have no solution where you basically have to do the following: Close the VS solution git pull run cmake to regenerate the solution and projects Open the Solution and Compile. Yep. Sucks. Purchased VS2010 last year and have yet to use it because of that bug. If we (the cmake community**) were to actually figure out how to solve the problem then VS2010 would be as seamless as VS2008. Here is hoping for the future. ** I have kept track of the bug. Kitware and others have put a lot of time into trying to fix the bug. It just seams to be one of those elusive fixes that there just may not be a solution to. -- Mike Jackson www.bluequartz.net On Nov 11, 2011, at 5:30 PM, David Doria wrote: I typically work in KDevelop which has CMake support, so if another developer pushes some new files and changes to the CMakeLists.txt of my project, I simply 'git pull' the project and then click Build and it knows exactly what to do - it runs CMake and then builds the project. However, when working with Visual Studio, do I have to 'git pull', then go open cmake-gui from the VS2010E terminal, re-configure and re-generate the project, then reimport the VS2010E project, then build? This seems horribly awkward. And the reverse appears to have the same problem - if working inside VS I add a file to the VS project, how do I 'export' this addition back to the git repo? Thanks, David -- -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Workflow of a collaborative project in Visual Studio+CMake
It basically comes down to the inconvenience of having to do that with Visual Studio being outweighed (considerably!) by the cross-platform benefits of CMake. (It does help that none of our developers use Windows as their primary development platform, so it only comes up when we make sure things are working on Windows...) I use Visual Studio 2010 daily for the last 6 months or so and the bug is not that difficult for me to work with at all. I do admit it is annoying when you get prompted 50 times to reload projects but most of the time it does not do that. I mean if you only add files to a single project it will not prompt you for the other 49. Now if I know the change will be big, I usually close the solution and run cmake externally from a script. John -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Workflow of a collaborative project in Visual Studio+CMake
On 11/12/2011 10:51 AM, John Drescher wrote: It basically comes down to the inconvenience of having to do that with Visual Studio being outweighed (considerably!) by the cross-platform benefits of CMake. (It does help that none of our developers use Windows as their primary development platform, so it only comes up when we make sure things are working on Windows...) I use Visual Studio 2010 daily for the last 6 months or so and the bug is not that difficult for me to work with at all. I do admit it is annoying when you get prompted 50 times to reload projects but most of the time it does not do that. I mean if you only add files to a single project it will not prompt you for the other 49. Now if I know the change will be big, I usually close the solution and run cmake externally from a script. Does this solution work for VS 2010: There is an out of cmake solution for this. http://vscommands.com/ [^] If you install the VSCommands plugin free version, it will fix the reload dialog to only ask once. -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Workflow of a collaborative project in Visual Studio+CMake
On Sat, Nov 12, 2011 at 11:08 AM, Bill Hoffman bill.hoff...@kitware.com wrote: On 11/12/2011 10:51 AM, John Drescher wrote: It basically comes down to the inconvenience of having to do that with Visual Studio being outweighed (considerably!) by the cross-platform benefits of CMake. (It does help that none of our developers use Windows as their primary development platform, so it only comes up when we make sure things are working on Windows...) I use Visual Studio 2010 daily for the last 6 months or so and the bug is not that difficult for me to work with at all. I do admit it is annoying when you get prompted 50 times to reload projects but most of the time it does not do that. I mean if you only add files to a single project it will not prompt you for the other 49. Now if I know the change will be big, I usually close the solution and run cmake externally from a script. Does this solution work for VS 2010: There is an out of cmake solution for this. http://vscommands.com/ [^] If you install the VSCommands plugin free version, it will fix the reload dialog to only ask once. I have not tried that. I will do so and report back in around 2 weeks. I am leaving for a vacation at 4:00 AM tomorrow and I do not think I will have any time to test this.. John -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Workflow of a collaborative project in Visual Studio+CMake
On Nov 12, 2011, at 11:08 AM, Bill Hoffman wrote: On 11/12/2011 10:51 AM, John Drescher wrote: It basically comes down to the inconvenience of having to do that with Visual Studio being outweighed (considerably!) by the cross-platform benefits of CMake. (It does help that none of our developers use Windows as their primary development platform, so it only comes up when we make sure things are working on Windows...) I use Visual Studio 2010 daily for the last 6 months or so and the bug is not that difficult for me to work with at all. I do admit it is annoying when you get prompted 50 times to reload projects but most of the time it does not do that. I mean if you only add files to a single project it will not prompt you for the other 49. Now if I know the change will be big, I usually close the solution and run cmake externally from a script. Does this solution work for VS 2010: There is an out of cmake solution for this. http://vscommands.com/ [^] If you install the VSCommands plugin free version, it will fix the reload dialog to only ask once. -Bill -- So with CMake 2.8.6 and the vscommands installed with VS 2010 I will get ONLY a single dialog asking me to reload the VS solution file? If that is true I can handle that as an added requirement. Thanks Mike Jackson -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Static Library output problem
On 11/11/2011 03:42 PM, Romain LEGUAY wrote: Ok thanks for your quick answers! It works perfectly now! Why don't we have just one variables for the library? With set_target_properties, we can define for each library the path. Because (1) ADD_LIBRARY() might lack the SHARED/STATIC keyword, and the user can decide which type of library is built via the BUILD_SHARED_LIBS variable, so an ADD_LIBRARY() command can be unalteredly used to build a shared library as well as a static one, and (2) on *nix, the outcome of ADD_LIBRARY(... SHARED ...) is a LIBRARY target whereas on Windows, the DLL part is a RUNTIME target, and the accompanying import library is an ARCHIVE target. For these reasons, the same ADD_LIBRARY() command - i.e., the same target - might generate different types of libraries, so there is a need to specify the respective *_OUTPUT_DIRECTORY individually. Regards, Michael Le 11/11/2011 15:38, Andreas Pakulat a écrit : On 11.11.11 15:18:05, Romain LEGUAY wrote: Hello everyone! First, I need to thank you all the CMake developers for their awesome work!!! I try to build a static and a shared libraries. I set the LIBRARY_OUTPUT_DIRECTORY for each library target like this: See the documentation for the LIBRARY_OUTPUT_DIRECTORY, it only applies to shared libraries on non-dll platforms (*nix usually). For a static library you need to set ARCHIVE_OUTPUT_DIRECTORY. Andreas -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] /usr/bin/gcc -o tcl2c++ -rdynamic \n gcc: fatal error: no input files
On 11/12/2011 02:48 PM, YunQiang Su wrote:
I do an cmake program, but encount an stranger problem.
1. mkdir tmp; cd tmp
2. tar -zxvf ../cmake-test.tar.gz
3. mkdir build; cd build
4. cmake ..; make
I got an error:
/usr/bin/gcc-o tcl2c++ -rdynamic
gcc: fatal error: no input files
Then
1. cd ..
1. head -51 CMakeLists.txt CMakeLists.txt.tmp
2. mv CMakeLists.txt.tmp CMakeLists.txt
3. cd build
4. rm -fr *
5. cmake ..; make
It works now.
Why?
Because of the MAIN_DEPENDENCY clause in the custom command; it's just
meant as a hint for Visual Studio, but not to establish a dependency,
and apparently, the Makefile generators are tangled when seeing this
clause. Actually, you don't need to explicitly declare a dependency
on the tcl2c++ executable at all; using the target name suffices.
The attached patch makes your project build on my system.
Regards,
Michael
--- CMakeLists.txt.bak 2011-11-13 01:51:16.981958217 +0100
+++ CMakeLists.txt 2011-11-13 01:51:55.492364967 +0100
@@ -95,16 +95,13 @@
set(CONSOLE_FILES ${LIBRARY_TK}/console.tcl)
-set(TCL2CPP ${CMAKE_CURRENT_BINARY_DIR}/tcl2c++)
-
add_custom_command(OUTPUT embedded-tcl.cc embedded-tk.cc embedded-tclobj.cc
- COMMAND ${TCL2CPP} ARGS et_tcl ${TCL_LIBRARY_FILES} embedded-tcl.cc
+ COMMAND tcl2c++ et_tcl ${TCL_LIBRARY_FILES} embedded-tcl.cc
COMMAND sed -i -e 's/package require -exact T/package require T/g' embedded-tcl.cc
- COMMAND ${TCL2CPP} ARGS et_tk ${TK_LIBRARY_FILES} embedded-tk.cc
+ COMMAND tcl2c++ et_tk ${TK_LIBRARY_FILES} embedded-tk.cc
COMMAND sed -i -e 's/package require -exact T/package require T/g' embedded-tk.cc
- COMMAND ${TCL2CPP} ARGS et_tclobject tcl-object.tcl tcl-import.tcl tcl-http.tcl embedded-tclobj.cc
- COMMAND ${TCL2CPP} ARGS et_console ${CONSOLE_FILES} embedded-console.cc
- MAIN_DEPENDENCY tcl2c++
+ COMMAND tcl2c++ et_tclobject tcl-object.tcl tcl-import.tcl tcl-http.tcl embedded-tclobj.cc
+ COMMAND tcl2c++ et_console ${CONSOLE_FILES} embedded-console.cc
)
#pkg_check_modules(OTCL REQUIRED otcl)
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Issue with check_include_file() and GL/glxproto.h
On 11/11/2011 12:42 PM, GOUJON Alexandre wrote:
On 11/11/2011 04:13 AM, Michael Hertling wrote:
On 11/10/2011 11:22 PM, Eric Noulard wrote:
If this is the case then it is a GL/glxproto.h design mistake
not CMake mistake.
Absolutely, try to compile the following program by hand; it's
the same the CHECK_INCLUDE_FILE() macro tries to compile, too:
#includeGL/glxproto.h
int main(void){return 0;}
It will fail with the same error message, i.e. the GL/glxproto.h header
is not self-sufficient; if intentionally or accidentally, I don't know.
It's this failure that makes CHECK_INCLUDE_FILE() report the header as
non-existent, or better as not compilable.
I just sent them an e-mail so that they will be aware of the issue.
Is the GL/glxproto.h header a public one or is it private, i.e. is it
meant to be included explicitly by client code or not? In the latter
case, by convention, it usually needs not to be self-sufficient.
This is true but the documentation tells you more about the macro
cmake --help-module CheckIncludeFile
says
an optional third argument is the CFlags to add to the compile line or
you can use CMAKE_REQUIRED_FLAGS
which clearly states that it does a compilation.
Indeed, CHECK_INCLUDE_FILE() means: Check if a header is *functional*.
Ok, will use find_file instead.
The thing you want is probably
if(DEFINED VARIABLE)
message(FATAL_ERROR VARIABLE already defined :${VARIABLE} aborting)
endif()
Yeah, thanks.
I think it's not the responsability of check_include_file to do such job
but you can do that in your CMakeLists.txt
With FIND_FILE/PATH() looking for a header, the user must have the
possibility to make them no-ops by presetting the result variable,
so these functions must not overwrite a valid path. However, with
CHECK_INCLUDE_FILE(), the user can't define a header as working;
thus, there is no need to protect an already defined variable from
being overwritten, IMO. Moreover, the user must have the chance to
reuse the same variable for this purpose again without having the
configuration terminate. OTOH, one usually uses an individually
named variable for each header, e.g. HAVE_GL_GLXPROTO_H, as you
do, which is most certainly not reused for anything at all.
Ok but as I didn't understand why check_include_file was failing, I
tried many things like simple then double quoting GL/glxproto.h and also
tried a different variable name. I took HAVE_UNISTDE_H because I knew
HAVE_UNISTD_H was working. With HAVE_UNISTDE_H, check_include_file
seemed to work (it wasn't true, this variable name was simply defined
before elsewhere) so in the end, I believed some variable names were
allowed and others not. So to avoid the same mistake, I thought a
message (at least a STATUS one) wouldn't hurt.
IF(${VARIABLE} MATCHES ^${VARIABLE}$) fails : is it intended ?
I do not understand
In which case does it fail?
Actually, every time.
Here is the beginning of my modified CheckIncludeFile.cmake :
MACRO(CHECK_INCLUDE_FILE INCLUDE VARIABLE)
message(STATUS ${VARIABLE})
IF(${VARIABLE} MATCHES ^${VARIABLE}$)
message(STATUS ${VARIABLE} matches ^${VARIABLE}$)
and I only have the following output
-- HAVE_SYS_TIME_H
-- HAVE_SYS_TYPES_H
-- HAVE_SYS_RESOURCE_H
-- HAVE_SYS_STAT_H
-- HAVE_UNISTD_H
-- HAVE_FCNTL_H
-- HAVE_GL_GLXPROTO_H
CMake Error at CMakeLists.txt:117 (message):
[..]
So the first IF is failing, skipping the whole macro.
If I add a # before this IF (and the corresponding ENDIF),
check_include_file does its jobs and even finds the other headers :
[...]
-- HAVE_FCNTL_H
-- HAVE_FCNTL_H matches ^HAVE_FCNTL_H$
-- Looking for fcntl.h
-- Looking for fcntl.h - found
-- HAVE_GL_GLXPROTO_H
-- HAVE_GL_GLXPROTO_H matches ^HAVE_GL_GLXPROTO_H$
-- Looking for GL/glxproto.h
-- Looking for GL/glxproto.h - not found
Any idea ?
Sorry, I talked nonsense in my previous reply. Obviously, the line
IF(${VARIABLE} MATCHES ^${VARIABLE}$)
serves to prevent the macro's re-execution if the result variable is
already defined, i.e. if the macro has most certainly been called
before with the same parameters. E.g., with VARIABLE equaling
HAVE_XYZ_H, this line expands to
IF(HAVE_XYZ_H MATCHES ^HAVE_XYZ_H$)
and due to the implicit evaluation of variables on the left-hand
side of the IF() command's MATCHES clause, it finally looks like
IF(TRUE MATCHES ^HAVE_XYZ_H$)
or
IF(FALSE MATCHES ^HAVE_XYZ_H$)
provided the macro has been called before, i.e. HAVE_XYZ_H is either
TRUE or FALSE. Of course, these latter conditions are false, so the
macro isn't executed again. OTOH, if the variable HAVE_XYZ_H is un-
defined, i.e. the macro has not been called yet, the line remains
IF(HAVE_XYZ_H MATCHES ^HAVE_XYZ_H$)
which is true, so the macro is executed. Therefore, the macro is
skipped if the result variable indicates that there is already a
result. Thus, in contrast to what I erroneously said before, one
can indeed define a header as working by
Re: [CMake] ifort,icc,icpc: ld: cannot find -lcilkrts
On 11/12/2011 08:48 AM, Ilias Miroslav wrote: Dear experts, our problem is that cmake sets automatically linking libraries for C,C++ and with Intel compilers (Fortran,C,C++) we are getting these problems ( first observed here https://repo.ctcc.no/CDash/viewBuildError.php?buildid=5283 ) : . . . Linking Fortran executable dirac.x /people/disk2/ilias/bin/cmake_install/bin/cmake -E cmake_link_script CMakeFiles/dirac.x.dir/link.txt --verbose=1 /people/disk2/magnus/intel/composerxe-2011.2.137/bin/intel64/ifort-static -Wl,-E -w -assume byterecl -DVAR_IFORT -g -traceback -static-libgcc -static-intel -i8 -O0 CMakeFiles/dirac.x.dir/main/main.F90.o -o dirac.x -i_dynamic lib/libdirac.a lib/libxcfun.a -ldecimal -lcilkrts -lstdc++ -lirc ld: cannot find -lcilkrts make[3]: *** [dirac.x] Error 1 . Manual linking without the -lcilkrts flag works: il...@fe6.dcsc.sdu.dk:~/QCH_Work/qch_progs/dirac_git/trunk/build_ompi_ifort_icc_ilp64_static/./people/disk2/magnus/intel/composerxe-2011.2.137/bin/intel64/ifort -static -Wl,-E -w -assume byterecl -DVAR_IFORT -g -traceback -static-libgcc -static-intel -i8 -O0 CMakeFiles/dirac.x.dir/main/main.F90.o -o dirac.x -i_dynamic lib/libdirac.a lib/libxcfun.a -ldecimal -lstdc++ -lirc il...@fe6.dcsc.sdu.dk:~/QCH_Work/qch_progs/dirac_git/trunk/build_ompi_ifort_icc_ilp64_static/. The problematic cilkrts library is set automatically within CMAKE_C_IMPLICIT_LINK_LIBRARIES CMAKE_CXX_IMPLICIT_LINK_LIBRARIES variables, as found: il...@fe6.dcsc.sdu.dk:~/QCH_Work/qch_progs/dirac_git/trunk/build_ompi_ifort_icc_ilp64_static/.grep cilkrts * */* . CMakeFiles/CMakeCCompiler.cmake:SET(CMAKE_C_IMPLICIT_LINK_LIBRARIES imf;svml;m;ipgo;decimal;cilkrts;stdc++;irc;c;irc_s;dl;c) CMakeFiles/CMakeCXXCompiler.cmake:SET(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES imf;svml;m;ipgo;decimal;cilkrts;stdc++;irc;c;irc_s;dl;c) . . Please how to remove cilkrts or any other parameter from CMAKE_LANG_IMPLICIT_LINK_LIBRARIES, http://www.cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_LANG_IMPLICIT_LINK_LIBRARIES ? We have cmake version 2.8.4 and Intel is Intel(R) 64, Version 12.0.2.137 Build 20110112. Yours, M.Ilias Perhaps, you might check how the offending library makes it into the CMAKE_LANG_IMPLICIT_LINK_LIBRARIES variables. IIRC, these libraries are determined by building a small test program and analyzing the link command line, so linking against the cilkrts library should basically work if it appears among the implicit link libraries. The results of the analysis are reported in CMakeFiles/CMakeOutput.log; could you post it, or the relevant part thereof, for further investigation? Regards, Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
