Re: [cmake-developers] Interface includes and defines plumbing
On 01/04/2013 12:09 PM, Stephen Kelly wrote: Brad King wrote: Yes, please. Thanks for splitting this out. Done, thanks, Thanks for cleaning up the dashboard trouble. I've merged this to master! -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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] LINK_LIBRARIES property topic
Steve, I've reviewed this topic: 4cf80cc Make sure types match exacty without conversion when making std::pairs. 786aa36 Fix (hopefully) the Mac build. 9bb1f54 Populate the LINK_LIBRARIES property when linking to targets. 1381d56 Add a HEAD-target to target linking API. I'm hesitant to use std::paircmTarget*, std::string as a map key. I had to read the commit history of it to understand what it represents. Please use a helper struct with a suitable name instead. Then squash the fixup commits back into the main HEAD-target commit. Also, I see a few uses of GetOriginalLinkLibraries left. The only one we should have left is the one for the CMP0003 OLD behavior. Thanks, -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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Interface includes and defines plumbing
Brad King wrote: On 01/04/2013 12:09 PM, Stephen Kelly wrote: Brad King wrote: Yes, please. Thanks for splitting this out. Done, thanks, Thanks for cleaning up the dashboard trouble. I've merged this to master! Great, thanks! I've pushed two new branches to my gitorious clone. include-dirs-convenience For the same reason that CMAKE_INCLUDE_CURRENT_DIR exists, but for interfaces. Please let me know what you think about the idea and API. target-includes-defines-commands For primary population of interface and non-interface includes and defines. The target_include_directories command will also be useful to 'correct' the order of includes in the future when that is done at the same time as link libs population. This one doesn't have unit tests yet, but if you agree to it, I can add tests. Thanks, Steve. -- 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] LINK_LIBRARIES property topic
Brad King wrote: Steve, I've reviewed this topic: 4cf80cc Make sure types match exacty without conversion when making std::pairs. 786aa36 Fix (hopefully) the Mac build. 9bb1f54 Populate the LINK_LIBRARIES property when linking to targets. 1381d56 Add a HEAD-target to target linking API. I'm hesitant to use std::paircmTarget*, std::string as a map key. I had to read the commit history of it to understand what it represents. Please use a helper struct with a suitable name instead. Then squash the fixup commits back into the main HEAD-target commit. Done. Also, I see a few uses of GetOriginalLinkLibraries left. The only one we should have left is the one for the CMP0003 OLD behavior. The other uses are in cmGlobalGenerator and in the Graphiviz generator. In cmGlobalGenerator it is used at configure-time, so we can't evaluate generator expressions, and shouldn't read LINK_LIBRARIES property directly because it can contain generator expressions set via set_property. Additionally, in a future patch, I strip out generator expressions before adding them to the OriginalLinkLibraries, so I think leaving that call there makes sense to get the link libraries known at configure time: https://gitorious.org/~steveire/cmake/steveires- cmake/commit/e18ddcd0fcfccdefcd8d6a5303fc809985cf9746 If you insist, I can rename the method, but I think that would be just noise in the history. The uses in the Graphviz generator are also called at configure-time. Downstreams may be relying on that and using the generated graphs in add_custom_target or similar. Additionally, the graphiviz generator does not generate multiple config- specific graph files (I think there is a bug for that, but I don't know where), nor does it put config specific information in all one graph (which should it do - it's an open question), so we can't use the information in generator expressions. I think it's a can of worms to try to do all that now, and it's a world away from the branch we're really trying to get integrated, and it will require discussion and maybe a policy etc. Thanks, Steve. -- 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] Interface includes and defines plumbing
Brad King wrote: On 01/07/2013 02:50 PM, Stephen Kelly wrote: I've pushed two new branches to my gitorious clone. include-dirs-convenience For the same reason that CMAKE_INCLUDE_CURRENT_DIR exists, but for interfaces. Please let me know what you think about the idea and API. The CMAKE_BUILD_INTERFACE_INCLUDES approach looks good. The name reserves room for other auto-BUILD_INTERFACE values in the future. Great. The install-tree equivalent is a neat idea. Upon first reading the test call with INCLUDES DESTINATION I wasn't sure whether it was trying to install some kind of associated headers list or something. Yes, I have the same concern. It's not like the other DESTINATION components of the command, which actually install what they say (includes in this case) to the destination. Perhaps the word INTERFACE should appear here to make sure it is clear that it is setting an interface on the installed target. Perhaps it should be install(TARGETS testLibRequired EXPORT RequiredExp DESTINATION lib INTERFACE_INCLUDES /foo/bar ) ? I wonder if we should hold off on this convenience interface until more of the new usage interface magic is worked out. We may be able to find an even more convenient way to set a whole bunch of stuff on an installed target's interface. Ok. I can split CMAKE_BUILD_INTERFACE_INCLUDES into a topic of its own. target-includes-defines-commands For primary population of interface and non-interface includes and defines. The target_include_directories command will also be useful to 'correct' the order of includes in the future when that is done at the same time as link libs population. It looks like the signatures have exactly one visibility keyword. Shouldn't they allow the keyword to be repeated so that the entire internal and external values can be specified in a single command? Yes, I can modify it to that effect. I was also thinking that for the includes command it might make sense to have a BEFORE keyword, but I'm not certain. I also have a slight concern that target_compile_definitions(foo PRIVATE bar) has an ambiguous meaning. It could mean 'take the INTERFACE_COMPILE_DEFINITIONS from the bar target and use them' or it could mean 'Add -Dbar to the COMPILE_DEFINITIONS', depending on whether a target called 'bar' exists. The workaround is to use set_property in that case. target_include_directories does not have that problem, as paths must be absolute. What do you think? The new commands do not need to be included in the bootstrap build. We won't be using them in CMake's own rules for a while. Ok. Thanks, Steve. -- 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] Interface includes and defines plumbing
On 01/07/2013 03:36 PM, Stephen Kelly wrote: Perhaps it should be install(TARGETS testLibRequired EXPORT RequiredExp DESTINATION lib INTERFACE_INCLUDES /foo/bar ) ? That looks better, but I think it is best to wait until we gain more experience with the new capabilities. We can always add convenience interfaces later but we can't take them away. wonder if we should hold off on this convenience interface until more of the new usage interface magic is worked out. We may be able to find an even more convenient way to set a whole bunch of stuff on an installed target's interface. Ok. I can split CMAKE_BUILD_INTERFACE_INCLUDES into a topic of its own. Yes. Yes, I can modify it to that effect. I was also thinking that for the includes command it might make sense to have a BEFORE keyword, but I'm not certain. I'm sure it won't take long for someone to ask for it if it isn't there. It essentially asks for the arguments to be prefixed instead of appended on the property value. I also have a slight concern that target_compile_definitions(foo PRIVATE bar) has an ambiguous meaning. Yes, this is in part a consequence of CMake's syntax and conventions. It could mean 'take the INTERFACE_COMPILE_DEFINITIONS from the bar target and use them' or it could mean 'Add -Dbar to the COMPILE_DEFINITIONS', depending on whether a target called 'bar' exists. The workaround is to use set_property in that case. target_include_directories does not have that problem, as paths must be absolute. What do you think? Allow bar= to mean a definition with no value. It will never be confused with a target name. Fortunately target names are usually lower case and macros are usually upper case so this conflict will be rare in practice. -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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Review request: Qt4 interface includes and defines (Was Re: Interface includes and defines plumbing)
On Monday, January 07, 2013 08:55:40 PM Stephen Kelly wrote: Stephen Kelly wrote: Brad King wrote: On 01/04/2013 12:09 PM, Stephen Kelly wrote: Brad King wrote: Yes, please. Thanks for splitting this out. Done, thanks, Thanks for cleaning up the dashboard trouble. I've merged this to master! Great, thanks! I've pushed two new branches to my gitorious clone. I also re-pushed the qt4-target-depends branch to add INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_COMPILE_DEFINTIONS to the Qt 4 targets. Alex, Clinton, could you review before I merge to next? Looks fine to me except that the Qt3Support module needs -DQT3_SUPPORT -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] LINK_LIBRARIES property topic
On 01/07/2013 03:26 PM, Stephen Kelly wrote: Brad King wrote: Also, I see a few uses of GetOriginalLinkLibraries left. The only one we should have left is the one for the CMP0003 OLD behavior. The other uses are in cmGlobalGenerator and in the Graphiviz generator. In cmGlobalGenerator it is used at configure-time, so we can't evaluate generator expressions, and shouldn't read LINK_LIBRARIES property directly because it can contain generator expressions set via set_property. It is used at the end of configuration after all processing is done. It is looking for raw string values that look like FIND_VAR-NOTFOUND to report their accidental use. This can be checked by reading the LINK_LIBRARIES property directly and using just ExpandListArgument without any generator expressions. I think this can wait for a future patch though and does not have to be squashed in the topic now. The uses in the Graphviz generator are also called at configure-time. Downstreams may be relying on that and using the generated graphs in add_custom_target or similar. Additionally, the graphiviz generator does not generate multiple config- specific graph files (I think there is a bug for that, but I don't know where), nor does it put config specific information in all one graph (which should it do - it's an open question), so we can't use the information in generator expressions. Ugh. IMO the graphviz feature should never have been added. It puts an unnecessary burden on new development like this while adding now real build capabilities. I've never used it even in large projects. Anyway, I think it can be skipped for now too. -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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Review request: Qt4 interface includes and defines
Clinton Stimpson wrote: On Monday, January 07, 2013 08:55:40 PM Stephen Kelly wrote: Stephen Kelly wrote: Brad King wrote: On 01/04/2013 12:09 PM, Stephen Kelly wrote: Brad King wrote: Yes, please. Thanks for splitting this out. Done, thanks, Thanks for cleaning up the dashboard trouble. I've merged this to master! Great, thanks! I've pushed two new branches to my gitorious clone. I also re-pushed the qt4-target-depends branch to add INTERFACE_INCLUDE_DIRECTORIES and INTERFACE_COMPILE_DEFINTIONS to the Qt 4 targets. Alex, Clinton, could you review before I merge to next? Looks fine to me except that the Qt3Support module needs -DQT3_SUPPORT Good catch. I've added it and merged it to next. Thanks, Steve. -- 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] Interface includes and defines plumbing
Brad King wrote: On 01/07/2013 03:36 PM, Stephen Kelly wrote: Perhaps it should be install(TARGETS testLibRequired EXPORT RequiredExp DESTINATION lib INTERFACE_INCLUDES /foo/bar ) ? That looks better, but I think it is best to wait until we gain more experience with the new capabilities. We can always add convenience interfaces later but we can't take them away. Yes. wonder if we should hold off on this convenience interface until more of the new usage interface magic is worked out. We may be able to find an even more convenient way to set a whole bunch of stuff on an installed target's interface. Ok. I can split CMAKE_BUILD_INTERFACE_INCLUDES into a topic of its own. Yes. I've merged it to next as include-dirs-convenience. Yes, I can modify it to that effect. I was also thinking that for the includes command it might make sense to have a BEFORE keyword, but I'm not certain. I'm sure it won't take long for someone to ask for it if it isn't there. It essentially asks for the arguments to be prefixed instead of appended on the property value. Yes, added now. I also have a slight concern that target_compile_definitions(foo PRIVATE bar) has an ambiguous meaning. What do you think? Fortunately target names are usually lower case and macros are usually upper case so this conflict will be rare in practice. Yes, I agree. That's why I think the set_property workaround should be fine too. The new commands do not need to be included in the bootstrap build. We won't be using them in CMake's own rules for a while. I've merged the branch to next for testing. It's not clear how to add the commands without bootstrapping them. In my branch, the BootstrapTest fails: cmake.o: In function `cmTargetIncludeDirectoriesCommand::cmTargetIncludeDirectoriesCommand()': cmake.cxx: (.text._ZN33cmTargetIncludeDirectoriesCommandC2Ev[_ZN33cmTargetIncludeDirectoriesCommandC5Ev]+0x1f): undefined reference to `vtable for cmTargetIncludeDirectoriesCommand' cmake.o: In function `cmTargetCompileDefinitionsCommand::cmTargetCompileDefinitionsCommand()': cmake.cxx: (.text._ZN33cmTargetCompileDefinitionsCommandC2Ev[_ZN33cmTargetCompileDefinitionsCommandC5Ev]+0x1f): undefined reference to `vtable for cmTargetCompileDefinitionsCommand' I'm sure the reason is that cmake.cxx itself is bootstrapped. Thanks, Steve. -- 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] Request for Comments: Will implementing an interactive CMake debugger be welcome?
Hi Shlomi, I also think this would be a great feature. I started on an implementation here: https://github.com/thewtex/cmakedbg but I have not had time to follow it through. The user interface is written in Python/Cython for fast prototyping purposes, but it could be written all C/C++ if you would like. I believe I got to the point where it was possible to set a breakpoint. I was building against this branch: https://github.com/thewtex/CMake/tree/cmakedbg Overall, I think the approach is fairly solid. When CMake processes a line, it asks a debugger if it is interested. For there, the debugger can pause if a breakpoint is set at that point, let the user print the content of current variables that are defined, ... Since it uses CMake for processing all the code, the debugger will behave exactly the same as a cmake executable. Feel free to take the project and run with it. Matt On Thu, Jan 3, 2013 at 3:46 PM, Stephen Kelly steve...@gmail.com wrote: Shlomi Fish wrote: Hi all, following a discussion we had on ##llvm on irc.oftc.net (the main LLVM channel, because LLVM+clang can be built using CMake), I've been wondering if you would like someone (like me) to implement an interactive debugger (or debugging mode) for cmake invocations, similar to gdb, perl -d, pdb.py, etc.? I saw this thread: http://www.cmake.org/pipermail/cmake/2009-July/030728.html Where it was recommended to use cmake --trace, and I've been using MESSAGE ( ... ) and MESSAGE (FATAL_ERROR ...) for most of my debugging, but I'm interested in something better. I can try working on it given the time and motivation (in a separate git branch on a GitHub/Bitbucket repository), but I want to get a green light for it, because once introduced, it naturally should be supported in the future (and if I'm going to write it, I am willing to help support it). Hi there, I'm sure such an addition would be welcome, but it would be a lot of work. Before writing such a feature, do you have enough familiarity with the cmake codebase already to describe how much work it would be? Thanks, Steve. -- 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
[cmake-developers] DESTDIR does not work correctly with install(FILES ... signature
Here is a simple project to show the issue summarized in the subject
line for the default Unix Makefiles generator on Linux.
# Test DESTDIR
cmake_minimum_required (VERSION 2.8.5)
project (test_destdir NONE)
INSTALL(CODE
FILE(MAKE_DIRECTORY $ENV{DESTDIR}/whatever)
)
This does not work correctly with either 2.8.5 or 2.8.10.2.
The above idea of using $ENV{DESTDIR} for this case was taken
from an old Brad King post to the cmake mailing list so
in case that post was outdated, I also tried dropping $ENV{DESTDIR}
from the above test project, but that failed in the same way
as described below.
cmake does not generate any error messages for all cases I
tried. However, in all cases the issue is $ENV{DESTDIR} is completely missing
as a prefix to
/whatever in cmake_install.cmake, i.e.,
software@raven grep -n whatever cmake_install.cmake
37: FILE(MAKE_DIRECTORY /whatever)
Because of that issue you get the following error from make for that
same line in the file.
software@raven make DESTDIR=/tmp/test_DIR install
Install the project...
-- Install configuration: Release
CMake Error at cmake_install.cmake:37 (FILE):
file problem creating directory: /whatever
If I hand-edit that file to fix up the issue, all is well
software@raven grep -n whatever cmake_install.cmake
37: FILE(MAKE_DIRECTORY $ENV{DESTDIR}/whatever)
software@raven make DESTDIR=/tmp/test_DIR install
Install the project...
-- Install configuration: Release
software@raven ls /tmp/test_DIR/
whatever/
Since the fundamentals of the above test project were copied from an
old cmake mailing list post from Brad King, this issue for 2.8.5 and
2.8.10.2 may be a regression against some previous version of cmake.
I am trying to get releases for two separate projects out the door
so any quick workaround suggestions for the DESTDIR issue would be welcome.
My exact use case for those two projects (as well as PLplot) doesn't
use FILE, but that was the easiest way to demonstrate the issue above.
Instead, I am copying doxygen-generated documentation from the build
tree to the install tree at install time for all three projects using
install(CODE
message(STATUS \Installing: $ENV{DESTDIR}${DOC_DIR}/doxygen tree\)
execute_process(COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_CURRENT_BINARY_DIR}/doxygen $ENV{DESTDIR}${DOC_DIR}/doxygen)
)
cmake (incorrectly) drops $ENV{DESTDIR} when translating
these instructions to doc/cmake_install.cmake, i.e.,
software@raven grep -n doxygen doc/cmake_install.cmake
53:message(STATUS Installing:
/home/software/plplot_svn/installcmake/share/doc/plplot/doxygen tree)
54:execute_process(COMMAND
/home/software/cmake/install-2.8.10.2/bin/cmake -E copy_directory
/home/software/plplot_svn/HEAD/build_dir/doc/doxygen
/home/software/plplot_svn/installcmake/share/doc/plplot/doxygen)
(This example is for PLplot, but the actual two urgent releases
that use similar logic are ephcom and te_gen.)
So if there is no quick way to fix this DESTDIR issue, then can
somebody suggest a different alternative that can quickly be
implemented for installing doxygen-generated files in the install-tree
that is sensitive to DESTDIR? I don't think there are any guarantees
that doxygen-generated files have the same names from one doxygen
release to the next so any solutions should not use the assumption of
fixed names for that relatively large number of different files.
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); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Cmake absolute paths with gcc, __FILE__ , and logging
2013/1/4 Gregor Jasny gja...@googlemail.com:
Hello Willy,
On 1/4/13 4:58 PM, Willy Lambert wrote:
I am trying to convert an existing project from Manual Makefiles to
Cmake for building it.
We have a logger that rely on the __FILE__ define to say which file is
writing into the log but this is broken by the CMake default
behavior using absolute paths.
So I wonder if there is any way to have the file name in the code to
be able to log Error : line XXX in file.cpp.
This is somewhat hackish and should be surrounded by a check for the
Makefile generator:
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -D__FILENAME__='\$(subst
${CMAKE_SOURCE_DIR}/,,$(abspath $))\')
Thanks,
Gregor
Thanks ! This is working and is a great solution for us. CMake is in
love with abspath anyway, so whatever I'll do, it'll be hackish.
I wasn't aware that CMake was letting us hacking with make likewise. I
agree it is not a clean way but when it is the only solution it is a
good exit gate when converting project from makefiles. Is this
features expected by CMake or is it a un-wanted bug ? May I rely on
Cmake kepping this behavior in futur versions.
--
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 absolute paths with gcc, __FILE__ , and logging
2013/1/7 Willy Lambert lambert.wi...@gmail.com:
2013/1/4 Gregor Jasny gja...@googlemail.com:
Hello Willy,
On 1/4/13 4:58 PM, Willy Lambert wrote:
I am trying to convert an existing project from Manual Makefiles to
Cmake for building it.
We have a logger that rely on the __FILE__ define to say which file is
writing into the log but this is broken by the CMake default
behavior using absolute paths.
So I wonder if there is any way to have the file name in the code to
be able to log Error : line XXX in file.cpp.
This is somewhat hackish and should be surrounded by a check for the
Makefile generator:
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -D__FILENAME__='\$(subst
${CMAKE_SOURCE_DIR}/,,$(abspath $))\')
Thanks,
Gregor
Thanks ! This is working and is a great solution for us. CMake is in
love with abspath anyway, so whatever I'll do, it'll be hackish.
I wasn't aware that CMake was letting us hacking with make likewise. I
agree it is not a clean way but when it is the only solution it is a
good exit gate when converting project from makefiles. Is this
features expected by CMake or is it a un-wanted bug ? May I rely on
Cmake kepping this behavior in futur versions.
eh, in fact it works only for the cpp file. But included files are
not stated correctly (case of inlined functions)...
But it's a step.
--
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
[CMake] Selective build and install of subfolders
Hello list, I have a project with subfolders that should be selectively built and installed. The problem ist that there are various dependencies between them. At the moment I have a list-variable that contains the targets I want to be built and the folders are included depending on this list: $ cmake -DWANTED=this;that A folder is included with ADD_SUBDIRECTORY if it is explicitly named in the list or is needed as dependency of another target - done with multiple LIST(FIND) commands. This way I'm functionally recreating the dependency list that is also built by ADD_DEPENDENCIES and TARGET_LINK_LIBRARIES. I searched the documentation for a better solution, but found only these things that seem related at first glance but don't do what I want: - Using EXCLUDE_FROM_ALL in ADD_SUBDIRECTORY, ADD_EXECUTABLE or ADD_LIBRARY. This should handle dependencies, but the docs say: Installing a target with EXCLUDE_FROM_ALL set to true has undefined behavior. - Using COMPONENT in INSTALL commands. Does not affect compilation, just installation and does not handle dependencies. So my question: Am I missing something or is it not possible to do selective build and install without the fuss of recreating the dependencies? Thanks Stefan -- 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 absolute paths with gcc, __FILE__ , and logging
2013/1/4 Andreas Mohr a...@lisas.de: Hi, On Fri, Jan 04, 2013 at 11:47:40AM -0500, cmake-requ...@cmake.org wrote: Date: Fri, 4 Jan 2013 16:58:05 +0100 From: Willy Lambert lambert.wi...@gmail.com Hi all, Short Story : I am trying to convert an existing project from Manual Makefiles to Cmake for building it. We have a logger that rely on the __FILE__ define to say which file is writing into the log but this is broken by the CMake default behavior using absolute paths. So I wonder if there is any way to have the file name in the code to be able to log Error : line XXX in file.cpp. Long Story : So I have for instance a source /home/me/src/main.cpp, compiled with relative paths gcc -o main.cpp. So the logger say Error : line XXX in main.cpp. I'm afraid given the discussion at Short form of __FILE__ http://bytes.com/topic/c/answers/453661-short-form-__file__ the onus is on your project since it seems to be relying on seemingly rather volatile (non-standardized) behaviour of the __FILE__ macro (compilers seem to be free to pass on either a file's basename only or a relative path or even a FQPN). Depends what you listen under standard. In my case it's standrd with GNU tools. If you know how I could log filename + line number in a standardized way let me know (or point links), I'll be very happy for that. For now, I'm only expected my project working with GNU, and only it (which is rather by necessity than by choice). And now that one is using a CMake build which needs to do builds from an entirely separate binary tree referencing source files in a foreign source tree (thus having a justified reason for needing to specify paths in full), Yes and no. Yes, CMake has to manage a source root dir and a binary output dir (and maybe a relative path from source to build ?), but I'm not sure that you *need* it to build (see the CMAKE_USE_RELATIVE_PATHS option that is already working on simple cases). In my case, it's a classical CMake tructure : myproject/ So it's a strong reason in current implementation, not sure it is justified. Nevertheless I'm aware that as all free project it has limitation, lack of contributions, etc, ... what I mean is that I'm not sure that the onus of this is *only* my project. I have 3 solutions (in this order of priority) : _ extending Cmake _ finding a hack _ changing log system (for an obvious reason you can't switch easily an existing project regarding log because there are lot of work to do) these improper assumptions in your project seem to fall flat on their face, since gcc chooses to prefer to pass on as much information to the __FILE__ macro as it can get about the file location (i.e., full path). It's not really improper since I choosed GNU gcc, so everything is behaving as expected. What is not behaving as expected (on my point of view, with is relative), the improper assumption is that Cmake doesn't hide Since the problem is thus firmly located on the source code side (i.e. its assumptions about __FILE__), I'd suggest treating the problem right there, using e.g. the discussion's strrchr() solution (workaround?) to achieve a slightly improved guarantee of gaining sufficiently constant output format (but note that Keith Thompson noted that the C language itself does not have any business dealing with path separator definitions). I tried to use the suggested trigger set_source_files_properties to define my own __FILE__ but it doesn't works with included files (it shows main.cpp instead oh dummy.hpp) http://www.cmake.org/pipermail/cmake/2011-December/048281.html So this way is a dead end because the compilator (and the one that creates its command line) is the only one to be aware of this information. Beside that, as I would really like to simplify the VERBOSE=2 make output to be able to debug what CMake generates I currently have plenty of path with 20 or more folder level including many ../.., I am looking on making CMake giving relatives paths to gcc. I guess the problem is that CMake is operating from a separate binary tree as its base, thus it obviously needs to pass full paths to the source files to the compiler, to get to the other source dir over there. The alternative would be to have cwd set to the source tree directory when launching gcc, to be able to specify source file arguments as file-only (the -o object file argument however should be able to support full paths without any negative effects, right?). I have seen some thread about the use of CMAKE_USE_RELATIVE_PATHS, but it seems that it is not working, and maybe with no will to support this (is that true ?) http://cmake.3232098.n2.nabble.com/CMAKE-USE-RELATIVE-PATHS-td4042914.html I'm actually rather interested in CMAKE_USE_RELATIVE_PATHS myself, since I'd like to be able to generate a (semi-static) subset of Visual Studio projects for permanently adding them to an existing static .sln (this use case would probably
Re: [CMake] Cmake absolute paths with gcc, __FILE__ , and logging
really sorry, last mail was sent too early X-( 2013/1/7 Willy Lambert lambert.wi...@gmail.com: 2013/1/4 Andreas Mohr a...@lisas.de: Hi, On Fri, Jan 04, 2013 at 11:47:40AM -0500, cmake-requ...@cmake.org wrote: Date: Fri, 4 Jan 2013 16:58:05 +0100 From: Willy Lambert lambert.wi...@gmail.com Hi all, Short Story : I am trying to convert an existing project from Manual Makefiles to Cmake for building it. We have a logger that rely on the __FILE__ define to say which file is writing into the log but this is broken by the CMake default behavior using absolute paths. So I wonder if there is any way to have the file name in the code to be able to log Error : line XXX in file.cpp. Long Story : So I have for instance a source /home/me/src/main.cpp, compiled with relative paths gcc -o main.cpp. So the logger say Error : line XXX in main.cpp. I'm afraid given the discussion at Short form of __FILE__ http://bytes.com/topic/c/answers/453661-short-form-__file__ the onus is on your project since it seems to be relying on seemingly rather volatile (non-standardized) behaviour of the __FILE__ macro (compilers seem to be free to pass on either a file's basename only or a relative path or even a FQPN). Depends what you listen under standard. In my case it's standrd with GNU tools. If you know how I could log filename + line number in a standardized way let me know (or point links), I'll be very happy for that. For now, I'm only expected my project working with GNU, and only it (which is rather by necessity than by choice). And now that one is using a CMake build which needs to do builds from an entirely separate binary tree referencing source files in a foreign source tree (thus having a justified reason for needing to specify paths in full), Yes and no. Yes, CMake has to manage a source root dir and a binary output dir (and maybe a relative path from source to build ?), but I'm not sure that you *need* it to build (see the CMAKE_USE_RELATIVE_PATHS option that is already working on simple cases). In my case, it's a classical CMake tructure : myproject/ build src so I understand that cmake has to know about internal src/build structure (and I wouldn't mind cmake using src/XXX path without being able to prevent the src particule which is not a problem). What I don't want is having information in my binaries about my myproject folder location. So it's a strong reason in current implementation, not sure it is justified. Nevertheless I'm aware that as all free project it has limitation, lack of contributions, etc, ... what I mean is that I'm not sure that the onus of this is *only* my project. I have 3 solutions (in this order of priority) : _ extending Cmake _ finding a hack _ changing log system (for an obvious reason you can't switch easily an existing project regarding log because there are lot of work to do) these improper assumptions in your project seem to fall flat on their face, since gcc chooses to prefer to pass on as much information to the __FILE__ macro as it can get about the file location (i.e., full path). It's not really improper since I choosed GNU gcc, so everything is behaving as expected. What is not behaving as expected (on my point of view, with is relative), the improper assumption is that Cmake doesn't hide the path to the project Since the problem is thus firmly located on the source code side (i.e. its assumptions about __FILE__), I'd suggest treating the problem right there, using e.g. the discussion's strrchr() solution (workaround?) to achieve a slightly improved guarantee of gaining sufficiently constant output format (but note that Keith Thompson noted that the C language itself does not have any business dealing with path separator definitions). Thanks for pointing this link, very interesting. The strrchr() solution is demanding computation at run time, which is quite a pity (not to see a problem as it is an embedded project). But at least it's a solution. I tried to use the suggested trigger set_source_files_properties to define my own __FILE__ but it doesn't works with included files (it shows main.cpp instead oh dummy.hpp) http://www.cmake.org/pipermail/cmake/2011-December/048281.html So this way is a dead end because the compilator (and the one that creates its command line) is the only one to be aware of this information. Beside that, as I would really like to simplify the VERBOSE=2 make output to be able to debug what CMake generates I currently have plenty of path with 20 or more folder level including many ../.., I am looking on making CMake giving relatives paths to gcc. I guess the problem is that CMake is operating from a separate binary tree as its base, thus it obviously needs to pass full paths to the source files to the compiler, to get to the other source dir over there. The alternative would be to have cwd set to the source tree directory when launching gcc,
[CMake] Tracker.exe response file error
Hi all. On Windows, Visual Studio 2010, some machines in our company experience this error ( http://connect.microsoft.com/VisualStudio/feedback/details/540902/tracker-exe-response-file-not-found) when detecting C compiler, which makes it impossible to use CMake on them. The workaround (mentioned in the link) would be to add the following to the .vcxproj generated for try_compile: PropertyGroup TrackFileAccessfalse/TrackFileAccess /PropertyGroup Or add the following to the msbuild command line: /p:TrackFileAccess=false Is there a way to do this with the current capabilities of CMake (any of env.var, cache var, command-line option, ...)? Or should I raise a bug report? Has anyone encountered this problem, and is there a solution? Thanks in advance. Petr -- 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] What is the proper cross-platform way to link the Python library?
Alan W. Irwin wrote: If/when that python.org bug is fixed I will look into the Is it reported? If not it won't get fixed. I assume you saw this? http://thread.gmane.org/gmane.comp.science.paraview.user/10956/focus=11019 I wonder if that David reported it either. Thanks, Steve. -- 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] Selective build and install of subfolders
screamingfist@... writes: Hello list, I have a project with subfolders that should be selectively built and installed. The problem is that there are various dependencies between them. [snip] Hi Stefan, I think you should look into options, and the CMake dependent option macro. http://www.cmake.org/cmake/help/v2.8.4/cmake.html#command:option http://www.cmake.org/cmake/help/v2.8.4/cmake.html#module:CMakeDependentOption The idea is to guard add_subdirectory commands with if commands. The if commands would be checking the value of the options. It's not really pretty, but it may be enough for you to do the job. Hope that it helps. -- Amine -- 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] Ninja and *.i targets
On 1/5/2013 3:49 PM, Óscar Fuentes wrote: With the `Unix Makefiles' generator, a foo.i target is generated for foo.cpp. That's very convenient. However, ninja doesn't list such targets under `ninja help' and `ninja foo.i' complains about unknown target. Is this feature missing from the ninja generator? Is it because is hard to implement or just lack of time? I'm using cmake 2.8.9 and ninja 1.0.0 on Linux. This is a missing feature. Can you create a feature request for it in the bug tracker? Thanks. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- 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] Ninja and *.i targets
Bill Hoffman wrote: On 1/5/2013 3:49 PM, Óscar Fuentes wrote: With the `Unix Makefiles' generator, a foo.i target is generated for foo.cpp. That's very convenient. However, ninja doesn't list such targets under `ninja help' and `ninja foo.i' complains about unknown target. Is this feature missing from the ninja generator? Is it because is hard to implement or just lack of time? I'm using cmake 2.8.9 and ninja 1.0.0 on Linux. This is a missing feature. Can you create a feature request for it in the bug tracker? While at it, you comb this thread to see if there are other feature requests there which are not in the bug tracker: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3471/focus=3475 Thanks, Steve. -- 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] Ninja and *.i targets
Bill Hoffman bill.hoff...@kitware.com writes: On 1/5/2013 3:49 PM, Óscar Fuentes wrote: With the `Unix Makefiles' generator, a foo.i target is generated for foo.cpp. That's very convenient. However, ninja doesn't list such targets under `ninja help' and `ninja foo.i' complains about unknown target. This is a missing feature. Can you create a feature request for it in the bug tracker? Done: http://public.kitware.com/Bug/view.php?id=13838 Thanks. -- 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] install(EXPORT ...) behavior for multi-configuration generators
Hello,
I am using CMake 2.8.10.2, on windows.
I am trying to use install(TARGETS ) and install(EXPORT ) both with NMake
makefiles and with the multi-configuration generator Visual studio.
I cannot get the same behavior when I want my binaries to be installed in a
subfolder that depends on the configuration, e.g. :
- Debug/bin/myLib.dll
- Release/bin/myLib.dll
If I do that :
#start
install(TARGETS myLib EXPORT myTargets
ARCHIVE DESTINATION \${CMAKE_INSTALL_CONFIG_NAME}/lib
LIBRARY DESTINATION\${CMAKE_INSTALL_CONFIG_NAME}/lib
RUNTIME DESTINATION \${CMAKE_INSTALL_CONFIG_NAME}/bin
)
install(EXPORT myTargets DESTINATION cmake)
#end
This works find for NMake and Visual for install rules because
${CMAKE_INSTALL_CONFIG_NAME} will be evaluated at install time.
But in my myTargets-debug.cmake import files, ${CMAKE_INSTALL_CONFIG_NAME} will
not be evaluated correctly.
Now If I do that:
#start
install(TARGETS myLib EXPORT myTargets
ARCHIVE DESTINATION Debug/lib
LIBRARY DESTINATIONDebug/lib
RUNTIME DESTINATION Debug/bin
CONFIGURATIONS Debug
)
install(TARGETS myLib EXPORT myTargets
ARCHIVE DESTINATION Release/lib
LIBRARY DESTINATIONRelease/lib
RUNTIME DESTINATION Release/bin
CONFIGURATIONS Release
)
install(EXPORT myTargets DESTINATION cmake)
# end
CMake will complain that:
CMake Error: INSTALL(EXPORT myTargets ...) includes target myLib more
than once in the export set.
Is this a bug that CMake complains about a target being exported twice but with
different configurations?
Does anyone have a workaround?
Regards,
Gregoire
--
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] Ninja and *.i targets
Stephen Kelly steve...@gmail.com writes: While at it, you comb this thread to see if there are other feature requests there which are not in the bug tracker: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3471/focus=3475 Good idea. Apart from the .i targets, the only non-controversial unimplemented feature I see is the generation of .s targets. Created a feature request here: http://public.kitware.com/Bug/view.php?id=13839 -- 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] Ninja and *.i targets
Óscar Fuentes wrote: Stephen Kelly steve...@gmail.com writes: While at it, you comb this thread to see if there are other feature requests there which are not in the bug tracker: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3471/focus=3475 Good idea. Apart from the .i targets, the only non-controversial unimplemented feature I see is the generation of .s targets. Created a feature request here: http://public.kitware.com/Bug/view.php?id=13839 Great, thanks! -- 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 issue compiling CLucene
Hello Mike I also tried from the VS command prompt but it gives the same problem with the linker it seems... -- View this message in context: http://cmake.3232098.n2.nabble.com/Cmake-issue-compiling-CLucene-tp7582775p7582803.html Sent from the CMake mailing list archive at Nabble.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 issue compiling CLucene
On 1/7/2013 3:18 PM, Hatchi wrote: Hello Mike I also tried from the VS command prompt but it gives the same problem with the linker it seems... Does this work for you: http://stackoverflow.com/questions/12267158/failure-during-conversion-to-coff-file-invalid-or-corrupt -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- 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.10.2-1426-gd83569b
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 d83569b74e0ea6e7bde0d417262969dd6cb5705d (commit) via 7f633b4e69a79fc509499cf85a25b8605fcfecc9 (commit) via 6969515b097c05349f09549c16ad13ccebbe1eea (commit) via c7550d5ef12d8185fad93d581ebd52474ae3d1b0 (commit) via 427ef824988a926fc7c7e948345929fcd359d6fb (commit) from 985f897cd6965db5ce96765fafbaee210ec05b86 (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=d83569b74e0ea6e7bde0d417262969dd6cb5705d commit d83569b74e0ea6e7bde0d417262969dd6cb5705d Merge: 985f897 7f633b4 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Jan 7 09:55:39 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Jan 7 09:55:39 2013 -0500 Merge topic 'update-kwsys' into next 7f633b4 Merge branch 'upstream-kwsys' into update-kwsys 6969515 KWSys 2013-01-04 (5c0eb48c) c7550d5 CMake Nightly Date Stamp 427ef82 CMake Nightly Date Stamp http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7f633b4e69a79fc509499cf85a25b8605fcfecc9 commit 7f633b4e69a79fc509499cf85a25b8605fcfecc9 Merge: c7550d5 6969515 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Jan 7 09:53:48 2013 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Jan 7 09:53:48 2013 -0500 Merge branch 'upstream-kwsys' into update-kwsys http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6969515b097c05349f09549c16ad13ccebbe1eea commit 6969515b097c05349f09549c16ad13ccebbe1eea Author: KWSys Robot kwro...@kitware.com AuthorDate: Fri Jan 4 11:27:47 2013 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Jan 7 09:53:43 2013 -0500 KWSys 2013-01-04 (5c0eb48c) Extract upstream KWSys using the following shell commands. $ git archive --prefix=upstream-kwsys/ 5c0eb48c | tar x $ git shortlog --no-merges --abbrev=8 --format='%h %s' 8ce09af5..5c0eb48c Brad King (2): cb5f835f SystemTools: Fix MakeDirectory with colon in path 1643507a IOStream: Fix check for compiler 'long long' support Rolf Eike Beer (15): 4da9894d SystemInformation: Clean up QuerySolarisInfo() 01392358 SystemInformation: don't attribute i386 Solaris systems to Sun 3db65ac1 SystemInformation: wrap the call to CPUID in a function 61bd9b42 SystemInformation: use the __cpuid compiler intrinsic if present 5932e7c0 SystemInformation: query memory size on Cygwin using sysconf() ea5612ed SystemInformation: count memory with _SC_PAGESIZE and _SC_PHYS_PAGES 3aca6642 SystemInformation: query memory size, CPU count, and CPU speed on BSD 3572c54d SystemInformation: count CPUs on HP-UX e6771b34 SystemInformation: determine CPU type on HP-UX 640210e5 SystemInformation: use /proc/cpuinfo only when present 5bdcfd10 SystemInformation: query total memory on AIX de69d547 SystemInformation: use intrinsic for RDTSC if supported 9808d4e7 SystemInformation: get CPU speed on Windows when RDTSC fails f4c625b5 tests: avoid truncation of testSystemInformation output in CDash 03d6fbe5 SystemInformation: get x86 CPU features from /proc/cpuinfo Stephen Kelly (1): 247b8a3c SystemTools: Rename MakeCnidentifier() to MakeCidentifier() Change-Id: Ia59e43030fa27ce784a211beb103e6c8d044395c diff --git a/CMakeLists.txt b/CMakeLists.txt index ccdff12..6bfcab0 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -596,6 +596,13 @@ IF(KWSYS_USE_SystemInformation) ENDIF() ENDIF() ENDIF() + IF(CMAKE_SYSTEM MATCHES HP-UX) +CHECK_INCLUDE_FILES(sys/mpctl.h KWSYS_SYS_HAS_MPCTL_H) +IF(KWSYS_SYS_HAS_MPCTL_H) + SET_PROPERTY(SOURCE SystemInformation.cxx APPEND PROPERTY +COMPILE_DEFINITIONS KWSYS_SYS_HAS_MPCTL_H=1) +ENDIF() + ENDIF() IF(KWSYS_LFS_AVAILABLE AND NOT KWSYS_LFS_DISABLE) SET(KWSYS_PLATFORM_CXX_TEST_DEFINES -DKWSYS_HAS_LFS=1) ENDIF() diff --git a/IOStream.hxx.in b/IOStream.hxx.in index 9eb99e0..2eeedf2 100644 --- a/IOStream.hxx.in +++ b/IOStream.hxx.in @@ -26,12 +26,9 @@ /* Whether ostream supports long long. */ #define @KWSYS_NAMESPACE@_IOS_HAS_OSTREAM_LONG_LONG @KWSYS_IOS_HAS_OSTREAM_LONG_LONG@ -/* Size of type long long and 0 if not available. */ -#define @KWSYS_NAMESPACE@_IOS_SIZEOF_LONG_LONG @KWSYS_SIZEOF_LONG_LONG@ - /* Determine whether we need to define the streaming operators for long long or __int64. */ -#if @KWSYS_NAMESPACE@_IOS_SIZEOF_LONG_LONG +#if @KWSYS_USE_LONG_LONG@ #
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1430-gfd97a2c
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 fd97a2c77eb6509f70d7b9dd37b6d1e4202a7b52 (commit)
via 09a0da77891bae3820b48c44c48bef3837b0a6e2 (commit)
from e26c19a3ee3259d05953b0dbdecd89c328be7aa5 (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=fd97a2c77eb6509f70d7b9dd37b6d1e4202a7b52
commit fd97a2c77eb6509f70d7b9dd37b6d1e4202a7b52
Merge: e26c19a 09a0da7
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Jan 7 10:35:34 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jan 7 10:35:34 2013 -0500
Merge topic 'deprecate-load_command' into next
09a0da7 Revert load_command: Deprecate and document pending removal
diff --cc Tests/RunCMake/CMakeLists.txt
index cc544a3,3ea54f1..fec64b5
--- a/Tests/RunCMake/CMakeLists.txt
+++ b/Tests/RunCMake/CMakeLists.txt
@@@ -54,9 -52,7 +54,8 @@@ add_RunCMake_test(ObjectLibrary
add_RunCMake_test(build_command)
add_RunCMake_test(find_package)
add_RunCMake_test(include)
+add_RunCMake_test(include_directories)
add_RunCMake_test(list)
- add_RunCMake_test(load_command)
if(${CMAKE_TEST_GENERATOR} MATCHES Visual Studio [^6])
add_RunCMake_test(include_external_msproject)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=09a0da77891bae3820b48c44c48bef3837b0a6e2
commit 09a0da77891bae3820b48c44c48bef3837b0a6e2
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Jan 7 10:31:07 2013 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Jan 7 10:31:07 2013 -0500
Revert load_command: Deprecate and document pending removal
This reverts commit d2d43986e7f5013465473a71c393fc3897cecbac.
We will add a policy to remove the command more gracefully.
diff --git a/Source/cmLoadCommandCommand.cxx b/Source/cmLoadCommandCommand.cxx
index 181b922..b2acf06 100644
--- a/Source/cmLoadCommandCommand.cxx
+++ b/Source/cmLoadCommandCommand.cxx
@@ -224,10 +224,6 @@ cmLoadedCommand::~cmLoadedCommand()
bool cmLoadCommandCommand
::InitialPass(std::vectorstd::string const args, cmExecutionStatus )
{
- this-Makefile-IssueMessage(
-cmake::AUTHOR_WARNING,
-The \load_command\ command will be removed in CMake 3.0.
-See command documentation for details.);
if(args.size() 1 )
{
return true;
diff --git a/Source/cmLoadCommandCommand.h b/Source/cmLoadCommandCommand.h
index bcd1831..f0b34ee 100644
--- a/Source/cmLoadCommandCommand.h
+++ b/Source/cmLoadCommandCommand.h
@@ -47,7 +47,7 @@ public:
*/
virtual const char* GetTerseDocumentation() const
{
-return Deprecated. Use macro() or function() instead.;
+return Load a command into a running CMake.;
}
/**
@@ -56,13 +56,6 @@ public:
virtual const char* GetFullDocumentation() const
{
return
- This command will be removed in CMake 3.0.
- It works only when the target architecture matches the
- running CMake binary.
- Use macro() or function() to add commands.
- Use execute_process() to run advanced computations
- in external processes.
- \n
load_command(COMMAND_NAME loc1 [loc2 ...])\n
The given locations are searched for a library whose name is
cmCOMMAND_NAME. If found, it is loaded as a module and the command
@@ -74,12 +67,6 @@ public:
Otherwise the variable will not be set.;
}
- /** This command is kept for compatibility with older CMake versions. */
- virtual bool IsDiscouraged() const
-{
-return true;
-}
-
cmTypeMacro(cmLoadCommandCommand, cmCommand);
};
diff --git a/Tests/RunCMake/CMakeLists.txt b/Tests/RunCMake/CMakeLists.txt
index a484983..3ea54f1 100644
--- a/Tests/RunCMake/CMakeLists.txt
+++ b/Tests/RunCMake/CMakeLists.txt
@@ -53,7 +53,6 @@ add_RunCMake_test(build_command)
add_RunCMake_test(find_package)
add_RunCMake_test(include)
add_RunCMake_test(list)
-add_RunCMake_test(load_command)
if(${CMAKE_TEST_GENERATOR} MATCHES Visual Studio [^6])
add_RunCMake_test(include_external_msproject)
diff --git a/Tests/RunCMake/load_command/CMakeLists.txt
b/Tests/RunCMake/load_command/CMakeLists.txt
deleted file mode 100644
index e8db6b0..000
--- a/Tests/RunCMake/load_command/CMakeLists.txt
+++ /dev/null
@@ -1,3 +0,0 @@
-cmake_minimum_required(VERSION 2.8)
-project(${RunCMake_TEST} NONE)
-include(${RunCMake_TEST}.cmake)
diff --git a/Tests/RunCMake/load_command/LoadCommandDeprecated-stderr.txt
b/Tests/RunCMake/load_command/LoadCommandDeprecated-stderr.txt
deleted file mode 100644
index 7d374b2..000
--- a/Tests/RunCMake/load_command/LoadCommandDeprecated-stderr.txt
+++ /dev/null
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1434-gb557ecd
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 b557ecd6000ff5251f9b83f213b2633af9c24156 (commit)
via 57a67bf27efc286fffa883baad86c7d5d51834cc (commit)
from c10992c62541e2ae64f57991aad814ee761a3b9b (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=b557ecd6000ff5251f9b83f213b2633af9c24156
commit b557ecd6000ff5251f9b83f213b2633af9c24156
Merge: c10992c 57a67bf
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Jan 7 14:02:36 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jan 7 14:02:36 2013 -0500
Merge topic 'qt4-target-depends' into next
57a67bf Qt4: Add module dependencies to the IMPORTED targets
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=57a67bf27efc286fffa883baad86c7d5d51834cc
commit 57a67bf27efc286fffa883baad86c7d5d51834cc
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Dec 31 09:41:09 2012 +0100
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Jan 7 14:00:47 2013 -0500
Qt4: Add module dependencies to the IMPORTED targets
This means for example, that consumers can use:
target_link_libraries(foo ${QT_QTGUI_LIBRARIES})
instead of also needing to specify all 'public' dependencies:
target_link_libraries(foo ${QT_QTGUI_LIBRARIES} ${QT_QTCORE_LIBRARIES} )
when using the IMPORTED targets. Also populate the
IMPORTED_LINK_DEPENDENT_LIBRARIES property so CMake can help the linker
find shared library dependencies.
diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake
index ea4d8f4..381141c 100644
--- a/Modules/FindQt4.cmake
+++ b/Modules/FindQt4.cmake
@@ -942,12 +942,36 @@ if (QT_QMAKE_EXECUTABLE AND QTVERSION)
+ macro(_qt4_add_target_depends_internal _QT_MODULE _PROPERTY)
+if (TARGET Qt4::${_QT_MODULE})
+ foreach(_DEPEND ${ARGN})
+if (NOT TARGET Qt4::Qt${_DEPEND})
+ message(FATAL_ERROR _qt4_add_target_depends invoked with invalid
arguments)
+endif()
+set_property(TARGET Qt4::${_QT_MODULE} APPEND PROPERTY
+ ${_PROPERTY}
+ Qt4::Qt${_DEPEND}
+)
+ endforeach()
+endif()
+ endmacro()
+
+ macro(_qt4_add_target_depends _QT_MODULE)
+_qt4_add_target_depends_internal(${_QT_MODULE}
IMPORTED_LINK_INTERFACE_LIBRARIES ${ARGN})
+ endmacro()
+
+ macro(_qt4_add_target_private_depends _QT_MODULE)
+_qt4_add_target_depends_internal(${_QT_MODULE}
IMPORTED_LINK_DEPENDENT_LIBRARIES ${ARGN})
+ endmacro()
+
+
# Set QT_xyz_LIBRARY variable and add
# library include path to QT_INCLUDES
_QT4_ADJUST_LIB_VARS(QtCore)
foreach(QT_MODULE ${QT_MODULES})
_QT4_ADJUST_LIB_VARS(${QT_MODULE})
+_qt4_add_target_depends(${QT_MODULE} Core)
endforeach()
_QT4_ADJUST_LIB_VARS(QtAssistant)
@@ -962,6 +986,37 @@ if (QT_QMAKE_EXECUTABLE AND QTVERSION)
_QT4_ADJUST_LIB_VARS(QAxContainer)
endif()
+ # Only public dependencies are listed here.
+ # Eg, QtDBus links to QtXml, but users of QtDBus do not need to
+ # link to QtXml because QtDBus only uses it internally, not in public
+ # headers.
+ # Everything depends on QtCore, but that is covered above already
+ _qt4_add_target_depends(Qt3Support Sql Gui Network)
+ _qt4_add_target_depends(QtDeclarative Script Gui)
+ _qt4_add_target_depends(QtDesigner Gui)
+ _qt4_add_target_depends(QtHelp Gui)
+ _qt4_add_target_depends(QtMultimedia Gui)
+ _qt4_add_target_depends(QtOpenGL Gui)
+ _qt4_add_target_depends(QtSvg Gui)
+ _qt4_add_target_depends(QtWebKit Gui Network)
+
+ _qt4_add_target_private_depends(Qt3Support Xml)
+ _qt4_add_target_private_depends(QtSvg Xml)
+ _qt4_add_target_private_depends(QtDBus Xml)
+ _qt4_add_target_private_depends(QtUiTools Xml Gui)
+ _qt4_add_target_private_depends(QtHelp Sql Xml Network)
+ _qt4_add_target_private_depends(QtXmlPatterns Network)
+ _qt4_add_target_private_depends(QtScriptTools Gui)
+ _qt4_add_target_private_depends(QtWebKit XmlPatterns)
+ _qt4_add_target_private_depends(QtDeclarative XmlPatterns Svg Sql Gui)
+ _qt4_add_target_private_depends(QtMultimedia Gui)
+ _qt4_add_target_private_depends(QtOpenGL Gui)
+ _qt4_add_target_private_depends(QAxServer Gui)
+ _qt4_add_target_private_depends(QAxContainer Gui)
+ _qt4_add_target_private_depends(phonon Gui)
+ if(QT_QTDBUS_FOUND)
+_qt4_add_target_private_depends(phonon DBus)
+ endif()
###
#
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index f443b5b..924ff38 100644
--- a/Tests/CMakeLists.txt
+++
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1436-g427d2bd
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 427d2bdab9dec5861ffbaecf94266c4374681939 (commit)
via 119bf4bf7f1db2aea6afb64fff471d6994cadf44 (commit)
from b557ecd6000ff5251f9b83f213b2633af9c24156 (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=427d2bdab9dec5861ffbaecf94266c4374681939
commit 427d2bdab9dec5861ffbaecf94266c4374681939
Merge: b557ecd 119bf4b
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Jan 7 14:04:58 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jan 7 14:04:58 2013 -0500
Merge topic 'test-genex-custom-command' into next
119bf4b Add test for custom command with a genex referring to a target.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=119bf4bf7f1db2aea6afb64fff471d6994cadf44
commit 119bf4bf7f1db2aea6afb64fff471d6994cadf44
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Jan 3 19:56:54 2013 +0100
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Jan 7 14:03:51 2013 -0500
Add test for custom command with a genex referring to a target.
This test failed before d8a59ea4 (Port cmGeneratorExpression to
cmTarget from cmGeneratorTarget, 2012-10-27), and passes after.
diff --git a/Tests/IncludeDirectories/TargetIncludeDirectories/CMakeLists.txt
b/Tests/IncludeDirectories/TargetIncludeDirectories/CMakeLists.txt
index 7cb1b42..3044abd 100644
--- a/Tests/IncludeDirectories/TargetIncludeDirectories/CMakeLists.txt
+++ b/Tests/IncludeDirectories/TargetIncludeDirectories/CMakeLists.txt
@@ -45,3 +45,9 @@ set_property(TARGET TargetIncludeDirectories
APPEND PROPERTY INCLUDE_DIRECTORIES
$TARGET_PROPERTY:somelib::withcolons,INTERFACE_INCLUDE_DIRECTORIES
)
+
+add_custom_target(test_custom_target
+some_bogus_custom_tool
+$TARGET_PROPERTY:TargetIncludeDirectories,COMPILE_DEFINITIONS
+WORKING_DIRECTORY
+${CMAKE_CURRENT_SOURCE_DIR})
---
Summary of changes:
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.10.2-1438-g7e9d998
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 7e9d998fe3afad833d1e32d3c0c3a1bc47f086f9 (commit)
via 4b9ec00d0e175ec4cc7e1fbe6ed7d1dcbcfb25ba (commit)
from 427d2bdab9dec5861ffbaecf94266c4374681939 (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=7e9d998fe3afad833d1e32d3c0c3a1bc47f086f9
commit 7e9d998fe3afad833d1e32d3c0c3a1bc47f086f9
Merge: 427d2bd 4b9ec00
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Mon Jan 7 14:06:27 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jan 7 14:06:27 2013 -0500
Merge topic 'qt4-version-openssl' into next
4b9ec00 FindQt4: set QT_VERSION_* variables sooner.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4b9ec00d0e175ec4cc7e1fbe6ed7d1dcbcfb25ba
commit 4b9ec00d0e175ec4cc7e1fbe6ed7d1dcbcfb25ba
Author: Clinton Stimpson clin...@elemtech.com
AuthorDate: Mon Jan 7 11:06:35 2013 -0700
Commit: Clinton Stimpson clin...@elemtech.com
CommitDate: Mon Jan 7 11:06:35 2013 -0700
FindQt4: set QT_VERSION_* variables sooner.
Set QT_VERSION_* variables sooner so they can be set before
Qt4ConfigDependentSettings.cmake uses them.
diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake
index ea4d8f4..84196cc 100644
--- a/Modules/FindQt4.cmake
+++ b/Modules/FindQt4.cmake
@@ -538,6 +538,11 @@ endif ()
if (QT_QMAKE_EXECUTABLE AND QTVERSION)
+ # set version variables
+ string(REGEX REPLACE ^([0-9]+)\\.[0-9]+\\.[0-9]+.* \\1 QT_VERSION_MAJOR
${QTVERSION})
+ string(REGEX REPLACE ^[0-9]+\\.([0-9]+)\\.[0-9]+.* \\1 QT_VERSION_MINOR
${QTVERSION})
+ string(REGEX REPLACE ^[0-9]+\\.[0-9]+\\.([0-9]+).* \\1 QT_VERSION_PATCH
${QTVERSION})
+
# ask qmake for the mkspecs directory
# we do this first because QT_LIBINFIX might be set
if (NOT QT_MKSPECS_DIR OR QT_QMAKE_CHANGED)
@@ -1174,11 +1179,6 @@ if (QT_QMAKE_EXECUTABLE AND QTVERSION)
include(${_qt4_current_dir}/Qt4Macros.cmake)
- # set version variables
- string(REGEX REPLACE ^([0-9]+)\\.[0-9]+\\.[0-9]+.* \\1 QT_VERSION_MAJOR
${QTVERSION})
- string(REGEX REPLACE ^[0-9]+\\.([0-9]+)\\.[0-9]+.* \\1 QT_VERSION_MINOR
${QTVERSION})
- string(REGEX REPLACE ^[0-9]+\\.[0-9]+\\.([0-9]+).* \\1 QT_VERSION_PATCH
${QTVERSION})
-
endif()
#support old QT_MIN_VERSION if set, but not if version is supplied by
find_package()
---
Summary of changes:
Modules/FindQt4.cmake | 10 +-
1 files changed, 5 insertions(+), 5 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.10.2-373-g34f959e
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 34f959e5b11d3acbf352f20137aa17402ceb5f8e (commit) via e767ffcda58ab73cf2c4394202eec7ae1f6035b5 (commit) from 0a097af097fbce43ecda6799db869585366604b7 (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=34f959e5b11d3acbf352f20137aa17402ceb5f8e commit 34f959e5b11d3acbf352f20137aa17402ceb5f8e Merge: 0a097af e767ffc Author: Brad King brad.k...@kitware.com AuthorDate: Mon Jan 7 14:19:47 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Jan 7 14:19:47 2013 -0500 Merge topic 'fix-genex-with-no-target' e767ffc Don't crash when a target is expected but is not available. --- Summary of changes: Source/cmGeneratorExpressionEvaluator.cxx | 15 +++ 1 files changed, 15 insertions(+), 0 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.10.2-379-gb5ab3f0
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 b5ab3f0707cae7affa14423012997503825a867c (commit) via 76c44309717adf25ebe5892adc3b4181766868a9 (commit) from bb68d60571637edf481df8411999d4a399499f36 (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=b5ab3f0707cae7affa14423012997503825a867c commit b5ab3f0707cae7affa14423012997503825a867c Merge: bb68d60 76c4430 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Jan 7 14:20:04 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Jan 7 14:20:04 2013 -0500 Merge topic 'ninja-codeblocks-gui' 76c4430 Ninja: fix building from Codeblocks GUI --- Summary of changes: Source/cmExtraCodeBlocksGenerator.cxx |5 + 1 files changed, 5 insertions(+), 0 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.10.2-1445-gaae64e3
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 aae64e3bd91d3a1760302dd6addf0088d926b04c (commit) via db925e3532719af44022b50d2462ac5b050907bc (commit) via b5ab3f0707cae7affa14423012997503825a867c (commit) via bb68d60571637edf481df8411999d4a399499f36 (commit) via 9cbc637d78a2ee9c30565bc99e616c892934af05 (commit) via 34f959e5b11d3acbf352f20137aa17402ceb5f8e (commit) via 0a097af097fbce43ecda6799db869585366604b7 (commit) from 7e9d998fe3afad833d1e32d3c0c3a1bc47f086f9 (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=aae64e3bd91d3a1760302dd6addf0088d926b04c commit aae64e3bd91d3a1760302dd6addf0088d926b04c Merge: 7e9d998 db925e3 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Jan 7 14:20:55 2013 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Jan 7 14:20:55 2013 -0500 Merge branch 'master' into next --- Summary of changes: 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.10.2-394-gc2cde7f
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 c2cde7f1047b2f11e7d4a466000a20d8c42394be (commit) via cc676c3a08019b17433931a9287d9cd8b0ccf2f2 (commit) via 2dd67c7ea095957d557d2934a67baacdf8a82d7b (commit) via ba58d0c06fd8576844a5722930531a95d00c2003 (commit) from db925e3532719af44022b50d2462ac5b050907bc (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=c2cde7f1047b2f11e7d4a466000a20d8c42394be commit c2cde7f1047b2f11e7d4a466000a20d8c42394be Merge: db925e3 cc676c3 Author: Brad King brad.k...@kitware.com AuthorDate: Mon Jan 7 14:23:04 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Jan 7 14:23:04 2013 -0500 Merge topic 'osx-implicit-link-dirs' cc676c3 OS X: Detect implicit linker framework search paths 2dd67c7 OS X: Detect implicit link directories on modern toolchains ba58d0c OS X: Link with all framework search paths, not just the last --- Summary of changes: Modules/CMakeCCompiler.cmake.in|1 + Modules/CMakeCXXCompiler.cmake.in |1 + Modules/CMakeDetermineCompilerABI.cmake| 25 +++--- Modules/CMakeFortranCompiler.cmake.in |1 + Modules/CMakeParseImplicitLinkInfo.cmake | 51 ++-- Modules/Platform/Darwin-Clang.cmake|1 + Modules/Platform/Darwin-GNU.cmake |1 + Modules/Platform/Darwin.cmake | 18 Source/cmComputeLinkInformation.cxx| 29 ++- Source/cmDocumentVariables.cxx |9 ++ Source/cmLocalGenerator.cxx|2 +- Tests/CMakeTests/ImplicitLinkInfoTest.cmake.in | 108 +++- Tests/SystemInformation/SystemInformation.in |2 + 13 files changed, 220 insertions(+), 29 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.10.2-1447-ge80f247
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 e80f2479d8e61372a87c70c9882d6fa4970386f6 (commit) via c2cde7f1047b2f11e7d4a466000a20d8c42394be (commit) from aae64e3bd91d3a1760302dd6addf0088d926b04c (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=e80f2479d8e61372a87c70c9882d6fa4970386f6 commit e80f2479d8e61372a87c70c9882d6fa4970386f6 Merge: aae64e3 c2cde7f Author: Brad King brad.k...@kitware.com AuthorDate: Mon Jan 7 14:23:19 2013 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Mon Jan 7 14:23:19 2013 -0500 Merge branch 'master' into next --- Summary of changes: 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.10.2-1452-gd491ccc
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 d491ccc926f3fdaf2cef1329cc9bfc77a87568ad (commit)
via 7af053923fa52575709165b01ed674e0588f11e8 (commit)
via 6001e674e0eb1e8de7e26c21cc2683f0967f23d8 (commit)
from dc40de0fc18c30d271bdca360571f59d724f938f (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=d491ccc926f3fdaf2cef1329cc9bfc77a87568ad
commit d491ccc926f3fdaf2cef1329cc9bfc77a87568ad
Merge: dc40de0 7af0539
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Jan 7 15:11:55 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jan 7 15:11:55 2013 -0500
Merge topic 'LINK_LIBRARIES-property' into next
7af0539 Populate the LINK_LIBRARIES property when linking to targets.
6001e67 Add a HEAD-target to target linking API.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7af053923fa52575709165b01ed674e0588f11e8
commit 7af053923fa52575709165b01ed674e0588f11e8
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Dec 6 12:14:03 2012 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Mon Jan 7 21:11:12 2013 +0100
Populate the LINK_LIBRARIES property when linking to targets.
This will be used later to populate the INTERFACE_LINK_LIBRARIES
property when exporting targets, and will later allow use of
generator expressions when linking to libraries with
target_link_libraries.
Also make targets depend on the (config-specific) union of dependencies.
CMake now allows linking to dependencies or not
depending on the config. However, generated buildsystems are not
capable of processing config-specific dependencies, so the targets
depend on the union of dependencies for all configs.
diff --git a/Source/cmComputeTargetDepends.cxx
b/Source/cmComputeTargetDepends.cxx
index c3a75e4..8fd95b9 100644
--- a/Source/cmComputeTargetDepends.cxx
+++ b/Source/cmComputeTargetDepends.cxx
@@ -200,25 +200,51 @@ void cmComputeTargetDepends::CollectTargetDepends(int
depender_index)
// Get the depender.
cmTarget* depender = this-Targets[depender_index];
- // Loop over all targets linked directly.
+ // Loop over all targets linked directly in all configs.
+ // We need to make targets depend on the union of all config-specific
+ // dependencies in all targets, because the generated build-systems can't
+ // deal with config-specific dependencies.
{
- cmTarget::LinkLibraryVectorType const tlibs =
-depender-GetOriginalLinkLibraries();
std::setcmStdString emitted;
+ {
+ std::vectorstd::string tlibs;
+ depender-GetDirectLinkLibraries(0, tlibs, depender);
// A target should not depend on itself.
emitted.insert(depender-GetName());
- for(cmTarget::LinkLibraryVectorType::const_iterator lib = tlibs.begin();
+ for(std::vectorstd::string::const_iterator lib = tlibs.begin();
lib != tlibs.end(); ++lib)
{
// Don't emit the same library twice for this target.
-if(emitted.insert(lib-first).second)
+if(emitted.insert(*lib).second)
{
- this-AddTargetDepend(depender_index, lib-first.c_str(), true);
- this-AddInterfaceDepends(depender_index, lib-first.c_str(),
+ this-AddTargetDepend(depender_index, lib-c_str(), true);
+ this-AddInterfaceDepends(depender_index, lib-c_str(),
true, emitted);
}
}
}
+ std::vectorstd::string configs;
+ depender-GetMakefile()-GetConfigurations(configs);
+ for (std::vectorstd::string::const_iterator it = configs.begin();
+it != configs.end(); ++it)
+{
+std::vectorstd::string tlibs;
+depender-GetDirectLinkLibraries(it-c_str(), tlibs, depender);
+// A target should not depend on itself.
+emitted.insert(depender-GetName());
+for(std::vectorstd::string::const_iterator lib = tlibs.begin();
+lib != tlibs.end(); ++lib)
+ {
+ // Don't emit the same library twice for this target.
+ if(emitted.insert(*lib).second)
+{
+this-AddTargetDepend(depender_index, lib-c_str(), true);
+this-AddInterfaceDepends(depender_index, lib-c_str(),
+ true, emitted);
+}
+ }
+}
+ }
// Loop over all utility dependencies.
{
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 1338ec4..25054c5 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -520,6 +520,22 @@ void cmTarget::DefineProperties(cmake *cm)
undefined behavior.);
cm-DefineProperty
+(LINK_LIBRARIES, cmProperty::TARGET,
+ List of direct link dependencies.,
+
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1456-gd98f561
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 d98f561003af82e31ccae2fa324441c18b5b5c33 (commit)
via 3d2e6a06874603ebe6152045c34de9147a0c11dc (commit)
via 7a1b961de8b79416d168355e71f5af80fa4dbd02 (commit)
via ed96d9a605471694465dd7142dd25748dfdf3a90 (commit)
from d491ccc926f3fdaf2cef1329cc9bfc77a87568ad (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=d98f561003af82e31ccae2fa324441c18b5b5c33
commit d98f561003af82e31ccae2fa324441c18b5b5c33
Merge: d491ccc 3d2e6a0
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Mon Jan 7 15:54:53 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jan 7 15:54:53 2013 -0500
Merge topic 'Haiku' into next
3d2e6a0 check for Haiku only with __HAIKU__
7a1b961 Haiku no longer defines __BEOS__
ed96d9a bootstrap: use better defaults for Haiku
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3d2e6a06874603ebe6152045c34de9147a0c11dc
commit 3d2e6a06874603ebe6152045c34de9147a0c11dc
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Mon Jan 7 21:52:45 2013 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Mon Jan 7 21:52:45 2013 +0100
check for Haiku only with __HAIKU__
diff --git a/Modules/CMakeFortranCompilerId.F.in
b/Modules/CMakeFortranCompilerId.F.in
index 4d25de0..f84852a 100644
--- a/Modules/CMakeFortranCompilerId.F.in
+++ b/Modules/CMakeFortranCompilerId.F.in
@@ -74,12 +74,8 @@
PRINT *, 'INFO:platform[IRIX]'
#elif defined(__hpux) || defined(__hpux__)
PRINT *, 'INFO:platform[HP-UX]'
-#elif defined(__HAIKU) || defined(__HAIKU__) || defined(_HAIKU)
+#elif defined(__HAIKU__)
PRINT *, 'INFO:platform[Haiku]'
-# if 0
-! Haiku also defines __BEOS__ so we must
-! put it prior to the check for __BEOS__
-# endif
#elif defined(__BeOS) || defined(__BEOS__) || defined(_BEOS)
PRINT *, 'INFO:platform[BeOS]'
#elif defined(__QNX__) || defined(__QNXNTO__)
diff --git a/Modules/CMakePlatformId.h.in b/Modules/CMakePlatformId.h.in
index c373414..69171c2 100644
--- a/Modules/CMakePlatformId.h.in
+++ b/Modules/CMakePlatformId.h.in
@@ -35,11 +35,8 @@
#elif defined(__hpux) || defined(__hpux__)
# define PLATFORM_ID HP-UX
-#elif defined(__HAIKU) || defined(__HAIKU__) || defined(_HAIKU)
+#elif defined(__HAIKU__)
# define PLATFORM_ID Haiku
-/* Haiku also defines __BEOS__ so we must
- put it prior to the check for __BEOS__
-*/
#elif defined(__BeOS) || defined(__BEOS__) || defined(_BEOS)
# define PLATFORM_ID BeOS
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7a1b961de8b79416d168355e71f5af80fa4dbd02
commit 7a1b961de8b79416d168355e71f5af80fa4dbd02
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Mon Jan 7 21:20:11 2013 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Mon Jan 7 21:20:11 2013 +0100
Haiku no longer defines __BEOS__
diff --git a/Modules/CheckForPthreads.c b/Modules/CheckForPthreads.c
index 882dc21..7250fbf 100644
--- a/Modules/CheckForPthreads.c
+++ b/Modules/CheckForPthreads.c
@@ -16,7 +16,7 @@ int main(int ac, char*av[]){
pthread_create(tid[0], 0, runner, (void*)1);
pthread_create(tid[1], 0, runner, (void*)2);
-#if defined(__BEOS__) !defined(__ZETA__) !defined(__HAIKU__) // (no
usleep on BeOS 5.)
+#if defined(__BEOS__) !defined(__ZETA__) // (no usleep on BeOS 5.)
usleep(1); // for strange behavior on single-processor sun
#endif
diff --git a/Source/CPack/cmCPackGeneratorFactory.cxx
b/Source/CPack/cmCPackGeneratorFactory.cxx
index 5577673..b36c2a2 100644
--- a/Source/CPack/cmCPackGeneratorFactory.cxx
+++ b/Source/CPack/cmCPackGeneratorFactory.cxx
@@ -33,7 +33,7 @@
#endif
#if !defined(_WIN32) \
- !defined(__QNXNTO__) !defined(__BEOS__)
+ !defined(__QNXNTO__) !defined(__BEOS__) !defined(__HAIKU__)
# include cmCPackDebGenerator.h
# include cmCPackRPMGenerator.h
#endif
@@ -126,7 +126,7 @@ cmCPackGeneratorFactory::cmCPackGeneratorFactory()
}
#endif
#if !defined(_WIN32) \
- !defined(__QNXNTO__) !defined(__BEOS__)
+ !defined(__QNXNTO__) !defined(__BEOS__) !defined(__HAIKU__)
if (cmCPackDebGenerator::CanGenerate())
{
this-RegisterGenerator(DEB, Debian packages,
diff --git a/Source/cmCTest.cxx b/Source/cmCTest.cxx
index bb6f3f2..322a6a2 100644
--- a/Source/cmCTest.cxx
+++ b/Source/cmCTest.cxx
@@ -53,7 +53,7 @@
#include cm_zlib.h
#include cmsys/Base64.h
-#if defined(__BEOS__) !defined(__HAIKU__)
+#if defined(__BEOS__)
#include be/kernel/OS.h /* disable_debugger() API. */
#endif
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1458-g6e8d3f0
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 6e8d3f0bc6678e22361ab2b7a0e06b7d72ef0f19 (commit)
via fb86730a095d2f2d5bc69b4feac562d918e33734 (commit)
from d98f561003af82e31ccae2fa324441c18b5b5c33 (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=6e8d3f0bc6678e22361ab2b7a0e06b7d72ef0f19
commit 6e8d3f0bc6678e22361ab2b7a0e06b7d72ef0f19
Merge: d98f561 fb86730
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Jan 7 16:49:44 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jan 7 16:49:44 2013 -0500
Merge topic 'qt4-target-depends' into next
fb86730 Add INTERFACE includes and defines to the Qt 4 targets.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fb86730a095d2f2d5bc69b4feac562d918e33734
commit fb86730a095d2f2d5bc69b4feac562d918e33734
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Dec 31 00:55:38 2012 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Mon Jan 7 22:48:45 2013 +0100
Add INTERFACE includes and defines to the Qt 4 targets.
diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake
index 381141c..73431f8 100644
--- a/Modules/FindQt4.cmake
+++ b/Modules/FindQt4.cmake
@@ -418,6 +418,15 @@ macro (_QT4_ADJUST_LIB_VARS _camelCaseBasename)
set_property(TARGET Qt4::${_camelCaseBasename}PROPERTY
IMPORTED_LOCATION_DEBUG ${QT_${basename}_LIBRARY_DEBUG} )
endif()
endif ()
+ set_property(TARGET Qt4::${_camelCaseBasename} PROPERTY
+INTERFACE_INCLUDE_DIRECTORIES
+ ${QT_HEADERS_DIR}/${_camelCaseBasename}
+ )
+ string(REGEX REPLACE ^QT _stemname ${basename})
+ set_property(TARGET Qt4::${_camelCaseBasename} PROPERTY
+INTERFACE_COMPILE_DEFINITIONS
+ QT_${_stemname}_LIB
+ )
endif()
# If QT_USE_IMPORTED_TARGETS is enabled, the QT_QTFOO_LIBRARY variables
are set to point at these
@@ -952,6 +961,14 @@ if (QT_QMAKE_EXECUTABLE AND QTVERSION)
${_PROPERTY}
Qt4::Qt${_DEPEND}
)
+set_property(TARGET Qt4::${_QT_MODULE} APPEND PROPERTY
+ INTERFACE_INCLUDE_DIRECTORIES
+
$TARGET_PROPERTY:Qt4::Qt${_DEPEND},INTERFACE_INCLUDE_DIRECTORIES
+)
+set_property(TARGET Qt4::${_QT_MODULE} APPEND PROPERTY
+ INTERFACE_COMPILE_DEFINITIONS
+
$TARGET_PROPERTY:Qt4::Qt${_DEPEND},INTERFACE_COMPILE_DEFINITIONS
+)
endforeach()
endif()
endmacro()
@@ -968,6 +985,11 @@ if (QT_QMAKE_EXECUTABLE AND QTVERSION)
# Set QT_xyz_LIBRARY variable and add
# library include path to QT_INCLUDES
_QT4_ADJUST_LIB_VARS(QtCore)
+ set_property(TARGET Qt4::QtCore APPEND PROPERTY
+INTERFACE_INCLUDE_DIRECTORIES
+ ${QT_MKSPECS_DIR}/default
+ ${QT_HEADERS_DIR}
+ )
foreach(QT_MODULE ${QT_MODULES})
_QT4_ADJUST_LIB_VARS(${QT_MODULE})
@@ -992,6 +1014,10 @@ if (QT_QMAKE_EXECUTABLE AND QTVERSION)
# headers.
# Everything depends on QtCore, but that is covered above already
_qt4_add_target_depends(Qt3Support Sql Gui Network)
+ if (TARGET Qt4::Qt3Support)
+# An additional define is required for QT3_SUPPORT
+set_property(TARGET Qt4::Qt3Support APPEND PROPERTY
INTERFACE_COMPILE_DEFINITIONS QT3_SUPPORT)
+ endif()
_qt4_add_target_depends(QtDeclarative Script Gui)
_qt4_add_target_depends(QtDesigner Gui)
_qt4_add_target_depends(QtHelp Gui)
diff --git a/Tests/Qt4Targets/CMakeLists.txt b/Tests/Qt4Targets/CMakeLists.txt
index 3adff48..9bd7a64 100644
--- a/Tests/Qt4Targets/CMakeLists.txt
+++ b/Tests/Qt4Targets/CMakeLists.txt
@@ -4,11 +4,18 @@ project(Qt4Targets)
find_package(Qt4 REQUIRED)
-include_directories(${QT_INCLUDES})
-
add_executable(Qt4Targets WIN32 main.cpp)
target_link_libraries(Qt4Targets Qt4::QtGui)
if (WIN32)
target_link_libraries(Qt4Targets Qt4::qtmain)
endif()
+
+set_property(TARGET Qt4Targets APPEND PROPERTY
+ INCLUDE_DIRECTORIES
+$TARGET_PROPERTY:Qt4::QtGui,INTERFACE_INCLUDE_DIRECTORIES
+)
+set_property(TARGET Qt4Targets APPEND PROPERTY
+ COMPILE_DEFINITIONS
+$TARGET_PROPERTY:Qt4::QtGui,INTERFACE_COMPILE_DEFINITIONS
+)
diff --git a/Tests/Qt4Targets/main.cpp b/Tests/Qt4Targets/main.cpp
index f4890fa..3c98c99 100644
--- a/Tests/Qt4Targets/main.cpp
+++ b/Tests/Qt4Targets/main.cpp
@@ -4,6 +4,14 @@
#include QString
+#ifndef QT_CORE_LIB
+#error Expected QT_CORE_LIB
+#endif
+
+#ifndef QT_GUI_LIB
+#error Expected QT_GUI_LIB
+#endif
+
int main(int argc, char **argv)
{
QApplication app(argc, argv);
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1460-g2c7d884
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 2c7d8849db2025dfd189f16771d8c6c5ff043cfc (commit)
via d6ca57bd0e200e2f86166b076a87a8910aaea6a5 (commit)
from 6e8d3f0bc6678e22361ab2b7a0e06b7d72ef0f19 (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=2c7d8849db2025dfd189f16771d8c6c5ff043cfc
commit 2c7d8849db2025dfd189f16771d8c6c5ff043cfc
Merge: 6e8d3f0 d6ca57b
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Jan 7 16:55:15 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jan 7 16:55:15 2013 -0500
Merge topic 'include-dirs-convenience' into next
d6ca57b Add CMAKE_BUILD_INTERFACE_INCLUDES build-variable.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d6ca57bd0e200e2f86166b076a87a8910aaea6a5
commit d6ca57bd0e200e2f86166b076a87a8910aaea6a5
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Sun Nov 25 01:15:44 2012 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Mon Jan 7 22:54:15 2013 +0100
Add CMAKE_BUILD_INTERFACE_INCLUDES build-variable.
This makes
set(CMAKE_BUILD_INTERFACE_INCLUDES ON)
add the equivalent of
set_property(TARGET tgt APPEND PROPERTY
INTERFACE_INCLUDE_DIRECTORIES
$BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR};${CMAKE_CURRENT_BINARY_DIR}
)
to every target.
If the headers are in CMAKE_CURRENT_SOURCE_DIR, and the generated headers
are in CMAKE_CURRENT_BINARY_DIR, this is a convenient way to build a target
bar, which depends on foo, just by using target_link_libraries() and adding
the INTERFACE_INCLUDE_DIRECTORIES to the INCLUDE_DIRECTORIES of the target
being linked. There will be more-convenient porcelain API to consume the
property in the future.
diff --git a/Source/cmDocumentVariables.cxx b/Source/cmDocumentVariables.cxx
index be45e2d..08b3ef1 100644
--- a/Source/cmDocumentVariables.cxx
+++ b/Source/cmDocumentVariables.cxx
@@ -1147,6 +1147,17 @@ void cmDocumentVariables::DefineVariables(cmake* cm)
Variables that Control the Build);
cm-DefineProperty
+(CMAKE_BUILD_INTERFACE_INCLUDES, cmProperty::VARIABLE,
+ Automatically add the current source- and build directories
+ to the INTERFACE_INCLUDE_DIRECTORIES.,
+ If this variable is enabled, CMake automatically adds for each
+ target ${CMAKE_CURRENT_SOURCE_DIR} and ${CMAKE_CURRENT_BINARY_DIR}
+ to the INTERFACE_INCLUDE_DIRECTORIES.
+ By default CMAKE_BUILD_INTERFACE_INCLUDES is OFF.,
+ false,
+ Variables that Control the Build);
+
+ cm-DefineProperty
(CMAKE_INSTALL_RPATH, cmProperty::VARIABLE,
The rpath to use for installed targets.,
A semicolon-separated list specifying the rpath
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index 0f439e9..d030aa7 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -938,6 +938,23 @@ void cmGlobalGenerator::Generate()
(*targets)[tit-first] = tit-second;
(*targets)[tit-first].SetMakefile(mf);
}
+
+for ( tit = targets-begin(); tit != targets-end(); ++ tit )
+ {
+ if (mf-IsOn(CMAKE_BUILD_INTERFACE_INCLUDES))
+{
+const char *binDir = mf-GetStartOutputDirectory();
+const char *srcDir = mf-GetStartDirectory();
+const std::string dirs = std::string(binDir ? binDir : )
++ std::string(binDir ? ; : )
++ std::string(srcDir ? srcDir : );
+if (!dirs.empty())
+ {
+ tit-second.AppendProperty(INTERFACE_INCLUDE_DIRECTORIES,
+($BUILD_INTERFACE: + dirs + ).c_str());
+ }
+}
+ }
}
// Add generator specific helper commands
diff --git a/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt
b/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt
index 60b36fc..29b69d9 100644
--- a/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt
+++ b/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt
@@ -53,6 +53,13 @@ set_target_properties(targetA PROPERTIES
LINK_INTERFACE_LIBRARIES )
assert_property(targetA LINK_INTERFACE_LIBRARIES )
+add_subdirectory(subdir)
+target_link_libraries(targetA subdirlib)
+set_property(TARGET targetA APPEND PROPERTY
+ INCLUDE_DIRECTORIES
+$TARGET_PROPERTY:subdirlib,INTERFACE_INCLUDE_DIRECTORIES
+)
+
target_link_libraries(targetA depB depC)
assert_property(targetA LINK_INTERFACE_LIBRARIES )
diff --git a/Tests/CMakeCommands/target_link_libraries/subdir/CMakeLists.txt
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1464-g7e91a0f
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 7e91a0f4baa905b8d8c635616bb8d89d18ee23c1 (commit)
via 0380f36cd8dbdf7a89f8fac91d99235e75075bde (commit)
via 8e9630c719f59f69f813e3eb4a4f91ba2396b4ef (commit)
via 50bfedf391a078e628bf1259f819da42dea1cde0 (commit)
from 2c7d8849db2025dfd189f16771d8c6c5ff043cfc (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=7e91a0f4baa905b8d8c635616bb8d89d18ee23c1
commit 7e91a0f4baa905b8d8c635616bb8d89d18ee23c1
Merge: 2c7d884 0380f36
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Mon Jan 7 18:42:58 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jan 7 18:42:58 2013 -0500
Merge topic 'Haiku' into next
0380f36 FindOpenGL: add Haiku paths
8e9630c FindGLUT: BeOS does not have libXi and libXmu
50bfedf FindLua51: do not try to link libm on BeOS
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0380f36cd8dbdf7a89f8fac91d99235e75075bde
commit 0380f36cd8dbdf7a89f8fac91d99235e75075bde
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Tue Jan 8 00:38:08 2013 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Tue Jan 8 00:39:53 2013 +0100
FindOpenGL: add Haiku paths
Also check the HP-UX specific paths only when on HP-UX.
diff --git a/Modules/FindOpenGL.cmake b/Modules/FindOpenGL.cmake
index 4a393f2..96c4d8d 100644
--- a/Modules/FindOpenGL.cmake
+++ b/Modules/FindOpenGL.cmake
@@ -58,14 +58,22 @@ else ()
find_path(OPENGL_INCLUDE_DIR OpenGL/gl.h DOC Include for OpenGL on OSX)
else()
-# Handle HP-UX cases where we only want to find OpenGL in either hpux64
-# or hpux32 depending on if we're doing a 64 bit build.
-if(CMAKE_SIZEOF_VOID_P EQUAL 4)
- set(HPUX_IA_OPENGL_LIB_PATH /opt/graphics/OpenGL/lib/hpux32/)
-else()
- set(HPUX_IA_OPENGL_LIB_PATH
-/opt/graphics/OpenGL/lib/hpux64/
-/opt/graphics/OpenGL/lib/pa20_64)
+if (CMAKE_SYSTEM_NAME MATCHES HP-UX)
+ # Handle HP-UX cases where we only want to find OpenGL in either hpux64
+ # or hpux32 depending on if we're doing a 64 bit build.
+ if(CMAKE_SIZEOF_VOID_P EQUAL 4)
+set(_OPENGL_LIB_PATH
+ /opt/graphics/OpenGL/lib/hpux32/)
+ else()
+set(_OPENGL_LIB_PATH
+ /opt/graphics/OpenGL/lib/hpux64/
+ /opt/graphics/OpenGL/lib/pa20_64)
+ endif()
+elseif(CMAKE_SYSTEM_NAME STREQUAL Haiku)
+ set(_OPENGL_LIB_PATH
+/boot/develop/lib/x86)
+ set(_OPENGL_INCLUDE_PATH
+/boot/develop/headers/os/opengl)
endif()
# The first line below is to make sure that the proper headers
@@ -80,6 +88,7 @@ else ()
/usr/share/doc/NVIDIA_GLX-1.0/include
/usr/openwin/share/include
/opt/graphics/OpenGL/include /usr/X11R6/include
+ ${_OPENGL_INCLUDE_PATH}
)
find_path(OPENGL_xmesa_INCLUDE_DIR GL/xmesa.h
@@ -93,9 +102,12 @@ else ()
PATHS /opt/graphics/OpenGL/lib
/usr/openwin/lib
/usr/shlib /usr/X11R6/lib
-${HPUX_IA_OPENGL_LIB_PATH}
+${_OPENGL_LIB_PATH}
)
+unset(_OPENGL_INCLUDE_PATH)
+unset(_OPENGL_LIB_PATH)
+
# On Unix OpenGL most certainly always requires X11.
# Feel free to tighten up these conditions if you don't
# think this is always true.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8e9630c719f59f69f813e3eb4a4f91ba2396b4ef
commit 8e9630c719f59f69f813e3eb4a4f91ba2396b4ef
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Mon Jan 7 23:57:07 2013 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Mon Jan 7 23:57:07 2013 +0100
FindGLUT: BeOS does not have libXi and libXmu
diff --git a/Modules/FindGLUT.cmake b/Modules/FindGLUT.cmake
index 55790ae..843d138 100644
--- a/Modules/FindGLUT.cmake
+++ b/Modules/FindGLUT.cmake
@@ -40,25 +40,39 @@ else ()
set(GLUT_cocoa_LIBRARY -framework Cocoa CACHE STRING Cocoa framework
for OSX)
else ()
+if (BEOS)
+
+ set(_GLUT_INC_DIR /boot/develop/headers/os/opengl)
+ set(_GLUT_glut_LIB_DIR /boot/develop/lib/x86)
+
+else()
+
+ find_library( GLUT_Xi_LIBRARY Xi
+/usr/openwin/lib
+)
+
+ find_library( GLUT_Xmu_LIBRARY Xmu
+/usr/openwin/lib
+)
+
+endif ()
+
find_path( GLUT_INCLUDE_DIR GL/glut.h
/usr/include/GL
/usr/openwin/share/include
/usr/openwin/include
/opt/graphics/OpenGL/include
/opt/graphics/OpenGL/contrib/libglut
+ ${_GLUT_INC_DIR}
)
find_library( GLUT_glut_LIBRARY glut
/usr/openwin/lib
+
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1466-g1a489e5
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 1a489e5c088e31b33b506b4c941b0f45f91ef161 (commit)
via b14ba08fdcfcb22c0392e7166bcfb41f7fe6f357 (commit)
from 7e91a0f4baa905b8d8c635616bb8d89d18ee23c1 (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=1a489e5c088e31b33b506b4c941b0f45f91ef161
commit 1a489e5c088e31b33b506b4c941b0f45f91ef161
Merge: 7e91a0f b14ba08
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Jan 7 19:03:16 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Jan 7 19:03:16 2013 -0500
Merge topic 'include-dirs-convenience' into next
b14ba08 Add missing EXPORT macro.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b14ba08fdcfcb22c0392e7166bcfb41f7fe6f357
commit b14ba08fdcfcb22c0392e7166bcfb41f7fe6f357
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Jan 8 01:02:32 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Tue Jan 8 01:02:32 2013 +0100
Add missing EXPORT macro.
Hopefully fix Windows build.
diff --git a/Tests/CMakeCommands/target_link_libraries/subdir/subdirlib.h
b/Tests/CMakeCommands/target_link_libraries/subdir/subdirlib.h
index d9eaf65..e386f87 100644
--- a/Tests/CMakeCommands/target_link_libraries/subdir/subdirlib.h
+++ b/Tests/CMakeCommands/target_link_libraries/subdir/subdirlib.h
@@ -4,7 +4,7 @@
#include subdirlib_export.h
-struct SubDirLibObject
+struct SUBDIRLIB_EXPORT SubDirLibObject
{
int foo() const;
};
---
Summary of changes:
.../target_link_libraries/subdir/subdirlib.h |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.10.2-395-g97758f2
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 97758f29206a172524edd144e588558bb4a83700 (commit) from c2cde7f1047b2f11e7d4a466000a20d8c42394be (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=97758f29206a172524edd144e588558bb4a83700 commit 97758f29206a172524edd144e588558bb4a83700 Author: Kitware Robot kwro...@kitware.com AuthorDate: Tue Jan 8 00:01:19 2013 -0500 Commit: Kitware Robot kwro...@kitware.com CommitDate: Tue Jan 8 00:01:19 2013 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index a18fcf0..528fa13 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 10) -set(CMake_VERSION_TWEAK 20130107) +set(CMake_VERSION_TWEAK 20130108) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.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
