Re: [cmake-developers] Extracting target metadata, IDE integration
On 12/18/2014 09:02 PM, Aleix Pol wrote: I would like to propose this as a final version of this patch. http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch For reference, this was also attached in a later message of this thread on 2015-01-09: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12061 I have a working proof of concept in KDevelop already I'm quite happy with. Can you post a link to that implementation so others may try it? Steve K. posted a review of your patch on 2014-12-19: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11972 that has not yet received a response. Also, for unrelated reasons we've now added JsonCpp into the CMake build process. You could consider using that to write the .json file so that no manual formatting or escaping code is needed. The current patch does not add potentially needed json escapes. Thanks, -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] Extracting target metadata, IDE integration
On Tue, Jan 20, 2015 at 3:47 PM, Brad King brad.k...@kitware.com wrote: On 12/18/2014 09:02 PM, Aleix Pol wrote: I would like to propose this as a final version of this patch. http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch For reference, this was also attached in a later message of this thread on 2015-01-09: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12061 I have a working proof of concept in KDevelop already I'm quite happy with. Can you post a link to that implementation so others may try it? It can be found by: git clone git://anongit.kde.org/kdevelop -b cmakePossibleTargetsFile https://projects.kde.org/projects/extragear/kdevelop/kdevelop/repository/show?rev=cmakePossibleTargetsFile Steve K. posted a review of your patch on 2014-12-19: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11972 that has not yet received a response. Will look into these tonight. Also, for unrelated reasons we've now added JsonCpp into the CMake build process. You could consider using that to write the .json file so that no manual formatting or escaping code is needed. The current patch does not add potentially needed json escapes. I will consider to. Aleix -- 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] Introduce 'Unix Ninja' generator
On Tue, Jan 20, 2015 at 10:42:47 -0500, Daniel Levin wrote: This wrapper script cannot be common, because for each kind of build env variable set will be different. So it need to be created at CMake generation time saving current QNX* env variables into this wrapper script. So next time you can open clean shell and run 'make' or 'ninja' and it will properly use environment variables defined previously at generation stage. What if Ninja itself gained support for 'env =' on rules for Ninja to set environment variables for the rule and QNX-on-Windows set CMake variables which filled this in appropriately? --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] Introduce 'Unix Ninja' generator
As far as I understand this 'env' is not a standard key in Ninja, right? That would be actually great to let CMake define environment variables in rules. Does CMake support that already? What about Makefile compatibility, is it possible to define env variables per rule in Makefiles? On Tue, Jan 20, 2015 at 12:00 PM, Ben Boeckel ben.boec...@kitware.com wrote: On Tue, Jan 20, 2015 at 10:42:47 -0500, Daniel Levin wrote: This wrapper script cannot be common, because for each kind of build env variable set will be different. So it need to be created at CMake generation time saving current QNX* env variables into this wrapper script. So next time you can open clean shell and run 'make' or 'ninja' and it will properly use environment variables defined previously at generation stage. What if Ninja itself gained support for 'env =' on rules for Ninja to set environment variables for the rule and QNX-on-Windows set CMake variables which filled this in appropriately? --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] Introduce 'Unix Ninja' generator
Brad, below is the list of variables set manually by me before testing QNX SDK environment variables, the qcc will fail if any of them are missing: set QNX_CONFIGURATION=d:\opt\qnx-software-systems set QNXLM_LICENSE_FILE=@10.144.209.10 set QNX_HOST=d:\opt\qnx650sp1\host\win32\x86 set QNX_TARGET=d:\projects\pasa\ford\r6\QNX_SDK\target\qnx6 set PATH=d:\opt\qnx650sp1\host\win32\x86\usr\bin;%PATH% Do you mean some kind of dll injection to intercept CreateProcess calls? I doubt, but that does not mean it does not. I remember errors from Ninja when it was trying to execute %1 in CreateProcess call, but suspect that was a problem in escape characters in .ninja file. I did short research again and would want to explain from scratch. 1. My story takes start from the existing QNX project based on Makefiles and my effort was to inject CMake into that build tree. QNX SDK always uses Unix environment which means: - Makefiles always use Unix syntax - environment guarantees that you can use shell scripts in your Makefiles as commands 2. When you want to reuse existing .sh scripts in your CMake target rules it apparently fails because Ninja does not know how to execute them. QNX SDK make tool does. 3. The most problematic issue for me was that qcc and gcc tools from QNX SDK cannot run without QNX_HOST and QNX_TARGET variables set. Also qcc will fail if QNX_CONFIGURATION and QNXLM_LICENSE_FILE are missing or license server is not available (but that is another story). CMake build works in two stages: generation and native build. Setting listed env variables at generation stage is absolutely valid. But setting them again later at build stage leads to issues: - you need to explicitly load environment variables each time before build - if you have multiple QNX SDKs you might accidentally load wrong variable set - if you use IDE launched from clean shell with default variables you cannot source env variables saved in some script anymore - if you use IDE you probably need to explicitly replicate env variables in some IDE specific way CMake has solution to overcome problems like this: cache. But apparently cache does not work when you need to save environment variables which need to be loaded _before_ build starts. So the only way to fix that was to wrap compiler into script, that does: a) environment variable setup, b) launch real compiler, forwarding passed arguments to it. This wrapper script cannot be common, because for each kind of build env variable set will be different. So it need to be created at CMake generation time saving current QNX* env variables into this wrapper script. So next time you can open clean shell and run 'make' or 'ninja' and it will properly use environment variables defined previously at generation stage. I implemented that in my toolchain file, redirecting CMAKE_C_COMPILER to my gcc_wrapper.sh and that was working perfectly for 'Unix Makefiles' generator. 'Ninja' generator was failing because it cannot execute .sh files. Fine, lets replace CMAKE_C_COMPILER=gcc_wrapper.sh with CMAKE_C_COMPILER=/path/to/sh.exe gcc_wrapper.sh. But that does not work, because CMAKE_C_COMPILER expects full path to executable, not command line. I reworked wrapper as Windows batch file: gcc_wrapper.bat. Now it works under 'Ninja' but fails under 'Unix Makefiles', because QNX SDK make overrides .bat processing somehow. Maybe there were another reasons, but at some point I decided that the most appropriate way will be to stop playing with Windows environment. If QNX SDK applications always expect Unix environment we should give it to them. That is why I added 'Unix Ninja' generator that will always use sh as shell tool. Thanks, Daniel On Mon, Jan 19, 2015 at 2:50 PM, Brad King brad.k...@kitware.com wrote: On 01/16/2015 01:13 PM, Daniel Levin wrote: The CMake and Ninja were part of the bigger build script, which was running under the QNX SDK sh.exe. When running under this shell it overrides some environment variables (compare attached files). The main differences I see are: * The Windows shell is a 64-bit cmd and the MSYS one is 32-bit * PATH has been converted to MSYS-style and prepended with /usr/bin * Added: QNX_HOST=c:\opt\qnx650-gcc-4.8.1\host\win32\x86 * Added: QNX_TARGET=c:\opt\qnx650-gcc-4.8.1\target\qnx6 * Added: TERM=cygwin, consistent with MSYS shells * Added: SHLVL=1 * The TEMP and TMP variables are /tmp instead of the Windows dirs So this is a MSYS shell. AFAIK ninja under MSYS sh.exe normally works even for pure Windows builds. Perhaps their shell does more. But as far as I remember it also does some nasty launcher overrides, intercepting calls to cmd, bat and sh and tries to process them somehow else. Do you mean some kind of dll injection to intercept CreateProcess calls? I'd really like to have a deep understanding of the situation before adding a lot of escaping code for a specialized environment. It may be that ninja simply needs to learn how to
Re: [cmake-developers] Introduce 'Unix Ninja' generator
On 01/20/2015 12:26 PM, Daniel Levin wrote: As far as I understand this 'env' is not a standard key in Ninja, right? That would be actually great to let CMake define environment variables in rules. Does CMake support that already? What about Makefile compatibility, is it possible to define env variables per rule in Makefiles? There is no model for specifying environment variables as part of build rules. We expect that environment variables required by the toolchain in use are already loaded. -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] Introduce 'Unix Ninja' generator
On 01/20/2015 10:42 AM, Daniel Levin wrote: - you need to explicitly load environment variables each time before build This is the standard approach expected by Makefile and Ninja generators. Even for builds with MSVC's cl tool we expect users to launch a command prompt with the proper PATH, INCLUDE, LIB, etc. environment variables set, and then run the build from 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] Introduce 'Unix Ninja' generator
Brad, do you think rule env variables would be a good enhancement for CMake? This actually follows existing approach: configure everything once, save into cache, build with single invocation of build tool. The difference is only in details whether to pass options as arguments or as environment variables. But for the end user both should be able to be saved in cache, because regardless whether that was env variable or CMake variable they have same meaning: it is a configure time option. Requiring user to set same env variables at build is error prone, because it is something that can be automated. P.S. My personal thumb rule is what can be automated should be automated. On Tue, Jan 20, 2015 at 12:51 PM, Brad King brad.k...@kitware.com wrote: On 01/20/2015 12:26 PM, Daniel Levin wrote: As far as I understand this 'env' is not a standard key in Ninja, right? That would be actually great to let CMake define environment variables in rules. Does CMake support that already? What about Makefile compatibility, is it possible to define env variables per rule in Makefiles? There is no model for specifying environment variables as part of build rules. We expect that environment variables required by the toolchain in use are already loaded. -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] Introduce 'Unix Ninja' generator
On 01/20/2015 01:04 PM, Daniel Levin wrote: Brad King wrote: We expect that environment variables required by the toolchain in use are already loaded. configure everything once, save into cache, build with single invocation of build tool Use of a developer-provided environment was a very early and quite fundamental design decision, and is unlikely to be changed. I'd rather this discussion focus on how to get a sh-based ninja working for your environment. Unfortunately without access to such an environment myself I do not understand it well enough to suggest the best approach. Can you provide sample ninja build files (perhaps hand written) that demonstrate invocations of the compiler and other tools, assuming it runs with the proper environment already defined? -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
[cmake-developers] Unknown CMake bugs
Some bugs of CMake (or what downstreams thinks are bug), that I was not aware of, and maybe noone else. I have no connection to any of these bugs, I just found them by accident: https://bugs.gentoo.org/show_bug.cgi?id=445308 http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/devel/cmake/patches/patch-bootstrap?rev=1.7content-type=text/x-cvsweb-markup http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/devel/cmake/patches/patch-Source_CMakeLists_txt?rev=1.6content-type=text/x-cvsweb-markuphideattic=1 signature.asc Description: This is a digitally signed message part. -- 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] [PATCH] Retrieve Xcode CompilerId via static libraries
Hello, On 12/01/15 15:00, Brad King wrote: I've made a change using that approach here: Xcode: Do not require code signing for compiler id (#15329) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=584aaa1c Works great. Do you plan to make this patch available in 3.1.1 release? Thanks, Gregor -- 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
