Re: [cmake-developers] Xcode source file type
Thanks, guys; I'll investigate and see what I can do. On Mon, May 15, 2017 at 6:06 AM, Brad Kingwrote: > On 05/14/2017 05:42 PM, Gregor Jasny via cmake-developers wrote: > > I'd welcome any attempts to simplify the Xcode generator. But before I'd > > ack such a PR I'd like to know why this functionality was added in the > > first place. CMake still supports (does not actively break) Xcode 3. If > > there is no answer to that question: maybe you could test and limit your > > changes to a newer Xcode version (like 5 or above). > > Run > > ``` > $ git log -SlastKnownFileType -- Source/ > ``` > > to see a history for this setting. Some investigation may be > needed to determine what is needed for current Xcode versions. > The setting could easily be made conditional on the Xcode version. > > -Brad > > -- 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] Wrongly assuming lib/ is IsImplicitDirectory for runtime-paths
On 05/15/2017 03:28 AM, Patrick Boettcher wrote: > To this list somewhere the lib/-path located next to the > compiler-bin/-path has been added. [snip] > What can I do? Is this a bug in cmake or in my setup? > Why is this path considered implicit? CMake tries to detect the implicit link directories used by the compiler front-end when driving the linker. See results in any build tree: ``` $ grep IMPLICIT CMakeFiles/*/CMake*Compiler.cmake ``` The `Modules/CMakeParseImplicitLinkInfo.cmake` file contains the code that does this. It is called while detecting the compiler. The assumption is that running `c++ foo.cpp && ./a.out` will work with no special runtime paths explicitly added. The toolchain should be configured to add its own implicit link directories to the runtime path of binaries it links, or the environment should otherwise be configured such that the dynamic loader looks there. -Brad -- 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_TEST_XXX variables
On 05/13/2017 08:55 PM, Craig Scott wrote: > only set on the CMake command line by CI builds or similar, Correct. We need a way to activate such tests only on machines where we expect them to work. It would be nice to have something better but I'm not sure what else we can do. We used to try to add tests for find modules automatically but that ends up needing to run the find modules as part of configuring CMake, giving the false appearance that CMake actually needs all those packages and possibly breaking on bad ones. The GTK2 tests still have this problem. -Brad -- 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] ;-list in docs
On 05/13/2017 06:43 PM, Jean-Michaël Celerier wrote: > On Sat, May 13, 2017 at 5:39 AM, Craig Scott wrote: >> ;-list > It's a shorthand for semicolon-separated list : > https://cmake.org/cmake/help/v3.8/command/separate_arguments.html?highlight=semicolon Yes. In documentation that has been modernized we use :ref:`;-list ` to link here: https://cmake.org/cmake/help/v3.8/manual/cmake-language.7.html#lists -Brad -- 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] Xcode source file type
On 05/14/2017 05:42 PM, Gregor Jasny via cmake-developers wrote: > I'd welcome any attempts to simplify the Xcode generator. But before I'd > ack such a PR I'd like to know why this functionality was added in the > first place. CMake still supports (does not actively break) Xcode 3. If > there is no answer to that question: maybe you could test and limit your > changes to a newer Xcode version (like 5 or above). Run ``` $ git log -SlastKnownFileType -- Source/ ``` to see a history for this setting. Some investigation may be needed to determine what is needed for current Xcode versions. The setting could easily be made conditional on the Xcode version. -Brad -- 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] Does JOB_POOL_[COMPILE|LINK] work with custom_target?
On Mon, May 15, 2017 at 11:46:37 +0200, Eric Noulard wrote: > No answer whatsoever on this? I don't think it is supported right now. > I'd like to be able assign some custom targets to a ninja job pool. > If I were to implement the feature would it be acceptable upstream ? I think it'd be fine. --Ben -- 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] Does JOB_POOL_[COMPILE|LINK] work with custom_target?
Hi all, No answer whatsoever on this? Initial contributor of Ninja job pool appears to be Peter Kümmel: commit 7605e37aabae2678e5696a75e84aced2e84f9037 Author: Peter KümmelDate: Sat Nov 23 10:49:36 2013 +0100 I'd like to be able assign some custom targets to a ninja job pool. If I were to implement the feature would it be acceptable upstream ? Eric 2017-05-05 16:16 GMT+02:00 Eric Noulard : > Hi all, > > We have a bunch of custom_target and a subset of them should be run in > sequence. > So we tried to define: > > set_property(GLOBAL PROPERTY JOB_POOLS exclusive=1) > > and then: > > set_property(TARGET my_custom_target PROPERTY JOB_POOL_COMPILE exclusive) > set_property(TARGET my_custom_target PROPERTY JOB_POOL_LINK exclusive) > > > This does not seem to reach build.ninja ? > > The new pool is defined but the concerned custom targets are never > assigned to the pool? > > May custom target be assigned to a ninja pool? > If so how can we do that? > -- > Eric > -- Eric -- 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] Wrongly assuming lib/ is IsImplicitDirectory for runtime-paths
Hi list, This is a follow-up of my problem I discussed with myself on the cmake-mailing list: "CLANG vs GCC when linking executables". I found the root-cause of this problem: When constructing the rpath-arguments cmake is using an cmOrderDirectories called OrderLinkerSearchPath to which all the runtime-libraries via AddRuntimeLibrary() have been added. In AddRuntimeLibrary() it checks whether the library-path is an implicit directory. To this list somewhere the lib/-path located next to the compiler-bin/-path has been added. This works well if the compiler is installed in /usr/bin because /usr/lib is present in the system's loader-configuration. In my case I have locally built a compiler and in the lib/-dir next to the bin/-dir I installed other libraries. When now linking with one of them (via an IMPORTED library), cmake does not add the rpath because it assumes lib/ is implicitly used by the loader (or something else?). What can I do? Is this a bug in cmake or in my setup? Why is this path considered implicit? best regards, -- Patrick. -- 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