Re: [cmake-developers] CMake is slow for project with hundred target and one command with large number of dependencies
On Sat, Jul 13, 2013 at 10:21 AM, Nicolas Desprès nicolas.desp...@gmail.com
wrote:
On Fri, Jul 12, 2013 at 11:35 PM, Stephen Kelly steve...@gmail.comwrote:
Nicolas Desprès wrote:
I have pushed my work so far on my github clone of CMake.
https://github.com/nicolasdespres/CMake/tree/topic/large-deps-perf
Something must have gone wrong with the push :)
Oups, sorry :(. Friday evening after a long hard week...
This is now fixed. The patch is 3ac529b4a568dbd78d7ccd9b0ec1443efd75f6ae
stephen@hal:~/dev/src/cmake{master}$ git show origin/master | grep
commit
commit b9412889e9c5028e32ef3b978d8cdd1175f14b0f
stephen@hal:~/dev/src/cmake{master}$ git show nicolasdespres/topic/large-
deps-perf | grep commit
commit b9412889e9c5028e32ef3b978d8cdd1175f14b0f
I noticed a lot of obsolete branches in your clone. I noticed a lot of
branches, but mostly it looks like ninja stuff that's already been merged.
Is there anything else interesting there?
Yes I have many old branches I should get rid of. There is only the
topic/large-deps-perf branch interesting at the moment. I pushed one commit
on it containing the test I mentioned above. All that work is on my
computer at the office so I could only fix the push on monday morning.
Sorry again.
I also cleaned that up a bit.
Have a good day,
--
Nicolas Desprès
--
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] CMake is slow for project with hundred target and one command with large number of dependencies
Nicolas Desprès wrote: I have pushed my work so far on my github clone of CMake. https://github.com/nicolasdespres/CMake/tree/topic/large-deps-perf Thanks. The bottleneck seems to be in cmTargetTraceDependencies::FollowName as it follows each entry in the LARGE_LIST for each of the 100 targets. I also cleaned that up a bit. At least ninja_convenience_targets seems to be obsolete too? I didn't check the others. Just looking through my 'git branch -a' output :). 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] CMake is slow for project with hundred target and one command with large number of dependencies
On Mon, Jul 15, 2013 at 11:53 AM, Stephen Kelly steve...@gmail.com wrote: Nicolas Desprès wrote: I have pushed my work so far on my github clone of CMake. https://github.com/nicolasdespres/CMake/tree/topic/large-deps-perf Thanks. The bottleneck seems to be in cmTargetTraceDependencies::FollowName as it follows each entry in the LARGE_LIST for each of the 100 targets. Yes that one or cmMakefile::GetSourceFileWithOutput(char const*). I can send you a gzipped of my callgrind data off-list if you want (it weights 534K). I also cleaned that up a bit. At least ninja_convenience_targets seems to be obsolete too? I didn't check the others. Just looking through my 'git branch -a' output :). That's right. I have deleted it. Thanks, Nico -- 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] CMake is slow for project with hundred target and one command with large number of dependencies
On Mon, Jul 15, 2013 at 12:45 PM, Nicolas Desprès nicolas.desp...@gmail.com wrote: On Mon, Jul 15, 2013 at 11:53 AM, Stephen Kelly steve...@gmail.comwrote: Nicolas Desprès wrote: I have pushed my work so far on my github clone of CMake. https://github.com/nicolasdespres/CMake/tree/topic/large-deps-perf Thanks. The bottleneck seems to be in cmTargetTraceDependencies::FollowName as it follows each entry in the LARGE_LIST for each of the 100 targets. Yes that one or cmMakefile::GetSourceFileWithOutput(char const*). I can send you a gzipped of my callgrind data off-list if you want (it weights 534K). If we had a map associating each input to output, we could maybe have better performance. WDYT? I also cleaned that up a bit. At least ninja_convenience_targets seems to be obsolete too? I didn't check the others. Just looking through my 'git branch -a' output :). That's right. I have deleted it. Thanks, Nico -- Nicolas Desprès -- 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] CMake is slow for project with hundred target and one command with large number of dependencies
Nicolas Desprès wrote: Yes that one or cmMakefile::GetSourceFileWithOutput(char const*). I can send you a gzipped of my callgrind data off-list if you want (it weights 534K). If we had a map associating each input to output, we could maybe have better performance. WDYT? Perhaps. I can probably create the same callgrind data locally anyway, but I won't have a change until later to dig into this. On looking at the cmMakefile::GetSourceFileWithOutput code though, it seems that it might also be useful to maintain this-SourceFiles and (*i)-GetCustomCommand()-GetOutputs() as sorted vectors. They are rarely modified, so the O(1) - O(log N) inserts probably won't matter much, but the O(N) - O(log N) might provide a useful gain. Or, as most access is at generate time, keep the O(1) insertions, sort() after the configure step, and then use the binary search at generate time. Of course, I don't know if there are also configure-time accesses which would be difficult to isolate from the generate-time ones. Does that make any sense? 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] Working towards Windows Phone 8 support
On 07/12/2013 07:58 AM, Paul Annetts wrote: I'm interested in contributing towards Windows Phone 8 support in CMAKE, i.e. http://public.kitware.com/Bug/view.php?id=13791 Thanks for working on this. Consider drawing attention to your work by posting in the issue tracker too. I haven't personally worked on any wp80 development so it will be helpful to recruit others to help review the work. new Visual Studio 11 Windows Phone 8 generator Our convention is to have no spaces in the name of the architecture, so a name like Visual Studio 11 WP8 will be better. Some projects use regular expressions to parse the generator name so we should stick to that convention. 1. Targets the Windows Phone 8 platform toolset (v110_wp80). See the CMAKE_GENERATOR_TOOLSET feature added in 2.8.11 along with the -T command-line option to set it. 2. Has content that allows MSBUILD/Visual Studio to build a .lib target for either Win32 (x86 emulator) and ARM (devices) platforms. Do you mean multiple architectures in one vcxproj file? How should I go about getting my work reviewed at an early stage? If the patch series is relatively small you can just use git format-patch and post the patches to this list. Alternatively, if the topic is large, we publish mirrors of the Git repo: https://github.com/Kitware/CMake http://gitorious.org/cmake/cmake If you have an account on one of those you can fork/clone the project there, publish your topic to your own account, and then post a link here. -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] Why does this work - linking against a library before it has been defined ?
On 07/11/2013 03:52 PM, Alexander Neundorf wrote:
target_link_libraries(kf5-config ${KDE4_KDECORE_LIBS} kde4support)
add_subdirectory(lib)
The thing is, the library kde4support is built inside the lib
subdirectory, which is added after using kde4support in
target_link_libraries().
I think in previous version of cmake the kde4support in the tll() call
would
have been recognized as the name of a library and added to the link command
using -lkde4support.
Now it seems to be recognized as the name of a target.
This has always been the case. Link analysis has always
been done at generate time.
-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] CMAKE_SYSROOT vs CMAKE_OSX_SYSROOT
On 07/12/2013 09:47 AM, Stephen Kelly wrote: Brad King wrote: On 07/11/2013 11:08 AM, Brad King wrote: Can anyone else think of complications? Side note: If we cannot resolve this soon we should revert CMAKE_SYSROOT before 2.8.12 to leave room for the two to be combined later. I've reverted it now. I've also removed the replace-CMAKE_SYSROOT_FLAG branch from next, and squashed it into the re-commit of the initial feature and pushed the result to my clone as add-CMAKE_SYSROOT. Okay, thanks. Please bring this up again after 2.8.12. -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] CMAKE_INSTALL_PREFIX vs CMAKE_SYSROOT ?
On 07/14/2013 10:13 AM, Samuel Martin wrote: I'd like to give a point of view of a user. Great, thanks for your input. To stick back to this thread, I have not used the CMAKE_SYSROOT variable yet. But imho, it should only affect the compiler flags, not the install rules because the given sysroot may be read-only for whatever reason. Yes, I agree. FYI for now we've reverted CMAKE_SYSROOT so we can re-introduce it later properly integrated with CMAKE_OSX_SYSROOT. IMHO, the only install locations that matter are the staging area and the target one, which should be defined by the combination of the DESTDIR and CMAKE_INSTALL_PREFIX variables. If someone wants to install somewhere else for development purpose (say, nfs or chroot), then he/she can rerun the install phase with a new DESTDIR. The simplicity of this does make sense. On 07/04/2013 04:29 AM, Stephen Kelly wrote: Goals: * Install to /opt/kf5 on the target * Install to $HOME/dev/kf5 on the host Steve, why do we need to have the host location not end in the target's install prefix? 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] CMAKE_INSTALL_PREFIX vs CMAKE_SYSROOT ?
Brad King wrote: On 07/04/2013 04:29 AM, Stephen Kelly wrote: Goals: * Install to /opt/kf5 on the target * Install to $HOME/dev/kf5 on the host Steve, why do we need to have the host location not end in the target's install prefix? For me, it's because I install things to the same $HOME/dev prefix on my dev machine, and my bash aliases and functions assume that. If I cd to $HOME/kf5 I know I'll find the include/ and lib/ dirs right there. I'd want to cd to $HOME/kf5-rpi and have the include/ and lib/ dirs right there too for my raspberry pi builds instead of having $HOME/kf5-rpi/opt/kf5/lib. That's the first reason I think of at least. The opt/kf5/ part might also be a more inconvenient location, different depending on the platform/device I'm building for etc. Not having that gives me uniformity. 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
[cmake-developers] install-interface-includes topic
Steve, From the documentation of the feature: + The INCLUDES DESTINATION specifies a list of directories which will + be added to the INTERFACE_INCLUDE_DIRECTORIES of the targets when + exported by install(EXPORT). If a relative path is specified, it is + treated as relative to the $INSTALL_PREFIX. Should the INCLUDES DESTINATION option produce an error if it is used without the EXPORT option? Also, note there are two trailing spaces at the end of the paragraph. -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] [CMake 0014291]: add_custom_command() DEPENDS does not work with the Xcode generator
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14291
==
Reported By:Paul Smith
Assigned To:
==
Project:CMake
Issue ID: 14291
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2013-07-15 10:43 EDT
Last Modified: 2013-07-15 10:43 EDT
==
Summary:add_custom_command() DEPENDS does not work with the
Xcode generator
Description:
I have a set of rules I'm using to copy (stage) some files after they're
built. I do not want to use install rules for this for various reasons. The
statements I'm using work great with the Makefile generator and the Visual
Studio generator, but the build fails with the Xcode generator.
Xcode tries to run the stage rule before it builds the target to be staged,
even though the stage rule has a DEPENDS statement on the target. The build
fails because the target does not exist:
$ xcodebuild build -configuration RelWithDebInfo
...
=== BUILD NATIVE TARGET myapp OF PROJECT TestApp WITH CONFIGURATION
RelWithDebInfo ===
Check dependencies
PhaseScriptExecution CMake Rules
TestApp.build/RelWithDebInfo/myapp.build/Script-2C3540A800314C1082C9261D.sh
cd /Users/build/pds/xcode-test
/bin/sh -c
/Users/paul/xcode-test/TestApp.build/RelWithDebInfo/myapp.build/Script-2C3540A800314C1082C9261D.sh
make: *** No rule to make target
`/Users/paul/xcode-test/RelWithDebInfo/myapp', needed by
`/Users/paul/xcode-test/dist/bin/myapp'. Stop.
Command /bin/sh failed with exit code 2
** BUILD FAILED **
The following build commands failed:
PhaseScriptExecution CMake Rules
TestApp.build/RelWithDebInfo/myapp.build/Script-2C3540A800314C1082C9261D.sh
(1 failure)
Steps to Reproduce:
Create a simple C file:
cd ~
mkdir xcode-test
cd xcode-test
cat myapp.c EOF
#include stdio.h
int main()
{
printf(Hello world!\n);
return 0;
}
EOF
Then create a simple CMake file:
cat CMakeLists.txt EOF
cmake_minimum_required(VERSION 2.8)
project(TestApp C)
add_executable(myapp myapp.c)
set(MYPREFIX ${TestApp_SOURCE_DIR}/dist CACHE PATH install prefix FORCE)
add_custom_command(OUTPUT ${MYPREFIX}/bin/myapp
COMMAND ${CMAKE_COMMAND} -E make_directory ${MYPREFIX}/bin
COMMAND ${CMAKE_COMMAND} -E copy $TARGET_FILE:myapp
${MYPREFIX}/bin
DEPENDS myapp
COMMENT Staging myapp to ${MYPREFIX}/bin
VERBATIM)
add_custom_target(stage_myapp ALL
DEPENDS ${MYPREFIX}/bin/myapp)
EOF
Now build an Xcode generator, then run xcodebuild:
$ cmake -G Xcode .
$ xcodebuild build -configuration RelWithDebInfo
Additional Information:
If you use the 'Unix Makefile' generator instead, it will work fine (even with
high parallelism). Also I've tried replacing the DEPENDS myapp with a full
pathname to myapp and that fails as well, with the same error.
I've seen this same behavior on various different versions of Xcode: 4.1, 4.6,
and 4.6.3 at least.
==
Issue History
Date ModifiedUsername FieldChange
==
2013-07-15 10:43 Paul Smith New Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Working towards Windows Phone 8 support
Thanks for the response Brad. Comments inline below... Paul. Date: Mon, 15 Jul 2013 08:38:11 -0400 From: brad.k...@kitware.com To: cmake-developers@cmake.org Subject: Re: [cmake-developers] Working towards Windows Phone 8 support On 07/12/2013 07:58 AM, Paul Annetts wrote: I'm interested in contributing towards Windows Phone 8 support in CMAKE, i.e. http://public.kitware.com/Bug/view.php?id=13791 Thanks for working on this. Consider drawing attention to your work by posting in the issue tracker too. I haven't personally worked on any wp80 development so it will be helpful to recruit others to help review the work. Ok - I'll make a post to the tracker. new Visual Studio 11 Windows Phone 8 generator Our convention is to have no spaces in the name of the architecture, so a name like Visual Studio 11 WP8 will be better. Some projects use regular expressions to parse the generator name so we should stick to that convention. No problem. 1. Targets the Windows Phone 8 platform toolset (v110_wp80). See the CMAKE_GENERATOR_TOOLSET feature added in 2.8.11 along with the -T command-line option to set it. I wasn’t aware of that: yes I'll take a look at that. 2. Has content that allows MSBUILD/Visual Studio to build a .lib target for either Win32 (x86 emulator) and ARM (devices) platforms. Do you mean multiple architectures in one vcxproj file? Yes. There are only 2 possible architectures for WP8, it isn’t WinCE with a plethora of different CPU options. This is all cross-compilation anyhow: even if you pick the x86 platform the ABIs differ to Windows Desktop. As x86 support is designed solely to emulate the ARM phones, I believe that the platform API can be relied on to be the same between architectures. I can see the following advantages in this case:this is what the VCXPROJ files you would create in Visual Studio have, so it is a closer match to non-CMAKE projects.It gives a better developer user experience - it makes it possible to switch between emulator and device without having to run CMAKE twice and open a new project. This allows non-CMAKE generated WP8 Visual Studio projects to integrate properly with the CMAKE generated ones. It is an approach which may be applicable to Windows Store apps as well (although I've not got much experience of that myself). The extension of the VS10 target generator to support this is the largest change in the patch. How should I go about getting my work reviewed at an early stage? If the patch series is relatively small you can just use git format-patch and post the patches to this list. Alternatively, if the topic is large, we publish mirrors of the Git repo: https://github.com/Kitware/CMake http://gitorious.org/cmake/cmake If you have an account on one of those you can fork/clone the project there, publish your topic to your own account, and then post a link here. OK - I think this is patch sized for now, but thanks for the pointers to github and gitorious. -- 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] [CMake 0014292]: CMake does not add QT_NO_DEBUG definition for non-debug builds
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14292
==
Reported By:Nikita Krupen'ko
Assigned To:
==
Project:CMake
Issue ID: 14292
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2013-07-15 11:26 EDT
Last Modified: 2013-07-15 11:26 EDT
==
Summary:CMake does not add QT_NO_DEBUG definition for
non-debug builds
Description:
I created Qt5 CMake project and use the code like the following:
cmake_minimum_required(VERSION 2.8.11)
find_package(Qt5Core REQUIRED)
target_link_libraries(${PROJECT_NAME} Qt5::Core)
The problem is that CMake does not defines QT_NO_DEBUG for release build, like
qmake does. If I build qml-plugin, I can't use release build of it, because Qt
takes it for debug build and I get the following error:
The plugin uses incompatible Qt library. (Cannot mix debug and release
libraries.)
The workaround is simple:
if(NOT CMAKE_BUILD_TYPE STREQUAL Debug)
add_definitions(-DQT_NO_DEBUG)
endif()
It works, but I think this should be done in CMake.
==
Issue History
Date ModifiedUsername FieldChange
==
2013-07-15 11:26 Nikita Krupen'koNew Issue
==
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake is slow for project with hundred target and one command with large number of dependencies
On Mon, Jul 15, 2013 at 1:51 PM, Stephen Kelly steve...@gmail.com wrote: Nicolas Desprès wrote: Yes that one or cmMakefile::GetSourceFileWithOutput(char const*). I can send you a gzipped of my callgrind data off-list if you want (it weights 534K). If we had a map associating each input to output, we could maybe have better performance. WDYT? Perhaps. I can probably create the same callgrind data locally anyway, but I won't have a change until later to dig into this. On looking at the cmMakefile::GetSourceFileWithOutput code though, it seems that it might also be useful to maintain this-SourceFiles and (*i)-GetCustomCommand()-GetOutputs() as sorted vectors. They are rarely modified, so the O(1) - O(log N) inserts probably won't matter much, but the O(N) - O(log N) might provide a useful gain. Or, as most access is at generate time, keep the O(1) insertions, sort() after the configure step, and then use the binary search at generate time. Of course, I don't know if there are also configure-time accesses which would be difficult to isolate from the generate-time ones. Does that make any sense? I think so. I fixed my timeout problem for writing the test, and pushed a first draft of a commit fixing this issue. I have the remaining test failling: 56 - ExportImport (Failed) 87 - CustomCommand (Failed) I will investigate them tomorrow. -- Nicolas Desprès -- 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] install-interface-includes topic
On 7/15/2013 11:25 AM, Stephen Kelly wrote: The solution I think is to add the specified include directories to the cmTargetExport instance which gets created when using the EXPORT, and to append the directories only when generating. Yes, certainly the INCLUDES DESTINATION needs to be associated with the EXPORT whose targets will get the usage requirement. 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] Working towards Windows Phone 8 support
On 7/15/2013 11:08 AM, Paul Annetts wrote: Yes. There are only 2 possible architectures for WP8, it isn’t WinCE [snip] The extension of the VS10 target generator to support this is the largest change in the patch. If possible, please factor that out as a separate patch independent of the Windows Phone work. This would be a generally useful feature and has been requested before. Note also that the Xcode generator supports multiple simultaneous architectures for universal binaries. This may be related. -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] install-interface-includes topic
Brad King wrote: On 7/15/2013 11:25 AM, Stephen Kelly wrote: The solution I think is to add the specified include directories to the cmTargetExport instance which gets created when using the EXPORT, and to append the directories only when generating. Yes, certainly the INCLUDES DESTINATION needs to be associated with the EXPORT whose targets will get the usage requirement. Ok, I've implemented that. I couldn't squash in the fix commit because that causes a conflict with tid-system-argument, but I guess it can be squashed before merge. 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
[cmake-developers] compile-defs-debugging topic
Steve, I merged this topic, consisting of commits a18e9586..d7dd0108, to master this morning. However, when I use the VS generators on Windows CMake now crashes because something clobbers the cmMakefile::SourceGroups member. This didn't crash when the topic was in next. Does it depend on something else? I bisected the problem down to commit d7dd0108. While investigating I noticed something I missed while reviewing the topic earlier. The cmMakefile::GetProperty implementation tries to re-compose the property value as a ;-list, but does not preserve escaped semicolons which IIRC are supported when setting the COMPILE_DEFINITIONS property. Please add a test case that checks getting the property with ;s. 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] Working towards Windows Phone 8 support
Sure - that should separate out well into two parts (Win32/ARM architecture and Windows Phone). The way I'm currently specifying the multiple architectures is too hard-coded to be generally useful (I'm just checking the generator type), so I'll see if I can tidy that up first before submitting that patch. Paul. Date: Mon, 15 Jul 2013 13:29:17 -0400 From: brad.k...@kitware.com To: p...@lightunobscured.com CC: cmake-developers@cmake.org Subject: Re: [cmake-developers] Working towards Windows Phone 8 support On 7/15/2013 11:08 AM, Paul Annetts wrote: Yes. There are only 2 possible architectures for WP8, it isn’t WinCE [snip] The extension of the VS10 target generator to support this is the largest change in the patch. If possible, please factor that out as a separate patch independent of the Windows Phone work. This would be a generally useful feature and has been requested before. Note also that the Xcode generator supports multiple simultaneous architectures for universal binaries. This may be related. -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] [CMake 0014294]: Command-line options overwritten by re-run
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14294
==
Reported By:Greg Coombe
Assigned To:
==
Project:CMake
Issue ID: 14294
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2013-07-15 20:17 EDT
Last Modified: 2013-07-15 20:17 EDT
==
Summary:Command-line options overwritten by re-run
Description:
If I specify a command-line option using the option() function and provide it
on the command line along with CMAKE_lang_COMPILER option (specified without
full path), it is overwritten.
Steps to Reproduce:
1. Make a small CMakeLists.txt:
cmake_minimum_required(VERSION 2.8.11)
option(RERUN_TEST Re-run me! OFF)
message(STATUS Re-run test variable is ${RERUN_TEST})
2. Run twice with both the option specified, as well as the compiler:
$ cmake -D RERUN_TEST=ON -D CMAKE_CXX_COMPILER=g++ CMakeLists.txt
-- The C compiler identification is GNU 4.6.3
-- The CXX compiler identification is GNU 4.6.3
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++
-- Check for working CXX compiler: /usr/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Re-run test variable is ON
-- Configuring done
-- Generating done
$ cmake -D RERUN_TEST=ON -D CMAKE_CXX_COMPILER=g++ CMakeLists.txt
-- Re-run test variable is ON
-- Configuring done
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_CXX_COMPILER= g++
-- The C compiler identification is GNU 4.6.3
-- The CXX compiler identification is GNU 4.6.3
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++
-- Check for working CXX compiler: /usr/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Re-run test variable is OFF
-- Configuring done
-- Generating done
So now we've built the project without the command-line option.
3. Interestingly, note that using the full path of the compiler doesn't have the
same behavior:
$ cmake -D RERUN_TEST=ON -D CMAKE_CXX_COMPILER=/usr/bin/g++ CMakeLists.txt
-- Re-run test variable is ON
-- Configuring done
-- Generating done
Additional Information:
Speculation:
It appears that CMake is writing the CMAKE_lang_COMPILER value to the cache
before expanding it, then interpreting the different value as requiring a
re-run. This re-run ignores the command-line options (maybe because the cache is
nuked: http://public.kitware.com/Bug/view.php?id=13756).
==
Issue History
Date ModifiedUsername FieldChange
==
2013-07-15 20:17 Greg CoombeNew Issue
2013-07-15 20:17 Greg CoombeFile Added: CMakeLists.txt
==
--
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
