Re: [cmake-developers] generator expression in install RENAME
Please open an issue at https://gitlab.kitware.com/cmake/cmake/issues to request support for this. Kyle On Tue, Oct 29, 2019 at 9:58 AM Nicolas Desprès wrote: > > Hi there, > > Generator expressions are allowed in the FILES/PROGRAMS and DESTINATION part > of an install command. > > Would that be possible to enable generator expression in the RENAME part as > well? > > The use-case is for the TARGET_FILE_BASE_NAME expression. > > Cheers, > > -- > Nicolas Desprès > > -- > > 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: > https://cmake.org/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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Proposal: Using smart pointers to own dynamically allocated memory
On Fri, 2019-09-13 at 22:08 +0530, Tushar Maheshwari wrote: > Hi, > > I am a C++ developer and a modern-C++ enthusiast. In the interest of > modernizing the codebase, I propose using smart pointers to handle > dynamically allocated memory. I would like to get the feedback from > the developers if this change is planned/attempted/desirable or > inapplicable for CMake. > > Currently, in the master branch (limiting to the Source directory): > - delete expression appears 127 times (2 of those are false > positives). > $ grep -Er 'delete(\[\])? \S+;' Source | wc -l > 127 > - cmDeleteAll function (a helper to delete a Range of objects) is > used 40 times. > $ grep -Er 'cmDeleteAll\(.+\);' Source | wc -l > 40 > - [Skipping the `free` stats. I can investigate that if required.] > > Many of these are great candidates for `std::unique_ptr`. This can > reduce the destructors of many classes to default, and in some cases > achieve the rule of zero. This aligns well with the "Resource > management" section of the CppCoreGuidelines. > However, it might be impractical to replace some occurrences, like > the > interfaces with C libraries. > > I have pushed some sample commits to > https://gitlab.kitware.com/tusharpm/cmake/commits/smart_mem. > > One drawback I noticed while changing some members to use smart > pointers is the boilerplate required to expose them to the callers. > There might be a cleaner way than passing references to smart > pointers. I would like to discuss those options also, if possible. > > If this is something I can pursue, I would appreciate a review of my > changes to better suit the project. We have already made lots of progress in replacing manual delete's with std::unique_ptr's, and completing this modernization has been a goal of ours since we switched to C++11. I would very strongly encourage you to open a merge request with any progress you've made in this regard. Kyle -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] escape double quote in generated file
On Fri, 2019-08-30 at 19:01 +0300, Eugene Karpov wrote:
> Not working too.
> The failed lines in a generated make file looks like this
> ---
> CMakeFiles/mkflags_test:
> /usr/bin/cmake -DDEFINITIONS=-
> DAPI=__attribute__((visibility("default"))) -
> DFILENAME=/home/ekarpov/tmp/build/flags.txt -P
> /home/ekarpov/tmp/escape_quotes.cmake
> ---
>
> And I've tried to double quote the DEFINITIONS parameter that is
> passed to cmake - didn't help.
Please try adding the VERBATIM option to add_custom_target():
https://cmake.org/cmake/help/latest/command/add_custom_target.html
Kyle
--
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:
https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] escape double quote in generated file
On Fri, 2019-08-30 at 17:54 +0300, Eugene Karpov wrote:
> I've tried this. But then it fails to compile due to `INTERFACE
> API=${API_EXPORT_MACRO}` target compile definition.
Ah right, you want the file contents to be escaped while the compile
flags are not. My next suggestion was going to be to use a generator
expression that replaces `"` with `\"`, but there does not appear to be
a "string replace" genex. In that case, I would suggest using
add_custom_command()/add_custom_target() to call a cmake -P script
which escapes the quotes and writes the file. For example:
set(_compile_definitions
"$")
set(_compile_definitions "$<$:-
D$\n>")
add_custom_target(mkflags_${_target} COMMAND ${CMAKE_COMMAND} "-
DDEFINITIONS=${_compile_definitions}" "-DFILENAME=${_filename}" -P
path/to/script.cmake BYPRODUCTS "${_filename}")
And then the script would look like:
string(REPLACE "\"" "\\\"" DEFINITIONS "${DEFINITIONS}")
file(WRITE "${FILENAME}" "${DEFINITIONS}")
Kyle
--
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:
https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] escape double quote in generated file
On Fri, 2019-08-30 at 17:36 +0300, Eugene Karpov wrote:
> Hello all,
>
> I'm working on a cross platform project. On Ubuntu I would like to
> save all the compiler options, definitions and other complier related
> stuff to a generated file to use it later for precompiled header
> generation.
> My issue is that I have to specify a macro that contain double quotes
> for g++ compiler visibility attribute. When I generate a file with
> double quotes they are not escaped. I also tried to use
> `string(replace "\"" "\\\""...)` without effect.
> I've made simple two files project of a shared library to show the
> issue. It has only target compile definitions for simplicity.
>
> - CMakeLists.txt --
> cmake_minimum_required(VERSION 3.14)
> set(target test)
> project(${target})
> if(CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang")
> set(API_IMPORT_MACRO "__attribute__((visibility(\"default\")))")
> set(API_EXPORT_MACRO "__attribute__((visibility(\"default\")))")
The quotes here need to be double-escaped, like so:
set(API_IMPORT_MACRO "__attribute__((visibility(\\\"default\\\")))")
set(API_EXPORT_MACRO "__attribute__((visibility(\\\"default\\\")))")
Kyle
--
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:
https://cmake.org/mailman/listinfo/cmake-developers
[cmake-developers] CMake Release Candidate Builds Available for Ubuntu
All, I am pleased to announce that we are now offering Ubuntu builds of the CMake release candidates, in addition to the production releases. The first available release candidate build is 3.15.0~rc1-0kitware2. If you would like to receive release candidate builds, follow the instructions at https://apt.kitware.com/ to add the release candidate repository to your installation. (Please note that the release candidates are optional and opt-in - if you don't explicitly add the release candidate repository, you will only receive production builds.) In addition, starting with this release candidate, we are now offering 32-bit builds on Ubuntu. The steps for 32-bit Ubuntu are exactly the same as 64-bit - just add the repository to your installation and install it. Happy coding! Kyle -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ubuntu CMake Repository Now Available
On Sat, 2019-04-06 at 10:56 +0200, Rolf Eike Beer wrote: > Nice! > > The magic spell for TravisCI is: > > addons: > apt: > sources: > - sourceline: 'deb https://apt.kitware.com/ubuntu/ xenial main' > key_url: 'https://apt.kitware.com/keys/kitware-archive-2019.a > sc' > packages: > - cmake > > Or "trusty" if you still use the default distro. > > Eike Awesome! Thanks for the tip Eike! Please keep in mind that we don't officially support Trusty (though that doesn't necessarily mean the binaries won't work), and we don't have a repository named "trusty" on our server, so I don't think putting "trusty" in the source line will work. Also, it now occurs to me that we should have a "latest" key so that use cases like this don't have to change the URL every year. I have just done this, so the key URL is now: https://apt.kitware.com/keys/kitware-archive-latest.asc Kyle -- 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: https://cmake.org/mailman/listinfo/cmake-developers
[cmake-developers] Ubuntu CMake Repository Now Available
All, I am pleased to announce that Kitware is now offering an officially-supported set of Ubuntu packages for CMake. These CMake packages can be installed with apt-get, just like other Ubuntu packages. We currently support Ubuntu 16.04 and 18.04. The following packages are available: * cmake - Contains the CMake command line executable, CTest, and CPack. * cmake-curses-gui - Contains ccmake. * cmake-qt-gui - Contains cmake-gui. * cmake-doc - Contains the CMake documentation. To use these packages, follow the instructions at https://apt.kitware.com/ to add our APT repository to your Ubuntu installation, and then use apt-get install to install one or all of the above packages. We currently offer CMake 3.14.1, and will continue to update the repository as new CMake releases are issued. Kyle -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Controlling CMake GUI source/build directory from CLI
On Fri, 2019-01-25 at 14:06 -0800, Venedict Tchistopolskii wrote: > Could you clarify on saving the build-directory section? > > I'm not sure how it knows which cache or build directory to load. In > my setup here the issue I noted applies even if build directory is > generated on both projects/etc. > > VT As a convenience, cmake-gui uses a QSettings object to store the last few build directories that it configured. These directories are populated in the build directory dropdown menu. The source directories are not stored in QSettings at all, but instead extracted from the build directories. If the build directory hasn't been configured, then CMake has no way of knowing what source directory to pick. Kyle > -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Controlling CMake GUI source/build directory from CLI
On Fri, 2019-01-25 at 13:23 -0800, Venedict Tchistopolskii wrote: > Get 2 CMake projects. > > Get CMake GUI to 'configure' one of them. Close/re-open and it will > automatically point to this configured project source and build > locations, regardless of what build/version/cmake-gui.exe you use. > > Run a different cmake-gui.exe through the CLI, passing in source and > build locations. It will be properly load these instead of the 'last > configured project' now. > > Now close it, without configuring, and re-open it normally without > CLI overrides. Now it'll load the original project as if you've never > set it to a different source/build location. > > tl;dr CMake loads the last-configured source/bin directory by > default. If you don't configure (or pass override through CLI) it > will keep loading the same project. Ah, I see what you mean. Saving the build path is easy: just add the command-line path to the cache of build directories on startup as well as at configure time. Saving the source path is more difficult. The GUI gets the source directory by scanning the files in the build directory. If the build directory hasn't been generated yet, then the GUI will have no idea where to find the source directory, unless we start caching source directories as well. I think, as you noted, you're better off just triggering "Configure" before closing the dialog. Kyle > -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Controlling CMake GUI source/build directory from CLI
On Fri, 2019-01-25 at 12:55 -0800, Venedict Tchistopolskii wrote: > Cherry picked and tested. Works great, thank you! Great, glad to hear it! > Now, if only the source/build path would stick around, without requiring > config to be triggered. :P Can you clarify what you mean by this? Kyle > -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Controlling CMake GUI source/build directory from CLI
Venedict, Currently, cmake-gui only lets you specify a build or source directory, not both. I've opened https://gitlab.kitware.com/cmake/cmake/merge_requests/2863 to add explicit -S and -B options to cmake-gui, which will allow you to specify both. Kyle On Fri, 2019-01-25 at 08:10 -0800, Venedict Tchistopolskii wrote: > Actually that doesn't work. > cmake-gui.exe "D:/GitHub/SOURCE" > "D:/GitHub/SOURCE/solutions_cmake/win64" > > Ignores both options, but > cmake-gui.exe "D:/GitHub/SOURCE" > > Uses current directory as noted. Why? Syntax wrong or something? > > VT > > > On Fri, Jan 25, 2019 at 6:52 AM Kyle Edwards > m> wrote: > > On Fri, 2019-01-25 at 09:18 +0100, Gößwein Matthias / eeas gmbh > > wrote: > > > However, the manual does not describe this behavior, maybe it > > should > > > be > > > mentioned there. > > > (https://cmake.org/cmake/help/v3.13/manual/cmake-gui.1.html) > > > > Even better, perhaps we should add explicit -B and -S options the > > way > > cmake and ccmake already do. > > > > Kyle > > -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Controlling CMake GUI source/build directory from CLI
On Fri, 2019-01-25 at 09:18 +0100, Gößwein Matthias / eeas gmbh wrote: > However, the manual does not describe this behavior, maybe it should > be > mentioned there. > (https://cmake.org/cmake/help/v3.13/manual/cmake-gui.1.html) Even better, perhaps we should add explicit -B and -S options the way cmake and ccmake already do. Kyle -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Compiling static/stand-alone CMake.exe
On Thu, 2019-01-24 at 12:31 -0800, Venedict Tchistopolskii wrote: > Nevermind, fixed the cmake-gui. Ah OK, then disregard my response. > Would be nice to know how to triger the proper install/release config from > VStudio, atm I do this: > cmake . --target install --config Release This looks correct for doing it on the command line. The VStudio solution should have an "INSTALL" project which does what you want. Kyle > -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Compiling static/stand-alone CMake.exe
On Thu, 2019-01-24 at 12:25 -0800, Venedict Tchistopolskii wrote: > The install command auto-installs release right? > How do I trigger this 'install' from VStudio? > Is building in VStudio enough before install? > e.g. generate solution -> build in VStudio -> run install > command in CLI? Yes, this will work. > Just not sure on the proper flow because I use VStudio to debug/modify/test > CMake. Usually debugging etc. is done on the .exe inside the build tree, rather than the install tree. > Additionally with this setup cmake-gui.exe can't find Qt5widgets etc. no > matter what I do. You mean at build-time, or at runtime? > It finds it if I use the .exe built by VStudio. Does the one in VStudio have all the Qt DLLs beside it in the directory? Kyle > -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Compiling static/stand-alone CMake.exe
On Thu, 2019-01-24 at 12:36 -0500, Kyle Edwards wrote: > cmake --build . --target install > windeployqt C:/Path/To/Where/I/Want/To/Install/bin/cmake.exe Oops - this should obviously be C:/Path/To/Where/I/Want/To/Install/bin/cmake-gui.exe. Kyle-- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Compiling static/stand-alone CMake.exe
On Thu, 2019-01-24 at 09:27 -0800, Venedict Tchistopolskii wrote: > Er, lemme clarify. > > Can cmake-gui.exe be built along with cmake if using the install path > setting? I currently use windeployqt to handle gui dependencies. Yes, like I mentioned, just build with BUILD_QtDialog=ON. You can then run windeployqt after running cmake --build . --target install: cmake --build . --target install windeployqt C:/Path/To/Where/I/Want/To/Install/bin/cmake.exe Kyle > -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Compiling static/stand-alone CMake.exe
On Thu, 2019-01-24 at 09:23 -0800, Venedict Tchistopolskii wrote: > I was building it via VStudio and generating the solution via CMake, > is that wrong? Nope! You're building it just fine. The only problem is in the installation - you were installing cmake.exe without all of the external files it needs. Running cmake --build . --target install will take care of this for you. > I need cmake-gui.exe to be built too, would that work with this install path > setting? Yes. You just need to make sure BUILD_QtDialog is turned ON: cmake C:/Path/To/CMake/Source -DCMAKE_INSTALL_PREFIX=C:/Path/To/Where/I/Want/To/Install -DBUILD_QtDialog=ON Keep in mind that you will need a Qt installation to build cmake-gui. Kyle > -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Compiling static/stand-alone CMake.exe
I forgot to mention - building it this way doesn't require the use of a toolchain file - it was in response to this: > Trying to do so because building CMake without toolchain gives me the below; After I move cmake.exe to another directory: If you build it as I laid out below, you won't need a toolchain file. Hope this helps! Kyle On Thu, 2019-01-24 at 12:09 -0500, Kyle Edwards wrote: > Venedict, > > To relocate cmake.exe, it's not sufficient to just copy the > executable - you have to install all of the modules along with it. > You do this by running the "install" target. > > Given a path to where you want to put CMake, you would build it like > this: > > cmake C:/Path/To/CMake/Source > -DCMAKE_INSTALL_PREFIX=C:/Path/To/Where/I/Want/To/Install > cmake --build . > cmake --build . --target install > > This will install cmake.exe along with all of its dependencies. > > Kyle > > On Thu, 2019-01-24 at 08:42 -0800, Venedict Tchistopolskii wrote: > > Hey there! > > > > Current toolchain file for compiling CMake using CMake (on > > WIndows): > > SET(CMAKE_SYSTEM_NAME Windows) > > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) > > set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) > > set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) > > set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) > > set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) > > > > Unfortunately this konks out with: > > CMake Error: The following variables are used in this project, but > > they are set to NOTFOUND. > > Please set them or make sure they are set and tested correctly in > > the CMake files: > > LIBMD_LIBRARY > > linked by target "cmTC_356fd" in directory > > D:/GitHub/custom_cmake/solutions_cmake/CMakeFiles/CMakeTmp > > > > Trying to do so because building CMake without toolchain gives me > > the below; After I move cmake.exe to another directory: > > CMake Error: Could not find CMAKE_ROOT !!! > > CMake has most likely not been installed correctly. > > Modules directory not found in > > > > Usage > > > > cmake [options] > > cmake [options] > > cmake [options] -S -B > > > > Specify a source directory to (re-)generate a build system for it > > in the > > current working directory. Specify an existing build directory to > > re-generate its build system. > > > > Run 'cmake --help' for more information. > > > > Please advise!! > > > > VT > > > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: http://ww > > w.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: > > https://cmake.org/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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Compiling static/stand-alone CMake.exe
Venedict, To relocate cmake.exe, it's not sufficient to just copy the executable - you have to install all of the modules along with it. You do this by running the "install" target. Given a path to where you want to put CMake, you would build it like this: cmake C:/Path/To/CMake/Source -DCMAKE_INSTALL_PREFIX=C:/Path/To/Where/I/Want/To/Install cmake --build . cmake --build . --target install This will install cmake.exe along with all of its dependencies. Kyle On Thu, 2019-01-24 at 08:42 -0800, Venedict Tchistopolskii wrote: > Hey there! > > Current toolchain file for compiling CMake using CMake (on WIndows): > SET(CMAKE_SYSTEM_NAME Windows) > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) > set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) > set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) > set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) > set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) > > Unfortunately this konks out with: > CMake Error: The following variables are used in this project, but > they are set to NOTFOUND. > Please set them or make sure they are set and tested correctly in the > CMake files: > LIBMD_LIBRARY > linked by target "cmTC_356fd" in directory > D:/GitHub/custom_cmake/solutions_cmake/CMakeFiles/CMakeTmp > > Trying to do so because building CMake without toolchain gives me the > below; After I move cmake.exe to another directory: > CMake Error: Could not find CMAKE_ROOT !!! > CMake has most likely not been installed correctly. > Modules directory not found in > > Usage > > cmake [options] > cmake [options] > cmake [options] -S -B > > Specify a source directory to (re-)generate a build system for it in > the > current working directory. Specify an existing build directory to > re-generate its build system. > > Run 'cmake --help' for more information. > > Please advise!! > > VT > > > -- > > 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/op > ensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Referencing all sources in compile command
On Sun, 2018-12-30 at 13:09 -0800, Saleem Abdulrasool wrote: > Hi, > > I was looking at supporting Swift as a language in CMake. I know > that CMake has some preliminary support that assumes that you are > building on macOS with Xcode. I am trying to support building swift > libraries and executables on Linux and Windows. > > There is some preliminary work on this that I have put up on GitHub > [1]. One place that I am hitting a roadblock in is the need to > reference all the target sources in the compile rule for a single > object. AFAICT, there is no placeholder that will expand to the > target sources. Would it be acceptable to add a `` > place holder? Or is there another approach that would be better? > > Thanks. > > [1] https://github.com/compnerd/cmake-swift > > -- > Saleem Abdulrasool > compnerd (at) compnerd (dot) org > -- > > 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/op > ensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake-developers Saleem, Not sure if this will help, but have you taken a look at the $ generator expression? https://cmake.org/cmake/help/v3.13/manual/cmake-generator- expressions.7.html#output-expressions Kyle-- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Idea for Multi-Toolchain Support
On Sat, 2018-12-22 at 16:57 +0100, Torsten Robitzki wrote: > What I’m still missing is support to define dependencies between > different targets (build by different toolchains), so that I can > describe that I require a tool that is build with the HostToolChain, > to generate a file that is required by the part of the build, that is > using the CrossToolChain. And, of cause, if the source of that tool > changes, that tool have to be rebuild and the generated file from the > CrossToolChain part of the build have to be rebuild. What about add_dependencies()? Is that sufficient, or is there something more that you need? Kyle -- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Idea for Multi-Toolchain Support
On Tue, 2018-12-18 at 20:53 -0500, frodak17 wrote: > I have thought about it which is why I asked. The original > assumption of one toolchain per CMake project is being extended. So > why not think of extending the build type. Sure it's simpler to > ignore the build type. However, it doesn't make sense to me to build > and run a host tool in debug mode when it could be running faster if > built in release mode. This is independent of whatever I'm doing > with cross-compiler targets. You're already updating the generator to > pick and choose the proper flags just on the tool chain type and it > already picks the correct flags based on the configuration type. But > instead of the generator looking at the global build type it looks at > the target build type. The target build type could default to the > global build type and be overridden via a property. > > Multi config generators would be problematic if they don't have a > Configuration Manager that allows for setting different projects with > different configurations (like Visual Studio) but is that reason > enough to exclude the idea for single configuration generators? I suppose we could consider the idea of supporting this separation for single-config generators, but I can't think of a good way to make it work for multi-config generators. > If this can already be simply done why is anyone asking to use multiple > toolchains in a single project? You just use an ExternalProject with each > toolchain file and you're done, or is this a shortcut method instead of using > ExternalProject to build the host tool? You can use ExternalProject, but it's a bit like using a chainsaw when all you need is a scalpel. Multi-toolchain would make it easy to keep host tools and target code in the same project in the *simple* case (like the Linux kernel example I gave in a previous email.) If you want to do something more complicated then ExternalProject would be your best bet. Kyle-- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Idea for Multi-Toolchain Support
On Tue, 2018-12-18 at 16:12 -0500, frodak17 wrote: > So it would be something like project( [TOOLCHAIN > [LANGUAGES] [...]) where TOOLCHAIN > and its supported languages can be repeated for each tool chain. i.e > project(whatever TOOLCHAIN default LANGUAGES cpp TOOLCHAIN cross > LANGUAGES c) I think this sounds about right. > But isn't this all (or mostly) cached so you don't have to redo all this when > regenerating build files. I guess it would be CMAKE___* ? Good point about caching, I did not think of that. Perhaps we need some separate caching mechanism for toolchain properties - or perhaps the properties could be loaded from undocumented cache variables defined only for CMake's internal use. > What about conflicting build types when building a host tool target vs the > cross compiler target? > For instance the host tool may (should?) be built as a release project > (default optimization levels) but the cross compiler project could be built > as a debug project (so you can debug it with no optimizations)? > I guess it would then be CMAKE__BUILD_TYPE and then targets using that > toolchain would be built with that build type. I think that both host and cross targets would be built with the same build type. If you're using a multi-config generator like VS or Xcode, how do you specify which combination of configs you want? It's simpler if every target is built as the same type, whether it's host or cross. Think about it - the current system already expects that every target in the project is built as the same build type. There's no way to specify "foo is built as debug, bar is built as release." Why would this assumption change just because we add a multi-toolchain mechanic? > On the other hand this doesn't really help anyone working with mixed build > systems. What you can't do in a straight forward manner is host tool > development with Visual Studio or Eclipse, execute it and use it's results > with a cross compiler (that uses Ninja or Makefiles) targeting an embedded > system. Every target would be built by the same generator regardless of whether it's a host or cross target. So if you select the VS generator, both the host tools and the embedded software would be built in VS (if this is possible.) Likewise for Ninja and Make. > In this case I think that what you want is to easily control multiple > projects using different build systems, the inter-dependencies, and > easily specify that external project A produces a file for external > project B. Ideally you would be in the root of the build folder and > type 'cmake --build .' and have it take care of everything with > minimal extraneous build tool executions or sometimes even invoking > the build tool in parallel for external projects that don't depend on > each other. > If you want to build different parts of the software with different generators (build systems) then you're better off using a superbuild with ExternalProject. The intent of this proposal is to allow users to build both host tools and cross-compiled software in the same build tree with the same generator. As an example of a real-world project, I would like to emulate the Linux kernel's separation of host and cross compiler. The vast majority of files in the kernel source tree are built with a single cross compiler, while a very small set of host tools are built with the host compiler. Both the host tools and the kernel itself are built using the same Makefile, and there's no ExternalProject-like separation between them. The kernel's buildsystem only supports Makefiles and can't generate Ninja, VS, etc., but if it did, then both the host tools and the kernel would be built with the same Ninja files/VS solution. I don't remember whether it supports building the host tools and kernel as separate types (debug vs release), but for sake of simplicity, I'd rather not try to support that, especially in multi-config generators. Kyle-- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Idea for Multi-Toolchain Support
On Tue, 2018-12-18 at 14:10 -0500, frodak17 wrote: > How does this work with multiple languages and the project() command > and enable_language() commands? Both project() and enable_language() could be extended with an optional TOOLCHAIN argument. > For instance you want to use the host c++ compiler and a toolchain > specified compiler for c and c++. > When project() enables the c++ compiler it runs through a bunch of scripts to > find and test the compiler also setting several CMAKE__* variables to use > that compiler. These variables also happen to be the default compile options > for the build types when using that compiler. The point of this idea is to get rid of the old variable-based system and have everything instead be a property of a toolchain. So the scripts would set properties of the default toolchain instead of setting variables. > Then the same thing happens with the tool-chain specified compiler > for these languages how do you track that the variables are different > for these two toolchains? > Are these variables now project scoped and for any given project it > is limited to one toolchain per language per project? > See above. Kyle-- 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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Idea for Multi-Toolchain Support
On Tue, 2018-12-18 at 06:14 -0500, frodak17 wrote:
> What first cross my mind with '"utilities" needed for build' is when
> you have to build the cross-compiler in the first place before you
> build anything for the target.
> If so how do you handle verification of the tool-chain can build a
> working executable or library?
> Normally that is done at the time before project files are generated
> but it has to either be skipped or delayed because the toolchain
> doesn't even exist because it has to be built first by the host
> tools. For tool-chains that already exist on the host machine then
> add_toolchain() command is when you can test and verify its
> functionality?
Yes, add_toolchain() would do all the same checks that happen on the
"main" toolchain when CMake starts up. The process would be:
1) add_toolchain() gets called with a FILE argument
2) the file gets loaded the same way CMAKE_TOOLCHAIN_FILE does on
startup
3) CMake performs all the same checks that it did with the "main"
toolchain
4) add_toolchain() returns and script execution resumes
So you could build the cross toolchain during configure-time and then
add it with add_toolchain(). However, I would recommend having the
toolchain build and the actual project be separate CMake projects in
order to maintain separation of responsibilities. At the very least,
I'd recommend that the cross-compiled project be a subdirectory of the
superbuild via add_subdirectory(), and the toolchain would be built in
the top directory.
> Do these targets automatically get separate binary directories so
> that the outputs don't overwrite each other?
No. In this feature, each target would get one toolchain, and *only*
one toolchain. If you want to build the same target with multiple
toolchains, you would build them as separate targets. Example:
add_executable(foo-arm foo.c bar.c TOOLCHAIN ArmToolchain)
add_executable(foo-x86_64 foo.c bar.c TOOLCHAIN x86_64Toolchain)
This could of course be abstracted away with a function():
function(make_foo toolchain)
add_executable(foo-${toolchain} foo.c bar.c TOOLCHAIN ${toolchain})
endfunction()
make_foo(arm)
make_foo(x86_64)
My reasoning for this is that each .c/.cxx file has to be built
multiple times (once for each toolchain) anyway, so why bother trying
to make them part of the same target? Just make them separate targets.
> I assume this feature is limited only to ninja or makefile
> generators?
If Visual Studio and/or Xcode support multiple toolchains (I don't know
if they do) then it could work for them too. If not then they would
unfortunately be out of luck for multi-toolchain projects.
Kyle--
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:
https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] Idea for Multi-Toolchain Support
Eric,
Thanks for the feedback. See comments below.
On Mon, 2018-12-17 at 22:06 +0100, Eric Noulard wrote:
> > This has some common design issue as my proposal:
> > enable_cross_target(...)
> > for which Eike has valuable doubt:
> > https://cmake.org/pipermail/cmake-developers/2018-November/030919.h
> > tml
If you're talking about the issue of specifying multiple toolchain
files on the command line, I'm imagining a design like this:
add_toolchain(TargetToolchain FILE ${CMAKE_TOOLCHAIN_FILE_TARGET})
and then specify it on the command line with:
cmake ../src -DCMAKE_TOOLCHAIN_FILE=/path/to/host/toolchain.cmake
-DCMAKE_TOOLCHAIN_FILE_TARGET=/path/to/target/toolchain.cmake
> > So if you want to build both for host and cross toolchain you'll have to
> > explicitely
> > add_executable/library(MyLibrary TOOLCHAIN DEFAULT)
> > add_executable/library(MyLibrary TOOLCHAIN CrossToolchain)
> > > > If you follow the previously referred discussion you cannot assume that
> > > > one lib/exe
> > built for a toolchain is not built for another toolchain as well.
If you want to build the same target with multiple toolchains then I
think you're better off declaring them as different targets, with
different TOOLCHAINs but the same source files, etc.
> > ... sorry wrong key pressed...
> > > > CMake could perfectly automatically create the new "TOOLCHAIN" object
> > > > by loading the very
> > same toolchain file as we have today. We could simple add a new variable
> > CMAKE_TOOLCHAIN_NAME in that file so that CMake (and the user) can name
> > them as he wants.
> > When there is no CMAKE_TOOLCHAIN_NAME this would be the default
> > toolchain.
>
My vision for this feature is that the project specifies the names of
the toolchains that it's expecting, and the toolchain file is agnostic
of this - it simply sets the properties of the toolchain named
${CMAKE_SELECTED_TOOLCHAIN}.
If you want to have a variable number of toolchains, you could do
something like this:
set(PROJECT_TARGET_TOOLCHAIN_NAMES "" CACHE STRING "Names of
toolchains")
foreach(i ${PROJECT_TARGET_TOOLCHAIN_NAMES})
add_toolchain(${i} FILE ${CMAKE_TOOLCHAIN_FILE_${i}})
add_executable(foo-${i} TOOLCHAIN ${i} ...) # Build a copy of foo for
each target platform
endforeach()
Kyle--
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:
https://cmake.org/mailman/listinfo/cmake-developers
[cmake-developers] Idea for Multi-Toolchain Support
Hello everyone,
One of the things that's long been requested of CMake is the ability to
have multiple toolchains - for instance, one host toolchain and one
cross toolchain, so that "utilities" needed for build can be built with
the host toolchain and then the "real" software can be built with the
cross toolchain.
To solve this problem, I would like to propose the creation of a new
first-class object type, the "toolchain" type, which would replace the
current variable-based system, similar to how imported targets replaced
variable-based usage requirements.
Every project would automatically receive one toolchain, the "DEFAULT"
toolchain, which would be either automatically configured or configured
based on CMAKE_TOOLCHAIN_FILE, just like the current system. New
toolchains could be added with the add_toolchain() command:
add_toolchain(CrossToolchain FILE /path/to/toolchain/file.cmake)
Then, executables and libraries could have a toolchain specified:
add_executable(BuildUtility TOOLCHAIN DEFAULT ...)
add_library(MyLibrary TOOLCHAIN CrossToolchain ...)
Note that the TOOLCHAIN argument is optional, and if omitted, the
DEFAULT toolchain is used.
If a project uses multiple toolchains, we could have the option to
rename the default toolchain with an alternative add_toolchain()
syntax:
add_toolchain(HostToolchain DEFAULT)
Rather than adding a new toolchain, this would simply rename the
"DEFAULT" toolchain to "HostToolchain". Then the toolchain
specification for each target could look like this:
add_executable(BuildUtility TOOLCHAIN HostToolchain ...)
add_library(MyLibrary TOOLCHAIN CrossToolchain ...)
Two new global read-only properties would be added: TOOLCHAINS and
DEFAULT_TOOLCHAIN. TOOLCHAINS would be a semicolon-separated list of
all registered toolchains, and DEFAULT_TOOLCHAIN would be the name of
the DEFAULT toolchain (which could be changed with the alternative
add_toolchain() syntax.)
The CMAKE_TOOLCHAIN_FILE format would be changed so that rather than
setting variables:
set(CMAKE_C_COMPILER /usr/bin/gcc)
set(CMAKE_C_COMPILER_ID gnu)
# etc.
it would instead set properties on the selected toolchain:
set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY C_COMPILER
/usr/bin/gcc)
set_property(TOOLCHAIN ${CMAKE_SELECTED_TOOLCHAIN} PROPERTY
C_COMPILER_ID gnu)
# etc.
where CMAKE_SELECTED_TOOLCHAIN is a variable passed to the toolchain
file either at the root or by the add_toolchain() command.
If you want to read the value of C_COMPILER, etc. then just use
get_property():
get_property(c_compiler TOOLCHAIN HostToolchain PROPERTY C_COMPILER)
Obviously this system would scale well to more than just two toolchains
- just use as many add_toolchain() commands as you need.
Backwards compatibility is going to be a challenge. Both the toolchain
file and the project have to be aware of the new toolchain system,
which means we have to handle four permutations:
1) old toolchain + old project
2) old toolchain + new project
3) new toolchain + old project
4) new toolchain + new project
I propose adding a policy that both the toolchain file and the project
can set separately, and which would have a slightly different meaning
in each one. If the toolchain is OLD and the project is NEW, then the
variables set by the toolchain file would be converted into properties
on the toolchain for the project. If the toolchain is NEW and the
project is OLD, then the properties on the toolchain would be converted
into variables in the project. If both the toolchain and project have
the same value, then no special conversion is required.
I would welcome everyone's feedback on this proposal. Obviously this is
a big change to how CMake handles toolchains, and would require a lot
of very deep refactoring.
Kyle
--
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:
https://cmake.org/mailman/listinfo/cmake-developers
