Re: [cmake-developers] The upcoming CMake 2.8.7 release candidate cycle
During our merge session yesterday, there were a handful of topics that we were almost ready to merge to 'master' but which could not be because they missed the nightly start time or because they caused style errors on the dashboard... They are ready to be merged today, and then we'll wait for confirmation from the dashboards overnight that all is ready. and then: You can expect to see CMake 2.8.7-rc1 tomorrow. Cheers, David On Thu, Dec 1, 2011 at 4:39 PM, David Cole david.c...@kitware.com wrote: Reminder for contributors: Just one more reminder: CMake 2.8.7-rc1 is scheduled for next Wednesday, Dec. 7th. Please get topics finished up and merged to 'next' before 01:00:00 UTC next Tuesday morning. (That's Monday night at 8 pm here on the East coast of the US.) Thanks, David On Wed, Nov 16, 2011 at 1:31 PM, David Cole david.c...@kitware.com wrote: Just looking at the calendar... Three short weeks from today, we are planning to schedule the build and upload of CMake 2.8.7-rc1 so all of you can give it a try. Followed by weekly rc's as needed until the final official release of CMake 2.8.7, scheduled for Wednesday Dec. 28, 2011. If you are a contributor, please take note, and get any pending changes merged to 'next' and tested on the dashboard over the next 2-3 weeks before the first rc. Thanks, David Cole Kitware, Inc. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] The upcoming CMake 2.8.7 release candidate cycle
I had two or three changes to FindCUDA that missed the cutoff by an hour. Could they be considered as well? James On Wed, Dec 7, 2011 at 9:49 AM, David Cole david.c...@kitware.com wrote: During our merge session yesterday, there were a handful of topics that we were almost ready to merge to 'master' but which could not be because they missed the nightly start time or because they caused style errors on the dashboard... They are ready to be merged today, and then we'll wait for confirmation from the dashboards overnight that all is ready. and then: You can expect to see CMake 2.8.7-rc1 tomorrow. Cheers, David On Thu, Dec 1, 2011 at 4:39 PM, David Cole david.c...@kitware.com wrote: Reminder for contributors: Just one more reminder: CMake 2.8.7-rc1 is scheduled for next Wednesday, Dec. 7th. Please get topics finished up and merged to 'next' before 01:00:00 UTC next Tuesday morning. (That's Monday night at 8 pm here on the East coast of the US.) Thanks, David On Wed, Nov 16, 2011 at 1:31 PM, David Cole david.c...@kitware.com wrote: Just looking at the calendar... Three short weeks from today, we are planning to schedule the build and upload of CMake 2.8.7-rc1 so all of you can give it a try. Followed by weekly rc's as needed until the final official release of CMake 2.8.7, scheduled for Wednesday Dec. 28, 2011. If you are a contributor, please take note, and get any pending changes merged to 'next' and tested on the dashboard over the next 2-3 weeks before the first rc. Thanks, David Cole Kitware, Inc. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] The upcoming CMake 2.8.7 release candidate cycle
Those are some of the ones I'll be merging this afternoon. Thx, D On Wed, Dec 7, 2011 at 12:24 PM, James Bigler jamesbig...@gmail.com wrote: I had two or three changes to FindCUDA that missed the cutoff by an hour. Could they be considered as well? James On Wed, Dec 7, 2011 at 9:49 AM, David Cole david.c...@kitware.com wrote: During our merge session yesterday, there were a handful of topics that we were almost ready to merge to 'master' but which could not be because they missed the nightly start time or because they caused style errors on the dashboard... They are ready to be merged today, and then we'll wait for confirmation from the dashboards overnight that all is ready. and then: You can expect to see CMake 2.8.7-rc1 tomorrow. Cheers, David On Thu, Dec 1, 2011 at 4:39 PM, David Cole david.c...@kitware.com wrote: Reminder for contributors: Just one more reminder: CMake 2.8.7-rc1 is scheduled for next Wednesday, Dec. 7th. Please get topics finished up and merged to 'next' before 01:00:00 UTC next Tuesday morning. (That's Monday night at 8 pm here on the East coast of the US.) Thanks, David On Wed, Nov 16, 2011 at 1:31 PM, David Cole david.c...@kitware.com wrote: Just looking at the calendar... Three short weeks from today, we are planning to schedule the build and upload of CMake 2.8.7-rc1 so all of you can give it a try. Followed by weekly rc's as needed until the final official release of CMake 2.8.7, scheduled for Wednesday Dec. 28, 2011. If you are a contributor, please take note, and get any pending changes merged to 'next' and tested on the dashboard over the next 2-3 weeks before the first rc. Thanks, David Cole Kitware, Inc. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] cdash hiding dashboards
Dear all, I think I've managed to trigger the problem. I had recreated the projects and just now I changed the timezone on my computer. By accident it had been reset to Canada/Something, and I changed it back to Europe/Zurich again. After a computer restart the projects I host are again only showing the Coverage and Dynamic Analysis. So, to trigger bug: - Register a project on the server - Change timezone on server (typically /etc/rc.conf or similar on Linux machines) - Restart server Could anyone confirm this? Is it expected? Cheers, Yngve On 2 December 2011 15:46, Yngve Levinsen yngve.levin...@gmail.com wrote: I figured out that I could simply delete the projects and create them again on the cdash web page to resolve the issue. Since we are in a trial period it doesn't matter so much if we lose the history, so I did that. Cheers, Yngve On 1 December 2011 15:49, Yngve Levinsen yngve.levin...@gmail.com wrote: Dear Developers, I am sure I have just managed to configure something wrong somewhere, but I cannot find it. My CDash page now looks like this: http://dl.dropbox.com/u/2293502/cdash_missingDashboards.png In short, Experimental, Nightly and Continuous aren't showing. They are there, as an example I get e-mail with specific links to nightly builds when I have fixed something. The same problem is true for all projects I host on the site. Could I be missing a module/daemon? I have also recently upgraded my server, so I might have a package of something which is too new... Suggestions and questions are welcome! Best Regards, Yngve -- 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] cdash hiding dashboards
Dear all, I think I've managed to trigger the problem. I had recreated the projects and just now I changed the timezone on my computer. By accident it had been reset to Canada/Something, and I changed it back to Europe/Zurich again. After a computer restart the projects I host are again only showing the Coverage and Dynamic Analysis. So, to trigger bug: - Register a project on the server - Change timezone on server (typically /etc/rc.conf or similar on Linux machines) - Restart server Could anyone confirm this? Is it expected? Have you checked that the new submissions aren't just accounted for the day before? If yes I bet this is some correlation between the nightly start time you set (or did not set). 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] import/export and DLL's
On Wed, Dec 7, 2011 at 1:40 AM, Michael Wild them...@gmail.com wrote:
On 12/07/2011 01:49 AM, Totte Karlsson wrote:
Well, then just use add_definitions(-DIMPORT_X_DLL). If
-DEXPORT_X_DLL is present, it will override your export/import
header definitions for the import case, and everything should be
fine.
Not sure what you mean by override. If both symbols are defined,
MTK_COMMON will be defined as __declspec(dllexport) and not
__declspec(dllimport), since my headers have #elif, #not elses.
*That's* what I meant by _override_...
Using add_definitions makes sense however. I just started using CMake
two days ago and was not aware of that command.
Well, then you got a lot of RTFM'ing before you ;-)
CMake will only
add the DEFINE_SYMBOL when *building* the specified target, and
otherwise just leave it away.
When CMake invokes the compiler to *build* the DLL it adds
-DEXPORT_X_DLL. If the DLL is being *used* it doesn't do anything.
That is the problem. When you say it does not do anything,(in the
'use' case) it is in fact defining the dllimport flag (after your
#else).
The way my define structure looks, that does not happen.
Yes, and that is broken. Simple as that.
So, in your code you do something like this:
#ifdef EXPORT_A_DLL #define A_API __declspec(dllexport) #else
#define A_API __declspec(dllimport) #endif
No, I'm not doing that in my code. But I tried it, and together with
target_link_library everything compiles fine. In my opinion,
however, those #defines gives you something defined, without
defining anything.. that is a little too clever in my opinion. But
practical.
Not too clever; Common practice and actually recommended by Microsoft:
http://msdn.microsoft.com/en-us/library/8fskxacy.aspx
I'll try to see if that works. Right now I do have an
exporter/importer header and it is more complex and looks like
(for a target COMMON): #if defined(EXPORT_COMMON_DLL) #define
MTK_COMMON __declspec(dllexport) #elif defined(IMPORT_COMMON_DLL)
#define MTK_COMMON __declspec(dllimport) #elif
defined(EXPORT_COMMON_PKG) #define MTK_COMMON __declspec(package)
#elif defined(IMPORT_COMMON_PKG) #define MTK_COMMON
__declspec(package) #else #define MTK_COMMON #endif
Is this for embarcadero c++? in which case do you define
EXPORT_COMMON_DLL, and when do you use EXPORT_COMMON_PKG?
The package spec is a embarcadero flavor of a dll (that can be
installed in the IDE). That is why I need elseifs, and not just an
else.
So, __declspec(package) is used exactly when? Only when building the
DLL, only when using the DLL or in both cases? Assuming you only need it
when building, you could do the following in your CMakeLists.txt:
---
# loads of stuff...
# possibly detect this automatically using the BORLAND variable?
option(BUILD_EMBARCADERO_PACKAGE Build a bpl package OFF)
if(BUILD_EMBARCADERO_PACKAGE)
set(SYMBOL_SUFFIX PACKAGE)
else()
set(SYMBOL_SUFFIX DLL)
endif()
add_library(A SHARED a.cpp a.h)
add_library(B SHARED b.cpp b.h)
add_library(C SHARED c.cpp c.h)
target_link_libraries(B A)
target_link_libraries(C B)
foreach(t A B C)
set_target_properties(${t} PROPERTIES
DEFINE_SYMBOL ${t}_BUILD_${SYMBOL_SUFFIX})
endforeach()
# more stuff...
---
This defines TARGET_NAME_BUILD_{DLL,PACKAGE} when the target
TARGET_NAME is built, and otherwise nothing is defined. In your
headers you can then do something like the following (here for a.h, the
others are analogous):
---
#ifndef A_H
#define A_H
#if defined(A_BUILD_DLL)
#define A_API __declspec(dllexport)
#elif defined(A_BUILD_PACKAGE)
#define A_API __declspec(package)
#else
#define A_API __declspec(dllimport)
#endif
class A_API SuperDuperClass
{
// some stuff goes here...
};
#endif
---
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
See also the new in 2.8.6 module GenerateExportHeader:
http://cmake.org/cmake/help/cmake-2-8-docs.html#module:GenerateExportHeader
cmake --help-module GenerateExportHeader
HTH,
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
[CMake] CMake builds library/executable out of order
I am having this strange issue with building a library and then linking it to
an executable.
If I have the following in my CMakeList:
add_library(libfoo.a ${srcfiles})
add_executable(foo_exec.Fx foo_exec.F)
target_link_libraries(foo_exec.Fx libfoo.a)
I get an error returned of no rule to make target libfoo.a needed by
foo_exec.Fx.
I should mention I have library prefixes and suffixes turned off for both
linking and building, meaning that the full filename of libraries are specified
(hence the libfoo.a and not just foo).
But if I change my CMakeList to:
add_library(libfoo.a ${srcfiles})
#add_executable(foo_exec.Fx foo_exec.F)
#target_link_libraries(foo_exec.Fx libfoo.a)
It builds libfoo.a without any complaint. When I uncomment the executable
lines after building libfoo.a via the above, the library is linked to the
executable with no complaints.
I might also mention since the Fortran compiler used is ABSoft and I am
building on a 64-bit Redhat system, the linker I am using for Fortran
executables is g++, but that may be irrelevant.
How do I specify that the library needs to be built before the executable which
links to it, so that CMake does not return an error when it tries to build and
link the executable before building its dependent library?
This almost seems like a bug in 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 builds library/executable out of order
On Wed, Dec 7, 2011 at 9:37 AM, Schuchard, Matthew
matthew.schuch...@gtri.gatech.edu wrote:
I am having this strange issue with building a library and then linking it
to an executable.
If I have the following in my CMakeList:
add_library(libfoo.a ${srcfiles})
add_executable(foo_exec.Fx foo_exec.F)
target_link_libraries(foo_exec.Fx libfoo.a)
I get an error returned of “no rule to make target libfoo.a needed by
foo_exec.Fx.”
I should mention I have library prefixes and suffixes turned off for both
linking and building, meaning that the full filename of libraries are
specified (hence the libfoo.a and not just foo).
But if I change my CMakeList to:
add_library(libfoo.a ${srcfiles})
#add_executable(foo_exec.Fx foo_exec.F)
#target_link_libraries(foo_exec.Fx libfoo.a)
It builds libfoo.a without any complaint. When I uncomment the executable
lines after building libfoo.a via the above, the library is linked to the
executable with no complaints.
I might also mention since the Fortran compiler used is ABSoft and I am
building on a 64-bit Redhat system, the linker I am using for Fortran
executables is g++, but that may be irrelevant.
How do I specify that the library needs to be built before the executable
which links to it, so that CMake does not return an error when it tries to
build and link the executable before building its dependent library?
This almost seems like a bug in 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
Try this:
add_library(foo ${srcfiles})
add_executable(foo_exec.Fx foo_exec.F)
target_link_libraries(foo_exec.Fx foo)
CMake will automatically add the lib prefix and the .a suffix to
the actually built library file. foo is the CMake target name for
the libfoo.a library in this case.
I don't know why it should matter, but perhaps the target name
libfoo.a is confounding things somehow.
HTH,
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] import/export and DLL's
On Dec 7, 2011, at 7:57 AM, David Cole wrote: See also the new in 2.8.6 module GenerateExportHeader: http://cmake.org/cmake/help/cmake-2-8-docs.html#module:GenerateExportHeader cmake --help-module GenerateExportHeader HTH, David -- +1 for that. Now to get all my developers to move to CMake 2.8.6 so I can jettison all my own code that did the same thing. Awesome addition. I also updated the wiki page at http://www.cmake.org/Wiki/BuildingWinDLL ___ Mike JacksonPrincipal Software Engineer BlueQuartz SoftwareDayton, Ohio mike.jack...@bluequartz.net www.bluequartz.net -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake builds library/executable out of order
Please note:
I should mention I have library prefixes and suffixes turned off for
both linking and building, meaning that the full filename of libraries
are specified (hence the libfoo.a and not just foo).
Also a side consequence is I specify linked libraries by filepath and not
target names, which has worked fine thus far.
-Original Message-
From: David Cole [mailto:david.c...@kitware.com]
Sent: Wednesday, December 07, 2011 9:53 AM
To: Schuchard, Matthew
Cc: cmake@cmake.org
Subject: Re: [CMake] CMake builds library/executable out of order
On Wed, Dec 7, 2011 at 9:37 AM, Schuchard, Matthew
matthew.schuch...@gtri.gatech.edu wrote:
I am having this strange issue with building a library and then
linking it to an executable.
If I have the following in my CMakeList:
add_library(libfoo.a ${srcfiles})
add_executable(foo_exec.Fx foo_exec.F)
target_link_libraries(foo_exec.Fx libfoo.a)
I get an error returned of no rule to make target libfoo.a needed by
foo_exec.Fx.
I should mention I have library prefixes and suffixes turned off for
both linking and building, meaning that the full filename of libraries
are specified (hence the libfoo.a and not just foo).
But if I change my CMakeList to:
add_library(libfoo.a ${srcfiles})
#add_executable(foo_exec.Fx foo_exec.F)
#target_link_libraries(foo_exec.Fx libfoo.a)
It builds libfoo.a without any complaint. When I uncomment the
executable lines after building libfoo.a via the above, the library is
linked to the executable with no complaints.
I might also mention since the Fortran compiler used is ABSoft and I
am building on a 64-bit Redhat system, the linker I am using for
Fortran executables is g++, but that may be irrelevant.
How do I specify that the library needs to be built before the
executable which links to it, so that CMake does not return an error
when it tries to build and link the executable before building its dependent
library?
This almost seems like a bug in CMake.
Try this:
add_library(foo ${srcfiles})
add_executable(foo_exec.Fx foo_exec.F)
target_link_libraries(foo_exec.Fx foo)
CMake will automatically add the lib prefix and the .a suffix to the
actually built library file. foo is the CMake target name for the libfoo.a
library in this case.
I don't know why it should matter, but perhaps the target name libfoo.a is
confounding things somehow.
HTH,
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] import/export and DLL's
On 12/07/2011 03:57 PM, Michael Jackson wrote: On Dec 7, 2011, at 7:57 AM, David Cole wrote: See also the new in 2.8.6 module GenerateExportHeader: http://cmake.org/cmake/help/cmake-2-8-docs.html#module:GenerateExportHeader cmake --help-module GenerateExportHeader HTH, David -- +1 for that. Now to get all my developers to move to CMake 2.8.6 so I can jettison all my own code that did the same thing. Awesome addition. I also updated the wiki page at http://www.cmake.org/Wiki/BuildingWinDLL Really cool tool. +1! 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] import/export and DLL's
See also the new in 2.8.6 module GenerateExportHeader: http://cmake.org/cmake/help/cmake-2-8-docs.html#module:GenerateExportHeade r cmake --help-module GenerateExportHeader I see the header has this: #ifdef IS_STATIC_BUILD ... #else ... #endif Is there any way to generate this configured header for a static or for a shared build, so one doesn't have to add preprocessor defines to use the header file? -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.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] The upcoming CMake 2.8.7 release candidate cycle
During our merge session yesterday, there were a handful of topics that we were almost ready to merge to 'master' but which could not be because they missed the nightly start time or because they caused style errors on the dashboard... They are ready to be merged today, and then we'll wait for confirmation from the dashboards overnight that all is ready. and then: You can expect to see CMake 2.8.7-rc1 tomorrow. Cheers, David On Thu, Dec 1, 2011 at 4:39 PM, David Cole david.c...@kitware.com wrote: Reminder for contributors: Just one more reminder: CMake 2.8.7-rc1 is scheduled for next Wednesday, Dec. 7th. Please get topics finished up and merged to 'next' before 01:00:00 UTC next Tuesday morning. (That's Monday night at 8 pm here on the East coast of the US.) Thanks, David On Wed, Nov 16, 2011 at 1:31 PM, David Cole david.c...@kitware.com wrote: Just looking at the calendar... Three short weeks from today, we are planning to schedule the build and upload of CMake 2.8.7-rc1 so all of you can give it a try. Followed by weekly rc's as needed until the final official release of CMake 2.8.7, scheduled for Wednesday Dec. 28, 2011. If you are a contributor, please take note, and get any pending changes merged to 'next' and tested on the dashboard over the next 2-3 weeks before the first rc. Thanks, David Cole Kitware, Inc. -- 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-developers] The upcoming CMake 2.8.7 release candidate cycle
I had two or three changes to FindCUDA that missed the cutoff by an hour. Could they be considered as well? James On Wed, Dec 7, 2011 at 9:49 AM, David Cole david.c...@kitware.com wrote: During our merge session yesterday, there were a handful of topics that we were almost ready to merge to 'master' but which could not be because they missed the nightly start time or because they caused style errors on the dashboard... They are ready to be merged today, and then we'll wait for confirmation from the dashboards overnight that all is ready. and then: You can expect to see CMake 2.8.7-rc1 tomorrow. Cheers, David On Thu, Dec 1, 2011 at 4:39 PM, David Cole david.c...@kitware.com wrote: Reminder for contributors: Just one more reminder: CMake 2.8.7-rc1 is scheduled for next Wednesday, Dec. 7th. Please get topics finished up and merged to 'next' before 01:00:00 UTC next Tuesday morning. (That's Monday night at 8 pm here on the East coast of the US.) Thanks, David On Wed, Nov 16, 2011 at 1:31 PM, David Cole david.c...@kitware.com wrote: Just looking at the calendar... Three short weeks from today, we are planning to schedule the build and upload of CMake 2.8.7-rc1 so all of you can give it a try. Followed by weekly rc's as needed until the final official release of CMake 2.8.7, scheduled for Wednesday Dec. 28, 2011. If you are a contributor, please take note, and get any pending changes merged to 'next' and tested on the dashboard over the next 2-3 weeks before the first rc. Thanks, David Cole Kitware, Inc. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- 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-developers] The upcoming CMake 2.8.7 release candidate cycle
Those are some of the ones I'll be merging this afternoon. Thx, D On Wed, Dec 7, 2011 at 12:24 PM, James Bigler jamesbig...@gmail.com wrote: I had two or three changes to FindCUDA that missed the cutoff by an hour. Could they be considered as well? James On Wed, Dec 7, 2011 at 9:49 AM, David Cole david.c...@kitware.com wrote: During our merge session yesterday, there were a handful of topics that we were almost ready to merge to 'master' but which could not be because they missed the nightly start time or because they caused style errors on the dashboard... They are ready to be merged today, and then we'll wait for confirmation from the dashboards overnight that all is ready. and then: You can expect to see CMake 2.8.7-rc1 tomorrow. Cheers, David On Thu, Dec 1, 2011 at 4:39 PM, David Cole david.c...@kitware.com wrote: Reminder for contributors: Just one more reminder: CMake 2.8.7-rc1 is scheduled for next Wednesday, Dec. 7th. Please get topics finished up and merged to 'next' before 01:00:00 UTC next Tuesday morning. (That's Monday night at 8 pm here on the East coast of the US.) Thanks, David On Wed, Nov 16, 2011 at 1:31 PM, David Cole david.c...@kitware.com wrote: Just looking at the calendar... Three short weeks from today, we are planning to schedule the build and upload of CMake 2.8.7-rc1 so all of you can give it a try. Followed by weekly rc's as needed until the final official release of CMake 2.8.7, scheduled for Wednesday Dec. 28, 2011. If you are a contributor, please take note, and get any pending changes merged to 'next' and tested on the dashboard over the next 2-3 weeks before the first rc. Thanks, David Cole Kitware, Inc. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- 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] Build doesn't work with Mac OS X Lion...
Yes I'm using 2.8.6. Best, Dick Munroe On 11/26/11 11:18 AM, David Cole wrote: Are you using CMake 2.8.6...? Older CMake versions have not been used much on Lion. It wouldn't surprise me if 2.8.6 works, but earlier versions have issues... HTH, David On Sat, Nov 26, 2011 at 6:37 AM, Daniel Dekkersd.dekk...@cthrough.nl wrote: This: SET(CMAKE_OSX_ARCHITECTURES $(ARCHS_STANDARD_32_BIT)) seems to result in a standard Xcode setting (armv7 (standard)) which is also set when you let Xcode create a fresh iOS app (from its own templates). But you also see this a lot on the fora: SET(CMAKE_OSX_ARCHITECTURES $(ARCHS_UNIVERSAL_IPHONE_OS)) Not sure. On Nov 26, 2011, at 4:38 AM, Michael Jackson wrote: There is a cmake variable that you set during onfiguration time. Something like os_x_architectures. There you can add the specific arch that you want to build for. - Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio Sent from my mobile device. Please excuse the shortness of the reply. On Nov 25, 2011, at 14:47, Dick Munroemun...@csworks.com wrote: I've got a build that works just fine with Leopard. For reasons I won't get into, I had to upgrade one of my systems to Lion and now (I've installed XCode 4.2) the build won't work. I get the following error: [ 0%] Reaping winning child 0x10260c510 PID 1009 Live child 0x10260c510 (libxp/CMakeFiles/xp.dir/Users/munroe/Documents/My_SVN/ESPlanner_Computation_Engine.U2011-11-01/Common/xmllib/print/libxp.cpp.o) PID 1010 Building CXX object libxp/CMakeFiles/xp.dir/Users/munroe/Documents/My_SVN/ESPlanner_Computation_Engine.U2011-11-01/Common/xmllib/print/libxp.cpp.o Reaping winning child 0x10260c510 PID 1010 Live child 0x10260c510 (libxp/CMakeFiles/xp.dir/Users/munroe/Documents/My_SVN/ESPlanner_Computation_Engine.U2011-11-01/Common/xmllib/print/libxp.cpp.o) PID 1011 llvm-g++-4.2: Invalid arch name : -O2 Reaping losing child 0x10260c510 PID 1011 make[2]: *** [libxp/CMakeFiles/xp.dir/Users/munroe/Documents/My_SVN/ESPlanner_Computation_Engine.U2011-11-01/Common/xmllib/print/libxp.cpp.o] Error 1 Removing child 0x10260c510 PID 1011 from chain. Reaping losing child 0x10c20c290 PID 1008 make[1]: *** [libxp/CMakeFiles/xp.dir/all] Error 2 Removing child 0x10c20c290 PID 1008 from chain. Reaping losing child 0x10940e730 PID 996 If I dig around, I find the CXX flags to be: -arch -O2 -fPIC and for some reason the Lion g++ compiler is choking thinking that there should be and arch value. Which if I dig around in the Leopard build I find: -Dxp_EXPORTS -arch i386 -O2 -g -fPIC Which brings up the questions, (1) with the same CMakeLists.txt file, why am I getting different values and (2) how do I get the arch to be i386 on the Lion build. Best, Dick Munroe -- 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 -- 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] Question about add_custom_target
Anyone? - Robert Dailey On Tue, Dec 6, 2011 at 4:36 PM, Robert Dailey rcdai...@gmail.com wrote: Does $CONFIGURATION work in add_custom_target as it does in add_custom_command? The documentation doesn't state anything about this that I can see, but it seems like it should work. - Robert Dailey -- 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] How to make a shared library to use relative paths to the executable
I think it's $ORIGIN, not @ORIGIN. Alex This works with WIN files too? -- 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] Cleaning up find module
I have attached a find module I created to find specific parts of an Install Shield installation on the system as required by our product. I wanted to see if there was a way to clean up this find module. In particular, there are cases where I am trying to find 2 files in 2 different locations, but for each file I have to make 1 call each to find_file(). I was hoping to just consolidate this to 1 call to find_file and provide multiple, different directories in the HINTS list, but I tried this and it doesn't try to find each file listed in multiple directories... i.e. if it finds one file in one directory, it seems to expect all of the other files to be in that same directory. In any case, if someone wouldn't mind taking a peek at my find module and offering some suggestions for improvements I'd greatly appreciate it! Thanks!! - Robert Dailey FindInstallShield.cmake Description: Binary data -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about add_custom_target
On 12/07/2011 09:09 PM, Robert Dailey wrote: Anyone? AFAICT, all generator expressions documented for ADD_CUSTOM_COMMAND() and ADD_TEST() also work for ADD_CUSTOM_TARGET() although this isn't mentioned explicitly. IMO, you should file an appropriate bug report in order to have ADD_CUSTOM_TARGET()'s documentation enhanced, or to advise against using generator expressions therein in case it works just by accident. Regards, Michael On Tue, Dec 6, 2011 at 4:36 PM, Robert Dailey rcdai...@gmail.com wrote: Does $CONFIGURATION work in add_custom_target as it does in add_custom_command? The documentation doesn't state anything about this that I can see, but it seems like it should work. - Robert Dailey -- 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] Visual Studio 10 default property sheets
I'm not sure if this has been discussed much within the CMake developer community but I wanted to give some thoughts on the use of Visual Sudio property sheets and some suggestion for CMake. As far as I know this is only relevant to Visual Studio 10 and hence MSBuild. I am not familiar with older versions of VS. Sorry if this a bit long winded or it falls into the bleeding obvious category. I did look around and couldn't find any discussion like this online. So first an overview of property sheets in VS10/MSBuild skip this if you are in the know. For those not to familiar with property sheets you can consider them to be collections of compiler/linker flags and other build related information. Physically property sheets are just MSBuild XML files which get included into the main Visaul Studio project file, the .vcxproj file, which is also an MSBuild XML file. To a certain degree you can consider one of Visual Studio functions to be a glorified editor of MSBuild XML files. When you create a project in Visual Studio you have to select what type of project it is, for instance a standard DLL, aka shared library, project. When you do this the project file that VS produces will automatically includes certain property sheets that Microsoft supplies with MSBuild. These files can be found in something like C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0 and have names like Microsoft.Cl.Common.props. The is also a sub directory called Platforms which contains directories like Win32 and x64. These correspond directly to the Platform you see in VS. These directories contain further MSBuild predefined platform specific property sheets like Microsoft.Cpp.Win32.props Property sheets can be inherited what this means is that a property sheet can inherit a set of compiler flags from a parent sheet and can override or extend them if it wants to. This is the key to the usefulness of property sheets. If you look in the Property Manager screen in VS of a standard DLL project you should see something like the following property sheets being inherited for a 32 bit windows build Microsoft.Cpp.Win32.user Windows Dynamic Link Library Multi-byte Character Support Core Windows Libraries Sheets higher up inherit and can override sheets lower down the list. The bottom three correspond to MSBuild supplied property sheets in the MSBuild install directories mentioned earlier. Sadly I haven't found a way in the VS GUI of finding out the actual file name and path of the property sheet but you can normally guess it. The Microsoft.Cpp.Win32.user property sheet which is normally somewhere like AppData\Local\Microsoft\MSBuild\v4.0 in your user id allows you to store user specific build overrides which is generally a bad idea. When you right click on a project in VS solution explorer ( or other equivalent method ) you can look at the properties of that project, including all the compiler/linker flags. Items that are in bold font are defined directly in the property sheet you are looking at while non bold indicates a value that has been inherited. For some compiler flags like the include path it makes sense to inherit the value from your parent property sheet and extend it. In this case you'll see something like %(AdditionIncludeDirectories) in the value which is a macro value representing the value of this field inherited from the parent sheet. A very key portion of the property sheet you can see in VS GUI is the General page under Configuration Properties. At the bottom of this screen is a section called Project Defaults which looks something like Configuration TypeDynamic Library (.dll) Use of MFC Use Standard Windows Libraries Use of ATL Not using ATL Character Set Use Multi Byte Character Set Common Language Runtime Support No Common Language Runtime Support Whole Program Optimization No Whole Program Optimization The above are not really compiler flags directly but define which MSBuild supplied property sheets to inherit. In other words they effect compiler flags used in your build by changing what property sheets you inherit from. So if you change the Character set from multi byte to Unicode you will see in the property manager that you now inherit from a sheet called Unicode Support rather than Multi-byte Character set. This may change many compiler/linker flags/defines etc... Note the situation is a little more complicated as you can define certain MSBuild XML elements before you inherit the MSBuild supplied property sheets which influence what flags they set. A good exmple of this is the UseDebugLibrariestrueUseDebugLibraries which amongst many other things makes the build process link to the debug versions MDd of the MS runtime libraries rather than the optimized/release ones. End of overview So what was the point of this ramble through property sheets. My assertion is that
[CMake] help texts
Hello, I am trying to make a parser that can use cmake --help-... commands to determine the functions that are available and their signature. I have 2 problems: - It is difficult to know if it's an example usage or if it is the signature of the function - How can I know the keywords per function? Now I just get the list of functions and then call cmake for each function and parse the output lines where they start with the function name followed by a ( sign. Then this is the signature until an empty line or until a new function-name-with-(-sign is found. Maybe the examples could be prefixed with something to distinguish them from the real function signatures? Maybe to solve the keywords problem the keywords could all be uppercase and the variables lowercase so I can extract them? This is in most cases correct now but e.g. in the find_file documentation there is VAR which would wrongly be extracted as a keyword. Thanks, Best regards Tom, -- 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.6-2160-gaf62563
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 af6256309dd2acf91c9b8dd89d375f374d5d0671 (commit) via 2d1195123ec85ffd04b415914cc5127db918d2c9 (commit) via 1eca18fd522575126b4d1e4faa3c9437d2f12e22 (commit) from a286108643fc5768f825060fc25c6cbc47fb7f66 (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=af6256309dd2acf91c9b8dd89d375f374d5d0671 commit af6256309dd2acf91c9b8dd89d375f374d5d0671 Merge: a286108 2d11951 Author: David Cole david.c...@kitware.com AuthorDate: Wed Dec 7 16:31:10 2011 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Dec 7 16:31:10 2011 -0500 Merge topic 'AutomocIncludedDotMocFileHandling' into next 2d11951 Merge branch 'master' into AutomocIncludedDotMocFileHandling 1eca18f automoc: add documentation for CMAKE_AUTOMOC_STRICT_MODE http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2d1195123ec85ffd04b415914cc5127db918d2c9 commit 2d1195123ec85ffd04b415914cc5127db918d2c9 Merge: 1eca18f 9f18f64 Author: David Cole david.c...@kitware.com AuthorDate: Wed Dec 7 16:29:13 2011 -0500 Commit: David Cole david.c...@kitware.com CommitDate: Wed Dec 7 16:29:13 2011 -0500 Merge branch 'master' into AutomocIncludedDotMocFileHandling Conflicts: Source/cmTarget.cxx diff --cc Modules/AutomocInfo.cmake.in index 293ba64,2c7c724..44f2da2 --- a/Modules/AutomocInfo.cmake.in +++ b/Modules/AutomocInfo.cmake.in @@@ -10,5 -11,5 +11,6 @@@ set(AM_QT_MOC_EXECUTABLE @QT_MOC_EXECU set(AM_CMAKE_CURRENT_SOURCE_DIR @CMAKE_CURRENT_SOURCE_DIR@/) set(AM_CMAKE_CURRENT_BINARY_DIR @CMAKE_CURRENT_BINARY_DIR@/) set(AM_QT_VERSION_MAJOR @QT_VERSION_MAJOR@ ) + set(AM_Qt5Core_VERSION_MAJOR @Qt5Core_VERSION_MAJOR@ ) set(AM_TARGET_NAME @_moc_target_name@) +set(AM_STRICT_MODE @_moc_strict_mode@) diff --cc Source/cmQtAutomoc.cxx index 349b738,d07f84b..65c7952 --- a/Source/cmQtAutomoc.cxx +++ b/Source/cmQtAutomoc.cxx @@@ -200,11 -145,11 +210,12 @@@ void cmQtAutomoc::SetupAutomocTarget(cm makefile-AddDefinition(_moc_incs, _moc_incs.c_str()); makefile-AddDefinition(_moc_defs, _moc_defs.c_str()); makefile-AddDefinition(_moc_compile_defs, _moc_compile_defs.c_str()); + makefile-AddDefinition(_moc_options, _moc_options.c_str()); makefile-AddDefinition(_moc_files, _moc_files.c_str()); makefile-AddDefinition(_moc_headers, _moc_headers.c_str()); + makefile-AddDefinition(_moc_strict_mode, strictMode ? TRUE : FALSE); - const char* cmakeRoot = makefile-GetDefinition(CMAKE_ROOT); + const char* cmakeRoot = makefile-GetSafeDefinition(CMAKE_ROOT); std::string inputFile = cmakeRoot; inputFile += /Modules/AutomocInfo.cmake.in; std::string outputFile = targetDir; diff --cc Source/cmTarget.cxx index 279f626,87f8c5e..276c5e0 --- a/Source/cmTarget.cxx +++ b/Source/cmTarget.cxx @@@ -158,11 -159,21 +159,23 @@@ void cmTarget::DefineProperties(cmake * which is compiled as part of the target. This property is initialized by the value of the variable CMAKE_AUTOMOC if it is set when a target is created.\n + Additional command line options for moc can be set via the - AUTOMOC_MOC_OPTIONS property. -); ++ AUTOMOC_MOC_OPTIONS property.\n + By setting the CMAKE_AUTOMOC_STRICT_MODE variable to FALSE the rules + for searching the files which will be processed by moc can be relaxed. + See the documentation for this variable for more details.); cm-DefineProperty + (AUTOMOC_MOC_OPTIONS, cmProperty::TARGET, + Additional options for moc when using automoc (see the AUTOMOC property), + This property is only used if the AUTOMOC property is set to TRUE for + this target. In this case, it holds additional command line options + which will be used when moc is executed during the build, i.e. it is + equivalent to the optional OPTIONS argument of the qt4_wrap_cpp() + macro.\n + By default it is empty.); + + cm-DefineProperty (BUILD_WITH_INSTALL_RPATH, cmProperty::TARGET, Should build tree targets have install tree rpaths., BUILD_WITH_INSTALL_RPATH is a boolean specifying whether to link http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1eca18fd522575126b4d1e4faa3c9437d2f12e22 commit 1eca18fd522575126b4d1e4faa3c9437d2f12e22 Author: Alex Neundorf neund...@kde.org AuthorDate: Tue Dec 6 20:42:20 2011 +0100 Commit: Alex Neundorf neund...@kde.org CommitDate: Tue Dec 6 20:42:20 2011 +0100 automoc: add documentation for CMAKE_AUTOMOC_STRICT_MODE Alex diff --git a/Source/cmDocumentVariables.cxx
[Cmake-commits] CMake branch, master, updated. v2.8.6-336-gc26e287
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 c26e28754c2f61ba704924bd5051e4d12b88fabf (commit) via 80e279d37c246fb2b3da5e3cf396bab51e8b8f6b (commit) from 6fb2a38b0a672959a7ecc8fe4d07350371486310 (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=c26e28754c2f61ba704924bd5051e4d12b88fabf commit c26e28754c2f61ba704924bd5051e4d12b88fabf Merge: 6fb2a38 80e279d Author: David Cole david.c...@kitware.com AuthorDate: Wed Dec 7 16:45:00 2011 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Dec 7 16:45:00 2011 -0500 Merge topic 'topics/FindCUDA/Multi-dir-clash' 80e279d Make CUDA working directory unique for each target. --- Summary of changes: Modules/FindCUDA.cmake | 64 --- 1 files changed, 54 insertions(+), 10 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, master, updated. v2.8.6-338-g0ea95b9
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 0ea95b99cebc23d9fbf7d50872176911f5f65f96 (commit) via aa36082a2b62e7612838a7e777d2cfe104fa6e52 (commit) from c26e28754c2f61ba704924bd5051e4d12b88fabf (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=0ea95b99cebc23d9fbf7d50872176911f5f65f96 commit 0ea95b99cebc23d9fbf7d50872176911f5f65f96 Merge: c26e287 aa36082 Author: David Cole david.c...@kitware.com AuthorDate: Wed Dec 7 16:45:35 2011 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Dec 7 16:45:35 2011 -0500 Merge topic 'topics/FindCUDA/Misc-fixes' aa36082 Miscellaneous fixes. --- Summary of changes: Modules/FindCUDA.cmake | 21 +++-- 1 files changed, 11 insertions(+), 10 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, master, updated. v2.8.6-340-g174ecf5
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 174ecf51f857031b0204a516df809814d4dc0386 (commit) via 96f65ba68e82b64eac67b75282bbcab8103c0eb0 (commit) from 0ea95b99cebc23d9fbf7d50872176911f5f65f96 (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=174ecf51f857031b0204a516df809814d4dc0386 commit 174ecf51f857031b0204a516df809814d4dc0386 Merge: 0ea95b9 96f65ba Author: David Cole david.c...@kitware.com AuthorDate: Wed Dec 7 16:46:35 2011 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Dec 7 16:46:35 2011 -0500 Merge topic 'refactor-versioned-lib-names' 96f65ba cmTarget: Create helper method for versioned library names --- Summary of changes: Source/cmTarget.cxx | 70 ++- Source/cmTarget.h |7 + 2 files changed, 37 insertions(+), 40 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, master, updated. v2.8.6-366-gd050d6b
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 d050d6b58b311a6675286407bf626c0fae6c2eaf (commit) via 2d1195123ec85ffd04b415914cc5127db918d2c9 (commit) via 1eca18fd522575126b4d1e4faa3c9437d2f12e22 (commit) via bc278ceb0f704ada0cc2cecedc01dd2cb6dc603a (commit) via 62e223e8fab50e87a804efd822dc336577608a9d (commit) via 40c516783e1df141f3d4a8f6400e90da822395c1 (commit) via c207f5d3616efacdc4d91217f90609fd3679f116 (commit) via 9c0df72dc4b4e9403a3516390bc59f971ad1c3de (commit) via 174bf35fbbcb22636e538323c168ecbc33a7cb39 (commit) via 8507eaed1659d91709c41d34b351ea6a0585983e (commit) via 7ada172002e56d3900f4498a2f1bc2ffbc531816 (commit) via 3b93e266c0e6f0a58d813fc8ec7bc5810ace4827 (commit) via 47457159c70d031cfdb5704ce46166de5a26 (commit) via bde4edb6ab6501de42bdc167e027a9f5c5760244 (commit) via 74ab0f6aa409a9d3e90c91b1b1c7a6e4b865ed62 (commit) via bc7560e6e56d1f6fa65745cf5c1206192fb77b04 (commit) via 30fd8e603a52b7230e0b716d8120fc01551c8a4f (commit) via 80dfbc99f4b04b5eaea9111fa014f07603a8db16 (commit) via 72bb058e92167a272b40b4b710fc2fe41b1fc8fe (commit) via e44ebd5f9b5eed18697dabbc4c1f570f60ded39c (commit) via 142317782842751dba4e68f016f3c89c692dc5ac (commit) via f98e6151dc4d1bcc14373e423fcdd668f99ce07a (commit) via 69cf480cd65621d3db1390f78ef2d3cd1dddb5d8 (commit) via 81c43b4fb6e46430e730e2cb268c283e47995b78 (commit) via 72428228970b8b7da54a3c98a36eca6810c46bb5 (commit) via d08bc32bc29078764fc44fd3809eeda527e7017f (commit) from 174ecf51f857031b0204a516df809814d4dc0386 (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=d050d6b58b311a6675286407bf626c0fae6c2eaf commit d050d6b58b311a6675286407bf626c0fae6c2eaf Merge: 174ecf5 2d11951 Author: David Cole david.c...@kitware.com AuthorDate: Wed Dec 7 16:47:35 2011 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Dec 7 16:47:35 2011 -0500 Merge topic 'AutomocIncludedDotMocFileHandling' 2d11951 Merge branch 'master' into AutomocIncludedDotMocFileHandling 1eca18f automoc: add documentation for CMAKE_AUTOMOC_STRICT_MODE bc278ce automoc: fix line length 62e223e automoc: add variable CMAKE_AUTOMOC_STRICT_MODE, to enable strict parsing 40c5167 automoc: accept even more .moc files in non-strict mode c207f5d automoc: also accept other files when .moc is included in non-strict mode 9c0df72 automoc: add a StrictParseCppFile(), which is only qmake-compatible 174bf35 automoc: move the code for finding headers into separate function 8507eae automoc: fix handling of included _p.moc files 7ada172 automoc: some more linebreaks for the warnings for better readability 3b93e26 automoc: add extra check whether the header contains Q_PRIVATE_SLOT 4745715 Add a test case for the use of Q_PRIVATE_SLOT. bde4edb automoc: add special handling for including basename_p.moc, with test 74ab0f6 automoc: move some code from the big parsing loop into separate functions bc7560e automoc: add test for including a moc_abc_p.cpp file 30fd8e6 automoc: add test for including the moc file from another header ... --- Summary of changes: Modules/AutomocInfo.cmake.in |1 + Source/cmDocumentVariables.cxx | 14 ++ Source/cmQtAutomoc.cxx | 395 +++--- Source/cmQtAutomoc.h | 12 +- Source/cmTarget.cxx |6 +- Tests/QtAutomoc/CMakeLists.txt |2 +- Tests/QtAutomoc/abc.cpp | 49 + Tests/QtAutomoc/abc.h| 28 +++ Tests/QtAutomoc/abc_p.h | 30 +++ Tests/QtAutomoc/bar.cpp | 28 +++ Tests/QtAutomoc/blub.cpp | 40 Tests/QtAutomoc/blub.h | 26 +++ Tests/QtAutomoc/main.cpp | 20 ++ Tests/QtAutomoc/private_slot.cpp | 21 ++ Tests/QtAutomoc/private_slot.h | 20 ++ Tests/QtAutomoc/sub/bar.h| 28 +++ Tests/QtAutomoc/xyz.cpp | 28 +++ Tests/QtAutomoc/xyz.h| 28 +++ Tests/QtAutomoc/yaf.cpp | 32 +++ Tests/QtAutomoc/yaf.h| 25 +++ Tests/QtAutomoc/yaf_p.h | 30 +++ 21 files changed, 790 insertions(+), 73 deletions(-) create mode 100644 Tests/QtAutomoc/abc.cpp create mode 100644 Tests/QtAutomoc/abc.h create mode 100644 Tests/QtAutomoc/abc_p.h create mode 100644 Tests/QtAutomoc/bar.cpp create mode
[Cmake-commits] CMake branch, next, updated. v2.8.6-2166-gb721d7d
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 b721d7d0c9754e59f613e16c8580336d8e3c724b (commit) via d050d6b58b311a6675286407bf626c0fae6c2eaf (commit) via 174ecf51f857031b0204a516df809814d4dc0386 (commit) via 0ea95b99cebc23d9fbf7d50872176911f5f65f96 (commit) via c26e28754c2f61ba704924bd5051e4d12b88fabf (commit) via 6fb2a38b0a672959a7ecc8fe4d07350371486310 (commit) from af6256309dd2acf91c9b8dd89d375f374d5d0671 (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=b721d7d0c9754e59f613e16c8580336d8e3c724b commit b721d7d0c9754e59f613e16c8580336d8e3c724b Merge: af62563 d050d6b Author: David Cole david.c...@kitware.com AuthorDate: Wed Dec 7 16:48:47 2011 -0500 Commit: David Cole david.c...@kitware.com CommitDate: Wed Dec 7 16:48:47 2011 -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, master, updated. v2.8.6-367-ge61d2de
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 e61d2ded80e98c96911eaf9545f720c29de72dc3 (commit) from d050d6b58b311a6675286407bf626c0fae6c2eaf (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=e61d2ded80e98c96911eaf9545f720c29de72dc3 commit e61d2ded80e98c96911eaf9545f720c29de72dc3 Author: KWSys Robot kwro...@kitware.com AuthorDate: Thu Dec 8 00:05:03 2011 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Thu Dec 8 00:05:03 2011 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 625cc6e..d6d4c70 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 12) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 07) +SET(KWSYS_DATE_STAMP_DAY 08) --- 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
