[Cmake-commits] CMake branch, master, updated. v3.13.0-rc3-372-g9474496
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 94744965f810958b58d94d4b3e4f67566b392396 (commit) from 48bc74710d4ddcf62e3dcf69e3400e4060a2bdc1 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=94744965f810958b58d94d4b3e4f67566b392396 commit 94744965f810958b58d94d4b3e4f67566b392396 Author: Kitware Robot AuthorDate: Sat Nov 10 00:01:05 2018 -0500 Commit: Kitware Robot CommitDate: Sat Nov 10 00:01:05 2018 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 3671d53..d164a6d 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 13) -set(CMake_VERSION_PATCH 20181109) +set(CMake_VERSION_PATCH 20181110) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[CMake] Generating libtool file with CMake
Hi ! I'm trying to port the LibVMI project from autotools to CMake: https://github.com/libvmi/libvmi/pull/674 One of the problems I have is to generate a libtool libvmi.la file, like autotools is already doing. So far I have found this module on CMake wiki: https://gitlab.kitware.com/cmake/community/wikis/contrib/macros/LibtoolFile But it seems a bit old. CMake Error at cmake/modules/Libtool.cmake:9 (GET_TARGET_PROPERTY): The LOCATION property may not be read from target "vmi_shared". Use the target name directly with add_custom_command, or use the generator expression $, as appropriate. Call Stack (most recent call first): libvmi/CMakeLists.txt:127 (create_libtool_file) I found an updated version of this script on the GNU Radio project: https://github.com/gnuradio/gnuradio/blob/master/cmake/Modules/CMakeMacroLibtoolFile.cmake But again, another error: CMake Error: Error evaluating generator expression: $ Expression syntax not recognized. -> Can the CMake community help me a bit to generate this libtool file on a recent CMake release ? Thanks ! -- Mathieu Tarral Sent with ProtonMail Secure Email. -- 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
Re: [CMake] INTERFACE_LINK_LIBRARIES/LINK_INTERFACE_LIBRARIES
In other words, when providing the EXPORT_LINK_INTERFACE_LIBRARIES flag for exported targets (in main project that was changed to CMP0022 NEW), I was expecting the IMPORTED_LINK_INTERFACE_LIBRARIES property set in the .cmake file so that projects that import it (with CMP0022 OLD) can see it. Instead, I am only seeing the INTERFACE_LINK_LIBRARIES property set. On Fri, Nov 9, 2018 at 1:58 PM Hendrik Greving < hendrik.greving@gmail.com> wrote: > If CMP0022 is set to new, since project is still using > LINK_INTERFACE_LIBRARIES I have added EXPORT_LINK_INTERFACE_LIBRARIES to > install(EXPORT) and export() calls. Looking at the generated exported cmake > files, I only see the INTERFACE_LINK_LIBRARIES link property set. There are > downstream projects that are using the previously mentioned project > importing targets from it. These downstream projects still have CMP0022 set > to OLD. Will this work? My understanding is that these downstream projects > now don't see the linked libraries since they will ignore > INTERFACE_LINK_LIBRARIES? > > Is it possible to achieve both, and have the main project generate the > LINK_INTERFACE_LIBRARIES > properties with CMP0022 set to NEW? > -- 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
[CMake] INTERFACE_LINK_LIBRARIES/LINK_INTERFACE_LIBRARIES
If CMP0022 is set to new, since project is still using LINK_INTERFACE_LIBRARIES I have added EXPORT_LINK_INTERFACE_LIBRARIES to install(EXPORT) and export() calls. Looking at the generated exported cmake files, I only see the INTERFACE_LINK_LIBRARIES link property set. There are downstream projects that are using the previously mentioned project importing targets from it. These downstream projects still have CMP0022 set to OLD. Will this work? My understanding is that these downstream projects now don't see the linked libraries since they will ignore INTERFACE_LINK_LIBRARIES? Is it possible to achieve both, and have the main project generate the LINK_INTERFACE_LIBRARIES properties with CMP0022 set to NEW? -- 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
Re: [CMake] CPack disable build all
Le ven. 9 nov. 2018 à 17:22, DKLind a écrit : > I have a very large project where each sub-project creates a debian > package. > > When "make/ninja package" is specified, it performs a "make/ninja all" > before packaging. I would prefer to perform a "make/ninja all" myself > before > I doing a "make/ninja package". > > I want to create a package for just one target. I can use "cpack -D > CPACK_COMPONENTS_ALL=" to do this but, CPack takes a long time to > create the package. I can only surmise that CPack is building everything in > the background, as there is no output. If I have everything build BEFORE i > run "cpack -D CPACK_COMPONENTS_ALL=", it completes in seconds. > I'm almost sure that when invoked on itself like: cpack -G TGZ cpack does not build at all. cpack does install but AFAIK it does not trigger the build. you can try: ninja clean cpack -V -G TGZ and I'm pretty sure CPack will fail because it won't find the expected bits to be installed precisely because they are not built. Note that using "-V" verbose option of CPack you'll more traces of what CPack does. > Is it possible to disable CPack from building everything? > If you observe that could you send us a stripped down project that exhibit this behavior? -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] option to prevent in-source builds
Just a small remark to say this request of "builtin" way to forbid in-source is quite old: https://gitlab.kitware.com/cmake/cmake/issues/6672 which find its origin in: https://cmake.org/Bug/view.php?id=6672 I don't know if the note from that initial discussion are valid nowadays but the fact that: "Code in CMakeLists.txt is not even executed until after the cache is initialized so there would have to be some other way to indicate in the source tree that it should not be built in-source." and the fact that "The cache is initialized before the procedural steps start to run. With cmake-gui or the cmake command-line "-D" option it is even possible to store entries in the cache before CMake even parses CMakeLists.txt" almost implies that this should be done outside CMakeLists.txt That said, I think that I would rather have some obviously visible and fixed place like CMakeInit.json that should be located in the very same directory as the concerned CMakeLists.txt rather than some list of possible places (cmake/, cmake/init, .cmake, etc...). The exact path to CMakeInit.json could be overwritten by some new command line option, like --init-file if for some reason we want a configurable place (may be used in various CI scripts occasion). This file could hold more options than "just forbid in-source" it could indicate a default generator (which may be different from the usual default generator on the concerned platform), some a toolchain. It's usage would be different than the initial cache precisely because it could work before cache is created. Le ven. 9 nov. 2018 à 17:03, Ben Boeckel a écrit : > On Fri, Nov 09, 2018 at 07:28:54 -0500, Taylor Holberton wrote: > > A lot of projects that use CMake already have a `./cmake` directory, I > > would think `./cmake/init.json` would fit nicer as opposed to the hidden > > directory. I'm not a fan of hidden directories in software projects > anyway. > > There are also `./CMake` directories. HDF5 uses `./config/cmake`. I > think just claiming a "hidden" directory with exact casing is better. > > --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: > https://cmake.org/mailman/listinfo/cmake-developers > -- 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: https://cmake.org/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, release, updated. v3.13.0-rc3-2-gcda0b14
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, release has been updated via cda0b14ec32ad3d3aa67dd12d75aa34ffb1bcd19 (commit) via bd831ed0948a1e99f573f0056f2bee5d3b21009e (commit) from 8d70ed5a10362209d265a15d993f319235aea7e5 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - --- Summary of changes: Modules/FindBoost.cmake | 3 +++ 1 file changed, 3 insertions(+) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.13.0-rc3-371-g48bc747
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 48bc74710d4ddcf62e3dcf69e3400e4060a2bdc1 (commit) via cda0b14ec32ad3d3aa67dd12d75aa34ffb1bcd19 (commit) from a02712840021706cea43bd10ebf742ef38c8f710 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=48bc74710d4ddcf62e3dcf69e3400e4060a2bdc1 commit 48bc74710d4ddcf62e3dcf69e3400e4060a2bdc1 Merge: a027128 cda0b14 Author: Brad King AuthorDate: Fri Nov 9 11:45:09 2018 -0500 Commit: Brad King CommitDate: Fri Nov 9 11:45:09 2018 -0500 Merge branch 'release-3.13' --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.13.0-rc3-369-ga027128
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via a02712840021706cea43bd10ebf742ef38c8f710 (commit)
via bd831ed0948a1e99f573f0056f2bee5d3b21009e (commit)
from 65522e5e0ef95b7424714ec4d67345bf00e9b8bd (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a02712840021706cea43bd10ebf742ef38c8f710
commit a02712840021706cea43bd10ebf742ef38c8f710
Merge: 65522e5 bd831ed
Author: Brad King
AuthorDate: Fri Nov 9 16:38:01 2018 +
Commit: Kitware Robot
CommitDate: Fri Nov 9 11:38:07 2018 -0500
Merge topic 'FindBoost-link-threads'
bd831ed094 FindBoost: Add system thread library to Boost_LIBRARIES
Acked-by: Kitware Robot
Merge-request: !2570
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd831ed0948a1e99f573f0056f2bee5d3b21009e
commit bd831ed0948a1e99f573f0056f2bee5d3b21009e
Author: Felix Geyer
AuthorDate: Tue Nov 6 18:33:43 2018 +0100
Commit: Brad King
CommitDate: Fri Nov 9 10:38:45 2018 -0500
FindBoost: Add system thread library to Boost_LIBRARIES
Add the system thread library to Boost_LIBRARIES when the boost thread
component has been found.
The Boost::thread imported target already pulls in Threads::Threads.
This changes does the same for projects using the Boost_LIBRARIES variable
instead.
diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index e983941..0794a6f 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -2074,6 +2074,9 @@ if(Boost_FOUND)
message (STATUS " ${COMPONENT}")
endif()
list(APPEND Boost_LIBRARIES ${Boost_${UPPERCOMPONENT}_LIBRARY})
+ if(COMPONENT STREQUAL "thread")
+list(APPEND Boost_LIBRARIES ${CMAKE_THREAD_LIBS_INIT})
+ endif()
endif()
endforeach()
else()
---
Summary of changes:
Modules/FindBoost.cmake | 3 +++
1 file changed, 3 insertions(+)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits
[CMake] CPack disable build all
I have a very large project where each sub-project creates a debian package. When "make/ninja package" is specified, it performs a "make/ninja all" before packaging. I would prefer to perform a "make/ninja all" myself before I doing a "make/ninja package". I want to create a package for just one target. I can use "cpack -D CPACK_COMPONENTS_ALL=" to do this but, CPack takes a long time to create the package. I can only surmise that CPack is building everything in the background, as there is no output. If I have everything build BEFORE i run "cpack -D CPACK_COMPONENTS_ALL=", it completes in seconds. Is it possible to disable CPack from building everything? -- Sent from: http://cmake.3232098.n2.nabble.com/ -- 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
Re: [cmake-developers] option to prevent in-source builds
On Fri, Nov 09, 2018 at 07:28:54 -0500, Taylor Holberton wrote: > A lot of projects that use CMake already have a `./cmake` directory, I > would think `./cmake/init.json` would fit nicer as opposed to the hidden > directory. I'm not a fan of hidden directories in software projects anyway. There are also `./CMake` directories. HDF5 uses `./config/cmake`. I think just claiming a "hidden" directory with exact casing is better. --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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] dependencies of cross compiliations
There are two options. Each with pros and cons. The first what you are doing now, except you use external project https://cmake.org/cmake/help/v3.12/module/ExternalProject.html to build the host tools instead of add_custom_command. It otherwise has all the cons you mention, but are they significant (this is a question that is different for each project)? Going back to the manual build for host before the target isn't bad, though it is harder to teach. The second is to use a package/dependency manager to setup your build environment with all tools. In this approach the host tools would be in a separate source control repository and the package manager will download the latest binaries. Conan.io comes to mind as a tool to do this, but there are at least a dozen others that you can choose from (or write your own if you have a year to spend) . This approach is much more complex, but these systems offer many other features that are often compelling. I would recommend you spend some time researching the package/dependency manager tools available. It is likely that you (or your team) will look at some feature completely unrelated to your question and say "This is a good solution to our problem". At that point your question changes from "how do I best make cmake do this" to "how do I do this in my new package manager". If after a review nothing stands out, your approach is perfectly fine, the only question is it worth tweaking. -Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Torsten Robitzki Sent: Friday, November 9, 2018 3:04 AM To: cmake@cmake.org Subject: [CMake] dependencies of cross compiliations Hi, I hope this question was not asked before. I work in the embedded field and there it is usually to have at least two different build platforms. The Host platform, where unit tests are build (and where CMake is running) and an embedded Target platform, where targets are build with a cross compiler. Sometimes such a system comes with self-written tools that are build and run on the Host platform to build a target for the embedded Target platform (adding meta data to a binary to be used by a bootloader for example). Usually I have two different build folders, one for the Host platform and one for the Target platform, using different calls to cmake to choose from a set of tools and targets. But when using this approach, it is necessary that the Host platform build ran before the Target platform build, so that tools that are required for the Target platform are build during the Host target build. One solution I’ve came up with, is to build the required tools during the Target platform build, using an add_custom_target() to invoke the Target compiler directly. This works fine, as long as the tools are basically build just out of a couple of files. What would be the „CMake-Way“ to add the tools (that have to be build on the Target platform) as dependency to targets that have to be build for the Target (cross compile) platform? Kind regards and thanks in advance, Torsten -- 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 -- 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
[Cmake-commits] CMake branch, master, updated. v3.13.0-rc3-367-g65522e5
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via 65522e5e0ef95b7424714ec4d67345bf00e9b8bd (commit)
via 9463d73cc4d58b190fac0cac6aeee424b5d29514 (commit)
via f29e2292c90d4fbdadce041b1c9d649aca3c602b (commit)
via 860338491ee96274ac110459b3b316149d4585f7 (commit)
via e855bd5248bbb7b77b45e269e4fa098b29c9e889 (commit)
via 8ba2a8d4a415d2288786a0d56e90b3d7693ad32e (commit)
via 85498fccd8ac1dd7345d995e52e1bf63d663071e (commit)
via e24ef9694275b9345bf08cf46ca1cf064b34813b (commit)
via e4554149c476e9eb9fe00368b2ac1ac7ac9ffe5c (commit)
via 3de551cc22bf80f63ec9f05e3e934f42f79b8965 (commit)
via eba7273c203f0698ccd716604cc298b7da1d3ee6 (commit)
from 8db4bd115c566460986ddd2f7a8f4f90ee5baf26 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=65522e5e0ef95b7424714ec4d67345bf00e9b8bd
commit 65522e5e0ef95b7424714ec4d67345bf00e9b8bd
Merge: 9463d73 f29e229
Author: Brad King
AuthorDate: Fri Nov 9 15:37:07 2018 +
Commit: Kitware Robot
CommitDate: Fri Nov 9 10:37:14 2018 -0500
Merge topic 'cpack-improve-unknown-generator-error'
f29e2292c9 cpack: When given an unknown generator print out all valid
generators
eba7273c20 cpack: Better error message when generator doesn't exist.
Acked-by: Kitware Robot
Acked-by: David Cole
Merge-request: !2580
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9463d73cc4d58b190fac0cac6aeee424b5d29514
commit 9463d73cc4d58b190fac0cac6aeee424b5d29514
Merge: 8db4bd1 8603384
Author: Brad King
AuthorDate: Fri Nov 9 15:34:40 2018 +
Commit: Kitware Robot
CommitDate: Fri Nov 9 10:35:28 2018 -0500
Merge topic 'env'
860338491e Help: Describe $CACHE and $ENV as operators
e855bd5248 Help: Document if(DEFINED ENV{name})
8ba2a8d4a4 Help: short/long variable reference in if command
85498fccd8 Help: Provide backreferences.
e24ef96942 Help: New section on Environment Variables in cmake-language.7
e4554149c4 Help: Remove over-precise clause.
3de551cc22 Help: Clarify effect of set(ENV{..} ..) and unset(ENV{..})
Acked-by: Kitware Robot
Merge-request: !2538
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f29e2292c90d4fbdadce041b1c9d649aca3c602b
commit f29e2292c90d4fbdadce041b1c9d649aca3c602b
Author: Robert Maynard
AuthorDate: Thu Nov 8 09:27:28 2018 -0500
Commit: Brad King
CommitDate: Thu Nov 8 19:07:24 2018 -0500
cpack: When given an unknown generator print out all valid generators
This makes cpack behavior match cmake when passed an invalid generator
diff --git a/Source/CPack/cpack.cxx b/Source/CPack/cpack.cxx
index 3df1b36..7cf69fc 100644
--- a/Source/CPack/cpack.cxx
+++ b/Source/CPack/cpack.cxx
@@ -21,6 +21,7 @@
#include "cmCPackLog.h"
#include "cmDocumentation.h"
#include "cmDocumentationEntry.h"
+#include "cmDocumentationFormatter.h"
#include "cmGlobalGenerator.h"
#include "cmMakefile.h"
#include "cmStateSnapshot.h"
@@ -360,7 +361,19 @@ int main(int argc, char const* const* argv)
cmCPack_Log(, cmCPackLog::LOG_ERROR,
"Could not create CPack generator: " << gen
<< std::endl);
-
+// Print out all the valid generators
+cmDocumentation generatorDocs;
+std::vector v;
+for (auto const& g : generators.GetGeneratorsList()) {
+ cmDocumentationEntry e;
+ e.Name = g.first;
+ e.Brief = g.second;
+ v.push_back(std::move(e));
+}
+generatorDocs.SetSection("Generators", v);
+std::cerr << "\n";
+generatorDocs.PrintDocumentation(cmDocumentation::ListGenerators,
+ std::cerr);
parsed = 0;
}
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=860338491ee96274ac110459b3b316149d4585f7
commit 860338491ee96274ac110459b3b316149d4585f7
Author: Joachim Wuttke (l)
AuthorDate: Thu Nov 1 11:18:15 2018 +0100
Commit: Joachim Wuttke (h)
CommitDate: Thu Nov 8 20:33:13 2018 +0100
Help: Describe $CACHE and $ENV as operators
This resolves issue #18514
Also add a cross-reference to if(DEFINED ENV{var}).
diff --git a/Help/manual/cmake-variables.7.rst
b/Help/manual/cmake-variables.7.rst
index efb217d..7a7f0b8 100644
--- a/Help/manual/cmake-variables.7.rst
+++ b/Help/manual/cmake-variables.7.rst
@@ -241,7 +241,6 @@ Variables that Describe the System
/variable/ANDROID
Re: [cmake-developers] CMake string question
Am 2018-11-09 14:55, schrieb Joachim Wuttke:
if("${srcdir}" STREQUAL "${bindir}")
if(srcdir STREQUAL bindir)
looks more idiomatic, thank you Eike -
But can we be sure that srcdir contains no blank?
Or does STREQUAL work even for argument strings
that contain blanks?
If you pass in only the variable names CMake will do the expansion only
internally, so this is save. It just works (tm).
Eike
--
--
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 string question
if("${srcdir}" STREQUAL "${bindir}")
if(srcdir STREQUAL bindir)
looks more idiomatic, thank you Eike -
But can we be sure that srcdir contains no blank?
Or does STREQUAL work even for argument strings
that contain blanks?
- Joachim
smime.p7s
Description: S/MIME Cryptographic Signature
--
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] option to prevent in-source builds
On 11/09/2018 07:28 AM, Taylor Holberton wrote: > A lot of projects that use CMake already have a `./cmake` directory, > I would think `./cmake/init.json` would fit nicer as opposed to the > hidden directory. We could have a list of supported places so projects can choose. > I would prefer an init file be written as a CMake file instead of JSON. We need to be able to load the file without initializing much. If it is a CMake language file then people will try to write `if` conditions to check things that we wouldn't provide access to at that point. The idea of this file is to have a purely declarative specification. A format like JSON will work well for that. -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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] module proposal: PreventInSourceBuilds
(correct list this time)
# disallow in-source builds
if("${srcdir}" STREQUAL "${bindir}")
if(srcdir STREQUAL bindir)
HTH
Eike
--
--
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] [cmake-developers] module proposal: PreventInSourceBuilds
# disallow in-source builds
if("${srcdir}" STREQUAL "${bindir}")
if(srcdir STREQUAL bindir)
HTH
Eike
--
--
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
Re: [cmake-developers] option to prevent in-source builds
A lot of projects that use CMake already have a `./cmake` directory, I would think `./cmake/init.json` would fit nicer as opposed to the hidden directory. I'm not a fan of hidden directories in software projects anyway. I would prefer an init file be written as a CMake file instead of JSON. JSON is nice because it plays well with GUIs, but I think using CMake syntax will function better if the file ever needs to be a bit more complicated. On Fri, Nov 9, 2018, 07:14 Brad King On 11/09/2018 05:34 AM, Joachim Wuttke wrote: > > include(PreventInSourceBuilds) > > > > to protect users (and myself) from unintentionally running CMake > > in the source directory. > > > > Would you consider adding this little module to the CMake code base? > > If we are going to offer an upstream solution for this I think > it should be done in a way that avoids ever creating any files > (like CMakeCache.txt or CMakeFiles) in the first place. This > could be achieved by looking for a `.cmake/init.json` file > at the top of the source tree with declarative information > about the project's preferences. One of those settings could > reject in-source builds. > > -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: > 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] option to prevent in-source builds
On 11/09/2018 05:34 AM, Joachim Wuttke wrote: > include(PreventInSourceBuilds) > > to protect users (and myself) from unintentionally running CMake > in the source directory. > > Would you consider adding this little module to the CMake code base? If we are going to offer an upstream solution for this I think it should be done in a way that avoids ever creating any files (like CMakeCache.txt or CMakeFiles) in the first place. This could be achieved by looking for a `.cmake/init.json` file at the top of the source tree with declarative information about the project's preferences. One of those settings could reject in-source builds. -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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [cmake-developers] module proposal: PreventInSourceBuilds
On 09/11/2018 10:34, Joachim Wuttke wrote: In all my projects, the top-level CMakeLists.txt contains the line include(PreventInSourceBuilds) to protect users (and myself) from unintentionally running CMake in the source directory. I for one have an equivalent to this logic in all my projects to prevent in-source builds. Having a standardised version would be very useful, and I would certainly make use of it. Thanks, Roger -- 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] module proposal: PreventInSourceBuilds
In all my projects, the top-level CMakeLists.txt contains the line
include(PreventInSourceBuilds)
to protect users (and myself) from unintentionally running CMake
in the source directory.
Would you consider adding this little module to the CMake code base?
I would then add an option so that users can override the not-in-source policy.
/Joachim
---
#.rst:
# PreventInSourceBuilds
# -
#
# Prevent in-source builds
#
# It is generally acknowledged that it is preferable to run CMake out of source,
# in a dedicated build directory. To prevent users from accidentally running
# CMake in the source directory, just include this module.
# make sure the user doesn't play dirty with symlinks
get_filename_component(srcdir "${CMAKE_SOURCE_DIR}" REALPATH)
get_filename_component(bindir "${CMAKE_BINARY_DIR}" REALPATH)
# disallow in-source builds
if("${srcdir}" STREQUAL "${bindir}")
message(FATAL_ERROR "\
CMake must not to be run in the source directory. \
Rather create a dedicated build directory and run CMake there. \
To clean up after this aborted in-source compilation:
rm -r CMakeCache.txt CMakeFiles
")
endif()
smime.p7s
Description: S/MIME Cryptographic Signature
--
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] dependencies of cross compiliations
Hi, I hope this question was not asked before. I work in the embedded field and there it is usually to have at least two different build platforms. The Host platform, where unit tests are build (and where CMake is running) and an embedded Target platform, where targets are build with a cross compiler. Sometimes such a system comes with self-written tools that are build and run on the Host platform to build a target for the embedded Target platform (adding meta data to a binary to be used by a bootloader for example). Usually I have two different build folders, one for the Host platform and one for the Target platform, using different calls to cmake to choose from a set of tools and targets. But when using this approach, it is necessary that the Host platform build ran before the Target platform build, so that tools that are required for the Target platform are build during the Host target build. One solution I’ve came up with, is to build the required tools during the Target platform build, using an add_custom_target() to invoke the Target compiler directly. This works fine, as long as the tools are basically build just out of a couple of files. What would be the „CMake-Way“ to add the tools (that have to be build on the Target platform) as dependency to targets that have to be build for the Target (cross compile) platform? Kind regards and thanks in advance, Torsten -- 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
