[CMake] Add custom command problem ?
Hi all,
Using 2.8.2 I'm trying to make a rule to create a timestamp header, but only if
a certain file has changed, like so:
ADD_CUSTOM_COMMAND(
OUTPUT src/timestamp.h
COMMAND tools/win32/timestamper
ARGS src/timestamp.h
DEPENDS Version.cmake
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
COMMENT Generating timestamp header...
)
but the rule is always executed, even if the Version.cmake file has not
changed. What am I doing wrong ?
TIA
/Rob
___
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] Add custom command problem ?
On 12/10/2010 09:23 AM, Robert Bielik wrote:
Hi all,
Using 2.8.2 I'm trying to make a rule to create a timestamp header, but
only if a certain file has changed, like so:
ADD_CUSTOM_COMMAND(
OUTPUT src/timestamp.h
COMMAND tools/win32/timestamper
ARGS src/timestamp.h
DEPENDS Version.cmake
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
COMMENT Generating timestamp header...
)
but the rule is always executed, even if the Version.cmake file has not
changed. What am I doing wrong ?
TIA
/Rob
1. Always use absolute paths (e.g. using CMAKE_CURRENT_SOURCE_DIR and
CMAKE_CURRENT_BINARY_DIR).
2. Never create output in the source tree.
HTH
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
Re: [CMake] Add custom command problem ?
Michael Wild skrev 2010-12-10 10:28: 1. Always use absolute paths (e.g. using CMAKE_CURRENT_SOURCE_DIR and CMAKE_CURRENT_BINARY_DIR). 2. Never create output in the source tree. Thanks, I'll try that. /Rob ___ 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] Howto let FIND_LIBRARY prefer static over shared libraries
Hi all, Is there a way to let FIND_LIBRARY prefer static over shared libraries? I know of one, but that's a bit hack-ish: SET(CMAKE_FIND_LIBRARY_SUFFIXES .a) Are there other options? Ideally, I would like to be able to specify this per library search, i.e. as an option to FIND_LIBRARY. 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] CMake 2.8.4 release scheduled for next month
This are great news, thank you very much -Ursprüngliche Nachricht- Von: David Cole [mailto:david.c...@kitware.com] Gesendet: Donnerstag, 09. Dezember 2010 22:10 An: Roman Wüger Cc: CMake MailingList Betreff: Re: [CMake] CMake 2.8.4 release scheduled for next month That one is assigned to Bill Hoffman and he will be looking at it sometime before Jan. 10. On Thu, Dec 9, 2010 at 4:04 PM, Roman Wüger noru...@me.com wrote: Is the fix for the following bug included: http://www.cmake.org/Bug/view.php?id=4068 If not, when would this bug fixed, because a fix is already attached and the bug is open since 2006-11-23 Thanks in advance Best Regards NoRulez Am 09.12.2010 um 21:57 schrieb Tyler Roscoe ty...@cryptio.net: So are you ready to start collecting candidate bugs for 2.8.4? I nominate this one! http://www.vtk.org/Bug/view.php?id=11561 Thanks, tyler On Thu, Dec 09, 2010 at 03:37:16PM -0500, David Cole wrote: We are still planning to start the release candidate cycle for CMake 2.8.4 on Wed. Jan. 12, 2011. Because of that, all changes to be considered for inclusion in the -rc1 build should be pushed to the stage and merged to 'next' before the nightly start time on the evening of Mon. Jan. 10, 2011. ___ 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] Howto let FIND_LIBRARY prefer static over shared libraries
On 12/10/2010 06:36 AM, Marcel Loose wrote: Is there a way to let FIND_LIBRARY prefer static over shared libraries? I know of one, but that's a bit hack-ish: SET(CMAKE_FIND_LIBRARY_SUFFIXES .a) Are there other options? Ideally, I would like to be able to specify this per library search, i.e. as an option to FIND_LIBRARY. Just ask for the archive name first: find_library(MYLIB NAMES libmylib.a mylib) -Brad ___ 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] R: CMake 2.8.4 release scheduled for next month
On 12/9/2010 5:42 PM, Marco Atzeri wrote: any hope to solve http://public.kitware.com/Bug/view.php?id=10122 with the discussed change of policy for cygwin ? Yes, I have put that on the roadmap. I hope to have time to create the policy before the release. Thanks for the reminder. -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] CMake bug tracker discussion
There are a few things we have already started to do that should help with the bug tracker issue. 1. We hare having 4 releases of CMake each year. After each release we post to the list and ask people to vote for bugs they would like fixed in the next release. 2. We are now sending all new bugs to the cmake-developer list. This way any CMake developer can start working on them or at least know about them when the are opened. I have a third idea that we have not yet tried: What do people think of automatically closing bugs if they are not modified for some period of time (say 6 months). They can always be reopened if the closed. By closing them, it will notify those that have expressed interest in the bug. We could send the closed bugs to the cmake-developer list just like the new ones. That way all developers will know that they are being closed. -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] Simultaneous --build-and-test and CDash submission
You can do it all in one step with ctest, but you have to write a ctest -S script, and call that... Inside it, you can do a configure from scratch using the ctest_configure(...) command. Then you'll see all the configure output submitted to the dashboard. Poke around the wiki and the mailing list for ctest -S script documentation. (Go with a new style script that uses the commands 'ctest_configure' and 'ctest_build' and 'ctest_test'.) Maybe somebody else has time to chime in and give you more details. Cheers, David Thanks fot hints - I finally managed to make it work using ctest scripting. Basic setup was quite easy, but for a longer while I coudn't find a way to have the BuildName and Site name being set - instead they were void. This resulted in having separate entries being shown in CDash for all three stages: configure, build and test. As suggested by wiki entries I tried playing with setting initial cache but it did not work. After few hours I found out that I need to set variables CTEST_BUILD_NAME and CTEST_SITE in the CTestConfig.cmake file. Once I did that the CDash entries were non-void and the submissions were merged together. With CTest -S working now I have a system with subprojects, and with labels not assigned as subprojects as well, what by the means of filtering feature gives me a very nice possibility to browse submissions by labels, something I asked about in one of my recent posts. Thanks, Wojtek -- Szukasz pracy? Możemy Ci ją dać! Sprawdź http://linkint.pl/f288d ___ 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] Simultaneous --build-and-test and CDash submission
On Fri, Dec 10, 2010 at 10:42 AM, Wojciech Migda wojtek.g...@interia.pl wrote: You can do it all in one step with ctest, but you have to write a ctest -S script, and call that... Inside it, you can do a configure from scratch using the ctest_configure(...) command. Then you'll see all the configure output submitted to the dashboard. Poke around the wiki and the mailing list for ctest -S script documentation. (Go with a new style script that uses the commands 'ctest_configure' and 'ctest_build' and 'ctest_test'.) Maybe somebody else has time to chime in and give you more details. Cheers, David Thanks fot hints - I finally managed to make it work using ctest scripting. Basic setup was quite easy, but for a longer while I coudn't find a way to have the BuildName and Site name being set - instead they were void. This resulted in having separate entries being shown in CDash for all three stages: configure, build and test. As suggested by wiki entries I tried playing with setting initial cache but it did not work. After few hours I found out that I need to set variables CTEST_BUILD_NAME and CTEST_SITE in the CTestConfig.cmake file. Once I did that the CDash entries were non-void and the submissions were merged together. With CTest -S working now I have a system with subprojects, and with labels not assigned as subprojects as well, what by the means of filtering feature gives me a very nice possibility to browse submissions by labels, something I asked about in one of my recent posts. Thanks, Wojtek -- Szukasz pracy? Możemy Ci ją dać! Sprawdź http://linkint.pl/f288d You should set CTEST_BUILD_NAME and CTEST_SITE directly in your ctest script for a given machine. They should not be in CTestConfig.cmake because that file is read on all machines, and only machine-independent variables should be set in there. Glad you got it working. 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
Re: [CMake] CMake bug tracker discussion
On Fri, Dec 10, 2010 at 3:42 PM, Bill Hoffman bill.hoff...@kitware.com wrote: I have a third idea that we have not yet tried: What do people think of automatically closing bugs if they are not modified for some period of time (say 6 months). They can always be reopened if the closed. By closing them, it will notify those that have expressed interest in the bug. We could send the closed bugs to the cmake-developer list just like the new ones. That way all developers will know that they are being closed. It's a bad idea, IMHO. If a user took the time to file a bug and CMake developers do nothing in 6 months, closing it is the wrong thing to do. The message you are sending to the bugreporter is I didn't care about the bug you reported in 6 months, and now I will care even less. For an example, see what I said yesterday about bug 8707: two years later, a patch provided, still no action on Kitware's side. On the other hand, on KDE, when we moved to KDE4, we closed almost all KDE3-related bugs without checking if they had been fixed. It did not made too much sense to keep bug reports around unless they were feature requests. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ 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] ANN: Books available on amazon.co.uk
Great news for everyone in Europe who would like to purchase the VTK User's Guide or Mastering CMake - we now have these two titles available on amazon.co.uk (thanks to our new officehttp://www.kitware.com/news/home/browse/306in Lyon, France). You can get the VTK User's Guide herehttp://www.amazon.co.uk/gp/offer-listing/1930934238/sr=8-1/qid=1291910998/ref=olp_tab_new?ie=UTF8coliid=me=qid=1291910998sr=8-1seller=colid=condition=newfor£69.00 and Mastering CMake herehttp://www.amazon.co.uk/gp/offer-listing/193093422X/sr=1-2/qid=1291913938/ref=olp_tab_new?ie=UTF8coliid=me=qid=1291913938sr=1-2seller=colid=condition=newfor £49.00. You can always find these links on our web site under www.kitware.com - use the menu to navigate to Products - Books, then select the book you'd like to order. The amazon.com and amazon.co.uk links are both listed on the Ordering Information tab. Ordering from amazon.co.uk should result in significantly lower shipping costs for our European customers. We do plan to offer more of our titles on more Amazon sites in the EU in this coming year. Lisa --- Lisa S. Avila Vice President Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 USA 518-371-3971 x103 lisa.av...@kitware.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 bug tracker discussion
On 12/10/2010 11:01 AM, Pau Garcia i Quiles wrote: On Fri, Dec 10, 2010 at 3:42 PM, Bill Hoffmanbill.hoff...@kitware.com wrote: I have a third idea that we have not yet tried: What do people think of automatically closing bugs if they are not modified for some period of time (say 6 months). They can always be reopened if the closed. By closing them, it will notify those that have expressed interest in the bug. We could send the closed bugs to the cmake-developer list just like the new ones. That way all developers will know that they are being closed. It's a bad idea, IMHO. If a user took the time to file a bug and CMake developers do nothing in 6 months, closing it is the wrong thing to do. The message you are sending to the bugreporter is I didn't care about the bug you reported in 6 months, and now I will care even less. For an example, see what I said yesterday about bug 8707: two years later, a patch provided, still no action on Kitware's side. Right, and by closing that bug after six months with a message like: If you are still interested in this issue, please re-open and comment. You may want to bring this issue up on the CMake mailing list as well. I am thinking that issues like 8707 would not be forgotten because they would be re-opened and eventually addressed. So, by closing the issue, it would keep the issues from getting stale. -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] CMake bug tracker discussion
Mantis lets you customize bug resolution. Maybe a new category of resolution could be created. Instead of Won't Fix it could be Lack of Activity? David From: cmake-boun...@cmake.org [cmake-boun...@cmake.org] On Behalf Of Bill Hoffman [bill.hoff...@kitware.com] Sent: Friday, December 10, 2010 09:31 To: Pau Garcia i Quiles Cc: cmake@cmake.org Subject: Re: [CMake] CMake bug tracker discussion On 12/10/2010 11:01 AM, Pau Garcia i Quiles wrote: On Fri, Dec 10, 2010 at 3:42 PM, Bill Hoffmanbill.hoff...@kitware.com wrote: I have a third idea that we have not yet tried: What do people think of automatically closing bugs if they are not modified for some period of time (say 6 months). They can always be reopened if the closed. By closing them, it will notify those that have expressed interest in the bug. We could send the closed bugs to the cmake-developer list just like the new ones. That way all developers will know that they are being closed. It's a bad idea, IMHO. If a user took the time to file a bug and CMake developers do nothing in 6 months, closing it is the wrong thing to do. The message you are sending to the bugreporter is I didn't care about the bug you reported in 6 months, and now I will care even less. For an example, see what I said yesterday about bug 8707: two years later, a patch provided, still no action on Kitware's side. Right, and by closing that bug after six months with a message like: If you are still interested in this issue, please re-open and comment. You may want to bring this issue up on the CMake mailing list as well. I am thinking that issues like 8707 would not be forgotten because they would be re-opened and eventually addressed. So, by closing the issue, it would keep the issues from getting stale. -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 ___ 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 bug tracker discussion
On 12/10/2010 12:48 PM, Thompson, David C wrote: Mantis lets you customize bug resolution. Maybe a new category of resolution could be created. Instead of Won't Fix it could be Lack of Activity? It would have to be something that made it clear, that unless someone cares enough to re-open it, it is not going to be fixed. I sort of like closed, with a special comment that explains why it is being closed, and how to re-open it. -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] CMake 2.8.4 release scheduled for next month
On Thu, Dec 9, 2010 at 3:57 PM, Tyler Roscoe ty...@cryptio.net wrote: So are you ready to start collecting candidate bugs for 2.8.4? I nominate this one! http://www.vtk.org/Bug/view.php?id=11561 Thanks, tyler On Thu, Dec 09, 2010 at 03:37:16PM -0500, David Cole wrote: We are still planning to start the release candidate cycle for CMake 2.8.4 on Wed. Jan. 12, 2011. Because of that, all changes to be considered for inclusion in the -rc1 build should be pushed to the stage and merged to 'next' before the nightly start time on the evening of Mon. Jan. 10, 2011. This one (11561) is now on the roadmap for 2.8.4. 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
Re: [CMake] CMake bug tracker discussion
On 2010-12-10 17:01+0100 Pau Garcia i Quiles wrote: On Fri, Dec 10, 2010 at 3:42 PM, Bill Hoffman bill.hoff...@kitware.com wrote: I have a third idea that we have not yet tried: What do people think of automatically closing bugs if they are not modified for some period of time (say 6 months). They can always be reopened if the closed. By closing them, it will notify those that have expressed interest in the bug. We could send the closed bugs to the cmake-developer list just like the new ones. That way all developers will know that they are being closed. It's a bad idea, IMHO. If a user took the time to file a bug and CMake developers do nothing in 6 months, closing it is the wrong thing to do. The message you are sending to the bugreporter is I didn't care about the bug you reported in 6 months, and now I will care even less. For an example, see what I said yesterday about bug 8707: two years later, a patch provided, still no action on Kitware's side. I completely agree. Time-based automatic bug closing is a bad idea. On the other hand, on KDE, when we moved to KDE4, we closed almost all KDE3-related bugs without checking if they had been fixed. It did not made too much sense to keep bug reports around unless they were feature requests. That sounds like you would support version-based (as opposed to time-based) bug report closing. To be specific what would you think of a new bugtracker policy to close all bugs automatically that were submitted for old versions of CMake with the message, please reopen this bug if it still applies to CMake-2.N? Such a policy seems reasonable to me (especially if the old version cutoff is sufficiently in the past, e.g., close all bugs relevant to CMake-2.N-2 when the 2.N series starts) and avoids the implicit bad message to bug reporters of a time-based policy that we both dislike so much. 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
[CMake] Trying to setup make folder configuration on linux
Hello everyone, i currently try to setup a make configuration where the debug and the release version of my programm should be built into different subfolders. My problem is that the installation does not find the created executable. The directory stucture looks like this: /massmailer CmakeLists.txt build_script.sh cd Release cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr ../ make make install /massmailer/Debug /massmailer/Release /massmailer/massmailer main.cpp CmakeLists.txt The installation stops with: -- Configuring done -- Generating done -- Build files have been written to: /root/massmailer/Debug [100%] Built target massmailer -- Configuring done -- Generating done -- Build files have been written to: /root/massmailer/Release [100%] Built target massmailer Install the massmailer release now [Yes/n]? Yes [100%] Built target massmailer Install the project... -- Install configuration: Release CMake Error at massmailer/cmake_install.cmake:36 (FILE): file INSTALL cannot find /root/massmailer/massmailer/massmailer. Call Stack (most recent call first): cmake_install.cmake:37 (INCLUDE) make: *** [install] Error 1 How do I solve this error? Thank you, Louis ___ 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 bug tracker discussion
On Fri, Dec 10, 2010 at 7:56 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On the other hand, on KDE, when we moved to KDE4, we closed almost all KDE3-related bugs without checking if they had been fixed. It did not made too much sense to keep bug reports around unless they were feature requests. That sounds like you would support version-based (as opposed to time-based) bug report closing. To be specific what would you think of a new bugtracker policy to close all bugs automatically that were submitted for old versions of CMake with the message, please reopen this bug if it still applies to CMake-2.N? Such a policy seems reasonable to me (especially if the old version cutoff is sufficiently in the past, e.g., close all bugs relevant to CMake-2.N-2 when the 2.N series starts) and avoids the implicit bad message to bug reporters of a time-based policy that we both dislike so much. That looks reasonable to me for plain bugreports but not for feature requests or any bugreport which includes a proposed patch -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ 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 bug tracker discussion
2010/12/10 Bill Hoffman bill.hoff...@kitware.com: There are a few things we have already started to do that should help with the bug tracker issue. 1. We hare having 4 releases of CMake each year. After each release we post to the list and ask people to vote for bugs they would like fixed in the next release. 2. We are now sending all new bugs to the cmake-developer list. This way any CMake developer can start working on them or at least know about them when the are opened. This was a very good idea. I would suggest that each reporter get the follow-up of the bug he posted, I think (but I have no way to verify that) that bug reporters do not get automatic e-mail follow-up for each comment posted to their bug unless they add themselves as monitor. I'm using this default behavior for other opens source project bug tracker and I usually get fast answers (including I have no time/mean to answer) on bug comments. Knowing that, If a bug reporter does not react to a comment posted on his bug I would usually tend to stop working on this bug because of the lack of info and let the bug close itself after a grace period. I have a third idea that we have not yet tried: What do people think of automatically closing bugs if they are not modified for some period of time (say 6 months). They can always be reopened if the closed. By closing them, it will notify those that have expressed interest in the bug. We could send the closed bugs to the cmake-developer list just like the new ones. That way all developers will know that they are being closed. I would prefer having 2 messages: One after 6 monthes of inactivity (i.e. no new comments etc...) saying the bug will be automatically closed a month later unless the situation evolves A second one closing it if no activity is seen after the grace period. Those message should be sent to the monitor list AND the bug reporter. The first message should be didactic, and may be explain that a bug is more easily fixed with the involvement of the reporter: - test case - patch etc -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ 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] Trying to setup make folder configuration on linux
On Fri, Dec 10, 2010 at 08:11:45PM +0100, Louis Hoefler wrote: -- Build files have been written to: /root/massmailer/Debug Probably not a good idea to be doing this kind of thing as root. [100%] Built target massmailer -- Configuring done -- Generating done -- Build files have been written to: /root/massmailer/Release [100%] Built target massmailer Install the massmailer release now [Yes/n]? Yes [100%] Built target massmailer Install the project... -- Install configuration: Release CMake Error at massmailer/cmake_install.cmake:36 (FILE): file INSTALL cannot find /root/massmailer/massmailer/massmailer. Call Stack (most recent call first): cmake_install.cmake:37 (INCLUDE) We'll need to see your CMakeLists.txt to help further, but it's likely that you got a path wrong in your install() command. hth, tyler ___ 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] cmake qt4 Lplates
Greetings,
I have my cmake L-plates firmly on ( with a Qt4 project I am stumbling on )
I have these in CMakeLists.txt file:-
FIND_PACKAGE( Qt4 REQUIRED )
INCLUDE( ${QT_USE_FILE} )
set(QT_USE_OPENGL TRUE)
set(QT_USE_QTSVG TRUE )
SET( QT_USE_QTXML TRUE )
SET( QT_USE_QT3SUPPORT TRUE )
SET( QT_USE_QTNETWORK TRUE )
SET( QT_USE_QTASSISTANT TRUE )
SET(QT_USE_QTSCRIPT TRUE)
include_directories( ${CMAKE_BINARY_DIR} ${QT_INCLUDE_DIR} )
Two sets pf problems I have encountered include:'
A:- I cannot set the includes for Qt4 as 'found' by FindQt4.cmake. I
looked through the said file for such a variable under mark_as_advanced()
or somesuch but I could not discern any related functions nor variable
names. I tried ${QT_INCLUDE_DIR}, ${QT_HEADERS_DIR} aand ${QT_INCLUDES} to
no avail.I had to resort to setting these manually as
/opt/qt4/include/
B:- This might be due to the manual setting of the Qt4_INCLUDE
(directory(s), but I seem to get duplication in the preprocessors
(generated automatically): Below is an example
-DQT_NO_DEBUG
-DQT_SVG_LIB
-DQT_QT3SUPPORT_LIB
-DQT3_SUPPORT
-DQT_XML_LIB
-DQT_OPENGL_LIB
-DQT_GUI_LIB
-DQT_NETWORK_LIB
-DQT_CORE_LIB
-DQT_SHARED
-DQT_NO_DEBUG
-DQT_GUI_LIB
-DQT_CORE_LIB
-DQT_SHARED
(REMARK I have -DQT_SHARED -DQT_NO_DEBUG both duplicated)
advice would be appreciated
luxInteg
___
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 qt4 Lplates
On 10.12.10 22:09:29, luxInteg wrote:
Greetings,
I have my cmake L-plates firmly on ( with a Qt4 project I am stumbling on )
I have these in CMakeLists.txt file:-
FIND_PACKAGE( Qt4 REQUIRED )
INCLUDE( ${QT_USE_FILE} )
set(QT_USE_OPENGL TRUE)
set(QT_USE_QTSVG TRUE )
SET( QT_USE_QTXML TRUE )
SET( QT_USE_QT3SUPPORT TRUE )
SET( QT_USE_QTNETWORK TRUE )
SET( QT_USE_QTASSISTANT TRUE )
SET(QT_USE_QTSCRIPT TRUE)
This is wrong, you should set the use-variables _before_ including
the use-file. Otherwise the qt-include-dir-variable as well as libraries
variable won't contain these modules. Thats the whole point of the
use-module.
include_directories( ${CMAKE_BINARY_DIR} ${QT_INCLUDE_DIR} )
This should work, but with the wrong order above it might only set
includes for Qt/, QtCore/ and QtGui/ subdirs.
Two sets pf problems I have encountered include:'
A:- I cannot set the includes for Qt4 as 'found' by FindQt4.cmake. I
looked through the said file for such a variable under mark_as_advanced()
or somesuch but I could not discern any related functions nor variable
names. I tried ${QT_INCLUDE_DIR}, ${QT_HEADERS_DIR} aand ${QT_INCLUDES} to
no avail.I had to resort to setting these manually as
/opt/qt4/include/
Did you print out QT_INCLUDE_DIR to check its value or QT_INCLUDES?
B:- This might be due to the manual setting of the Qt4_INCLUDE
(directory(s), but I seem to get duplication in the preprocessors
(generated automatically): Below is an example
-DQT_NO_DEBUG
-DQT_SVG_LIB
-DQT_QT3SUPPORT_LIB
-DQT3_SUPPORT
-DQT_XML_LIB
-DQT_OPENGL_LIB
-DQT_GUI_LIB
-DQT_NETWORK_LIB
-DQT_CORE_LIB
-DQT_SHARED
-DQT_NO_DEBUG
-DQT_GUI_LIB
-DQT_CORE_LIB
-DQT_SHARED
(REMARK I have -DQT_SHARED -DQT_NO_DEBUG both duplicated)
Whats the problem with that? And are you setting the defines yourself to
be included (via QT_DEFINITIONS) or is that done by the use-module?
Andreas
--
Are you sure the back door is locked?
___
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.3-790-gb25d5af
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 b25d5af1a5edf5b2bd39381bccf7dfef2fbefc59 (commit) via b90e9f9c3a61294b40bd45cada70c24d35bc705d (commit) from 23d26f27542b696654c336adfed2b0981ae991af (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=b25d5af1a5edf5b2bd39381bccf7dfef2fbefc59 commit b25d5af1a5edf5b2bd39381bccf7dfef2fbefc59 Merge: 23d26f2 b90e9f9 Author: Brad King brad.k...@kitware.com AuthorDate: Fri Dec 10 07:36:14 2010 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Fri Dec 10 07:36:14 2010 -0500 Merge branch 'master' into next --- 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
[Cmake-commits] CMake branch, next, updated. v2.8.3-796-g3a84289
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 3a8428979e93b052c50dcbeda4c9e88f7c6ac6be (commit)
via 09d1c1080def2b060397469240f184b3fa5358d9 (commit)
via af2ad90991faea2be0dfe62e456794f46758c92a (commit)
via 24cc3d48174ef7b120491520ceb9f81389dd6b3e (commit)
via 83892c4a1170bf68a1e5da305899a23eb69a7500 (commit)
via fe3f878f15c498dcd9583bfd17b1ee11cbc5249d (commit)
from b25d5af1a5edf5b2bd39381bccf7dfef2fbefc59 (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=3a8428979e93b052c50dcbeda4c9e88f7c6ac6be
commit 3a8428979e93b052c50dcbeda4c9e88f7c6ac6be
Merge: b25d5af 09d1c10
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Dec 10 07:58:33 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Dec 10 07:58:33 2010 -0500
Merge topic 'NAG-Fortran' into next
09d1c10 FortranCInterface: Recognize NAG Fortran module symbols
af2ad90 Add NAG Fortran compiler information files
24cc3d4 Recognize the NAG Fortran compiler
83892c4 Allow Fortran platform files to set empty values
fe3f878 Detect object files in implicit link information
diff --cc Modules/CMakeDetermineCompilerABI.cmake
index 81ec71c,ed0b6fb..7f918e6
--- a/Modules/CMakeDetermineCompilerABI.cmake
+++ b/Modules/CMakeDetermineCompilerABI.cmake
@@@ -75,10 -61,11 +75,11 @@@ FUNCTION(CMAKE_DETERMINE_COMPILER_ABI l
IF(CMAKE_${lang}_VERBOSE_FLAG
# Implicit link information cannot be used explicitly for
# multiple OS X architectures, so we skip it.
- AND NOT ${CMAKE_OSX_ARCHITECTURES} MATCHES ;
+ AND NOT MULTI_ARCH
# Skip this with Xcode for now.
AND NOT ${CMAKE_GENERATOR} MATCHES Xcode)
- CMAKE_PARSE_IMPLICIT_LINK_INFO(${OUTPUT} implicit_libs
implicit_dirs log)
+ CMAKE_PARSE_IMPLICIT_LINK_INFO(${OUTPUT} implicit_libs
implicit_dirs log
+ ${CMAKE_${lang}_IMPLICIT_OBJECT_REGEX})
FILE(APPEND
${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeOutput.log
Parsed ${lang} implicit link information from above
output:\n${log}\n\n)
ENDIF()
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=09d1c1080def2b060397469240f184b3fa5358d9
commit 09d1c1080def2b060397469240f184b3fa5358d9
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Dec 9 17:15:48 2010 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Dec 9 18:12:42 2010 -0500
FortranCInterface: Recognize NAG Fortran module symbols
diff --git a/Modules/FortranCInterface/CMakeLists.txt
b/Modules/FortranCInterface/CMakeLists.txt
index 18014af..4bcaae9 100644
--- a/Modules/FortranCInterface/CMakeLists.txt
+++ b/Modules/FortranCInterface/CMakeLists.txt
@@ -45,10 +45,12 @@ set(module_symbols
my_module_mp_my_sub_# Intel
MY_MODULE_mp_MY_SUB # Intel on Windows
my_module_my_sub_ # PGI
+ my_module_MP_my_sub # NAG
mymodule$mysub # HP
mymodule_mp_mysub_ # Intel
MYMODULE_mp_MYSUB # Intel on Windows
mymodule_mysub_ # PGI
+ mymodule_MP_mysub # NAG
${FortranCInterface_MODULE_SYMBOLS}
)
list(REMOVE_DUPLICATES module_symbols)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=af2ad90991faea2be0dfe62e456794f46758c92a
commit af2ad90991faea2be0dfe62e456794f46758c92a
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Dec 9 17:12:19 2010 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Dec 9 18:12:34 2010 -0500
Add NAG Fortran compiler information files
On Linux the NAG Fortran compiler uses gcc under the hood to link. Use
-Wl,-v to pass -v to the underlying gcc compiler to get verbose link
output. Detect the NAG Fortran directory (using -dryrun) and then honor
object files in the directory referenced in the implicit link line.
Pass real linker options with -Wl,-Xlinker,. The -Wl, gets through
the NAG front-end and the -Xlinker gets through the gcc front-end.
diff --git a/Modules/Compiler/NAG-Fortran.cmake
b/Modules/Compiler/NAG-Fortran.cmake
new file mode 100644
index 000..b68c479
--- /dev/null
+++ b/Modules/Compiler/NAG-Fortran.cmake
@@ -0,0 +1,32 @@
+# Help CMAKE_PARSE_IMPLICIT_LINK_INFO detect NAG Fortran object files.
+if(NOT CMAKE_Fortran_COMPILER_WORKS AND NOT CMAKE_Fortran_COMPILER_FORCED)
+ message(STATUS Detecting NAG Fortran directory)
+ # Run with -dryrun to see sample link line.
+ execute_process(
+COMMAND ${CMAKE_Fortran_COMPILER} dummy.o -dryrun
+OUTPUT_VARIABLE _dryrun
+ERROR_VARIABLE _dryrun
+)
+ # Match an
[Cmake-commits] CMake branch, next, updated. v2.8.3-800-gb7ea1c5
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 b7ea1c5879ce1025828f7b4ecc153a4aed67604d (commit)
via 10f01ae962feb68177f7bd698b01bbc18668920c (commit)
via 57e71533f45601275afd7787d763664f9e6b9536 (commit)
via 772817242bf1c94697b06f711f1cd24ad5b0d8d8 (commit)
from 3a8428979e93b052c50dcbeda4c9e88f7c6ac6be (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=b7ea1c5879ce1025828f7b4ecc153a4aed67604d
commit b7ea1c5879ce1025828f7b4ecc153a4aed67604d
Merge: 3a84289 10f01ae
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Dec 10 16:38:29 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Dec 10 16:38:29 2010 -0500
Merge topic 'vs10-sln-msbuild-workaround' into next
10f01ae Remove unused parameter root in some VS generator methods
57e7153 Avoid msbuild idiosyncrasy that builds multiple configs (#11594)
7728172 Remove unused variable rootdir in VS generators
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=10f01ae962feb68177f7bd698b01bbc18668920c
commit 10f01ae962feb68177f7bd698b01bbc18668920c
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Dec 10 14:33:34 2010 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri Dec 10 14:33:34 2010 -0500
Remove unused parameter root in some VS generator methods
The previous commit removed the last use of this parameter from the
implementation of WriteTargetsToSolution. Remove the parameter.
diff --git a/Source/cmGlobalVisualStudio71Generator.cxx
b/Source/cmGlobalVisualStudio71Generator.cxx
index ba18687..2874952 100644
--- a/Source/cmGlobalVisualStudio71Generator.cxx
+++ b/Source/cmGlobalVisualStudio71Generator.cxx
@@ -110,7 +110,7 @@ void cmGlobalVisualStudio71Generator
this-GetTargetSets(projectTargets, originalTargets, root, generators);
OrderedTargetDependSet orderedProjectTargets(projectTargets);
- this-WriteTargetsToSolution(fout, root, orderedProjectTargets);
+ this-WriteTargetsToSolution(fout, orderedProjectTargets);
bool useFolderProperty = this-UseFolderProperty();
if (useFolderProperty)
diff --git a/Source/cmGlobalVisualStudio7Generator.cxx
b/Source/cmGlobalVisualStudio7Generator.cxx
index 6858674..eb84a2c 100644
--- a/Source/cmGlobalVisualStudio7Generator.cxx
+++ b/Source/cmGlobalVisualStudio7Generator.cxx
@@ -270,7 +270,6 @@ void
cmGlobalVisualStudio7Generator::WriteTargetConfigurations(
void cmGlobalVisualStudio7Generator::WriteTargetsToSolution(
std::ostream fout,
-cmLocalGenerator* root,
OrderedTargetDependSet const projectTargets)
{
for(OrderedTargetDependSet::const_iterator tt =
@@ -386,7 +385,7 @@ void cmGlobalVisualStudio7Generator
this-GetTargetSets(projectTargets, originalTargets, root, generators);
OrderedTargetDependSet orderedProjectTargets(projectTargets);
- this-WriteTargetsToSolution(fout, root, orderedProjectTargets);
+ this-WriteTargetsToSolution(fout, orderedProjectTargets);
bool useFolderProperty = this-UseFolderProperty();
if (useFolderProperty)
diff --git a/Source/cmGlobalVisualStudio7Generator.h
b/Source/cmGlobalVisualStudio7Generator.h
index b6c84e8..57c079d 100644
--- a/Source/cmGlobalVisualStudio7Generator.h
+++ b/Source/cmGlobalVisualStudio7Generator.h
@@ -118,7 +118,6 @@ protected:
virtual void WriteTargetsToSolution(
std::ostream fout,
-cmLocalGenerator* root,
OrderedTargetDependSet const projectTargets);
virtual void WriteTargetDepends(
std::ostream fout,
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=57e71533f45601275afd7787d763664f9e6b9536
commit 57e71533f45601275afd7787d763664f9e6b9536
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Dec 10 14:26:56 2010 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri Dec 10 14:26:56 2010 -0500
Avoid msbuild idiosyncrasy that builds multiple configs (#11594)
If a .sln file refers to a project file with a leading .\, as in
.\foo.vcxproj instead of just foo.vcxproj or a full path then
msbuild behaves strangely. Whenever target foo is built as a dependency
of another target, msbuild brings multiple configurations up to date
instead of just the requested configuration!
Refer to all project files by full path to avoid this behavior.
diff --git a/Source/cmGlobalVisualStudio7Generator.cxx
b/Source/cmGlobalVisualStudio7Generator.cxx
index d421c7f..6858674 100644
--- a/Source/cmGlobalVisualStudio7Generator.cxx
+++ b/Source/cmGlobalVisualStudio7Generator.cxx
@@ -297,8 +297,6 @@ void
