Re: [cmake-developers] [CMake] Windows rpath emulation
On 09/20/2014 11:53 PM, Nils Gladitz wrote: On 20.09.2014 23:31, Roland Schulz wrote: it would be nice if there were a way to emulate rpath under Windows. As far as I can see there are two possible approaches: - Generate a shell script which sets PATH - Generate a manifest for the application and a manifest for the dependencies. http://sourceforge.net/p/mingw-w64/mailman/message/30019971/ has an example of how to do it. So I am thinking opt-in (target property) wrapper binaries that take the place of the actual binaries. e.g. # Initializes ENABLE_EXECUTABLE_WRAPPER target property set(CMAKE_ENABLE_EXECUTABLE_WRAPPER ON) add_executable(foo foo.cpp) Could produce foo.exe.real# Actual target binary foo.exe.wrapper # CMake generated configuration file foo.exe # Wrapper binary that reads foo.exe.wrapper, sets up the environment and runs foo.exe.real COMMANDs (add_custom_command()/add_custom_target()/add_test()) could transparently call foo.exe (like they would have done without the wrapper). install(TARGETS) should ignore the wrapper and transparently install and rename the real binary. $TARGET_FILE should continue to point at the real binary. A new $TARGET_WRAPPER could point at the wrapper binary. The wrapper binary itself could be precompiled and included with cmake itself. It would determine which configuration to read and which binary to run by inspecting its own name. I primarily had windows native builds in mind. Are there additional use cases? Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Was AUTOMOC designed to run for each build?
Hi (especially Alex), I noticed that the automoc target is run each time, even for a trivial project: cmake_minimum_required(VERSION 2.8) project(automoctest) set(CMAKE_AUTOMOC ON) find_package(Qt5Widgets REQUIRED) add_executable(main main.cpp) target_link_libraries(main Qt5::Widgets) Each time I run make I get [ 33%] Automatic moc for target main /path/to/cmake -E cmake_autogen /path/to/build/CMakeFiles/main_automoc.dir/ I checked CMake 2.8.7 and it executes the target each time too. In the implementation, makefile-AddUtilityCommand is called with 'true' to set the excludeFromAll parameter. I don't see why the target is executed each time, but is it that way by design? Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] iOS support
Hi! My company is organizing soon a hack week where each employee is able to work on any project he wants. So, I've decided to work with Cmake and improve support for iOS to help the product team getting rid of manual project files, constant merge conflicts and bad project file documentation, while improving our tooling possibilities (all that with Cmake!). I've had a quick look at the first issue that popped into my mind the other day and fixed try_compile by adding another variable to set the executable type in the generated project (it has to be MACOSX_BUNDLE) and fixing the search path for the resulting binary. So this is now working... Providing we are targeting the simulator. Due to the nature of Xcode projects that can easily target either the simulator or devices, thus using different compilation flags, the resulting projects aren't working in both case. There are conflicts between some options like the minimum iOS version target and the minimum iOS simulator target for example (which you need to build the try_compile binaries without signing them). Also, the Xcode support is very OSX focused and all variables have MACOSX in their name, which is confusing. So, has anyone worked on similar issues and can suggest a way to progress and improve support for iOS? In the end, I'd like to have a working Xcode project with separate settings for both simulator and device, Cmake compiler flag detection working, and possibly later Make/Ninja projects working too. Regards, /Orphis -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015170]: CMAKE_SYSTEM_PROCESSOR is broken on Windows
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15170 == Reported By:stopiccot Assigned To: == Project:CMake Issue ID: 15170 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2014-09-23 07:45 EDT Last Modified: 2014-09-23 07:45 EDT == Summary:CMAKE_SYSTEM_PROCESSOR is broken on Windows Description: According to it's description CMAKE_SYSTEM_PROCESSOR should have value of The name of the CPU CMake is building for. On Windows x64 hosts it always has value of AMD64 no matter which architecture you are building for: x86/x64 or arm. I have a strong opinion that this behavior should be fixed cause otherwise this var is completely useless on windows. And yes I know there is a CMAKE_CL_64 var for determining what arch we are building for. But it looks like a x64-only dirty hack not a generic solution == Issue History Date ModifiedUsername FieldChange == 2014-09-23 07:45 stopiccot New Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] iOS support
The lowest hanging fruit would be to transition over to setting the global variable CMAKE_MACOSX_BUNDLE which is used to initialize the MACOSX_BUNDLE property on all the targets. CMake also supports CMAKE_XCODE_ATTRIBUTE global variables to allow easy code signing etc. Lastly have you looked at setting up different toolchains for the simulator and device? On Tue, Sep 23, 2014 at 4:26 AM, Florent Castelli florent.caste...@gmail.com wrote: Hi! My company is organizing soon a hack week where each employee is able to work on any project he wants. So, I've decided to work with Cmake and improve support for iOS to help the product team getting rid of manual project files, constant merge conflicts and bad project file documentation, while improving our tooling possibilities (all that with Cmake!). I've had a quick look at the first issue that popped into my mind the other day and fixed try_compile by adding another variable to set the executable type in the generated project (it has to be MACOSX_BUNDLE) and fixing the search path for the resulting binary. So this is now working... Providing we are targeting the simulator. Due to the nature of Xcode projects that can easily target either the simulator or devices, thus using different compilation flags, the resulting projects aren't working in both case. There are conflicts between some options like the minimum iOS version target and the minimum iOS simulator target for example (which you need to build the try_compile binaries without signing them). Also, the Xcode support is very OSX focused and all variables have MACOSX in their name, which is confusing. So, has anyone worked on similar issues and can suggest a way to progress and improve support for iOS? In the end, I'd like to have a working Xcode project with separate settings for both simulator and device, Cmake compiler flag detection working, and possibly later Make/Ninja projects working too. Regards, /Orphis -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Windows rpath emulation
What is the problem that this feature is trying to solve? It seems unnecessary to me as a first-class feature of CMake. I must be missing something... But if you do pursue something like this, it seems to me that install(TARGETS ...) should install all files including the wrapper. Is this only for executable files, or would something like this also be possible/necessary for shared libraries, too? Slicer and ParaView do (or did in the past) have similar wrappers to set up necessary environment variables before invoking the real exe. Thanks, David C. On Tue, Sep 23, 2014 at 3:05 AM, Nils Gladitz nilsglad...@gmail.com wrote: On 09/20/2014 11:53 PM, Nils Gladitz wrote: On 20.09.2014 23:31, Roland Schulz wrote: it would be nice if there were a way to emulate rpath under Windows. As far as I can see there are two possible approaches: - Generate a shell script which sets PATH - Generate a manifest for the application and a manifest for the dependencies. http://sourceforge.net/p/mingw-w64/mailman/message/30019971/ has an example of how to do it. So I am thinking opt-in (target property) wrapper binaries that take the place of the actual binaries. e.g. # Initializes ENABLE_EXECUTABLE_WRAPPER target property set(CMAKE_ENABLE_EXECUTABLE_WRAPPER ON) add_executable(foo foo.cpp) Could produce foo.exe.real# Actual target binary foo.exe.wrapper # CMake generated configuration file foo.exe # Wrapper binary that reads foo.exe.wrapper, sets up the environment and runs foo.exe.real COMMANDs (add_custom_command()/add_custom_target()/add_test()) could transparently call foo.exe (like they would have done without the wrapper). install(TARGETS) should ignore the wrapper and transparently install and rename the real binary. $TARGET_FILE should continue to point at the real binary. A new $TARGET_WRAPPER could point at the wrapper binary. The wrapper binary itself could be precompiled and included with cmake itself. It would determine which configuration to read and which binary to run by inspecting its own name. I primarily had windows native builds in mind. Are there additional use cases? Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Windows rpath emulation
On 09/23/2014 03:11 PM, David Cole wrote: What is the problem that this feature is trying to solve? Being able to run binaries with DLL dependencies within the build tree. Basically the same thing that the build time RPATH feature does on e.g. linux. If you are e.g. linking to Qt5 (shared) and don't have the Qt5 bin directory in your PATH the binary will not run since it can not locate the DLL on its own. As workarounds people often copy the DLLs into their build directories, output all runtime files into a single directory and/or set up custom wrappers that set up PATH. But if you do pursue something like this, it seems to me that install(TARGETS ...) should install all files including the wrapper. CMake replaces build time RPATHs with installation RPATHs when deploying. I think the same should apply to these wrappers. They are only useful for a build tree. Is this only for executable files, or would something like this also be possible/necessary for shared libraries, too? I have been pondering DLLs as well but would restrict it to executables for now. For DLLs this probably only makes sense in a context where the DLL is build by CMake and used as-is without deployment in a context outside of CMake's control. Also I am guessing this might not be as simple to set up as it is for executables. Thanks for the feedback! Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] iOS support
On 9/23/2014 8:09 AM, Robert Maynard wrote: The lowest hanging fruit would be to transition over to setting the global variable CMAKE_MACOSX_BUNDLE which is used to initialize the MACOSX_BUNDLE property on all the targets. CMake also supports CMAKE_XCODE_ATTRIBUTE global variables to allow easy code signing etc. Lastly have you looked at setting up different toolchains for the simulator and device? We have recently looked at this problem. Setting CMAKE_MACOSX_BUNDLE in the toolchain file gets you part of the way there. However, some try_compile stuff will still fail because it can not find the app bundles. cmake_minimum_required(VERSION 2.8) project(foo) include(TestBigEndian) test_big_endian(CMAKE_WORDS_BIGENDIAN) https://github.com/Kitware/VTK/blob/master/CMake/ios.toolchain.xcode.cmake This will get you to the problem: cmake -GXcode -DCMAKE_TOOLCHAIN_FILE=../ios.toolchain.xcode.cmake .. -DIOS_PLATFORM=SIMULATOR Trouble is in cmake/Modules/CheckTypeSize.cmake where it does a try_compile with COPY_FILE. The COPY_FILE in cmCoreTryCompile.cxx does not look for the bundle option and therefore can not find the executable. However, now that I look at it, I think I might be able to fix it pretty easy. That said it would be really cool to beef up the xcode support enough to be able to create an actual ios app. I have not dug into that enough. Should be able to do most of it with CMAKE_XCODE_ATTRIBUTE. I will look into this try_compile COPY_FILE issue today and get back to the list. It would be great if you could get an example/Test in place that builds an app for a device and works with Xcode and for a stretch goal also works with makefiles or ninja. -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] iOS support
That said it would be really cool to beef up the xcode support enough to be able to create an actual ios app. I have not dug into that enough. Should be able to do most of it with CMAKE_XCODE_ATTRIBUTE. I will look into this try_compile COPY_FILE issue today and get back to the list. It would be great if you could get an example/Test in place that builds an app for a device and works with Xcode and for a stretch goal also works with makefiles or ninja. Couple of more things. Much of the stuff found in these toolchains: https://github.com/Kitware/VTK/blob/master/CMake/ios.toolchain.xcode.cmake https://github.com/Kitware/VTK/blob/master/CMake/ios.simulator.toolchain.cmake https://github.com/Kitware/VTK/blob/master/CMake/ios.device.toolchain.cmake Should be in Platform files. If we created ios platform files we could remove most of the stuff from those toolchain files. This would be a great thing to work on. Also, Robert M reminded me that there is a test that could be extended as this stuff is developed: https://github.com/Kitware/CMake/tree/master/Tests/iOSNavApp ) as it already builds targeting the iphone simulator. -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] iOS support
On 23 Sep 2014, at 16:56, Bill Hoffman bill.hoff...@kitware.com wrote: That said it would be really cool to beef up the xcode support enough to be able to create an actual ios app. I have not dug into that enough. Should be able to do most of it with CMAKE_XCODE_ATTRIBUTE. I will look into this try_compile COPY_FILE issue today and get back to the list. It would be great if you could get an example/Test in place that builds an app for a device and works with Xcode and for a stretch goal also works with makefiles or ninja. Couple of more things. Much of the stuff found in these toolchains: https://github.com/Kitware/VTK/blob/master/CMake/ios.toolchain.xcode.cmake https://github.com/Kitware/VTK/blob/master/CMake/ios.simulator.toolchain.cmake https://github.com/Kitware/VTK/blob/master/CMake/ios.device.toolchain.cmake Should be in Platform files. If we created ios platform files we could remove most of the stuff from those toolchain files. This would be a great thing to work on. The problem is that I want a project that is usable by developers directly and you can't really force them to target just the simulator. It should work for targeting both simulator and real device. So having a generic iOS toolchain that can generate both in one project is a requirement for me. Generating projects for Makefiles or Ninja would probably require a dedicated toolchain though (or proper platform files indeed), but that can be done later. Also, Robert M reminded me that there is a test that could be extended as this stuff is developed: https://github.com/Kitware/CMake/tree/master/Tests/iOSNavApp ) as it already builds targeting the iphone simulator. -Bill Nice, I will have a look! I also have a couple of patches for finding the binary during a try_compile that works with my other change to have an extra variable for the add_executable and I would need to change it. It's mostly changing cmCoreTryCompile::FindOutputFile() and adds / + targetName + .app/Contents/MacOS to the searchDirs. I'll try to pickup those toolchain files though and see how they work for me soon. I'll probably have some options to override a few things and make it find the compiler properly. Right now, it's hardcoding /usr/bin/clang and that's a no go :) (it should be found in the path or through DEVELOPER_DIR eventually). Not forcing the compiler would be sweet too (but that requires the try_compile fixup first) as it means we could use ccache or an alternative compiler (for reasons). /Orphis -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] iOS support
On 9/23/2014 11:42 AM, Florent Castelli wrote: I also have a couple of patches for finding the binary during a try_compile that works with my other change to have an extra variable for the add_executable and I would need to change it. It's mostly changing cmCoreTryCompile::FindOutputFile() and adds / + targetName + .app/Contents/MacOS to the searchDirs. I just pushed something to next that adds targetName.app. That worked for the example I was building. -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Windows rpath emulation
On 23.09.2014 19:12, Roland Schulz wrote: Have you got a solution to the problem you mentioned in your first email: I suppose it might be slightly more complex given that the import library that is being linked to and the DLL that corresponds to the import library might not be in the same location (and cmake might know the location of the one but not always the location of the the other). - For local targets CMake does have the location (these are also interesting but the main selling point would imo be external libraries). - For imported targets CMake may have DLL locations. More likely when set up by package configuration files (e.g. Qt5 sets them) than when set up by find modules (e.g. FindQt4 does not set them). There might be incentive to add those locations when they start to be more useful. - It might be possible to guess the DLL location from a given import library (assuming it was provided with a full path); probably not something you can rely on but it might be able to guess the location often enough to be convenient - Additional locations could be provided manually by target property On windows when you deploy to a system different from your own it is expected and common practice that you deploy your runtime requirements as well. You can not expect a preexisting installation of your library requirements nor can you expect them to be in the same location as in your development system. I think you are referring to making a binary cpack installation package. I was thinking about installing on the build system. Then It would still be different from the build directory. Yes, but I think that is the least common use case (maybe even more so on windows). CPack uses the same install commands for packaging and local install and I don't think CMake makes the distinction between deploying locally and remotely. Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Was AUTOMOC designed to run for each build?
On Tuesday, September 23, 2014 09:58:58 Stephen Kelly wrote: Hi (especially Alex), I noticed that the automoc target is run each time, even for a trivial project: cmake_minimum_required(VERSION 2.8) project(automoctest) set(CMAKE_AUTOMOC ON) find_package(Qt5Widgets REQUIRED) add_executable(main main.cpp) target_link_libraries(main Qt5::Widgets) Each time I run make I get [ 33%] Automatic moc for target main /path/to/cmake -E cmake_autogen /path/to/build/CMakeFiles/main_automoc.dir/ I checked CMake 2.8.7 and it executes the target each time too. In the implementation, makefile-AddUtilityCommand is called with 'true' to set the excludeFromAll parameter. I don't see why the target is executed each time, but is it that way by design? iirc, yes. The moc files have to be generated before any of the source files is compiled, so automoc is in a target the actual target depends on. IIRC it is exclude_from_all so that it is only built when the actual target is built. Do you think it should only rerun if any of the source files has changed ? There was some problem with this. The headers are usually not part of the listed source files. I would have to check to find out the details again. Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
