[cmake-developers] [CMake 0011368]: Let CTest return with an error status when compiler errors occur
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11368 == Reported By:Marcel Loose Assigned To: == Project:CMake Issue ID: 11368 Category: CTest Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2010-10-27 07:33 EDT Last Modified: 2010-10-27 07:33 EDT == Summary:Let CTest return with an error status when compiler errors occur Description: Currently, a command like 'ctest -D ExperimentalBuild' returns with exit status 0, even if compiler errors occurred. This is IMO caused by the fact that 'make -i' is used to build the code. See http://www.mail-archive.com/cm...@cmake.org/msg32294.html for a discussion on this issue. I would like ctest to return with a non-zero exit status when compiler errors have occurred. It would really help in situations where, e.g., 'ctest -D ExperimentalBuild' is used in a script. == Issue History Date ModifiedUsername FieldChange == 2010-10-27 07:33 Marcel Loose New Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011370]: There is no way to specify ] in [ ] list in regular expressions
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=11370
==
Reported By:Dmitry Kuzmenko
Assigned To:
==
Project:CMake
Issue ID: 11370
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2010-10-27 08:06 EDT
Last Modified: 2010-10-27 08:06 EDT
==
Summary:There is no way to specify ] in [ ] list in regular
expressions
Description:
I've tried to compile regular expression matches any string, ends with
set of symbols, including right square bracket (']', '}' and ')', for
example). I've found no way to do that simple thing.
If I specify .*[\]})] cmake prints error:
Syntax error in cmake code at /home/dimm/test/test.cmake:3 when parsing
string
.*[\]})] Invalid escape sequence \]
If I use .*[\\]})] it thinks I want to match a string ends with \})]
sequence.
==
Issue History
Date ModifiedUsername FieldChange
==
2010-10-27 08:06 Dmitry KuzmenkoNew Issue
==
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] next RC ?
Hi, how are the cmake RCs doing ? I didn't see an announcement for a 2.8.3 RC3, did I miss it ? (I'm waiting for it so I can announce it to the KDE developers to give it some extra testing) Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] next RC ?
Yes, the rc3 was announced last week. On Wed, Oct 27, 2010 at 3:42 PM, Alexander Neundorf neund...@kde.orgwrote: Hi, how are the cmake RCs doing ? I didn't see an announcement for a 2.8.3 RC3, did I miss it ? (I'm waiting for it so I can announce it to the KDE developers to give it some extra testing) Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] next RC ?
On Wednesday 27 October 2010, David Cole wrote: Yes, the rc3 was announced last week. Are you sure ? I can't find it in my emails, also neither here: http://public.kitware.com/pipermail/cmake-developers/2010-October/date.html nor here: http://www.cmake.org/pipermail/cmake/2010-October/date.html Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] CTest: use 'make -k' instead of 'make -i'
On Tue, 2010-10-26 at 11:46 +0200, Marcel Loose wrote: On Mon, 2010-10-25 at 17:30 +0200, Michael Wild wrote: On 25. Oct, 2010, at 17:14 , Tyler Roscoe wrote: On Mon, Oct 25, 2010 at 04:54:41PM +0200, Michael Wild wrote: On 25. Oct, 2010, at 16:45 , Marcel Loose wrote: Wouldn't it make more sense to use 'make -k' instead? Some weeks ago I also wanted to propose this, but then realized one important drawback of -k: Say, you have target B depending on A. If A fails, nothing from B will be compiled, thus hiding programming errors that will only show up once A is fixed. What needs to be fixed is the error parser in CTest. Marcel, I think you can override this compiler flag with use of CTestCustom.cmake or one of those override mechanisms. Michael and everyone, I think that use case is pretty narrow. If I know that B depends on A and I see that A failed, I'm going to take a pretty suspicious view of any build errors in B -- what if they were somehow caused by the failure in A? Besides, doesn't -k satisfy your use case while removing the confusing and erroneous report of success caused by using -i? Thanks, tyler Problem is, not a single file from B will be compiled (if building serial, that is). And I think that such errors are pretty common. Say, somebody changes the implementation of A (not the interface!) and introduces a compilation error there and somebody else messes with B. Although compilation errors from B would still be informative (they don't depend on the implementation of A, only its interface), they don't show up until A is fixed, wasting potentially a lot of time. I agree with you that it is a good thing to abort on first error when doing interactive work, but on a dashboard I prefer to see the whole picture and determine for myself whether a particular error is due to another, earlier error or not. And if you really must, you can do the override by setting the CTEST_BUILD_COMMAND variable to e.g. /usr/bin/make -k. Michael -- There is always a well-known solution to every human problem -- neat, plausible, and wrong. H. L. Mencken Hi Michael, If it's really the case that nothing from B will be compiled, then I can understand the rationale of using 'make -i', instead of 'make -k'. But, read my other mail as well. Anyway, would it possible to let 'ctest' return with a non-zero exit status when build errors occur? It would really help in situations where 'ctest -D ExperimentalBuild' is used in a script. It means, though, that 'ctest' cannot rely on the exit status of 'make' (because 'make -i' always returns 0); it'll need to analyze its output. Any ideas on this? Best regards, Marcel Loose. ___ 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 Hi all, I would really like ctest to return with an error status when compiler errors occur. Should I enter an issue report for this? Regards, Marcel Loose. ___ 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] CTest: use 'make -k' instead of 'make -i'
On 27. Oct, 2010, at 9:54 , Marcel Loose wrote: On Tue, 2010-10-26 at 11:46 +0200, Marcel Loose wrote: On Mon, 2010-10-25 at 17:30 +0200, Michael Wild wrote: On 25. Oct, 2010, at 17:14 , Tyler Roscoe wrote: On Mon, Oct 25, 2010 at 04:54:41PM +0200, Michael Wild wrote: On 25. Oct, 2010, at 16:45 , Marcel Loose wrote: Wouldn't it make more sense to use 'make -k' instead? Some weeks ago I also wanted to propose this, but then realized one important drawback of -k: Say, you have target B depending on A. If A fails, nothing from B will be compiled, thus hiding programming errors that will only show up once A is fixed. What needs to be fixed is the error parser in CTest. Marcel, I think you can override this compiler flag with use of CTestCustom.cmake or one of those override mechanisms. Michael and everyone, I think that use case is pretty narrow. If I know that B depends on A and I see that A failed, I'm going to take a pretty suspicious view of any build errors in B -- what if they were somehow caused by the failure in A? Besides, doesn't -k satisfy your use case while removing the confusing and erroneous report of success caused by using -i? Thanks, tyler Problem is, not a single file from B will be compiled (if building serial, that is). And I think that such errors are pretty common. Say, somebody changes the implementation of A (not the interface!) and introduces a compilation error there and somebody else messes with B. Although compilation errors from B would still be informative (they don't depend on the implementation of A, only its interface), they don't show up until A is fixed, wasting potentially a lot of time. I agree with you that it is a good thing to abort on first error when doing interactive work, but on a dashboard I prefer to see the whole picture and determine for myself whether a particular error is due to another, earlier error or not. And if you really must, you can do the override by setting the CTEST_BUILD_COMMAND variable to e.g. /usr/bin/make -k. Michael -- There is always a well-known solution to every human problem -- neat, plausible, and wrong. H. L. Mencken Hi Michael, If it's really the case that nothing from B will be compiled, then I can understand the rationale of using 'make -i', instead of 'make -k'. But, read my other mail as well. Anyway, would it possible to let 'ctest' return with a non-zero exit status when build errors occur? It would really help in situations where 'ctest -D ExperimentalBuild' is used in a script. It means, though, that 'ctest' cannot rely on the exit status of 'make' (because 'make -i' always returns 0); it'll need to analyze its output. Any ideas on this? Best regards, Marcel Loose. Hi all, I would really like ctest to return with an error status when compiler errors occur. Should I enter an issue report for this? Regards, Marcel Loose. I think this would be best. I didn't look into the code, but I suspect that fixing the error parser would also fix this... Michael -- There is always a well-known solution to every human problem -- neat, plausible, and wrong. H. L. Mencken PGP.sig Description: This is a digitally signed message part ___ 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] cmake for cygwin
--- Mer 27/10/10, Bill Hoffman ha scritto: On 10/26/2010 9:58 PM, Yaakov (Cygwin/X) wrote: On Tue, 2010-10-26 at 17:53 -0400, Bill Hoffman wrote: Backwards compatibility may not be important to you, but to CMake it is very important. When a developer chooses to use CMake, I want to respect that choice, and work as hard as I can to make sure I don't break that code. CMake has been doing this for 10 years on cygwin, wrong or right that is how it has been done. If there is code that builds with CMake on cygwin today, your suggested change will break that build. No, it will most likely *fix* it. How is that possible? If it is working today with the way CMake is for someone, and we make this change, it will stop working. It can not *fix* something that is already working. It can only break something that is already working, it can not fix something not broken... Bill, it is not working. We don't succeed to port programs using cmake as build chain in the cygwin distro, using your package. I need to use Yaakov one. So I need a working alternative. I doubt any linux distribution will accept to release a key tool that doesn't follow the distri guideline. Bottom line: we insist that the CMake in the Cygwin distro not define WIN32. If you're prepared to handle that upstream now, great. If not, we will need to ship a patched version until this issue is rectified. How do you wish to proceed? I guess you could release a patched cygwin that defaults to having the policy set to new, and I could release one that has the policy set to warn by default. I suppose one other options is something like this: Warning: CMake has be forced to break backwards compatibility by the cygwin ports maintainers, we apologize if this broke your code. If your code does not compile, then set the cygwin policy to OLD, or add if(CYGWIN) set(WIN32 1) to your code. I am not familiar with the cmake policy stuff. But it seems a workable solution. We could emit that warning when cmake is run on cygwin for all projects until they require a new enough CMake that contains these changes by using the policy mechanism. I would like to proceed by using the standard cmake policy mechanism. However, you have made it clear you will not be happy with that approach. I am curious what you mean by will need to ship a patched version until this issue is rectified.? Will you block me from being the CMake maintainer for cygwin somehow? This is something we would like to avoid, as the fallout will damage both the communities (cmake and cygwin). Think of it as our last desperate solution (nuclear one). Sorry this is becoming so difficult. I seriously just care about the existing CMake users and don't want to break things for them. -Bill Same for us. Cygwin users usually expect cygwin tools to build cygwin programs, not strange hybrid. Marco ___ 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] cmake for cygwin
On 27. Oct, 2010, at 12:38 , Marco Atzeri wrote: --- Mer 27/10/10, Bill Hoffman ha scritto: On 10/26/2010 9:58 PM, Yaakov (Cygwin/X) wrote: On Tue, 2010-10-26 at 17:53 -0400, Bill Hoffman wrote: Backwards compatibility may not be important to you, but to CMake it is very important. When a developer chooses to use CMake, I want to respect that choice, and work as hard as I can to make sure I don't break that code. CMake has been doing this for 10 years on cygwin, wrong or right that is how it has been done. If there is code that builds with CMake on cygwin today, your suggested change will break that build. No, it will most likely *fix* it. How is that possible? If it is working today with the way CMake is for someone, and we make this change, it will stop working. It can not *fix* something that is already working. It can only break something that is already working, it can not fix something not broken... Bill, it is not working. We don't succeed to port programs using cmake as build chain in the cygwin distro, using your package. I need to use Yaakov one. So I need a working alternative. The ones you tried to port didn't work, but there are the ones that work as they should (as has been reported in this thread). The proposed change would potentially break them. This is bad. Really bad. Breaking working builds in order to fix broken ones is just plain wrong. I doubt any linux distribution will accept to release a key tool that doesn't follow the distri guideline. That's preposterous! This is not a guideline, this is hijacking the project! Whether WIN32 and CYGWIN are defined simultaneously or not is a matter of convention and as far as Cygwin is concerned it is an implementation detail. It might have been a bad choice, granted, but that's all there is to it. Clearly it is possible to create a working build system for Cygwin with the current implementation, so it is NOT CMake's fault if people create broken build systems. You should report it to the respective package maintainers and tell them to fix their build systems, otherwise you don't accept their packages into Cygwin. That would be the proper (although for you more tedious) solution. They are breaking guidelines, not CMake. Period. Bottom line: we insist that the CMake in the Cygwin distro not define WIN32. If you're prepared to handle that upstream now, great. If not, we will need to ship a patched version until this issue is rectified. How do you wish to proceed? I guess you could release a patched cygwin that defaults to having the policy set to new, and I could release one that has the policy set to warn by default. I suppose one other options is something like this: Warning: CMake has be forced to break backwards compatibility by the cygwin ports maintainers, we apologize if this broke your code. If your code does not compile, then set the cygwin policy to OLD, or add if(CYGWIN) set(WIN32 1) to your code. I am not familiar with the cmake policy stuff. But it seems a workable solution. In my, not so humble, opinion it is the only solution if you insist on changed behavior. We could emit that warning when cmake is run on cygwin for all projects until they require a new enough CMake that contains these changes by using the policy mechanism. I would like to proceed by using the standard cmake policy mechanism. However, you have made it clear you will not be happy with that approach. I am curious what you mean by will need to ship a patched version until this issue is rectified.? Will you block me from being the CMake maintainer for cygwin somehow? This is something we would like to avoid, as the fallout will damage both the communities (cmake and cygwin). Think of it as our last desperate solution (nuclear one). To be completely frank, the commandeering tone you two guys used here already created some fallout, at least on my side. I'll make sure to steer clear of any Cygwin involvement... Sorry this is becoming so difficult. I seriously just care about the existing CMake users and don't want to break things for them. -Bill Same for us. Cygwin users usually expect cygwin tools to build cygwin programs, not strange hybrid. ACK, but that really isn't CMake's fault (as explained above). It might be true, that not defining WIN32 would fix a lot of packages, but that still means they are broken and should be fixed. I'm convinced that you are trying to fix the wrong software. Michael -- There is always a well-known solution to every human problem -- neat, plausible, and wrong. H. L. Mencken PGP.sig Description: This is a digitally signed message part ___ 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:
Re: [CMake] CTest: use 'make -k' instead of 'make -i'
On Wed, 2010-10-27 at 11:00 +0200, Michael Wild wrote: On 27. Oct, 2010, at 9:54 , Marcel Loose wrote: On Tue, 2010-10-26 at 11:46 +0200, Marcel Loose wrote: On Mon, 2010-10-25 at 17:30 +0200, Michael Wild wrote: On 25. Oct, 2010, at 17:14 , Tyler Roscoe wrote: On Mon, Oct 25, 2010 at 04:54:41PM +0200, Michael Wild wrote: On 25. Oct, 2010, at 16:45 , Marcel Loose wrote: Wouldn't it make more sense to use 'make -k' instead? Some weeks ago I also wanted to propose this, but then realized one important drawback of -k: Say, you have target B depending on A. If A fails, nothing from B will be compiled, thus hiding programming errors that will only show up once A is fixed. What needs to be fixed is the error parser in CTest. Marcel, I think you can override this compiler flag with use of CTestCustom.cmake or one of those override mechanisms. Michael and everyone, I think that use case is pretty narrow. If I know that B depends on A and I see that A failed, I'm going to take a pretty suspicious view of any build errors in B -- what if they were somehow caused by the failure in A? Besides, doesn't -k satisfy your use case while removing the confusing and erroneous report of success caused by using -i? Thanks, tyler Problem is, not a single file from B will be compiled (if building serial, that is). And I think that such errors are pretty common. Say, somebody changes the implementation of A (not the interface!) and introduces a compilation error there and somebody else messes with B. Although compilation errors from B would still be informative (they don't depend on the implementation of A, only its interface), they don't show up until A is fixed, wasting potentially a lot of time. I agree with you that it is a good thing to abort on first error when doing interactive work, but on a dashboard I prefer to see the whole picture and determine for myself whether a particular error is due to another, earlier error or not. And if you really must, you can do the override by setting the CTEST_BUILD_COMMAND variable to e.g. /usr/bin/make -k. Michael -- There is always a well-known solution to every human problem -- neat, plausible, and wrong. H. L. Mencken Hi Michael, If it's really the case that nothing from B will be compiled, then I can understand the rationale of using 'make -i', instead of 'make -k'. But, read my other mail as well. Anyway, would it possible to let 'ctest' return with a non-zero exit status when build errors occur? It would really help in situations where 'ctest -D ExperimentalBuild' is used in a script. It means, though, that 'ctest' cannot rely on the exit status of 'make' (because 'make -i' always returns 0); it'll need to analyze its output. Any ideas on this? Best regards, Marcel Loose. Hi all, I would really like ctest to return with an error status when compiler errors occur. Should I enter an issue report for this? Regards, Marcel Loose. I think this would be best. I didn't look into the code, but I suspect that fixing the error parser would also fix this... Michael -- There is always a well-known solution to every human problem -- neat, plausible, and wrong. H. L. Mencken OK, Here http://public.kitware.com/Bug/view.php?id=11368 it is. Regards, Marcel Loose. ___ 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] Installing projects built with ExternalProject_Add
Hi, I'm working on a project which depends on several external projects (mostly non-CMake), so naturally I've been taking a look at using ExternalProject to build these prerequisites. I've got a simple superproject working that just builds one of these external projects using ExternalProject_Add and that works nicely, building and installing the project (a library plus headers) into a directory under the build directory of the superproject. What I haven't been able to work out is if there's a good way, or if it's even good practice, to install the libraries, headers and applications built under ExternalProject_Add as part of the install of the superproject. The idea here is to provide a (semi) complete solution for an end user so they don't have to install and set up all the dependencies by hand (many of the packages are scientific software, so not commonly available pre-packaged). So far, my test superproject uses the install command with the DIRECTORY signature to install the contents of the external_project INSTALL_DIR to a location under the CMAKE_INSTALL_PREFIX for the superproject. That works, but if parts of the external project are prefix-aware, some paths in scripts are not correct in the superinstall as they point to somewhere under the build directory of the superproject. I think I might be able to fix this by setting prefixes of the external projects to their final superinstall location, missing out the install step in ExternalProject_Add and then using install(CODE ...) to somehow hook into the actual install command of the external project. That seems possible, but I wanted to check that I'm not over-reaching the purpose of ExternalProject_Add, or implementing bad practice with regard to installing dependencies! Or is there a better way to do this installation with ExternalProject_Add? The other option I can think of is converting all the external projects to CMake as VTK and Paraview do(?) for things like libxml2? That's clearly more work, but would it be a cleaner solution overall since everything would be under the CMake umbrella? Best Regards, Ben Morgan. ___ 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] Beginner's Question: Organizing Projects
Hi,
after reading the tutorial I've decided to make my own project using
cmake but I'm having some troubles here. I'd like to organize my project
as follows:
Pixels/
CMakeLists.txt (0)
Pixels.cpp
geometry/
CMakeLists.txt (1)
Vector.h Vector.cpp ...
ui/
CMakeLists.txt (2)
MainWindow.h MainWindow.cpp ...
The dependencies are the following: the geometry package should be self
sufficient. The ui package needs the geometry library, gtkmm etc. and
Pixels.cpp for now just calls a static method in MainWindow therefore
depends only on ui.
I've spent the past few hours trying to get everything to compile but I
always end up with some cmake or linker error :(
Here's what I've come up with so far:
### CMakeLists.txt (1)
add_library(Geometry Vector.h Vector.cpp ...)
### CMakeLists.txt (2)
add_library(Ui MainWindow.h MainWindow.cpp ...)
# Geometry
include_directories(${PIXELS_SRC_DIR}/geometry)
link_directories(${PIXELS_BIN_DIR}/geometry)
target_link_libraries(Ui Geometry)
find_package(PkgConfig)
# GTKMM
pkg_check_modules(GTKMM gtkmm-2.4)
include_directories(${GTKMM_INCLUDE_DIRS})
link_directories(${GTKMM_LIBRARY_DIRS})
target_link_libraries(Ui ${GTKMM_LIBRARIES})
# GTKGLEXTMM
pkg_check_modules(GLEXT gtkglextmm-1.2)
include_directories(${GLEXT_INCLUDE_DIRS})
link_directories(${GLEXT_LIBRARY_DIRS})
target_link_libraries(Ui ${GLEXT_LIBRARIES})
### CMakeLists.txt (0)
cmake_minimum_required(VERSION 2.8)
project(Pixels)
set(PIXELS_SRC_DIR ${CMAKE_CURRENT_SOURCE_DIR})
set(PIXELS_BIN_DIR ${CMAKE_CURRENT_BINARY_DIR})
add_executable(Pixels Pixels.cpp)
include_directories(${PIXELS_SRC_DIR}/ui)
add_subdirectory(${PIXELS_SRC_DIR}/ui)
target_link_libraries(Pixels Ui)
### end
Unfortunately, this results in a ton of errors such as
make[2]: *** [CMakeFiles/Pixels.dir/Pixels.cpp.o] Error 1
make[1]: *** [CMakeFiles/Pixels.dir/all] Error 2
make: *** [all] Error 2
Gtk has not been declared, Vector.h: no such file or directory.
Obviously I'm not doing it right ;)
The question then is: What am I doing wrong?
Thanks,
Dominik.
___
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] Beginner's Question: Organizing Projects
On Wed, 2010-10-27 at 14:02 +0200, Dominik Gabi wrote:
Hi,
after reading the tutorial I've decided to make my own project using
cmake but I'm having some troubles here. I'd like to organize my
project
as follows:
Pixels/
CMakeLists.txt (0)
Pixels.cpp
geometry/
CMakeLists.txt (1)
Vector.h Vector.cpp ...
ui/
CMakeLists.txt (2)
MainWindow.h MainWindow.cpp ...
The dependencies are the following: the geometry package should be
self
sufficient. The ui package needs the geometry library, gtkmm etc. and
Pixels.cpp for now just calls a static method in MainWindow therefore
depends only on ui.
I've spent the past few hours trying to get everything to compile but
I
always end up with some cmake or linker error :(
Here's what I've come up with so far:
### CMakeLists.txt (1)
add_library(Geometry Vector.h Vector.cpp ...)
### CMakeLists.txt (2)
add_library(Ui MainWindow.h MainWindow.cpp ...)
# Geometry
include_directories(${PIXELS_SRC_DIR}/geometry)
link_directories(${PIXELS_BIN_DIR}/geometry)
target_link_libraries(Ui Geometry)
find_package(PkgConfig)
# GTKMM
pkg_check_modules(GTKMM gtkmm-2.4)
include_directories(${GTKMM_INCLUDE_DIRS})
link_directories(${GTKMM_LIBRARY_DIRS})
target_link_libraries(Ui ${GTKMM_LIBRARIES})
# GTKGLEXTMM
pkg_check_modules(GLEXT gtkglextmm-1.2)
include_directories(${GLEXT_INCLUDE_DIRS})
link_directories(${GLEXT_LIBRARY_DIRS})
target_link_libraries(Ui ${GLEXT_LIBRARIES})
### CMakeLists.txt (0)
cmake_minimum_required(VERSION 2.8)
project(Pixels)
set(PIXELS_SRC_DIR ${CMAKE_CURRENT_SOURCE_DIR})
set(PIXELS_BIN_DIR ${CMAKE_CURRENT_BINARY_DIR})
add_executable(Pixels Pixels.cpp)
include_directories(${PIXELS_SRC_DIR}/ui)
add_subdirectory(${PIXELS_SRC_DIR}/ui)
target_link_libraries(Pixels Ui)
### end
Unfortunately, this results in a ton of errors such as
make[2]: *** [CMakeFiles/Pixels.dir/Pixels.cpp.o] Error 1
make[1]: *** [CMakeFiles/Pixels.dir/all] Error 2
make: *** [all] Error 2
Gtk has not been declared, Vector.h: no such file or directory.
Obviously I'm not doing it right ;)
The question then is: What am I doing wrong?
Thanks,
Dominik.
Hi Dominik,
You should realize that variables have scope, as have properties you set
on directories (which happens when you use, e.g.,
include_directories()). The GTK stuff is only put on the include path in
the UI directory.
There are, IMO, two ways you can solve this.
1) Search for GTK in you top-level CMakeLists.txt file and use
include_directories() there. This will ensure that the
INCLUDE_DIRECTORIES property is set on all the subdirectories.
2) Export the GTK include directory up-level. The IMO fragile way of
doing this is using PARENT_SCOPE, because you have to use that at all
intermediate levels. The safer way is to use a global property.
The first option is definitely the easiest to implement but, for larger
projects, will cause your top-level CMakeLists.txt file to grow
extensively. And, worse, that file will share implementation details
of some lower-level directory, requiring package XYZ. So, for larger
projects, I would choose the seconds option.
Hope this helps.
Best regards,
Marcel Loose.
___
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] Beginner's Question: Organizing Projects
Thanks. The way I understand this is that now instead of
include_directories(${GTKMM_INCLUDE_DIRS})
i would write something like
include_directories(${GTKMM_INCLUDE_DIRS})
# and at the end of the file
set(INCLUDE_DIRECTORIES ${INCLUDE_DIRECTORIES} PARENT_SCOPE)
? I'd do the same with the LINK_DIRECTORIES, LINK_LIBRARIES property and
for all other libraries?
Is this more or less what you mean by exporting? Sorry for the stupid
questions but I'm currently a bit overwhelmed by the cmake
documentation...
Thanks,
Dominik.
On Wed, 2010-10-27 at 14:32 +0200, Marcel Loose wrote:
On Wed, 2010-10-27 at 14:02 +0200, Dominik Gabi wrote:
Hi,
after reading the tutorial I've decided to make my own project using
cmake but I'm having some troubles here. I'd like to organize my
project
as follows:
Pixels/
CMakeLists.txt (0)
Pixels.cpp
geometry/
CMakeLists.txt (1)
Vector.h Vector.cpp ...
ui/
CMakeLists.txt (2)
MainWindow.h MainWindow.cpp ...
The dependencies are the following: the geometry package should be
self
sufficient. The ui package needs the geometry library, gtkmm etc. and
Pixels.cpp for now just calls a static method in MainWindow therefore
depends only on ui.
I've spent the past few hours trying to get everything to compile but
I
always end up with some cmake or linker error :(
Here's what I've come up with so far:
### CMakeLists.txt (1)
add_library(Geometry Vector.h Vector.cpp ...)
### CMakeLists.txt (2)
add_library(Ui MainWindow.h MainWindow.cpp ...)
# Geometry
include_directories(${PIXELS_SRC_DIR}/geometry)
link_directories(${PIXELS_BIN_DIR}/geometry)
target_link_libraries(Ui Geometry)
find_package(PkgConfig)
# GTKMM
pkg_check_modules(GTKMM gtkmm-2.4)
include_directories(${GTKMM_INCLUDE_DIRS})
link_directories(${GTKMM_LIBRARY_DIRS})
target_link_libraries(Ui ${GTKMM_LIBRARIES})
# GTKGLEXTMM
pkg_check_modules(GLEXT gtkglextmm-1.2)
include_directories(${GLEXT_INCLUDE_DIRS})
link_directories(${GLEXT_LIBRARY_DIRS})
target_link_libraries(Ui ${GLEXT_LIBRARIES})
### CMakeLists.txt (0)
cmake_minimum_required(VERSION 2.8)
project(Pixels)
set(PIXELS_SRC_DIR ${CMAKE_CURRENT_SOURCE_DIR})
set(PIXELS_BIN_DIR ${CMAKE_CURRENT_BINARY_DIR})
add_executable(Pixels Pixels.cpp)
include_directories(${PIXELS_SRC_DIR}/ui)
add_subdirectory(${PIXELS_SRC_DIR}/ui)
target_link_libraries(Pixels Ui)
### end
Unfortunately, this results in a ton of errors such as
make[2]: *** [CMakeFiles/Pixels.dir/Pixels.cpp.o] Error 1
make[1]: *** [CMakeFiles/Pixels.dir/all] Error 2
make: *** [all] Error 2
Gtk has not been declared, Vector.h: no such file or directory.
Obviously I'm not doing it right ;)
The question then is: What am I doing wrong?
Thanks,
Dominik.
Hi Dominik,
You should realize that variables have scope, as have properties you set
on directories (which happens when you use, e.g.,
include_directories()). The GTK stuff is only put on the include path in
the UI directory.
There are, IMO, two ways you can solve this.
1) Search for GTK in you top-level CMakeLists.txt file and use
include_directories() there. This will ensure that the
INCLUDE_DIRECTORIES property is set on all the subdirectories.
2) Export the GTK include directory up-level. The IMO fragile way of
doing this is using PARENT_SCOPE, because you have to use that at all
intermediate levels. The safer way is to use a global property.
The first option is definitely the easiest to implement but, for larger
projects, will cause your top-level CMakeLists.txt file to grow
extensively. And, worse, that file will share implementation details
of some lower-level directory, requiring package XYZ. So, for larger
projects, I would choose the seconds option.
Hope this helps.
Best regards,
Marcel Loose.
___
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] Beginner's Question: Organizing Projects
Thanks. The way I understand this is that now instead of
include_directories(${GTKMM_INCLUDE_DIRS})
i would write something like
include_directories(${GTKMM_INCLUDE_DIRS})
# and at the end of the file
set(INCLUDE_DIRECTORIES ${INCLUDE_DIRECTORIES} PARENT_SCOPE)
? I'd do the same with the LINK_DIRECTORIES, LINK_LIBRARIES property and
for all other libraries?
Don't set LINK_DIRECTORIES and LINK_LIBRARIES. When you are a beginner
probably every usage of them is wrong.
You simply do
TARGET_LINK_LIBRARIES(mytarget ${GTK_LIBRARIES}) (or however that is called)
The only thing you need to export upwards in this case would be the
GTK_LIBRARIES variable.
Eike
___
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] Status of clang support?
On Tue, Oct 26, 2010 at 1:02 AM, Mateusz Loskot mate...@loskot.net wrote:
On 25/10/10 01:38, Mateusz Loskot wrote:
On 24/10/10 23:00, Ryan Pavlik wrote:
My best guess would be to check for some Clang-specific defines,
similar to the platform checks. Actually, it looks like in the Git
repository of CMake, there is now some Clang-specific support:
http://github.com/Kitware/CMake/commit/571dc7489111893355deba710feee5990bce92e4
I think that this commit is included in 2.8.2.
Ryan,
It's very good to know.
I've made a note on that commit as to where I think a Clang-specific
variable might be set.
I've seen, great!
For now, you might be able to look at the
value of CMAKE_CXX_COMPILER_ID for a more general solution - it seems
like that might contain Clang if building using Clang.
I'm having access to CMake 2.8.0 at this moment
And, this version sets CMAKE_CXX_COMPILER_ID to GNU, even if
C/C++ compilers set to clang:
cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
Also, simple test always reports the gnu.
if(${CMAKE_CXX_COMPILER_ID} MATCHES clang)
message(STATUS clang)
elseif(${CMAKE_CXX_COMPILER_ID} MATCHES GNU)
message(STATUS gnu)
endif()
I will try 2.8.2 soon.
Thanks for your help!
FYI,
I have tried clang 2.9 (current SVN trunk)
together with CMake from current git.
The compiler ID matching works perfectly well!
Thanks again!
Best regards,
I've been using Clang static analyzer regular Clang from SVN with
CMake for some time and I only have 2 problems with this.
* When switching compilers some settings are lost, this is an
annoyance when using ccmake, since I have custom includes that need to
be entered in manually.
* For some reason I need to manually add these include paths to my
CXXFLAGS -I/usr/include/c++/4.5.1
-I/usr/include/c++/4.5.1/x86_64-unknown-linux-gnu/
Otherwise this works really well and gives especially good warnings
errors with macros, aside from the static checker.
--
- Campbell
___
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] ADD_CUSTOM_COMMAND, crating file with echo redirection, platform independent
Hello,
I need a custom command in my build process.
The tool that I am using has a small problem, I have to insert a line of code in
the output file manually:
#include gtk/gtk.h
I tried this with echo and output redirection:
echo #include gtk/gtk.h images.c
The tool, gdk-pixbuf-csource, is not able to generate a file, therefor its output has to be
redirected to the file too:
gdk-pixbuf-csource --raw pix1 ./images/pix1.png images.c
I can get it work one linux and win32 system, but with different syntax:
This works on a win32 System:
ADD_CUSTOM_COMMAND (OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/images.c
COMMAND ${CMAKE_COMMAND} -E echo \#include gtk/gtk.h
images.c
COMMAND gdk-pixbuf-csource --raw pix1 ./images/pix1.png
images.c
DEPENDS ./images/pix1.png )
This works on a linux System:
ADD_CUSTOM_COMMAND (OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/images.c
COMMAND echo \#includegtk/gtk.h \ images.c
COMMAND gdk-pixbuf-csource --raw pix1 ./images/pix1.png
images.c
DEPENDS ./images/pix1.png )
I tried many variations of above examples, but I can't get running on both systems with the same
syntax, any idea what might be right?
Perhaps there is another way then echo to write something in a file, I tried FILE(WRITE) but I
failed with this.
I could make a file with the include line already inserted and than try to copy it, I saw some
commands for that, is this the better Way? Actually I don't prefer this, I don't want to have a
strange single-line source file in the project.
regards
Arne
___
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] cmake for cygwin
On 2010-10-26 17:53-0400 Bill Hoffman wrote: The policy mechanism might not be ideal but in a year or so, all of this would go away, and the meantime the patches you have to maintain for cygwin ports would become trivial. The patch would basically have a set cmake version at the top. I thought the command line option was a nice compromise. Bill, as somebody associated with a software package (PLplot) which already works on Cygwin, I think the policy mechanism is the ideal way to handle this requested change. I do believe the Cygwin packagers when they say the change will make a lot more projects build without issues on Cygwin, but it is also extremely likely their preferred solution (breaking backwards compatibility for cmake) would also break currently working builds (such as the PLplot one) on Cygwin. I sympathize with the frustrations of the Cygwin packagers at the slowness with which this issue has been dealt with, but OTOH, I am not sure they completely understand the neat resolution of the issue that you are now offering with a policy-based approach to the requested change. Thus, I suggest you just go ahead and implement that preferred solution without further frustrating delays. Then publish cookbook instructions about the one-line change that needs to be made in the top-level CMakeLists.txt file of each currently non-working Cygwin project (but not the working ones like PLplot) in order for the new policy to be recognized. Ideally, upstream projects that currently don't build on Cygwin will adopt this solution, but if they are slow in doing that, it should not be too difficult for the Cygwin packagers to implement a sed (or whatever) script to do the required one-line changes in the top-level CMakeLists.txt files for each package in an automatic fashion. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ 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] cmake for cygwin
On Wed, Oct 27, 2010 at 2:38 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On 2010-10-26 17:53-0400 Bill Hoffman wrote: The policy mechanism might not be ideal but in a year or so, all of this would go away, and the meantime the patches you have to maintain for cygwin ports would become trivial. The patch would basically have a set cmake version at the top. I thought the command line option was a nice compromise. Bill, as somebody associated with a software package (PLplot) which already works on Cygwin, I think the policy mechanism is the ideal way to handle this requested change. I do believe the Cygwin packagers when they say the change will make a lot more projects build without issues on Cygwin, but it is also extremely likely their preferred solution (breaking backwards compatibility for cmake) would also break currently working builds (such as the PLplot one) on Cygwin. I sympathize with the frustrations of the Cygwin packagers at the slowness with which this issue has been dealt with, but OTOH, I am not sure they completely understand the neat resolution of the issue that you are now offering with a policy-based approach to the requested change. Thus, I suggest you just go ahead and implement that preferred solution without further frustrating delays. Then publish cookbook instructions about the one-line change that needs to be made in the top-level CMakeLists.txt file of each currently non-working Cygwin project (but not the working ones like PLplot) in order for the new policy to be recognized. Ideally, upstream projects that currently don't build on Cygwin will adopt this solution, but if they are slow in doing that, it should not be too difficult for the Cygwin packagers to implement a sed (or whatever) script to do the required one-line changes in the top-level CMakeLists.txt files for each package in an automatic fashion. As someone who packaged software for Gentoo Linux for many years I can sympathize with your frustration when something is not corrected in a timely fashion. I don't know much about the background of this particular case, but I would hope that you would choose to work with Bill rather than patch CMake and circumvent his efforts to fix this issue. If this results in a one line patch to Cygwin packages in the short term, which can be removed in the longer term, that would seem like a reasonable solution to the problem. Breaking backwards compatibility could potentially break all of the packages people got working on Cygwin with CMake, and that would be far worse. Disclaimer: I am also a Kitware employee, but before I came here I worked in open source for many years as part of larger projects such as Gentoo, KDE and Avogadro. I for one like the policy mechanism, as it allows CMake to move forward while not breaking existing builds. As a packager I would never intentionally change the default behavior of a project, effectively forking the project. If you chose to take such rash action I would also avoid cygwin in the future. Marcus ___ 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] cmake for cygwin
On Wednesday 27 October 2010, Michael Wild wrote: On 27. Oct, 2010, at 12:38 , Marco Atzeri wrote: --- Mer 27/10/10, Bill Hoffman ha scritto: On 10/26/2010 9:58 PM, Yaakov (Cygwin/X) wrote: On Tue, 2010-10-26 at 17:53 -0400, Bill Hoffman wrote: Backwards compatibility may not be important to you, but to CMake it is very important. When a developer chooses to use CMake, I want to respect that choice, and work as hard as I can to make sure I don't break that code. CMake has been doing this for 10 years on cygwin, wrong or right that is how it has been done. If there is code that builds with CMake on cygwin today, your suggested change will break that build. No, it will most likely *fix* it. How is that possible? If it is working today with the way CMake is for someone, and we make this change, it will stop working. It can not *fix* something that is already working. It can only break something that is already working, it can not fix something not broken... Bill, it is not working. We don't succeed to port programs using cmake as build chain in the cygwin distro, using your package. I need to use Yaakov one. So I need a working alternative. The ones you tried to port didn't work, but there are the ones that work as they should (as has been reported in this thread). The proposed change would potentially break them. This is bad. Really bad. Breaking working builds in order to fix broken ones is just plain wrong. I doubt any linux distribution will accept to release a key tool that doesn't follow the distri guideline. That's preposterous! This is not a guideline, this is hijacking the project! Whether WIN32 and CYGWIN are defined simultaneously or not is a matter of convention and as far as Cygwin is concerned it is an implementation detail. It might have been a bad choice, granted, but that's all there is to it. Clearly it is possible to create a working build system for Cygwin with the current implementation, so it is NOT CMake's fault if people create broken build systems. You should report it to the respective package maintainers and tell them to fix their build systems, otherwise you don't accept their packages into Cygwin. That would be the proper (although for you more tedious) solution. They are breaking guidelines, not CMake. Period. Bottom line: we insist that the CMake in the Cygwin distro not define WIN32. If you're prepared to handle that upstream now, great. If not, we will need to ship a patched version until this issue is rectified. How do you wish to proceed? I guess you could release a patched cygwin that defaults to having the policy set to new, and I could release one that has the policy set to warn by default. I suppose one other options is something like this: Warning: CMake has be forced to break backwards compatibility by the cygwin ports maintainers, we apologize if this broke your code. If your code does not compile, then set the cygwin policy to OLD, or add if(CYGWIN) set(WIN32 1) to your code. I am not familiar with the cmake policy stuff. But it seems a workable solution. In my, not so humble, opinion it is the only solution if you insist on changed behavior. I agree too. As a cmake developer, keeping backward compatibility is one of the major goals of cmake. Just changing the behaviour will most probably break stuff which is working now. Who uses cmake for building for cygwin, can test for if(UNIX) or if(CYGWIN) To differentiate between CYGWIN and a real native UNIX he can also test for if(WIN32), e.g. to check whether some other Windows stuff exists on the system (which does). This seems like a good and sensible choice to me. If a cmake-based project wants to support cygwin, it must be aware of that. If a project which was developed on e.g. Linux is ported to Cygwin, some patches may be necessary to that program. I think that's normal when porting software to another OS. 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] Status of clang support?
On Wednesday 27 October 2010, Campbell Barton wrote:
On Tue, Oct 26, 2010 at 1:02 AM, Mateusz Loskot mate...@loskot.net wrote:
On 25/10/10 01:38, Mateusz Loskot wrote:
On 24/10/10 23:00, Ryan Pavlik wrote:
My best guess would be to check for some Clang-specific defines,
similar to the platform checks. Actually, it looks like in the Git
repository of CMake, there is now some Clang-specific support:
http://github.com/Kitware/CMake/commit/571dc7489111893355deba710feee599
0bce92e4 I think that this commit is included in 2.8.2.
Ryan,
It's very good to know.
I've made a note on that commit as to where I think a Clang-specific
variable might be set.
I've seen, great!
For now, you might be able to look at the
value of CMAKE_CXX_COMPILER_ID for a more general solution - it seems
like that might contain Clang if building using Clang.
I'm having access to CMake 2.8.0 at this moment
And, this version sets CMAKE_CXX_COMPILER_ID to GNU, even if
C/C++ compilers set to clang:
cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
Also, simple test always reports the gnu.
if(${CMAKE_CXX_COMPILER_ID} MATCHES clang)
message(STATUS clang)
elseif(${CMAKE_CXX_COMPILER_ID} MATCHES GNU)
message(STATUS gnu)
endif()
I will try 2.8.2 soon.
Thanks for your help!
FYI,
I have tried clang 2.9 (current SVN trunk)
together with CMake from current git.
The compiler ID matching works perfectly well!
Thanks again!
Best regards,
I've been using Clang static analyzer regular Clang from SVN with
CMake for some time and I only have 2 problems with this.
* When switching compilers some settings are lost, this is an
annoyance when using ccmake, since I have custom includes that need to
be entered in manually.
What do you mean with switching compilers ?
Installing a new version of clang or changing the compiler in an already
configured build tree ?
* For some reason I need to manually add these include paths to my
CXXFLAGS -I/usr/include/c++/4.5.1
-I/usr/include/c++/4.5.1/x86_64-unknown-linux-gnu/
Maybe you should put this in the cmake bug tracker.
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] CMake hangs on new install
Sono ideas nowhere nohow?
We have:
- Reinstalled CMake
- Reinstalled Cygwin
- Tried a tiny, two-line CMakeLists.txt in an empty directory:
cmake_minimum_required (VERSION 2.6)
project(TEMP C)
The command line to CMake (in a .bat file) is:
cmake -DCMAKE_TOOLCHAIN_FILE:string=%~dp0\zosport.cmake -GUnix Makefiles .\
This works (well, works on the good machines, fails in the same way on the
bad) from the command line in that otherwise empty directory, provided the
%~dp0 is replaced with the appropriate path.
- Tried CMake on the same machine, with a Windows build (the failing
case is for cross-compiling - I should have noted that before); it worked.
So on this one machine, CMake isn't totally busted, but DOES NOT like
cross-compiling. The contents of zosport.cmake are:
# This is a CMake Toolchain file, required for cross-compiling using
# the Dignus cross-compilers on Windows, compiling for z/OS.
# Tell CMAKE the target system name
SET(CMAKE_SYSTEM_NAME IBM_ZOS)
# Specify the cross-compilers
SET(CMAKE_C_COMPILER regina.exe cc.rex dcc.exe)
SET(CMAKE_CXX_COMPILER regina.exe cc.rex dcxx.exe)
SET(CMAKE_C_CREATE_STATIC_LIBRARY DAR -rv TARGET OBJECTS)
SET(CMAKE_CXX_LINK_EXECUTABLE plink.exe
\-S$ENV{DIGNUS_PROGRAM}/objs_norent/M\ OBJECTS -o TARGET)
SET(CMAKE_C_LINK_EXECUTABLE plink.exe
\-S$ENV{DIGNUS_PROGRAM}/objs_norent/M\ OBJECTS -o TARGET)
The IBM_ZOS.cmake in the Platform\ directory contains:
INCLUDE(Platform/UnixPaths)
And that's about all I can see that's specific to the cross-compiling. Since
the problem occurs in the parameters it uses to call the compiler, it doesn't
seem to be the compiler that's at fault.
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Phil Smith
Sent: Tuesday, October 26, 2010 8:12 PM
To: cmake@cmake.org
Subject: [CMake] CMake hangs on new install
This is driving me nuts, and it's almost certainly something dumb. One of my
CMake users lost a hard drive and had to reimage.
Now she's installed CMake 2.8 and it LOOKS like it's all OK, but any attempt to
do a CMake hangs because the attempt to compile CMakeCCompilerId.c winds up
passing a bunch of flags and then -o CMakeCCompilerId.c - that is, the -o
flag, TWO spaces, and then CMakeCCompilerId.c. So there's no output file
specification; the input filespec becomes the output, and the compiler
dutifully waits for input from stdin.
Now, I think I've seen this before, but I'm damned if I can remember what
causes it. As far as I can tell, the compiler call is generated within
cmake.exe, which kinda makes it hard to debug.
Any ideas? Thanks in advance...
--
...phsiii
Phil Smith III
p...@voltage.commailto:p...@voltage.com
Voltage Security, Inc.
www.voltage.comhttp://www.voltage.com
___
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] CMake hangs on new install
If you have an instance of a program which has hung,
I would attach to it with a debugger and see where it
is, what it is doing (or not doing in this case)
and what it is waiting for.
Bill
Phil Smith wrote:
So….no ideas nowhere nohow?
We have:
- Reinstalled CMake
- Reinstalled Cygwin
- Tried a tiny, two-line CMakeLists.txt in an empty directory:
*cmake_minimum_required (VERSION 2.6)*
*project(TEMP C)
*
The command line to CMake (in a .bat file) is:
*cmake -DCMAKE_TOOLCHAIN_FILE:string=%~dp0\zosport.cmake -GUnix
Makefiles .\*
* *
This works (well, works on the “good” machines, fails in the same way on
the bad) from the command line in that otherwise empty directory,
provided the %~dp0 is replaced with the appropriate path.
- Tried CMake on the same machine, with a Windows build (the
failing case is for cross-compiling – I should have noted that before);
it worked.
So on this one machine, CMake isn’t totally busted, but DOES NOT like
cross-compiling. The contents of zosport.cmake are:
*# This is a CMake Toolchain file, required for cross-compiling using*
*# the Dignus cross-compilers on Windows, compiling for z/OS.*
* *
*# Tell CMAKE the target system name*
*SET(CMAKE_SYSTEM_NAME IBM_ZOS)*
* *
*# Specify the cross-compilers*
*SET(CMAKE_C_COMPILER regina.exe cc.rex dcc.exe)*
*SET(CMAKE_CXX_COMPILER regina.exe cc.rex dcxx.exe)*
* *
*SET(CMAKE_C_CREATE_STATIC_LIBRARY DAR -rv TARGET OBJECTS)*
* *
*SET(CMAKE_CXX_LINK_EXECUTABLE plink.exe
\-S$ENV{DIGNUS_PROGRAM}/objs_norent/M\ OBJECTS -o TARGET)*
*SET(CMAKE_C_LINK_EXECUTABLE plink.exe
\-S$ENV{DIGNUS_PROGRAM}/objs_norent/M\ OBJECTS -o TARGET)*
The IBM_ZOS.cmake in the Platform\ directory contains:
*INCLUDE(Platform/UnixPaths)*
And that’s about all I can see that’s specific to the cross-compiling.
Since the problem occurs in the parameters it uses to call the compiler,
it doesn’t seem to be the compiler that’s at fault.
*From:* cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] *On
Behalf Of *Phil Smith
*Sent:* Tuesday, October 26, 2010 8:12 PM
*To:* cmake@cmake.org
*Subject:* [CMake] CMake hangs on new install
This is driving me nuts, and it’s almost certainly something dumb. One
of my CMake users lost a hard drive and had to reimage.
Now she’s installed CMake 2.8 and it LOOKS like it’s all OK, but any
attempt to do a CMake hangs because the attempt to compile
CMakeCCompilerId.c winds up passing a bunch of flags and then “-o
CMakeCCompilerId.c” – that is, the -o flag, TWO spaces, and then
CMakeCCompilerId.c. So there’s no output file specification; the input
filespec becomes the output, and the compiler dutifully waits for input
from stdin.
Now, I think I’ve seen this before, but I’m damned if I can remember
what causes it. As far as I can tell, the compiler call is generated
within cmake.exe, which kinda makes it hard to debug.
Any ideas? Thanks in advance…
--
...phsiii
Phil Smith III
p...@voltage.com mailto:p...@voltage.com
Voltage Security, Inc.
www.voltage.com http://www.voltage.com
___
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] CMake hangs on new install
It's not *a program*, it's the compiler. Which is being invoked wrong BY CMAKE
-- dash o blank blank inputfilespec instead of dash o blank outputfilespec
inputfilespec. So what's a debugger going to tell me? I already know.
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
william.croc...@analog.com
Sent: Wednesday, October 27, 2010 4:56 PM
To: cmake@cmake.org
Subject: Re: [CMake] CMake hangs on new install
If you have an instance of a program which has hung,
I would attach to it with a debugger and see where it
is, what it is doing (or not doing in this case)
and what it is waiting for.
Bill
Phil Smith wrote:
Sono ideas nowhere nohow?
We have:
- Reinstalled CMake
- Reinstalled Cygwin
- Tried a tiny, two-line CMakeLists.txt in an empty directory:
*cmake_minimum_required (VERSION 2.6)*
*project(TEMP C)
*
The command line to CMake (in a .bat file) is:
*cmake -DCMAKE_TOOLCHAIN_FILE:string=%~dp0\zosport.cmake -GUnix
Makefiles .\*
* *
This works (well, works on the good machines, fails in the same way on
the bad) from the command line in that otherwise empty directory,
provided the %~dp0 is replaced with the appropriate path.
- Tried CMake on the same machine, with a Windows build (the
failing case is for cross-compiling - I should have noted that before);
it worked.
So on this one machine, CMake isn't totally busted, but DOES NOT like
cross-compiling. The contents of zosport.cmake are:
*# This is a CMake Toolchain file, required for cross-compiling using*
*# the Dignus cross-compilers on Windows, compiling for z/OS.*
* *
*# Tell CMAKE the target system name*
*SET(CMAKE_SYSTEM_NAME IBM_ZOS)*
* *
*# Specify the cross-compilers*
*SET(CMAKE_C_COMPILER regina.exe cc.rex dcc.exe)*
*SET(CMAKE_CXX_COMPILER regina.exe cc.rex dcxx.exe)*
* *
*SET(CMAKE_C_CREATE_STATIC_LIBRARY DAR -rv TARGET OBJECTS)*
* *
*SET(CMAKE_CXX_LINK_EXECUTABLE plink.exe
\-S$ENV{DIGNUS_PROGRAM}/objs_norent/M\ OBJECTS -o TARGET)*
*SET(CMAKE_C_LINK_EXECUTABLE plink.exe
\-S$ENV{DIGNUS_PROGRAM}/objs_norent/M\ OBJECTS -o TARGET)*
The IBM_ZOS.cmake in the Platform\ directory contains:
*INCLUDE(Platform/UnixPaths)*
And that's about all I can see that's specific to the cross-compiling.
Since the problem occurs in the parameters it uses to call the compiler,
it doesn't seem to be the compiler that's at fault.
*From:* cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] *On
Behalf Of *Phil Smith
*Sent:* Tuesday, October 26, 2010 8:12 PM
*To:* cmake@cmake.org
*Subject:* [CMake] CMake hangs on new install
This is driving me nuts, and it's almost certainly something dumb. One
of my CMake users lost a hard drive and had to reimage.
Now she's installed CMake 2.8 and it LOOKS like it's all OK, but any
attempt to do a CMake hangs because the attempt to compile
CMakeCCompilerId.c winds up passing a bunch of flags and then -o
CMakeCCompilerId.c - that is, the -o flag, TWO spaces, and then
CMakeCCompilerId.c. So there's no output file specification; the input
filespec becomes the output, and the compiler dutifully waits for input
from stdin.
Now, I think I've seen this before, but I'm damned if I can remember
what causes it. As far as I can tell, the compiler call is generated
within cmake.exe, which kinda makes it hard to debug.
Any ideas? Thanks in advance...
--
...phsiii
Phil Smith III
p...@voltage.com mailto:p...@voltage.com
Voltage Security, Inc.
www.voltage.com http://www.voltage.com
___
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] cmake for cygwin
--- Mer 27/10/10, Alexander Neundorf ha scritto: I suppose one other options is something like this: Warning: CMake has be forced to break backwards compatibility by the cygwin ports maintainers, we apologize if this broke your code. If your code does not compile, then set the cygwin policy to OLD, or add if(CYGWIN) set(WIN32 1) to your code. I am not familiar with the cmake policy stuff. But it seems a workable solution. In my, not so humble, opinion it is the only solution if you insist on changed behavior. I agree too. As a cmake developer, keeping backward compatibility is one of the major goals of cmake. Just changing the behaviour will most probably break stuff which is working now. Who uses cmake for building for cygwin, can test for if(UNIX) or if(CYGWIN) To differentiate between CYGWIN and a real native UNIX he can also test for if(WIN32), e.g. to check whether some other Windows stuff exists on the system (which does). This seems like a good and sensible choice to me. If a cmake-based project wants to support cygwin, it must be aware of that. If a project which was developed on e.g. Linux is ported to Cygwin, some patches may be necessary to that program. I think that's normal when porting software to another OS. Alex Dear Alex, thanks for you comments, but I would like to highlight one missing point on your reasoning. We don't want to limit ourself to the packages where the developer thought of cygwin as a defined target, we are potentially interested to all packages that have a generic unix as target. Most of the projects ignore what cygwin is; their developers write CMakeLists.txt with IF(WIN32) conditions for windows and IF(UNIX) for unix. Trying to build such programs on cygwin with both the two conditions is doomed to failure. To port such package, that are by large the majority, on cygwin we have 3 options: 1) propose a long patch to every upstream, highlighting the mistake they did forgetting us. Considering the easy success we have to convince cmake developers, this road is more a less a nightmare for any cygwin package maintainers. 2) use a cmake package outside the cygwin distro that don't set WIN32 for cygwin. It is my current solution; but it is not optimal for cygwin as I would like that also others could build the packages as I am doing. Should every cygwin maintainer have its own cmake package ? 3) convince the current cmake cygwin package maintainer, that is also a cmake developer, that we need a way to unset WIN32. How ? I am open to proposal, except case 1, please. I understand that making a unconditional WIN32 switch could break some package, but I suspect they are much less than Bill is afraid of. After all I built both CMAKE and VTK with WIN32=0. But I admit that eventually my build is different from the original aim of their developers. Having a switch/policy to define the cygwin behaviour, is a possible solution that would allow us to build the majority of unix package as smooth as possible also for cygwin and allow current developers using cmake on cygwin to maintain their settings if they need so. Regards Marco ___ 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] cmake for cygwin
--- Mer 27/10/10, Clinton Stimpson ha scritto: I did see in the Cygwin overview that the Win32 api should generally be avoided. However, its probably misleading that chapter 4, Programming with Cygwin, shows Win32 code instead of Unix code in the examples. http://cygwin.com/cygwin-ug-net/programming.html Updating the documentation is always THE problem ;-) But sometimes also on cygwin you need to develop something that is windows aware like a console http://code.google.com/p/mintty/ Clint Marco ___ 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] HINTS vs PATHS
Hello list, What is the difference between HINTS and PATHS, for example for find_library? Thanks -- Serghei ___ 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] CMake hangs on new install
RESOLVED: We realized that the bad machine was CMake 2.8.2, and mine (good) was
2.8.0. So I saved a copy of my 2.8.0 install and installed 2.8.2 over it. I
then had the hang symptom!
I swapped the directories back, and it worked again.
We found a saved copy of the 2.8.1 installer, installed that on the bad
machine, and now it works. So this is something between 2.8.1 (which we have on
a machine that works) and 2.8.2.
This is a nasty bug -- we spent several man-days off and on tinkering with it.
I know nothing of CMake internals, but am happy to work with anyone interested
to figure it out.
...phsiii
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Phil Smith
Sent: Wednesday, October 27, 2010 4:58 PM
To: william.croc...@analog.com; cmake@cmake.org
Cc: Janet Graff
Subject: Re: [CMake] CMake hangs on new install
It's not *a program*, it's the compiler. Which is being invoked wrong BY CMAKE
-- dash o blank blank inputfilespec instead of dash o blank outputfilespec
inputfilespec. So what's a debugger going to tell me? I already know.
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
william.croc...@analog.com
Sent: Wednesday, October 27, 2010 4:56 PM
To: cmake@cmake.org
Subject: Re: [CMake] CMake hangs on new install
If you have an instance of a program which has hung,
I would attach to it with a debugger and see where it
is, what it is doing (or not doing in this case)
and what it is waiting for.
Bill
Phil Smith wrote:
Sono ideas nowhere nohow?
We have:
- Reinstalled CMake
- Reinstalled Cygwin
- Tried a tiny, two-line CMakeLists.txt in an empty directory:
*cmake_minimum_required (VERSION 2.6)*
*project(TEMP C)
*
The command line to CMake (in a .bat file) is:
*cmake -DCMAKE_TOOLCHAIN_FILE:string=%~dp0\zosport.cmake -GUnix
Makefiles .\*
* *
This works (well, works on the good machines, fails in the same way on
the bad) from the command line in that otherwise empty directory,
provided the %~dp0 is replaced with the appropriate path.
- Tried CMake on the same machine, with a Windows build (the
failing case is for cross-compiling - I should have noted that before);
it worked.
So on this one machine, CMake isn't totally busted, but DOES NOT like
cross-compiling. The contents of zosport.cmake are:
*# This is a CMake Toolchain file, required for cross-compiling using*
*# the Dignus cross-compilers on Windows, compiling for z/OS.*
* *
*# Tell CMAKE the target system name*
*SET(CMAKE_SYSTEM_NAME IBM_ZOS)*
* *
*# Specify the cross-compilers*
*SET(CMAKE_C_COMPILER regina.exe cc.rex dcc.exe)*
*SET(CMAKE_CXX_COMPILER regina.exe cc.rex dcxx.exe)*
* *
*SET(CMAKE_C_CREATE_STATIC_LIBRARY DAR -rv TARGET OBJECTS)*
* *
*SET(CMAKE_CXX_LINK_EXECUTABLE plink.exe
\-S$ENV{DIGNUS_PROGRAM}/objs_norent/M\ OBJECTS -o TARGET)*
*SET(CMAKE_C_LINK_EXECUTABLE plink.exe
\-S$ENV{DIGNUS_PROGRAM}/objs_norent/M\ OBJECTS -o TARGET)*
The IBM_ZOS.cmake in the Platform\ directory contains:
*INCLUDE(Platform/UnixPaths)*
And that's about all I can see that's specific to the cross-compiling.
Since the problem occurs in the parameters it uses to call the compiler,
it doesn't seem to be the compiler that's at fault.
*From:* cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] *On
Behalf Of *Phil Smith
*Sent:* Tuesday, October 26, 2010 8:12 PM
*To:* cmake@cmake.org
*Subject:* [CMake] CMake hangs on new install
This is driving me nuts, and it's almost certainly something dumb. One
of my CMake users lost a hard drive and had to reimage.
Now she's installed CMake 2.8 and it LOOKS like it's all OK, but any
attempt to do a CMake hangs because the attempt to compile
CMakeCCompilerId.c winds up passing a bunch of flags and then -o
CMakeCCompilerId.c - that is, the -o flag, TWO spaces, and then
CMakeCCompilerId.c. So there's no output file specification; the input
filespec becomes the output, and the compiler dutifully waits for input
from stdin.
Now, I think I've seen this before, but I'm damned if I can remember
what causes it. As far as I can tell, the compiler call is generated
within cmake.exe, which kinda makes it hard to debug.
Any ideas? Thanks in advance...
--
...phsiii
Phil Smith III
p...@voltage.com mailto:p...@voltage.com
Voltage Security, Inc.
www.voltage.com http://www.voltage.com
___
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
Re: [CMake] HINTS vs PATHS
See the documentation for the full explanation of the search order: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_library Long story short: Hints get searched before the system paths, and should only be set by some source of knowledge (location of other files, etc) and not populated with guesses or default locations. Paths get searched after system locations, and is the place to put default locations. Ryan On Wed, Oct 27, 2010 at 4:23 PM, Serghei Amelian serghei.amel...@gmail.com wrote: Hello list, What is the difference between HINTS and PATHS, for example for find_library? Thanks -- Serghei ___ 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 -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rpav...@iastate.edu http://academic.cleardefinition.com Internal VRAC/HCI Site: http://tinyurl.com/rpavlik ___ 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] Status of clang support?
On 27. Oct, 2010, at 21:38 , Alexander Neundorf wrote:
On Wednesday 27 October 2010, Campbell Barton wrote:
On Tue, Oct 26, 2010 at 1:02 AM, Mateusz Loskot mate...@loskot.net wrote:
On 25/10/10 01:38, Mateusz Loskot wrote:
On 24/10/10 23:00, Ryan Pavlik wrote:
My best guess would be to check for some Clang-specific defines,
similar to the platform checks. Actually, it looks like in the Git
repository of CMake, there is now some Clang-specific support:
http://github.com/Kitware/CMake/commit/571dc7489111893355deba710feee599
0bce92e4 I think that this commit is included in 2.8.2.
Ryan,
It's very good to know.
I've made a note on that commit as to where I think a Clang-specific
variable might be set.
I've seen, great!
For now, you might be able to look at the
value of CMAKE_CXX_COMPILER_ID for a more general solution - it seems
like that might contain Clang if building using Clang.
I'm having access to CMake 2.8.0 at this moment
And, this version sets CMAKE_CXX_COMPILER_ID to GNU, even if
C/C++ compilers set to clang:
cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
Also, simple test always reports the gnu.
if(${CMAKE_CXX_COMPILER_ID} MATCHES clang)
message(STATUS clang)
elseif(${CMAKE_CXX_COMPILER_ID} MATCHES GNU)
message(STATUS gnu)
endif()
I will try 2.8.2 soon.
Thanks for your help!
FYI,
I have tried clang 2.9 (current SVN trunk)
together with CMake from current git.
The compiler ID matching works perfectly well!
Thanks again!
Best regards,
I've been using Clang static analyzer regular Clang from SVN with
CMake for some time and I only have 2 problems with this.
* When switching compilers some settings are lost, this is an
annoyance when using ccmake, since I have custom includes that need to
be entered in manually.
What do you mean with switching compilers ?
Installing a new version of clang or changing the compiler in an already
configured build tree ?
I think he's playing around with different compilers in a single build tree. I
suggest to create a separate build tree for every compiler, avoiding the
frequent re-configures.
* For some reason I need to manually add these include paths to my
CXXFLAGS -I/usr/include/c++/4.5.1
-I/usr/include/c++/4.5.1/x86_64-unknown-linux-gnu/
Maybe you should put this in the cmake bug tracker.
Does it work if you invoke the compiler on the command line directly? I suspect
that clang++ is mis-configured, nothing to do with CMake.
Michael
--
There is always a well-known solution to every human problem -- neat,
plausible, and wrong.
H. L. Mencken
PGP.sig
Description: This is a digitally signed message part
___
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-commits] CMake branch, next, updated. v2.8.2-1116-gc0fd19f
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via c0fd19f1ec5a4a98581f53b6fc2edbe1f02165e8 (commit)
via 48e80eb7246683f471f3886436020d34c784be86 (commit)
from 79b5cd4ed940032425fe34661cd6cb1d13e8aaac (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c0fd19f1ec5a4a98581f53b6fc2edbe1f02165e8
commit c0fd19f1ec5a4a98581f53b6fc2edbe1f02165e8
Merge: 79b5cd4 48e80eb
Author: Dave Partyka dave.part...@kitware.com
AuthorDate: Wed Oct 27 17:42:04 2010 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Oct 27 17:42:04 2010 -0400
Merge topic 'getprerequisites-endless-path-appending' into next
48e80eb Fixes to GetPrerequisites for cygwin
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=48e80eb7246683f471f3886436020d34c784be86
commit 48e80eb7246683f471f3886436020d34c784be86
Author: David Partyka dave.part...@kitware.com
AuthorDate: Wed Oct 27 17:23:00 2010 -0400
Commit: David Partyka dave.part...@kitware.com
CommitDate: Wed Oct 27 17:23:00 2010 -0400
Fixes to GetPrerequisites for cygwin
Fix IF(WIN32) guards check for cygwin. Fix checking if the depenency is in
a system location to use cygwin style paths on cygwin. Also change
GetPrerequisites to switch gp_tool to tools that are very unlikely to be found,
ie. dumpbin on Apple and otool on Windows/Unix.
diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake
index c877308..853b1a1 100644
--- a/Modules/GetPrerequisites.cmake
+++ b/Modules/GetPrerequisites.cmake
@@ -146,7 +146,7 @@ function(is_file_executable file result_var)
# If file name ends in .exe on Windows, *assume* executable:
#
- if(WIN32)
+ if(WIN32 AND NOT UNIX)
if(${file_full_lower} MATCHES \\.exe$)
set(${result_var} 1 PARENT_SCOPE)
return()
@@ -156,7 +156,7 @@ function(is_file_executable file result_var)
# to determine ${result_var}. In 99%+? practical cases, the exe name
# match will be sufficient...
#
- endif(WIN32)
+ endif(WIN32 AND NOT UNIX)
# Use the information returned from the Unix shell command file to
# determine if ${file_full} should be considered an executable file...
@@ -335,7 +335,7 @@ function(gp_resolve_item context item exepath dirs
resolved_item_var)
# Using find_program on Windows will find dll files that are in the PATH.
# (Converting simple file names into full path names if found.)
#
- if(WIN32)
+ if(WIN32 AND NOT UNIX)
if(NOT resolved)
set(ri ri-NOTFOUND)
find_program(ri ${item} PATHS ${exepath};${dirs} NO_DEFAULT_PATH)
@@ -347,7 +347,7 @@ function(gp_resolve_item context item exepath dirs
resolved_item_var)
set(ri ri-NOTFOUND)
endif(ri)
endif(NOT resolved)
- endif(WIN32)
+ endif(WIN32 AND NOT UNIX)
# Provide a hook so that projects can override item resolution
# by whatever logic they choose:
@@ -413,7 +413,7 @@ function(gp_resolved_file_type original_file file exepath
dirs type_var)
string(TOLOWER ${resolved_file} lower)
if(UNIX)
- if(resolved_file MATCHES
^(/lib/|/lib32/|/lib64/|/usr/lib/|/usr/lib32/|/usr/lib64/|/usr/X11R6/))
+ if(resolved_file MATCHES
^(/lib/|/lib32/|/lib64/|/usr/lib/|/usr/lib32/|/usr/lib64/|/usr/X11R6/|/usr/bin/))
set(is_system 1)
endif()
endif()
@@ -434,7 +434,27 @@ function(gp_resolved_file_type original_file file exepath
dirs type_var)
if(lower MATCHES
^(${sysroot}/sys(tem|wow)|${windir}/sys(tem|wow)|(.*/)*msvc[^/]+dll))
set(is_system 1)
endif()
-endif()
+
+ if(UNIX)
+# if cygwin, we can get the properly formed windows paths from cygpath
+find_program(CYGPATH_EXECUTABLE cygpath)
+
+if(CYGPATH_EXECUTABLE)
+ execute_process(COMMAND ${CYGPATH_EXECUTABLE} -W
+ OUTPUT_VARIABLE env_windir
+ OUTPUT_STRIP_TRAILING_WHITESPACE)
+ execute_process(COMMAND ${CYGPATH_EXECUTABLE} -S
+ OUTPUT_VARIABLE env_sysdir
+ OUTPUT_STRIP_TRAILING_WHITESPACE)
+ string(TOLOWER ${env_windir} windir)
+ string(TOLOWER ${env_sysdir} sysroot)
+
+ if(lower MATCHES
^(${sysroot}/sys(tem|wow)|${windir}/sys(tem|wow)|(.*/)*msvc[^/]+dll))
+set(is_system 1)
+ endif()
+endif(CYGPATH_EXECUTABLE)
+ endif(UNIX)
+endif(WIN32)
if(NOT is_system)
get_filename_component(original_path ${original_lower} PATH)
@@ -519,9 +539,9 @@ function(get_prerequisites target prerequisites_var
exclude_system recurse exepa
[Cmake-commits] CMake branch, master, updated. v2.8.2-597-g70101ee
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 70101ee8e7da58e5729fdc0fbb6a48cb3740ba9e (commit) from 01a90e9622bc74cf9d32e550f9342374b082a7fd (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=70101ee8e7da58e5729fdc0fbb6a48cb3740ba9e commit 70101ee8e7da58e5729fdc0fbb6a48cb3740ba9e Author: KWSys Robot kwro...@kitware.com AuthorDate: Thu Oct 28 00:01:04 2010 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Thu Oct 28 00:11:05 2010 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index ba4462f..8c487d6 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2010) SET(KWSYS_DATE_STAMP_MONTH 10) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 27) +SET(KWSYS_DATE_STAMP_DAY 28) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
