Re: [cmake-developers] [ANNOUNCE] CMake 3.5.0-rc1 now ready for testing!
> -Original Message- > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] > On Behalf Of Brad King > Sent: Wednesday, February 03, 2016 21:17 > To: Eric Wing; Robert Maynard > Cc: CMake Developers > Subject: Re: [cmake-developers] [ANNOUNCE] CMake 3.5.0-rc1 now ready > for testing! > > On 02/03/2016 03:48 PM, Eric Wing wrote: > > Hi, I'm curious about this. Would you explain the difference between > > the .msi and the installer? > > The .exe was a NSIS-generated installer tool. There were several bugs in it > caused by problems with NSIS, but worst is that it could wipe out long PATH > environment variables. The .msi is more like a .deb or .rpm but that is > managed by the Windows Installer Service. There's several other reasons as well. Not that I had anything to do with CMake moving to WiX, but I'm happy to see they did: * Windows Installer is transactional. If there's an error or other problem during installation, MSI will roll back the installation - it "just works" for the most part. Whereas with NSIS, offering something as simple as a "Cancel" button is apparently quite difficult: http://nsis.sourceforge.net/InstFiles_Cancel_-_Allowing_a_user_to_cancel_ins tallation_during_InstFiles * Self-healing functionality: if the application installation is damaged, MSI can automatically repair it when launching the application. If you like, you can have it go as far as verify checksums of each file. * MSI is declarative: standardized database schema defines what to install and where - not how to install it. So installs, uninstalls, repairs, recovery from a failed transaction, etc. "just work". The standardized behavior could also help system administrators to customize the installation with existing tools. * MSI packages can be deployed with Active Directory, and non-administrator users can elect to install them while the installation still runs at an elevated level (or the installation can be forced when the system starts or when the user logs in). Nice discussion here: http://serverfault.com/a/274609 Maybe now that CPack supports WiX, more open source projects will start to use it instead of NSIS. :) I only hope they set up the MSIs to support side-by-side installations of multiple CMake versions. I have yet to find time to see if this is the case. Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake daemon for user tools
> -Original Message- > From: Milian Wolff [mailto:m...@milianw.de] > Sent: Saturday, January 23, 2016 15:41 > To: cmake-developers@cmake.org > Cc: James Johnston > Subject: Re: [cmake-developers] CMake daemon for user tools > > You are aware that modern std::string is SSO'ed? I'm running on such a > system. > Another reason why you should not reinvent the wheel and keep relying on > the STL wherever possible. > > Qt has such a class, it's called QVarLengthArray, and I've also been able to > apply it in multiple occasions to good effect. That said, when you look at Yeah, but std::string is platform dependent, and the size of the buffer is also platform dependent. Maybe it tends to be optimal for CMake. Then again, maybe a larger buffer is needed. I don't know. The flexible option would be something that does exactly like QVarLengthArray. Different variables might have different optimal sizes. Some sample small strings for gcc/clang/VC++: http://stackoverflow.com/a/28003328/562766 Note that none of them are large enough to store an absolute path, which are maybe common (???) in CMake. Also there's a fair bit of variation; if CMake wants consistent performance in a section of code across compilers, it would need a way to explicitly specify the small string size. For example, some are large enough to store typical target sizes - and some maybe are not. There is also boost::container::small_vector in addition to QVarLengthArray: http://www.boost.org/doc/libs/1_60_0/doc/html/boost/container/small_vector.h tml > Just run cmake (or the daemon) through a profiler and check the results. > Doing so for the daemon (built with RelWithDebInfo) on the LLVM build dir > and recording it with `perf --call-graph lbr` I get these hotspots when looking > at the results with `perf report -g graph --no-children`: > > +8.67% cmake cmake[.] > cmGlobalGenerator::FindGeneratorTargetImpl > +4.21% cmake libc-2.22.so [.] _int_malloc > +2.67% cmake cmake[.] cmCommandArgument_yylex > +2.09% cmake libc-2.22.so [.] _int_free > +2.06% cmake libc-2.22.so [.] __memcmp_sse4_1 > +1.84% cmake libc-2.22.so [.] malloc > > This already shows you that you can gain a lot by reducing the number of > allocations done. Heaptrack is a good tool for that. Next question would be: who is calling malloc? Or rather, what % of callers are std::string, std::vector, other STL classes vs custom data structures? Next question would be: what is the size of those mallocs, for each caller? (Sorry I don't currently have an environment set up with a profiler to test this myself at the moment.) > Similarly, someone should > investigate cmGlobalGenerator::FindGeneratorTargetImpl. That does a lot of > string comparisons to find targets from my quick glance, so indeed could be > sped up with a smarter string class. > > But potentially you could also get a much quicker lookup by storing a hash > map of target name to cmGeneratorTarget. Indeed; there has got to be a way to reduce the complexity of that function in number of targets compared, if not the low-level string comparison itself as well. For example, if target names are short-ish, the string class has large enough SSO, and the underlying string class made use of vector CPU instructions for comparison, there is probably very little to be gained without such a hash map. (On the other hand, if some of the previous assumptions are not true on some common CMake platforms) > Seems like there's more than enough areas one could (and should) optimize > CMake. Indeed. Another idea - probably unrelated to the string allocations issue, but still - that came to mind: what if link-time code generation/optimization is turned on? IIRC this is not default in CMake. Maybe CMake is sufficiently well-organized (e.g. small functions implementations moved to header files) such that what needs to be inlined across units, is already being inlined. Then again, maybe it's not. I've seen other projects rely on this feature to keep clean organization by keeping implementations in .CPP files without sacrificing performance, and when you turn off LTCG performance takes a major hit... Also IIRC there are still a few optimizations that are turned off when CMake is built with RelWithDebInfo instead of Release. I forget the exact specifics at the moment but e.g. on Visual C++ when you ask it to turn on debug symbols, it will change the default values of some optimization flags. So a cursory examination of the flags wouldn't reveal all cases. However, one of my bigger performance gripes, being a primarily Windows developer right now, is the process creation overhead, especially during configuration. I think that is completely dominating over any CMake code being run
Re: [cmake-developers] CMake daemon for user tools
> -Original Message- > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] > On Behalf Of Milian Wolff > Sent: Thursday, January 21, 2016 22:31 > To: Daniel Pfeifer > Cc: CMake Developers; Stephen Kelly > Subject: Re: [cmake-developers] CMake daemon for user tools > > > What do you think about string interning? I started a cmString class > > [2] that stores short strings inplace and puts long strings into a > > pool. Copies never allocate extra memory and equality comparison is > > always O(1). > > In addition to `operator<` (which is lexicographical) there is a O(1) > > comparison that can be used where lexicographical ordering is not > > required (ie. for lookup tables). > > > > [1] https://en.wikipedia.org/wiki/String_interning > > [2] https://github.com/purpleKarrot/CMake/commits/string-pool > > Imo, you should replace this custom code by a boost::flyweight of std::string. > That said, I think this can have a significant impact on the memory footprint > of CMake, considering how heavy it relies on strings internally. But it also > seems to mutate strings a lot. I've seen places e.g. where a list of compile- > time known identifiers is prepended with "CMAKE_" at runtime. This is slow > with normal strings (reallocations), but will also be slow with a flyweight or > interning, possibly even leading to the pollution of the internal pool with > temporary strings. > > Did you measure any impact on both, runtime speed and memory footprint > yet? I was wondering the same. I would guess maybe the biggest impact would be the inplace storage of strings for small sized strings. But to know the inplace buffer size would probably require some profiling and measurement of string sizes... otherwise it is just a wild guess... Maybe for testing, you can swap out the string header file on your system with one that logs allocations/string sizes, and perhaps also profiles the time it takes to make each allocation? The interesting question is: could inplace storage be used for 95% of the cases such that fussing with string interning becomes unnecessary complexity? If so, then you mentioned equality comparison as another issue: the interesting question there is how much time is spent on allocations vs comparisons... In another application I worked on, I was able to get a big improvement in performance by replacing usage of std::vector in one place with a custom vector that stack-allocated the first 10 items (i.e. fixed-size C array as a member variable of the class), and then reverted to a regular vector after that. But to pick the number "10" required some profiling/measurement. The remaining use of the heap was so negligible as to not be worth improving. Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, next, updated. v3.4.1-1585-g26d765c
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, next has been updated via 26d765cf6b6c6a08b03b8643cd7b408dc29a373b (commit) via 7a3277276e69c92d0f69674cdc27bae11bcbc14f (commit) via 25211d756fad353e96d29e289d40d780a5341c92 (commit) via 060442c2e866c44ecf0c479e49e1d5ae35e8c6fb (commit) via f3b3219c9687e54a83dc7e5dabb0afc4637bb799 (commit) via ddbda72288f022fa558d8253c8894687634448c1 (commit) via 4ffeab0e3c451854a4a9d424b47b2179c6cf6c6b (commit) from 23b5ca6d7461f3c166a0ab826c456bc30a370452 (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=26d765cf6b6c6a08b03b8643cd7b408dc29a373b commit 26d765cf6b6c6a08b03b8643cd7b408dc29a373b Merge: 23b5ca6 7a32772 Author: James Johnston <johnstonj.pub...@codenest.com> AuthorDate: Thu Dec 3 16:39:47 2015 -0500 Commit: CMake Topic Stage <kwro...@kitware.com> CommitDate: Thu Dec 3 16:39:47 2015 -0500 Merge topic 'improve-embarcadero' into next 7a327727 Embarcadero: Fix erroneous interpretation of __CODEGEARC_VERSION__. 25211d75 Compiler ID: Compiler versions must be a valid, numeric version string. 060442c2 Embarcadero: Check code using CMAKE_CXX_COMPILER_ID and CMAKE_C_COMPILER_ID. f3b3219c Embarcadero/Watcom: Properly skip VSResource test for other generators. ddbda722 Embarcadero: Fix bug where duplicate Ninja job pools would be created. 4ffeab0e CMake Nightly Date Stamp https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7a3277276e69c92d0f69674cdc27bae11bcbc14f commit 7a3277276e69c92d0f69674cdc27bae11bcbc14f Author: James Johnston <johnstonj.pub...@codenest.com> AuthorDate: Thu Dec 3 21:24:56 2015 +0000 Commit: James Johnston <johnstonj.pub...@codenest.com> CommitDate: Thu Dec 3 21:37:08 2015 + Embarcadero: Fix erroneous interpretation of __CODEGEARC_VERSION__. As per the following link: http://docwiki.embarcadero.com/RADStudio/Seattle/en/Example_of_CODEGEARC_VERSION_Macro The major/minor versions must be decoded as a hex string, while the patch version must be decoded as a normal decimal string. As an example, C++ Builder XE 8.1's bcc32.exe sets this macro to 0x070189C9. The file version of bcc32.exe is 7.1.5570.35273. Therefore, the correct interpretation to COMPILER_VERSION would be 7.1.35273. diff --git a/Modules/Compiler/Embarcadero-DetermineCompiler.cmake b/Modules/Compiler/Embarcadero-DetermineCompiler.cmake index 2feedac..8375624 100644 --- a/Modules/Compiler/Embarcadero-DetermineCompiler.cmake +++ b/Modules/Compiler/Embarcadero-DetermineCompiler.cmake @@ -4,4 +4,4 @@ set(_compiler_id_pp_test "defined(__BORLANDC__) && defined(__CODEGEARC_VERSION__ set(_compiler_id_version_compute " # define @PREFIX@COMPILER_VERSION_MAJOR @MACRO_HEX@(__CODEGEARC_VERSION__>>24 & 0x00FF) # define @PREFIX@COMPILER_VERSION_MINOR @MACRO_HEX@(__CODEGEARC_VERSION__>>16 & 0x00FF) -# define @PREFIX@COMPILER_VERSION_PATCH @MACRO_HEX@(__CODEGEARC_VERSION__ & 0x)") +# define @PREFIX@COMPILER_VERSION_PATCH @MACRO_DEC@(__CODEGEARC_VERSION__ & 0x)") https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=25211d756fad353e96d29e289d40d780a5341c92 commit 25211d756fad353e96d29e289d40d780a5341c92 Author: James Johnston <johnstonj.pub...@codenest.com> AuthorDate: Thu Dec 3 21:17:26 2015 + Commit: James Johnston <johnstonj.pub...@codenest.com> CommitDate: Thu Dec 3 21:37:07 2015 + Compiler ID: Compiler versions must be a valid, numeric version string. This test helps catch errors in compiler identification. diff --git a/Tests/CMakeOnly/CompilerIdC/CMakeLists.txt b/Tests/CMakeOnly/CompilerIdC/CMakeLists.txt index 848ffdd..6fea73e 100644 --- a/Tests/CMakeOnly/CompilerIdC/CMakeLists.txt +++ b/Tests/CMakeOnly/CompilerIdC/CMakeLists.txt @@ -12,3 +12,10 @@ foreach(v message(SEND_ERROR "${v} not set!") endif() endforeach() + +# Version numbers may only contain numbers and periods. +if(NOT CMAKE_C_COMPILER_VERSION MATCHES +"^([0-9]+)(\\.([0-9]+))?(\\.([0-9]+))?(\\.([0-9]+))?$" +) + message(SEND_ERROR "Compiler version is not numeric!") +endif() diff --git a/Tests/CMakeOnly/CompilerIdCXX/CMakeLists.txt b/Tests/CMakeOnly/CompilerIdCXX/CMakeLists.txt index 94ac31e..05e6bb2 100644 --- a/Tests/CMakeOnly/CompilerIdCXX/CMakeLists.txt +++ b/Tests/CMakeOnly/CompilerIdCXX/CMakeLists.txt @@ -12,3 +12,10 @@ foreach(v message(SEND_ERROR "${v} not set!") endif(
[Cmake-commits] CMake branch, next, updated. v3.4.0-rc1-207-gecaf4ac
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, next has been updated via ecaf4ac91fefb0c8a063ff8823137b5685b0a9b1 (commit) via 81e01f92df657516456d036fd0a99f69410fd07e (commit) from b222a4ca6f7d84378164e67ce9f81a5e0865eda1 (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=ecaf4ac91fefb0c8a063ff8823137b5685b0a9b1 commit ecaf4ac91fefb0c8a063ff8823137b5685b0a9b1 Merge: b222a4c 81e01f9 Author: James Johnston <johnstonj.pub...@codenest.com> AuthorDate: Thu Oct 8 13:17:28 2015 -0400 Commit: CMake Topic Stage <kwro...@kitware.com> CommitDate: Thu Oct 8 13:17:28 2015 -0400 Merge topic 'doc-clarify-shared-lib' into next 81e01f92 Help: Clarify that build system requires SHARED libraries to export symbols. https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=81e01f92df657516456d036fd0a99f69410fd07e commit 81e01f92df657516456d036fd0a99f69410fd07e Author: James Johnston <johnstonj.pub...@codenest.com> AuthorDate: Thu Oct 8 17:14:12 2015 +0000 Commit: James Johnston <johnstonj.pub...@codenest.com> CommitDate: Thu Oct 8 17:14:12 2015 + Help: Clarify that build system requires SHARED libraries to export symbols. CMake assumes that a SHARED library compiled on Windows will export a LIB file. This is not actually the case on Visual C++ if the library does not export any symbols, and causes incremental builds to break if the user specifies SHARED anyway. (Users should use MODULE libraries instead.) diff --git a/Help/command/add_library.rst b/Help/command/add_library.rst index fe7735c..7a67d61 100644 --- a/Help/command/add_library.rst +++ b/Help/command/add_library.rst @@ -36,6 +36,11 @@ property is set to ``ON`` automatically. A ``SHARED`` library may be marked with the :prop_tgt:`FRAMEWORK` target property to create an OS X Framework. +If a library does not export any symbols, it must not be declared as a +``SHARED`` library to avoid breaking incremental builds on some generators +and compilers. For example, a Win32 resource DLL or a managed C++/CLI DLL +that exports no unmanaged symbols would need to be a ``MODULE`` library. + By default the library file will be created in the build tree directory corresponding to the source tree directory in which the command was invoked. See documentation of the :prop_tgt:`ARCHIVE_OUTPUT_DIRECTORY`, diff --git a/Help/manual/cmake-buildsystem.7.rst b/Help/manual/cmake-buildsystem.7.rst index 357aae9..154b05b 100644 --- a/Help/manual/cmake-buildsystem.7.rst +++ b/Help/manual/cmake-buildsystem.7.rst @@ -80,6 +80,10 @@ regardless of the library type. The ``MODULE`` library type is dissimilar in that it is generally not linked to -- it is not used in the right-hand-side of the :command:`target_link_libraries` command. It is a type which is loaded as a plugin using runtime techniques. +If the library does not export any unmanaged symbols (e.g. Win32 +resource DLL, C++/CLI DLL), it is required that the library not be a +``SHARED`` library. Some generators and compilers assume that +``SHARED`` libraries export at least one symbol. .. code-block:: cmake @@ -781,7 +785,8 @@ An *archive* output artifact of a buildsystem target may be: * On DLL platforms: the import library file (e.g. ``.lib``) of a shared library target created by the :command:`add_library` command - with the ``SHARED`` option. + with the ``SHARED`` option. This file is only guaranteed to exist if + the library exports at least one unmanaged symbol. * On DLL platforms: the import library file (e.g. ``.lib``) of an executable target created by the :command:`add_executable` command --- Summary of changes: Help/command/add_library.rst|5 + Help/manual/cmake-buildsystem.7.rst |7 ++- 2 files changed, 11 insertions(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
Re: [cmake-developers] generator expression for path slash conversion
> -Original Message- > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] > On Behalf Of Kislinskiy, Stefan > Sent: Thursday, September 24, 2015 15:09 > To: Brad King > Cc: cmake-developers@cmake.org > Subject: Re: [cmake-developers] generator expression for path slash > conversion > > Great, thank you, Brad & David. > > Regarding the ExternalProjectShellPathGenex test: I wrongly assumed that > the WIN32 variable wouldn't be set when using MSYS and the like. Would it > make sense to keep the test when changing the WIN32 check to MSVC? Just an FYI: MSVC can still be set; it's an indicator of the *compiler* in use, not the *generator*. For example, it could be set if using cl.exe with Ninja. Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version
> -Original Message- > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] > On Behalf Of Brad King > Sent: Friday, September 18, 2015 18:24 > To: Gilles Khouzam > Cc: cmake-developers@cmake.org > Subject: Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: > Correctly determine Windows version > > On 09/10/2015 07:24 PM, Gilles Khouzam wrote: > > This patch adds a simple version manifest > > Source\cmake.version.manifest to the CMake executables. > > After working out the support for manifests across all generators as > discussed elsewhere in this thread, I've added your manifest file to CMake's > own build: > > Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8 (#15674) > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cdd15551 While on the subject, there are some other additions to the manifest you might want to consider. The above block will disable UAC heuristics on Windows Vista and above, such that elevation won't ever be requested. It will also disable the Program Compatibility Assistant for Vista IIRC. (as I understand it, supportedOS wasn't added until Windows 7. Why there is a GUID in there for Vista, I'm not sure. App manifests are not the best documented thing on MSDN IMHO.) It would probably be appropriate to use this for all CMake executables. The above block will declare a preference to use the newer common controls library introduced with Windows XP. Without this, Windows will fall back on the old Windows 2000 era of common controls (i.e. Windows 95 style buttons). This would be appropriate for cmake-gui. Since it uses Qt though, the effect is probably minimal, but if some API were called such that native Win32 controls were used somewhere, this would improve the appearance. http://schemas.microsoft.com/SMI/2005/WindowsSettings;> True/PM The above block will make the cmake-gui DPI aware, such that DPI virtualization is disabled on Windows Vista and above. In laymen's terms, it fixes "blurry text". It looks like Qt already does this (I just tested CMake 3.3 on a high DPI profile.) See http://doc.qt.io/qt-5/highdpi.html. Probably they do it by calling the SetProcessDpiAwareness function. However, this API has some caveats; from MSDN: " The SetProcessDPIAware function in Windows Vista and later versions sets the current process as DPI-aware. However, the use of the SetProcessDPIAware function is discouraged. For example, if a DLL caches DPI settings during initialization, invoking SetProcessDPIAware in your application might generate a possible race condition. For this reason, we recommend that an application enable DPI awareness by using the application's assembly manifest rather than by calling SetProcessDPIAware." --- https://msdn.microsoft.com/en-us/library/windows/desktop/dn469266(v=vs.85).a spx And also: " If you use the SetProcessDpiAwareness method to set the DPI awareness level, you must call SetProcessDpiAwareness prior to any Win32API call that forces the system to begin virtualization." The safer path seems to me to be put it in the manifest, as recommended by MSFT. Note there are two possible values: "True" and "True/PM". "PM" stands for per-monitor DPI aware (introduced with Windows 8.1). Looks like Qt supports PM now, but since it was introduced in Windows 8.1, probably only very recent versions of Qt. You'd have to be careful what is in the manifest agrees with the version of Qt being used. (e.g. you don't want to declare "True/PM" on a non-PM older version of Qt, else no per-monitor scaling would happen at all - virtualized or otherwise). Since Qt does call SetProcessDPIAware and cmake-gui does seem to scale OK right now, including this block may end up being a little "pointless" in practice, despite the caveats from MSDN above. Finally there is this block; I'm not exactly sure which versions of Windows might actually require this or what. I'm a little fuzzy on why I included it. Most of the built-in Windows accessories seem to have this in their manifests though. IIRC it's especially needed with the common controls manifest block. Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake user-provided manifest files
> -Original Message- > From: Brad King [mailto:brad.k...@kitware.com] > Sent: Wednesday, September 16, 2015 20:13 > To: James Johnston; 'Gilles Khouzam' > Cc: cmake-developers@cmake.org > Subject: Re: [cmake-developers] CMake user-provided manifest files > > On 09/16/2015 03:43 PM, James Johnston wrote: > > So the problem is the current directory when linking is going to be > > root CMAKE_BINARY_DIR, and the relative path "DPIAware.manifest" will > > attempt to be used, which of course isn't there as it needs to look in > > "subdir\DPIAware.manifest". > > This should fix that: > > fixup! Add support for *.manifest source files with MSVC tools > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e78b5408 > > I'll also work on integrating your test case. > > Thanks, > -Brad That fixed it; just tested building a pile of projects with both Ninja and VS2008 generators (with VS2008 used with Ninja). Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake user-provided manifest files
> -Original Message- > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] > On Behalf Of Brad King > Sent: Monday, September 14, 2015 20:16 > To: James Johnston > Cc: cmake-developers@cmake.org > Subject: Re: [cmake-developers] CMake user-provided manifest files > > On 09/11/2015 11:45 AM, James Johnston wrote: > > Because CMake already does *some* things with the linker it makes it > > impossible for me to cleanly specify and use link.exe manifest-related > > switches myself. For example, it hard-codes usage of link.exe > > /MANIFESTFILE and the user can't specify their own location. And the > > locations it does use are undocumented. > > Is there a use case for doing something with the linker-generated manifest > file other than passing it to a "mt" invocation along with (possibly) user- > specified manifest files? If not then there is no reason to make the manifest > file location public. I can't think of anything like that. The only reason I was using the undocumented linker-generated manifest location was to merge it with my own manifest using mt.exe. So I agree, I can't think of a reason the location needs to be publicly documented/available if CMake can cleanly handle user-provided manifests to merge. Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version
Well this is quite cool. :) It's been an issue I've wanted to see addressed as well but haven't had the time to look at it. Not because of CMake itself not having a manifest (the improper GetVersionEx detection didn't affect me), but because I need to embed an app manifest in my own programs. I have some ideas while you are on the subject: 1. No documentation files were updated. I wonder if there is a good place in the docs for this? 2. If the user doesn't use the Visual Studio generator, still support embedding the manifest. For example, if I use Ninja generator in conjunction with Visual C++'s link.exe I'd like user-specified manifests to be merged with mt.exe. The second request is currently a big pain point with CMake to get working correctly. Ideally I want to reproduce the VS way of doing things, which is: a. Have link.exe generate default manifest for referencing the CRT side-by-side assemblies. b. Use mt.exe to put it all together in the output. Because CMake already does *some* things with the linker it makes it impossible for me to cleanly specify and use link.exe manifest-related switches myself. For example, it hard-codes usage of link.exe /MANIFESTFILE and the user can't specify their own location. And the locations it does use are undocumented. See Source/cmcmd.cxx and search for vs_link_exe to see what I'm talking about. (For that matter, git grep CMake for vs_link_exe and vs_link_dll to see how those commands end up getting used in the first place). Ultimately for now I wound up with this kludge to get link.exe intermediate manifest AND my own: if(CMAKE_CONFIGURATION_TYPES) # multiple-configuration generator? # WARNING: This magic directory location is an undocumented aspect of the # Visual Studio generator. list(APPEND inputManifests ${CMAKE_CURRENT_BINARY_DIR}/${AAM_TARGET}.dir/$/$<TARGET_FILE_NAME:$ {AAM_TARGET}>.intermediate.manifest ) else() # Can't change /MANIFESTFILE because CMake assumes the default... (see above) list(APPEND inputManifests $<TARGET_FILE:${AAM_TARGET}>.manifest) endif() list(APPEND inputManifests my_own_manifests.manifest) Which is then fed into add_custom_command( POST_BUILD COMMAND mt.exe -manifest ${inputManifests} ). Basically I'm hard-coding the hard-coded /MANIFESTFILE: locations used by various CMake generators, since it doesn't work for me to try to change it. Obviously the situation is not ideal because CMake makes no promises about where it puts the intermediate manifests from the linker. It would be certainly be nice if CMake supported user-provided manifests across most/all Windows generators as first-class support, not just Visual Studio 10. Especially the make-like tools (various Makefile generators, Ninja). :) Best regards, James Johnston From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Gilles Khouzam Sent: Thursday, September 10, 2015 23:25 To: Brad King Cc: cmake-developers@cmake.org Subject: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly determine Windows version This patch fixes the issue where on Windows 8 and above, by default the system version returned is always Windows 8. More info on this can be found on http://blogs.msdn.com/b/cjacks/archive/2009/03/27/manifesting-for-compatibil ity-on-windows-7.aspx In order for GetVersionEx to work properly, a manifest must be embedded in the exe telling it to ignore the new behavior and give the proper version. This patch adds support to specify manifests and teaches CMake how to embed them using Visual Studio. This patch adds a simple version manifest Source\cmake.version.manifest to the CMake executables. This removes the use of RtlGetVersion and properly uses GetVersionEx which will now return the proper operating system version for all operating systems until Windows 10. This patch also fixes a potential buffer overrun and improper call of GetVersionEx in SystemTools.cxx where GetVersionExW is called with a OSVERSIONINFOEXA struct causing a failure since the size is improper for the API. Fixing this, GetVersionEx should never fail anymore. Update the OSVersionAndName for new versions of Windows released after Windows 7. This change will require a double compile of CMake (I'm not sure if this is what the dashboards are doing) to have the functionality enabled, since the first step will build a new CMake that will know how to embed a manifest. The second compile with the version of CMake that knows how to embed a manifest, will then embed the manifest in CMake enabling this feature. Thanks ~Gilles -- 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 offe
Re: [cmake-developers] [CMake] Visual Studio - Ninja Generator
> -Original Message- > From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] > On Behalf Of Brad King > Sent: Wednesday, September 09, 2015 15:00 > To: cmake-developers@cmake.org > Subject: Re: [cmake-developers] [CMake] Visual Studio - > Ninja Generator > > On 09/02/2015 03:34 PM, James Johnston wrote: > > useful if the Visual Studio generators in CMake were refactored > > somewhat > > Even without the C# motivation I think factoring out a "MSBuild" generator > infrastructure internally will be useful. Currently we call it "VS 10" > because it happened to be the first version to use MSBuild project files. > Are you proposing to have some kind of internal object model for the > MSBuild project files to separate their construction from the actual > generation? Right, something like that. Another motivation: if somebody ever wanted to write a generator for Embarcadero C++ Builder projects... guess what format the project files are in... MSBuild... this otherwise has nothing to do with VStudio... Again, not something I'm working on right now but just putting some ideas out there. :) > > > it would be useful to have Visual Studio available as an "Extra" CMake > > generator. For example, specification of "Visual Studio 2015 - Ninja" > > This functionality sounds reasonable but the name of the extra/generator > pair looks funny when spelled out that way. We should consider having > another way to specify the extra generator. This name is consistent with the other extra generators: http://www.cmake.org/cmake/help/v3.3/manual/cmake-generators.7.html#id12 "[Extra] generator names have the form - ." But I agree it is just confusing at this point. Maybe this format could be deprecated in favor of a new cmake.exe switch to specify an extra generator. Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] Visual Studio - Ninja Generator
Hi, The problem with /MP in cl.exe, /CGTHREADS in link.exe, and /MAXCPUCOUNT in msbuild.exe is they don't communicate with each other, potentially leading to massive over/undersubscription of the system. I would love it if Microsoft could get this mishmash cleaned up somehow so they can all communicate and not oversubscribe the system. (Out-of-the-box, Visual C++ ought to have this straightened out). In theory it would be faster than Ninja because the /MP switch reduces forking overhead and fixed overhead initialization cl.exe by batch building. In the meantime, Ninja seems faster in practice, because it can properly avoid oversubscription with building individual C++ files and entire projects in parallel (whereas cl.exe and msbuild.exe cannot). (One problem with link.exe /CGTHREADS though is that Ninja needs to be told how many threads link.exe will actually use, so that Ninja doesn't oversubscribe. I'm not aware of a way to make Ninja do that though. You can use pools to restrict to one link at a time, but moderate oversubscription will still happen with the concurrent cl.exe instances.) Best regards, James Johnston From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Hendrik Sattler Sent: Monday, August 31, 2015 15:49 To: Guillaume Dumont; cmake@cmake.org Subject: Re: [CMake] Visual Studio - Ninja Generator Hi, did you really enable parallel compiling in VS with /MP24 or the like? Note that using devenv to build uses the number from the IDE user settings but using msbuild needs a command line option. Else just create a custom target that calls cmake for ninja and afterwards ninja itself in yet another build tree. you can limit the creation of that target to if(MSVC_IDE). HS Am 31. August 2015 16:35:01 MESZ, schrieb Guillaume Dumont <dumont.guilla...@gmail.com>: Hi all, I would like to know what kind of effort would it take to generate a Visual Studio generator that bypasses the normal MSBuild build and uses Ninja instead. I have been working on different projects which build much faster with ninja than MSBuild (several orders of magnitude on a machine with 24 cores). Still I like to use the Visual Studio environment to use the debugger. Using ninja is especially useful for projects with a lot of CUDA files which are built sequentially for every target using MSVS. I would like to contribute but I don't really know where to start and if such an effort already exists. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Visual Studio - Ninja Generator
h C# project - even when using non-VS generators like Ninja. The Ninja build rule for a C# project would just be to invoke MSBuild.exe and build that one project. (Only generate projects, not solutions.) But this requires the ability for a CMake language to invoke the MSBuild-generating code inside CMake to spit out a Visual Studio project for each C# target. Benefit: now CMake doesn't reimplement undocumented behavior of Microsoft's MSBuild targets; we just use them directly as a black box. Best regards, James Johnston From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Guillaume Dumont Sent: Monday, August 31, 2015 16:49 To: Gonzalo Cc: cmake@cmake.org Subject: Re: [CMake] Visual Studio - Ninja Generator @Hendrik Sattler I have not experimented with the /MP flag that much, but this won't solve my problem when the project contains a lot of CUDA files. The /MP flag as not effect there. Yes I could indeed create a custom build target and create additional build trees to build using ninja in there but this is suboptimal in my opinion. @Gonzalo Yes this is precisely what I do but then you only get the ninja build files. No solution for debugging etc. My question is more about the difficulty of creating a new generator that makes the use of ninja as transparent as possible to the user instead of writing custom CMake code to do this in my own projects. On Mon, Aug 31, 2015 at 12:29 PM, Gonzalo <ggarr...@gmail.com> wrote: s it has changed names a couple of times). That shoul -- Guillaume Dumont = dumont.guilla...@gmail.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: http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] [CMake] Visual Studio - Ninja Generator
h C# project - even when using non-VS generators like Ninja. The Ninja build rule for a C# project would just be to invoke MSBuild.exe and build that one project. (Only generate projects, not solutions.) But this requires the ability for a CMake language to invoke the MSBuild-generating code inside CMake to spit out a Visual Studio project for each C# target. Benefit: now CMake doesn't reimplement undocumented behavior of Microsoft's MSBuild targets; we just use them directly as a black box. Best regards, James Johnston From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Guillaume Dumont Sent: Monday, August 31, 2015 16:49 To: Gonzalo Cc: cm...@cmake.org Subject: Re: [CMake] Visual Studio - Ninja Generator @Hendrik Sattler I have not experimented with the /MP flag that much, but this won't solve my problem when the project contains a lot of CUDA files. The /MP flag as not effect there. Yes I could indeed create a custom build target and create additional build trees to build using ninja in there but this is suboptimal in my opinion. @Gonzalo Yes this is precisely what I do but then you only get the ninja build files. No solution for debugging etc. My question is more about the difficulty of creating a new generator that makes the use of ninja as transparent as possible to the user instead of writing custom CMake code to do this in my own projects. On Mon, Aug 31, 2015 at 12:29 PM, Gonzalo <ggarr...@gmail.com> wrote: s it has changed names a couple of times). That shoul -- Guillaume Dumont = dumont.guilla...@gmail.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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens
-Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Kislinskiy, Stefan Sent: Thursday, August 27, 2015 13:44 To: Brad King; CHEVRIER, Marc; David Cole Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens This is pretty nice from the perspective of an engineer. But I wonder if it wouldn't be kind of over-engineered in the sense that it would be a rather hidden feature for the purpose? -- I probably wouldn't think of searching for a generator expression in the documentation when I have trouble with the replacement of directory tokens. Then again, there could be a hint in the ExternalProject documentation which would be fine I guess. One way or another, I would be happy if we could determine what the patch should provide exactly so that we come to an end. :-) Thank you for all the feedback so far. I think Brad raises an excellent point here though I hadn't thought of... implementing the underlying functionality as a generator expression allows the problem to be solved outside of the scope of ExternalProject when it arises... For example if I add_custom_command as a custom build step and need to pass a native path argument to it - a path known only at generate time. I guess it is not possible right now? Another approach is to introduce a generator expression to transform the path slash style. Then it could be used both for ExternalProject and in other custom commands. E.g. $PATH_FOR_SHELL:SOURCE_DIR/bootstrap${shell_ext} In this case SOURCE_DIR would be replaced with forward slashes by ExternalProject but then at generate time CMake would evaluate the genex to convert slashes as needed. I would vote naming it TO_NATIVE_PATH instead of PATH_FOR_SHELL, for consistency with the existing parameter in the file command. There could then also be a corresponding TO_CMAKE_PATH gen-exp, although I wonder if it would be used much. (Then again, do people even use file(TO_CMAKE_PATH) very much?) James -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens
-Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Kislinskiy, Stefan Sent: Wednesday, August 26, 2015 10:03 To: CHEVRIER, Marc; David Cole Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens I see. Added native-style path replacements for SOURCE_NATIVE_DIR and so on. Also extended the documentation accordingly. Some relatively major/minor/nitpicky thoughts in the interests of thoroughness: * There's no test code. It would be good if there was some code to explicitly test these options for nightly testing. For that matter, I think the original tokens weren't thoroughly tested either (e.g. a quick grep for TMP_DIR doesn't show usage of that token at all in the tests). The whole situation could therefore use some help, I think. There are several existing tests of ExternalProject that could probably be extended to test these tokens as needed. * Token replacement is done for WORKING_DIRECTORY and BYPRODUCTS parameters of add_custom_command. You'd best be sure those parameters of add_custom_command can handle a native path, or else not convert to native paths - even for *_NATIVE tokens - when the path is destined for one of those parameters. (I'd tend to assume the command *could* handle it properly since a lot of users might inadvertently pass them, but it's something that should be double-checked. If the command is passing those paths as-is to the generator, correct operation could even vary by generator.) The easy way out might be to have a parameter on _ep_replace_location_tags declaring whether to ACTUALLY convert native path tokens to native paths, and then callers to that macro can decide if they can / should handle native paths. * It would be useful if the documentation explicitly stated that the old BINARY_DIR friends variables are using CMake paths; currently the documentation does not say - which was a shortcoming of the original docs (as you found out accidentally, it is CMake paths). * Nothing explicitly to do with your patch, but the documentation doesn't state that any of the tokens are valid in ExternalProject_Add; it may be useful to audit the options of ExternalProject_Add and see where they can be used, and document accordingly. (Some are obvious, like CONFIGURE_COMMAND, but some are less obvious, like CMAKE_CACHE_ARGS / CMAKE_CACHE_DEFAULT_ARGS which appear to have their own special handling for these tokens, yet none of that is documented. Even a newcomer might not realize the obvious, if they don't realize that ExternalProject_Add is implemented via ExternalProject_AddStep.) * New features should also be documented in Help/release/dev so that it makes it into the release notes of the next CMake version (i.e. so people notice your new feature). I leave it to others to decide if adding the new *_NATIVE tokens is the right way, or if there's a better way - as I myself am a newcomer to CMake. I think I like it though. :) Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] How to depend on external cmake projects?
-Original Message- From: rcdai...@gmail.com [mailto:rcdai...@gmail.com] On Behalf Of Robert Dailey Sent: Sunday, August 23, 2015 02:43 To: James Johnston Cc: CMake Subject: Re: [CMake] How to depend on external cmake projects? On Mon, Aug 17, 2015 at 10:17 AM, James Johnston jam...@motionview3d.com wrote: Well, you'd do this in conjunction with ExternalProject_Add. A well-written CMake external project will provide a projectConfig.cmake file which you will then find using find_package. After toying around with this idea for a bit, I've found out that ExternalProject_Add() actually builds the project from a custom target within Visual Studio (I'm using VS as my generator). However, find_package() works at CMake configure time, so this is a chicken egg problem. find_package() won't work because the external project has not been built yet. How do you solve this problem? By following the following suggestion from earlier: A high-level CMake project that does nothing but call ExternalProject_Add; this is called a superbuild. Your own CMake projects will be ExternalProjects to this high-level project and the superbuild would pass the location to your project via -Dproject_DIR=location so that find_package can locate the Config file. I'm not sure I understand this. This smells related to my question above, maybe an answer even. Can you clarify/go into more detail? Thanks a bunch. Here is an example: https://github.com/InsightSoftwareConsortium/ITKWikiExamples/tree/master/Superbuild This CMakeLists.txt is the root CMakeLists.txt for the superbuild. Notice that: 1. It calls ExternalProject_Add to build VTK/ITK, **as well as** its own project. 2. find_package is not called from the superbuild, thus avoiding the chicken and egg problem. Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v3.3.1-2430-g50e7fa6
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, next has been updated via 50e7fa615cfcb63b337640d353fc153a74ac1fde (commit) via 1869eacb3d2e897695007f210da219a0ee73cba8 (commit) from a3d0518c64d2a3848487ac0d2fc93af622bacc61 (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=50e7fa615cfcb63b337640d353fc153a74ac1fde commit 50e7fa615cfcb63b337640d353fc153a74ac1fde Merge: a3d0518 1869eac Author: James Johnston johnstonj.pub...@codenest.com AuthorDate: Mon Aug 24 23:10:56 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Aug 24 23:10:56 2015 -0400 Merge topic 'fix-load-command-doc-classification' into next 1869eacb Help: Fix classification of load_command in command TOC. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1869eacb3d2e897695007f210da219a0ee73cba8 commit 1869eacb3d2e897695007f210da219a0ee73cba8 Author: James Johnston johnstonj.pub...@codenest.com AuthorDate: Mon Aug 24 23:09:31 2015 -0400 Commit: James Johnston johnstonj.pub...@codenest.com CommitDate: Mon Aug 24 23:09:31 2015 -0400 Help: Fix classification of load_command in command TOC. In CMake 3.0, the load_command command was deprecated. However, the position of load_command in the help TOC was not fixed at that time: it was still listed as a Normal Command. diff --git a/Help/manual/cmake-commands.7.rst b/Help/manual/cmake-commands.7.rst index c916f77..5b92b51 100644 --- a/Help/manual/cmake-commands.7.rst +++ b/Help/manual/cmake-commands.7.rst @@ -71,7 +71,6 @@ These commands may be used freely in CMake projects. /command/link_libraries /command/list /command/load_cache - /command/load_command /command/macro /command/mark_as_advanced /command/math @@ -119,6 +118,7 @@ versions of CMake. Do not use them in new code. /command/install_files /command/install_programs /command/install_targets + /command/load_command /command/make_directory /command/output_required_files /command/remove --- Summary of changes: Help/manual/cmake-commands.7.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens
Hi, Funny you are mailing the list about this, since I just ran into this same issue today building something totally different from Boost... In this case it's a build tool that thinks the /U in C:/Users is a new command line argument, that isn't recognized - and then the subsequent s also ends up unrecognized... and it all fails... And it has nothing to do with the working directory, so _Add_Step(WORKING_DIRECTORY) isn't a possible workaround for me. I think the issue with globally making this change to the existing tokens is that there could be some external tool/program that is EXPECTING to get CMake paths, not native paths. Who knows? I am guessing that is what David Cole was concerned about. Maybe the right answer is to introduce some NEW tokens while leaving the behavior of the old ones unchanged. E.g. BINARY_DIR_NATIVE etc. It would be good if the patch updates the documentation of ExternalProject and clearly states the path format of BINARY_DIR vs BINARY_DIR_NATIVE. Then the user can pick whichever one suits them best, depending on the tool being invoked. Furthermore, sometimes BINARY_DIR_NATIVE still needs to be replaced with a CMake path, not native path. For example, if the token is being found in a property like WORKING_DIRECTORY that eventually gets passed to add_custom_command(WORKING_DIRECTORY) then I'm guessing still has to be a CMake path. I am guessing this is what David Cole was also concerned about. I still think your original method of building Boost is a bit unusual and would be better served by _Add_Step with a custom working directory - because that's the publicly documented/standard way of changing the working directory, but that is up to you. :) Best regards, James Johnston On Thu, 20 Aug 2015 14:37:08 + Stefan Kislinskiy s.kislins...@dkfz-heidelberg.de wrote Hi, thank you for our suggestions. I am aware that I can solve my example differently and that it might look not directly connected the proposal, but well, it is an example just to show a single case and why it matters. :) I did not want to discuss the example itself. Working around here would just resolve a symptom. My point is the overall problem that would persist: A big part of ExternalProject is to issue commands for predefined and custom steps. Those commands are supposed to be executed by the shell/command line. According to the documentation and the source code of ExternalProject, directory tokens are mainly supposed to be replaced in commands. It is my understanding, that it is a bug, if CMake isn't able to assemble these commands correctly. This would include usage of the correct path style of the OS for shell/command line commands. As directory tokens are replaced internally right before a shell/command line command is assembled, I can't see why this would be kind of API-breaking. You cannot interfere in your CMake code with these internal replacements. Therefore I would still prefer my solution as it is pretty simple without adding even more features to ExternalProject and in my opinion without breaking code in the wild. It is a true bug fix instead of a feature request for working directories, which is a different topic that just coincidentally arised because of my specific example I guess. The features you described wouldn't fix the actual bug. As you were not sure if my approach would even fix my problems: It does of course and this is what I am currently doing and what I tested extensively before creating the patch. :) Regarding your quote from the add_custom_command documentation I can tell you that this is how things are currently done in ExternalProject and always were as far as I know, for example (from ExternalProject.cmake): add_custom_command( OUTPUT ${stamp_file} BYPRODUCTS ${byproducts} COMMENT ${comment} COMMAND ${command} COMMAND ${touch} DEPENDS ${depends} WORKING_DIRECTORY ${work_dir} VERBATIM ) Best regards, Stefan -Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of James Johnston Sent: Donnerstag, 20. August 2015 15:37 To: cmake-developers@cmake.org Subject: Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens -Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Kislinskiy, Stefan Sent: Thursday, August 20, 2015 09:02 To: David Cole Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens Hi David, Example excerpt (it is not possible to change the working directory for the CONFIGURE_COMMAND as it is fixed to the BUILD_DIR, which might
Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens
-Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Kislinskiy, Stefan Sent: Thursday, August 20, 2015 09:02 To: David Cole Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens Hi David, Example excerpt (it is not possible to change the working directory for the CONFIGURE_COMMAND as it is fixed to the BUILD_DIR, which might not be sufficient): This doesn't really directly have to do with your proposal, but what if an option was added to change the working dir of the CONFIGURE_COMMAND? E.g. WORKING_DIRECTORY_CONFIGURE. And suppose you'd have it recognize the various tags like SOURCE_DIR, etc. This might be useful to add to other steps as well, and would be more portable than your solution which is using cmd.exe-specific commands. You'd want to audit for any resulting breakage (e.g. does ExternalProject make assumptions that the working directory of CONFIGURE is always the binary dir? - e.g. a relative path being used somewhere. And probably only allow specification of WORKING_DIRECTORY_CONFIGURE if a CONFIGURE_COMMAND was also specified, as the built-in commands certainly assume the default working dir.) In your situation though, I'm not sure it's strictly needed. From your sample, it looks like you're building boost. In your case what if you: * Use ExternalProject_Add_Step to bootstrap. You can specify a WORKING_DIRECTORY here. Note one problem: you can't do out of source build of b2, which breaks user expectations. * Then use ExternalProject_Add_Step to build Boost. Yes, using _Add_Step is somewhat of a workaround, but in this case, I've found it wasn't much of a burden at all. In fact the only case I can think of where it WOULD be a burden would be if the configure step is CMake. But then you wouldn't need to change the working directory; changing it would break CMake. In practice nobody will want to change WORKING_DIRECTORY unless it's a custom command and then it's easy to use _Add_Step anyway. That said, it might still be considered a little undesired and so maybe my proposal above would be a better way to handle it. Corrections from maintainers and others on the above commentary are welcome... set(bootstrap_cmd SOURCE_DIR/bootstrap${shell_ext} ${bootstrap_toolset}) if(WIN32) set(bootstrap_cmd pushd SOURCE_DIR COMMAND ${bootstrap_cmd} COMMAND popd) endif() ExternalProject_Add(Boost ... CONFIGURE_COMMAND ${bootstrap_cmd} ... ) From add_custom_command: If more than one COMMAND is specified they will be executed in order, but not necessarily composed into a stateful shell or batch script. So I am not sure your approach will work for you even if you fix the issue with path slashes. James -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens
-Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of David Cole via cmake-developers Sent: Thursday, August 20, 2015 21:21 To: James Johnston Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens It's exactly what I am concerned about: You're asking to change the behavior of something for EVERYONE to solve a problem which you have encountered. If you change it the way you have proposed, you will cause problems for others. It has worked the way it is now since ExternalProject_Add was introduced in CMake 2.8. Changing it unconditionally the way you propose is simply not feasible for backwards compatibility. I think commands that take native paths ought NOT to use the *_DIR replacement values, and instead, ought to pass in variables that contain the native paths in the first place. Right, agreed that the original *_DIR behavior would need to remain unchanged. But how would you know what the binary directory of the external project is, before calling ExternalProject_Add? It's too early to call ExternalProject_Get_Property(target BINARY_DIR). I assume that is why BINARY_DIR and friends exist, as the location will be affected via various ExternalProject parameters. From the doc: The *_DIR options specify directories for the project, with default directories computed as follows snip Quite a set of rules follow and if one is trying to use the binary directory in the path to some build tool, it's handy to put BINARY_DIR in the command. But if you need a native path for your build tool, BINARY_DIR doesn't work as Stefan Kislinskiy noted, which is why I suggested making new tokens might be a viable alternative, e.g. BINARY_DIR_NATIVE? Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, next, updated. v3.3.1-2257-g788a368
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, next has been updated via 788a368bb48a56e2ea91a9ab6aaeb717ef8c3615 (commit) via e89ea3d190492e41b37425ff021311c2b471f1b9 (commit) from f55e338e34017b32301a081a4ccc5967ecfbf0e3 (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=788a368bb48a56e2ea91a9ab6aaeb717ef8c3615 commit 788a368bb48a56e2ea91a9ab6aaeb717ef8c3615 Merge: f55e338 e89ea3d Author: James Johnston johnstonj.pub...@codenest.com AuthorDate: Mon Aug 17 23:57:23 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Mon Aug 17 23:57:23 2015 -0400 Merge topic 'get-filename-component-base-dir' into next e89ea3d1 get_filename_component: Teach new BASE_DIR parameter. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e89ea3d190492e41b37425ff021311c2b471f1b9 commit e89ea3d190492e41b37425ff021311c2b471f1b9 Author: James Johnston johnstonj.pub...@codenest.com AuthorDate: Mon Aug 17 23:55:38 2015 -0400 Commit: James Johnston johnstonj.pub...@codenest.com CommitDate: Mon Aug 17 23:55:38 2015 -0400 get_filename_component: Teach new BASE_DIR parameter. In the get_filename_component command, add a new BASE_DIR parameter to use with the ABSOLUTE and REALPATH options. This will be used when finding an absolute path from a relative path. diff --git a/Help/command/get_filename_component.rst b/Help/command/get_filename_component.rst index 60488da..82f9120 100644 --- a/Help/command/get_filename_component.rst +++ b/Help/command/get_filename_component.rst @@ -3,6 +3,8 @@ get_filename_component Get a specific component of a full filename. +-- + :: get_filename_component(VAR FileName COMP [CACHE]) @@ -15,8 +17,6 @@ Set ``VAR`` to a component of ``FileName``, where ``COMP`` is one of: NAME = File name without directory EXT = File name longest extension (.b.c from d/a.b.c) NAME_WE = File name without directory or longest extension - ABSOLUTE = Full path to file - REALPATH = Full path to existing file with symlinks resolved PATH = Legacy alias for DIRECTORY (use for CMake = 2.8.11) Paths are returned with forward slashes and have no trailing slahes. @@ -24,14 +24,41 @@ The longest file extension is always considered. If the optional ``CACHE`` argument is specified, the result variable is added to the cache. +-- + +:: + + get_filename_component(VAR FileName + COMP [BASE_DIR BASE_DIR] + [CACHE]) + +Set ``VAR`` to the absolute path of ``FileName``, where ``COMP`` is one +of: + +:: + + ABSOLUTE = Full path to file + REALPATH = Full path to existing file with symlinks resolved + +If the provided ``FileName`` is a relative path, it is evaluated relative +to the given base directory ``BASE_DIR``. If no base directory is +provided, the default base directory will be +:variable:`CMAKE_CURRENT_SOURCE_DIR`. + +Paths are returned with forward slashes and have no trailing slahes. If the +optional ``CACHE`` argument is specified, the result variable is added to the +cache. + +-- + :: - get_filename_component(VAR FileName + get_filename_component(VAR FileName PROGRAM [PROGRAM_ARGS ARG_VAR] [CACHE]) -The program in ``FileName`` will be found in the system search path or +The program in ``FileName`` will be found in the system search path or left as a full path. If ``PROGRAM_ARGS`` is present with ``PROGRAM``, then -any command-line arguments present in the ``FileName`` string are split +any command-line arguments present in the ``FileName`` string are split from the program name and stored in ``ARG_VAR``. This is used to separate a program name from its arguments in a command line string. diff --git a/Help/release/dev/get-filename-component-base-dir.rst b/Help/release/dev/get-filename-component-base-dir.rst new file mode 100644 index 000..c0df759 --- /dev/null +++ b/Help/release/dev/get-filename-component-base-dir.rst @@ -0,0 +1,6 @@ +get-filename-component-base-dir +--- + +* The :command:`get_filename_component` command learned a new ``BASE_DIR`` + subcommand. This is used to specify a base directory when calculating an + absolute path from a relative path. diff --git a/Source/cmGetFilenameComponentCommand.cxx b/Source/cmGetFilenameComponentCommand.cxx index
Re: [CMake] How to depend on external cmake projects?
-Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert Dailey Sent: Sunday, August 16, 2015 13:32 To: CMake Subject: [CMake] How to depend on external cmake projects? There are certain repositories on Github I'd like to pull in as a dependency. These repositories already use CMake to build their source code. Based on personal experience and reading material online, there are a couple of different options: 1. Pull down the repository as a submodule to my own git repository. Then call add_subdirectory() on it to make it part of the build, allowing me to refer to those targets as dependencies in my own targets. That's one way to do it. It might be a good way if the dependency is relatively small. Benefits: * Simpler/flattened build process (no hierarchy of makefiles are generated) * No need to delete timestamp files generated by ExternalProject_Add if you need to incrementally build the project. Problems: * Everything must be built with same compiler, generator, build settings, etc. (benefit for some projects, a problem for others). * The dependency must use CMake. * Potential for interference between CMake variables/properties set by your top-level project and your included submodule. ExternalProject_Add is guaranteed to work because this can't happen, but add_subdirectory is not guaranteed to work. * Incrementally building a bunch of these projects, or a big project, could be slow (e.g. your make tool has to check if the files in the submodule changed, in addition to your own. ExternalProject_Add sidesteps this with the timestamps). 2. Use ExternalProject_Add(). This seems like legacy, I'm not sure if I should use this. It also seems very verbose and boilerplate. I don't think it's legacy at all, lots of projects use it. It exists because of the problems of add_subdirectory shown above. The downside is you get these goofy timestamp files you have to manually delete now again if your submodule changes. You can still include the project as a submodule, just use SOURCE_DIR parameter to pass the submodule path and skip the preliminary steps before CONFIGURE. Even if CMake in the distant future supports different C++ compilers/architectures in the same project, there will still be a need to build non-CMake dependencies and thus a place for ExternalProject. 3. Use packages. The [CMake package documentation][1] does not go into great detail on support for both installed versions and build tree for a single package. Does this require two scripts? Can it share a single one? Where are the examples? Well, you'd do this in conjunction with ExternalProject_Add. A well-written CMake external project will provide a projectConfig.cmake file which you will then find using find_package. How do I accomplish this? A high-level CMake project that does nothing but call ExternalProject_Add; this is called a superbuild. Your own CMake projects will be ExternalProjects to this high-level project and the superbuild would pass the location to your project via -Dproject_DIR=location so that find_package can locate the Config file. Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[cmake-developers] Clarification requested on #10126 (CMake creates files with wrong permissions)
Hi, I figured I'd take a look at resolving #10126: http://www.cmake.org/Bug/view.php?id=10126 The fix proposed by Brad King at this ticket involves two parts. I'd like to seek clarification on this ticket. 1. It is proposed to add new file permissions to INSTALL and FILE commands called READ/WRITE/EXECUTE. a. So to clarify, you'd want existing OWNER_* / GROUP_* / EXECUTE_* options to remain unmodified? i.e. if you install(PERMISSIONS GROUP_WRITE) this will still NOT respect the umask, correct? (i.e. the only way to respect the umask would be to use the NEW READ/WRITE/EXECUTE options?) b. If the answer to (a) is yes, what do you want to do if the user specifies install(PERMISSIONS WRITE GROUP_WRITE)? Is that an error? Should we just have the WRITE take precedence and respect the umask anyway, even though GROUP_WRITE was specified to not respect umask? (If the answer to (a) is no, then obviously there's no harm in specify WRITE GROUP_WRITE because it's purely redundant.) c. Would it be better to introduce a new permissions keyword for respecting the umask for the entire set of keywords? E.g. install(PERMISSIONS RESPECT_UMASK GROUP_WRITE). This could be done in conjunction with new READ/WRITE/EXECUTE, so for example: install(PERMISSIONS RESPECT_UMASK WRITE) would specify owner/group/world write while respecting umask, and install(PERMISSIONS WRITE) would do the same but NOT respect the umask. What I like about this: (i) preserves compatibility as if you answer yes to (a) above, (ii) avoids the issues from (b) above. d. If the answer to (c) is yes, should that keyword become the default, subject to a new policy? (And introduction of a different NO_RESPECT_UMASK keyword). 2. Proposal to modify default permission copying of configure_file and friends: I may have questions here but haven't thought it through yet. Finally, to resolve the issue as reported by the original submitter: Fix works almost perfectly, yet there are some files still having 0644 rights: in builddir/CMakeFiles/ it's - CMakeCCompiler.cmake - CMakeCXXCompiler.cmake - CMakeSystem.cmake 3. Won't the proposal from #2 above fix this problem? As in, #1 then because a nice-to-have thing but not necessary to fix the original problem with CMake? (Or do we need to go on and modify the INSTALL commands in CMake itself to use the new #1 feature above to change CMake's installation?) Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting up environment using ExternalProject_Add
-Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of David Cole via cmake-developers Sent: Wednesday, August 12, 2015 15:53 To: Brad King Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] Setting up environment using ExternalProject_Add One thing to consider before embarking on modifying CMake for required environment purposes is that it might be just as simple to force (or at least strongly encourage) your project developers to use the proper environment for running the whole build. You could, for example, have an initial external project which all others depend on which verifies the proper environment is set when it is called. If not, it fails with an error, and prevents downstream bits from building. snip I think your situation is simpler than mine - i.e. if I'm reading this right, all your ExternalProjects are built for the same Visual C++ version and CPU architecture - such that the user can/should run VCVarsAll before invoking the CMake superbuild? What I'm trying to do: A CMake superbuild that expects NO environment set up, and NO languages configured. It: * Builds Visual C++ 32-bit * Builds Visual C++ 64-bit * Builds some other non-Visual-C++ compilers/architectures All within the same superbuild. This is due to the fact that CMake doesn't support multiple architectures directly (and probably won't for a long time, if ever). So, each ExternalProject_Add needs to have its own unique environment set up. I don't think it makes sense to try to run VCVarsAll.bat before invoking the superbuild - in fact, doing so is detrimental (i.e. increases risk of building for the wrong CPU architecture if a particular VCVarsAll.bat invocation silently malfunctions). Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting up environment using ExternalProject_Add
-Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Brad King Sent: Wednesday, August 12, 2015 14:10 To: cmake-developers@cmake.org Subject: Re: [cmake-developers] Setting up environment using ExternalProject_Add On 08/11/2015 10:41 AM, James Johnston wrote: 1. CMake creates a temporary shell script / batch file (the shell chosen based on the platform CMake compiled for - cmd.exe on Windows, sh on POSIX). I don't think CMake needs to be the one to generate this. The complexity of the file-based or command-line-based interfaces you discussed shows that it would be tricky to have CMake generate it. snip OK... enhancing e.g. add_custom_command as I proposed might make it easier, as this command could be aware of compiled EXE targets. With file(GENERATE) the project code can easily create scripts that reference executable targets and such. One would just need to tackle this feature request first to get file permissions right: http://www.cmake.org/Bug/view.php?id=15653 Indeed; that looks like a useful feature to have to begin with, and a requirement if ExternalProject is to generate its own script... Therefore I do not think add_custom_command needs any hook for this. One would simply give the script as the COMMAND. Right, obviously not needed if no cmake -E option is added/enhanced and if we want ExternalProject_Add (and anyone else needing custom targets) to make their own script... we'd want to add features to ExternalProject that use the new CMake functionality to finally solve the original problem. Yes, this part certainly needs an update to ExternalProject. Currently when one specifies an individual step_COMMAND like CONFIGURE_COMMAND, then one could simply give it the environment-set-and-launch script directly. What ExternalProject needs is an interface to specify the environment- setting script for use around otherwise default-generated commands for each step. For example, a step_ENVIRONMENT setting (which is perhaps not allowed in combination with step_COMMAND). This approach is similar to your original alternative (3). I'll explore that option some more, after the feature you linked to is addressed. one could simply give it the environment-set-and-launch script directly ... This script is obviously platform-specific, yet still needs knowledge of the command that ExternalProject will generate to launch the sub-CMake - which the user of ExternalProject obviously does not know. I am not sure that introducing some shell-specific knowledge to ExternalProject can be avoided in this case, so hopefully it will not be a problem to do this. There are two ways I immediately think of - trying to clarify what I think you are suggesting: 1. The new step_ENVIRONMENT setting points to a environment-set script that does not try to do any launching (e.g. you could pass VCVarsAll.bat directly as the step_ENVIRONMENT). ExternalProject determines which shell to generate for, and generates the environment-set-and-launch script itself from scratch (like how I originally proposed with the cmake -E enhancement). In other words, ExternalProject(snip CONFIGURE_ENVIRONMENT $ENV{VS100COMNTOOLS}/../../VC/vcvarsall.bat x86 CMAKE_GENERATOR Ninja CMAKE_CACHE_ARGS snip) and away the user goes.. 2. The new step_ENVIRONMENT setting points to an environment-set-and-launch script that is expected to be configured with configure_file by ExternalProject. So e.g. the user provides a batch file that calls VCVarsAll.bat, and then there is a magical ${EXTERNAL_PROJECT_COMMAND} or whatever that the user is expected to provide at the end of the template batch file that they give to ExternalProject. I suspect this will simplify ExternalProject a little bit at the cost of more boiler-plate code that the user has to provide (e.g. can't directly call VCVarsAll.bat in the common case, must manage their own scripts). And gives the user opportunity to really mess up ExternalProject operation (e.g. forgetting to include ${EXTERNAL_PROJECT_COMMAND}, or forgetting to check ERROR_LEVEL in a shell-specific way after calling EXTERNAL_PROJECT_COMMAND, etc.). I think this would not be as user friendly, but perhaps slightly easier for ExternalProject to handle. But at the end, the configure_file substitution for ${EXTERNAL_PROJECT_COMMAND} is still potentially shell-specific In other words, ExternalProject(snip CONFIGURE_ENVIRONMENT ProjectEnvironment.bat.in CMAKE_GENERATOR Ninja CMAKE_CACHE_ARGS snip) And ProjectEnvironment.bat.in: @echo off call %VS100COMNTOOLS%/../../VC/vcvarsall.bat rem Users better not forget this next line... rem ExternalProject would configure_file this. ${EXTERNAL_PROJECT_COMMAND} rem If a user adds more commands to the end of the batch file, they'd need this: if ERRORLEVEL 1 exit /b %ERRORLEVEL% Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic
Re: [cmake-developers] Setting up environment using ExternalProject_Add
-Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Tuesday, August 11, 2015 13:35 To: James Johnston Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] Setting up environment using ExternalProject_Add On 08/11/2015 12:49 AM, James Johnston wrote: CONFIGURE_ENVIRONMENT_COMMAND path to VCVarsAll.bat [snip] add_custom_command(snip ENVIRONMENT_COMMAND path to vcvarsall.bat COMMAND ${CMAKE_PROGRAM} -GNinja snip) A problem with both of these approaches is that on UNIX and in Make the environment does not persist after the command exits. Exactly right, I'm aware... and also it seems there is no good/easy/non-hackish way to capture the environment from a child process after it terminates, either - that I'm aware of. (It would be nice if we could run a process, then capture its environment after it exits, but I don't think it can be done.) Whatever wrapper tool is used must set the environment and also launch the real command to be run under that environment. This is what the env tool (and recently cmake -E env) does. Right, but the problem with cmake -E env is it assumes you know what variables you want to set - we don't. Only a shell script / batch file knows in the case of VCVarsAll.bat... I think I mentioned this solution in the original e-mail but in more detail, what I'm proposing with the proposed cmake -E run_commands or whatever we want to call it would be the following. In fact upon further thought, it might be better to see about enhancing the cmake -E env command but I am not sure if this is possible due to the syntax of cmake -E env. Anyhow the basic idea is this: 1. CMake creates a temporary shell script / batch file (the shell chosen based on the platform CMake compiled for - cmd.exe on Windows, sh on POSIX). 2. CMake calls one or more environment setup commands. These are pulled in using call / source. Users would be required to provide scripts for environment setup in the format of the native shell (e.g. you can't call a bash script from a Windows .bat file). For example: @echo off rem User script provided to CMake, including some arguments to the script call dir\VCVarsAll.bat x86 rem An additional environment variable explicitly specified by the user set MyVar=Value cmake -GNinja . Or: #!/bin/sh source setMyEnv.sh cmake -GNinja . Error handling has been cut for brevity, but we would want the script to check for ERRORLEVEL / $? after each line above. As you can see, the problem of environment not being retained has been solved by using call and source. 3. Then CMake runs the above script as normal and checks the exit code as normal. It's basically a close cousin of what cmake -E env does in that we: (1) do some things to set up the environment, (2) run the specified EXE. Ideally cmake -E env could be enhanced with the new functionality, but since we now want to pass an arbitrary list of commands, each with potentially unlimited parameters of any format, I'm not sure how that should look in practice. It might be easier to make a new command cmake -E env2 or whatever (need to find a better name): * It could be passed a file. The file contents would have a series of lines, either SET / UNSET name=[value], SOURCE VCVarsAll.bat x86, or COMMAND cmake.exe snip. Newlines delimit commands. * It could be passed all the commands directly on the command line. A recognized -- switch delimits commands. E.g. cmake -E env2 --unset NAME --set NAME=VALUE --source VCVarsAll.bat x86 --command cmake.exe snip --source moreSetup.bat --command somethingelse.exe Downsides with first method: file adds complexity. Downsides with second method: subject to command line length limits, though probably not an issue in practice. Also, what if user wants to pass --unset or --set parameter to their command as an argument? Without a means of escaping, CMake will think the command is ended and the user is trying to do something new. That's the first and most important step. The above functionality would still be inconvenient to use (e.g. cmake -E will not be aware of any compiled EXE target output paths). So, enhancing e.g. add_custom_command as I proposed might make it easier, as this command could be aware of compiled EXE targets. Finally, we'd want to add features to ExternalProject that use the new CMake functionality to finally solve the original problem. The alternative ideas in my e-mail are just a question of who generates the above temporary script that sources/calls a user script. E.g. in option 3, we leave C++ portion of CMake alone, and ExternalProject would then have to auto-generate the above temporary script instead. Best regards, James Johnston -- 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
[cmake-developers] Setting up environment using ExternalProject_Add
, and probably option 1a. In that case, steps would be: (1) implement cmake -E run_commands, (2) extend add_custom_command, (3) extend ExternalProject_Add. What do you think? Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[Cmake-commits] CMake branch, next, updated. v3.3.0-2109-g8618bdc
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, next has been updated via 8618bdc60bfe0f81fe5ce1e1c31afdcf69eb692e (commit) via 874e70bc57f54e5fc898a169797a0b1e45df31f6 (commit) via c5ac2b9df36a57d3b88e80a2d1c382d753faf2da (commit) via 101ba25e6a2c177f9f3a81f3879a171256806756 (commit) from 43e2c0863b0c71fe5573a8d9def948fa7c40cdff (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8618bdc60bfe0f81fe5ce1e1c31afdcf69eb692e commit 8618bdc60bfe0f81fe5ce1e1c31afdcf69eb692e Merge: 43e2c08 874e70b Author: James Johnston johnstonj.pub...@codenest.com AuthorDate: Sun Aug 9 13:59:02 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Sun Aug 9 13:59:02 2015 -0400 Merge topic 'ninja-version-handling' into next 874e70bc Ninja: Prevent generating if installed Ninja version is too old. c5ac2b9d Ninja: Centralized required Ninja version numbers and comparisons. 101ba25e CMake Nightly Date Stamp http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=874e70bc57f54e5fc898a169797a0b1e45df31f6 commit 874e70bc57f54e5fc898a169797a0b1e45df31f6 Author: James Johnston johnstonj.pub...@codenest.com AuthorDate: Sun Aug 9 13:51:35 2015 -0400 Commit: James Johnston johnstonj.pub...@codenest.com CommitDate: Sun Aug 9 13:51:35 2015 -0400 Ninja: Prevent generating if installed Ninja version is too old. diff --git a/Source/cmGlobalNinjaGenerator.cxx b/Source/cmGlobalNinjaGenerator.cxx index b46d85c..b92ad32 100644 --- a/Source/cmGlobalNinjaGenerator.cxx +++ b/Source/cmGlobalNinjaGenerator.cxx @@ -547,6 +547,18 @@ void cmGlobalNinjaGenerator // Source/cmake.cxx void cmGlobalNinjaGenerator::Generate() { + // Check minimum Ninja version. + if (cmSystemTools::VersionCompare(cmSystemTools::OP_LESS, +CurrentNinjaVersion().c_str(), +RequiredNinjaVersion().c_str())) +{ +std::ostringstream msg; +msg The detected version of Ninja ( this-CurrentNinjaVersion(); +msg ) is less than the version of Ninja required by CMake (; +msg this-RequiredNinjaVersion() ).; +this-GetCMakeInstance()-IssueMessage(cmake::FATAL_ERROR, msg.str()); +return; +} this-OpenBuildFileStream(); this-OpenRulesFileStream(); http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c5ac2b9df36a57d3b88e80a2d1c382d753faf2da commit c5ac2b9df36a57d3b88e80a2d1c382d753faf2da Author: James Johnston johnstonj.pub...@codenest.com AuthorDate: Sat Aug 8 20:04:08 2015 + Commit: James Johnston johnstonj.pub...@codenest.com CommitDate: Sun Aug 9 13:31:24 2015 -0400 Ninja: Centralized required Ninja version numbers and comparisons. diff --git a/Source/cmGlobalNinjaGenerator.cxx b/Source/cmGlobalNinjaGenerator.cxx index 088f0e1..b46d85c 100644 --- a/Source/cmGlobalNinjaGenerator.cxx +++ b/Source/cmGlobalNinjaGenerator.cxx @@ -1256,7 +1256,7 @@ std::string cmGlobalNinjaGenerator::ninjaCmd() const return ninja; } -std::string cmGlobalNinjaGenerator::ninjaVersion() const +std::string cmGlobalNinjaGenerator::CurrentNinjaVersion() const { std::string version; std::string command = ninjaCmd() + --version; @@ -1264,13 +1264,14 @@ std::string cmGlobalNinjaGenerator::ninjaVersion() const version, 0, 0, 0, cmSystemTools::OUTPUT_NONE); - return version; + return cmSystemTools::TrimWhitespace(version); } bool cmGlobalNinjaGenerator::SupportsConsolePool() const { return cmSystemTools::VersionCompare(cmSystemTools::OP_LESS, - ninjaVersion().c_str(), 1.5) == false; +CurrentNinjaVersion().c_str(), +RequiredNinjaVersionForConsolePool().c_str()) == false; } void cmGlobalNinjaGenerator::WriteTargetClean(std::ostream os) diff --git a/Source/cmGlobalNinjaGenerator.h b/Source/cmGlobalNinjaGenerator.h index 2a749c1..a1df1c2 100644 --- a/Source/cmGlobalNinjaGenerator.h +++ b/Source/cmGlobalNinjaGenerator.h @@ -299,8 +299,10 @@ public: virtual void ComputeTargetObjectDirectory(cmGeneratorTarget* gt) const; - std::string ninjaVersion() const; - + std::string CurrentNinjaVersion() const; + // Ninja generator uses 'deps' and 'msvc_deps_prefix' introduced in 1.3 + static std::string RequiredNinjaVersion() { return 1.3; } + static std::string RequiredNinjaVersionForConsolePool() { return 1.5; } bool SupportsConsolePool() const; protected: diff --git a/Source/cmLocalNinjaGenerator.cxx b/Source/cmLocalNinjaGenerator.cxx index 9889bd4..aaad075 100644 --- a/Source
[Cmake-commits] CMake branch, next, updated. v3.3.0-2103-g9b72aec
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, next has been updated via 9b72aec7b3624b6bb8e409e52a29263591856f81 (commit) via 203b20df98512094cc74061fd1b76e87bd2d3afb (commit) via b28b07db47b181718643399bd2aedc3e6d1b29c4 (commit) from fef2009bd53ee5089d51ff253d603097a9dfebab (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9b72aec7b3624b6bb8e409e52a29263591856f81 commit 9b72aec7b3624b6bb8e409e52a29263591856f81 Merge: fef2009 203b20d Author: James Johnston johnstonj.pub...@codenest.com AuthorDate: Sat Aug 8 01:27:54 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Sat Aug 8 01:27:54 2015 -0400 Merge topic 'fix-process-error-handling' into next 203b20df cmcmd: Improve error handling when executing a process. b28b07db cmCTestCoverageHandle: Improve error handling. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=203b20df98512094cc74061fd1b76e87bd2d3afb commit 203b20df98512094cc74061fd1b76e87bd2d3afb Author: James Johnston johnstonj.pub...@codenest.com AuthorDate: Sat Aug 8 01:06:27 2015 -0400 Commit: James Johnston johnstonj.pub...@codenest.com CommitDate: Sat Aug 8 01:06:27 2015 -0400 cmcmd: Improve error handling when executing a process. diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx index 71f47f3..7bee0ea 100644 --- a/Source/cmcmd.cxx +++ b/Source/cmcmd.cxx @@ -1468,18 +1468,24 @@ bool cmcmd::RunCommand(const char* comment, std::string output; int retCode =0; // use rc command to create .res file - cmSystemTools::RunSingleCommand(command, - output, output, - retCode, 0, cmSystemTools::OUTPUT_NONE); + bool res = cmSystemTools::RunSingleCommand(command, + output, output, + retCode, 0, + cmSystemTools::OUTPUT_NONE); // always print the output of the command, unless // it is the dumb rc command banner, but if the command // returned an error code then print the output anyway as // the banner may be mixed with some other important information. if(output.find(Resource Compiler Version) == output.npos - || retCode !=0) + || !res || retCode) { std::cout output; } + if (!res) +{ +std::cout comment failed to run. std::endl; +return false; +} // if retCodeOut is requested then always return true // and set the retCodeOut to retCode if(retCodeOut) @@ -1593,7 +1599,10 @@ int cmcmd::VisualStudioLinkIncremental(std::vectorstd::string args, mtCommand.push_back(tempManifest); // now run mt.exe to create the final manifest file int mtRet =0; - cmcmd::RunCommand(MT, mtCommand, verbose, mtRet); + if(!cmcmd::RunCommand(MT, mtCommand, verbose, mtRet)) +{ +return -1; +} // if mt returns 0, then the manifest was not changed and // we do not need to do another link step if(mtRet == 0) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b28b07db47b181718643399bd2aedc3e6d1b29c4 commit b28b07db47b181718643399bd2aedc3e6d1b29c4 Author: James Johnston johnstonj.pub...@codenest.com AuthorDate: Sat Aug 8 00:28:38 2015 -0400 Commit: James Johnston johnstonj.pub...@codenest.com CommitDate: Sat Aug 8 00:28:38 2015 -0400 cmCTestCoverageHandle: Improve error handling. diff --git a/Source/CTest/cmCTestCoverageHandler.cxx b/Source/CTest/cmCTestCoverageHandler.cxx index 6369e17..65599e0 100644 --- a/Source/CTest/cmCTestCoverageHandler.cxx +++ b/Source/CTest/cmCTestCoverageHandler.cxx @@ -1474,7 +1474,12 @@ int cmCTestCoverageHandler::HandleLCovCoverage( std::endl, this-Quiet); std::vectorstd::string files; - this-FindLCovFiles(files); + if (!this-FindLCovFiles(files)) +{ +cmCTestLog(this-CTest, ERROR_MESSAGE, + Error while finding LCov files.\n); +return 0; +} std::vectorstd::string::iterator it; if (files.empty()) @@ -1745,18 +1750,28 @@ void cmCTestCoverageHandler::FindGCovFiles(std::vectorstd::string files) } // -void cmCTestCoverageHandler::FindLCovFiles(std::vectorstd::string files) +bool cmCTestCoverageHandler::FindLCovFiles(std::vectorstd::string files) { cmsys::Glob gl; gl.RecurseOff(); // No need of recurse if -prof_dir${BUILD_DIR} flag is // used while compiling. gl.RecurseThroughSymlinksOff(); std::string prevBinaryDir; - cmSystemTools::ChangeDirectory( -this-CTest
[Cmake-commits] CMake branch, next, updated. v3.3.0-2015-g3f834d0
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, next has been updated via 3f834d0477db40bfb619b19ca66969e04d36a323 (commit) via d035e9687a2d28e2f64ec3a316f8abea57e49d63 (commit) via 38ed5866ed212effe0217f193f728ee54ea7378b (commit) via 772ca69f803a8f294d6e04f9e258becc35179233 (commit) from 925cb2ee6c3614195fc1786a3c909ec3092f3b89 (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3f834d0477db40bfb619b19ca66969e04d36a323 commit 3f834d0477db40bfb619b19ca66969e04d36a323 Merge: 925cb2e d035e96 Author: James Johnston johnstonj.pub...@codenest.com AuthorDate: Thu Aug 6 14:02:05 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Aug 6 14:02:05 2015 -0400 Merge topic 'fix-get-filename-component' into next d035e968 get_filename_component: Fix bug where CACHE was ignored. 38ed5866 get_filename_component: Added initial tests for PROGRAM component. 772ca69f get_filename_component: Tests now check for proper CACHE usage. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d035e9687a2d28e2f64ec3a316f8abea57e49d63 commit d035e9687a2d28e2f64ec3a316f8abea57e49d63 Author: James Johnston johnstonj.pub...@codenest.com AuthorDate: Wed Aug 5 00:33:59 2015 -0400 Commit: James Johnston johnstonj.pub...@codenest.com CommitDate: Thu Aug 6 17:53:34 2015 + get_filename_component: Fix bug where CACHE was ignored. If PROGRAM_ARGS is provided to get_filename_component, fix bug where the command failed to honor the CACHE argument. Added test cases to RunCMake.get_filename_component that fail when the bug is not fixed to prevent regressions. Signed-off-by: James Johnston johnstonj.pub...@codenest.com diff --git a/Source/cmGetFilenameComponentCommand.cxx b/Source/cmGetFilenameComponentCommand.cxx index 67f9f2d..13a9afb 100644 --- a/Source/cmGetFilenameComponentCommand.cxx +++ b/Source/cmGetFilenameComponentCommand.cxx @@ -24,7 +24,7 @@ bool cmGetFilenameComponentCommand // Check and see if the value has been stored in the cache // already, if so use that value - if(args.size() == 4 args[3] == CACHE) + if(args.size() = 4 args[args.size() - 1] == CACHE) { const char* cacheValue = this-Makefile-GetDefinition(args[0]); if(cacheValue !cmSystemTools::IsNOTFOUND(cacheValue)) @@ -111,7 +111,7 @@ bool cmGetFilenameComponentCommand return false; } - if(args.size() == 4 args[3] == CACHE) + if(args.size() = 4 args[args.size() - 1] == CACHE) { if(!programArgs.empty() !storeArgs.empty()) { diff --git a/Tests/RunCMake/get_filename_component/KnownComponents.cmake b/Tests/RunCMake/get_filename_component/KnownComponents.cmake index 1532792..386109f 100644 --- a/Tests/RunCMake/get_filename_component/KnownComponents.cmake +++ b/Tests/RunCMake/get_filename_component/KnownComponents.cmake @@ -62,6 +62,38 @@ check(CACHE 3 ${test_cache} /path/to/other) list(APPEND cache_vars test_cache) +# Test the PROGRAM component type with CACHE specified. + +# 1. Make sure it makes a cache variable in the first place for basic usage: +get_filename_component(test_cache_program_name_1 / arg1 arg2 PROGRAM CACHE) +check(PROGRAM CACHE 1 with no args output ${test_cache_program_name_1} /) +list(APPEND cache_vars test_cache_program_name_1) + +# 2. Set some existing cache variables make sure the function returns them: +set(test_cache_program_name_2 DummyProgramName CACHE FILEPATH ) +get_filename_component(test_cache_program_name_2 / arg1 arg2 PROGRAM CACHE) +check(PROGRAM CACHE 2 with no args output ${test_cache_program_name_2} + DummyProgramName) +list(APPEND cache_vars test_cache_program_name_2) + +# 3. Now test basic usage when PROGRAM_ARGS is used: +get_filename_component(test_cache_program_name_3 / arg1 arg2 PROGRAM + PROGRAM_ARGS test_cache_program_args_3 CACHE) +check(PROGRAM CACHE 3 name ${test_cache_program_name_3} /) +check(PROGRAM CACHE 3 args ${test_cache_program_args_3} arg1 arg2) +list(APPEND cache_vars test_cache_program_name_3) +list(APPEND cache_vars test_cache_program_args_3) + +# 4. Test that existing cache variables are returned when PROGRAM_ARGS is used: +set(test_cache_program_name_4 DummyPgm CACHE FILEPATH ) +set(test_cache_program_args_4 DummyArgs CACHE STRING ) +get_filename_component(test_cache_program_name_4 / arg1 arg2 PROGRAM + PROGRAM_ARGS test_cache_program_args_4 CACHE) +check(PROGRAM CACHE 4 name ${test_cache_program_name_4} DummyPgm) +check(PROGRAM CACHE 4 args ${test_cache_program_args_4} DummyArgs) +list(APPEND cache_vars test_cache_program_name_4) +list(APPEND cache_vars
Re: [CMake] on cmake supporting one arch per project (from CMake IR)
-Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Greg Marr Sent: Wednesday, August 05, 2015 18:42 To: Raymond Wan; Scott Aron Bloom Cc: cmake@cmake.org Subject: Re: [CMake] on cmake supporting one arch per project (from CMake IR) Gilles Khouzam from Microsoft has created an experimental fork, current as of 3.2.1, that adds this support. https://github.com/Microsoft/CMake/tree/feature/MSMultiPlatform Adding experimental MultiPlatform support to CMake for Windows and VS 2012 and above. By setting the CMAKE_VS_EFFECTIVE_PLATFORMS variable, the user is able to specify that multiple platforms should be produced for the same project. The supported platforms are Win32, ARM and x64 (not applicable to Windows Phone) and should be specified as a delimited string Win32;ARM;x64 for example. I read this and also glanced through the patch (look for commit ID 065bdceb0fbe5253b229faa843fce6b1c271f047 in his repo). It feels a little goofy and too VS-centric to me. How should existing end-user code like this be handled? if(MSVC90 AND NOT CMAKE_CL_64) # set 32-bit VC2008 flags set(CMAKE_CXX_FLAGS stuff) # snip elseif(MSVC90 AND CMAKE_CL_64) # set some 64-bit VC2008 flags set(CMAKE_CXX_FLAGS stuff) # snip endif() Well, it seems like you would need platform-specific CXX_FLAGS variables, in addition to the configuration-specific CXX_FLAGS variables already offered. So you'd need a lot new CMake variables for the compiler, linker, etc. Ideally you'd want to figure out how to do this without completely breaking every piece of user code that previously ever touched those variables. While you're at it, you'd want platform-specific variables containing platform-specific paths to each compiler. (e.g. path to 32-bit cl.exe, path to 64-bit cl.exe.) Of course, that opens the door to mixing VC++ and non-VC++ compilers in the same CMake project... Also, the meaning of variables like MSVC90 or even CMAKE_CL_64 change: previously CMAKE_CL_64 meant building for 64-bit whereas maybe now it means you may or may not be building for 64-bit ??? What is CMAKE_CL_64 supposed to do if CMAKE_VS_EFFECTIVE_PLATFORMS is set to Win32;x64? Also, you're still limited to VS generator in his patch, as evidenced by VS in CMAKE_VS_EFFECTIVE_PLATFORMS. I guess that's all fine well as far as Microsoft's concerned. What if I want to build multi-platforms with the Ninja generator? GNU Make generator? Multi-platforms on Linux? Mac? (Personally I dislike the VS generator / MSBuild on Windows for big builds because the parallelization in MSBuild and cl.exe isn't coordinated, leading to significant over/under-subscription problems that can be avoided with any other generator on Windows.) I'm not making this up, if CMake supported multi-platform building, I would be needing/wanting to specify multiple platforms for the project I'm working on right now: (1) VC++ 32-bit, (2) VC++ 64-bit, (3) GCC cross-compiler, (4) C++ Builder. Some targets would be built for multiple platforms; others would be built for only one of those four platforms. I have annoying requirements that multi-platform could help with like: the cross-compiler requires a custom build step/tool that is built using Visual Studio. Very flexible multi-platform can/should be easy for the makefile generators to handle. And the VS generator can handle #1 and #2 fine enough but what if I want it to generate a CMake project containing the GCC/BCC32 targets, for example? How the heck does that work? And what if I want multiple VC++ versions in my platform list - say, VC2008 and VS2013? (After all, I could point to differing versions of cl.exe with my platform-specific COMPILER variables). Again that's something that multi-platform makefile generators can/should handle easily but what if the VS generator is asked to generate for VC2008 and VC2013 platforms? Right now the VS generators have it easy - they only have one cl.exe version to contend with (and it's guaranteed to be a cl.exe to begin with). I guess you could have the Ninja/makefile generators happily generate true multi-platform stuff while have the VS generator just croak, but then what if I want to use the VS IDE for my VC++ targets? It would be awesome if CMake could support multi-platform - it could really simplify things for me (as now I am working on a superbuild that iterates through all the above platforms) - but I'd rather see it in a form that is baked into the core of CMake, rather than something VS-specific hacked onto the VS generator that I feel won't interact well with anything non-VS. Best regards, James Johnston -- 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
Re: [CMake] Managed C++ / C# Projects: Location of assembly DLL
-Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert Dailey Sent: Wednesday, August 05, 2015 19:02 To: CMake Subject: [CMake] Managed C++ / C# Projects: Location of assembly DLL I am including external MS projects via CMake for my C# projects. The Managed C++ projects I generate via CMake directly. However, sharing assembly references between the two is difficult. Sometimes I need my imported C# projects to know where to find the managed C++ DLL assembly it built. This is in the CMake binary directory, which might be different on each machine, so I can't exactly setup a relative path to this file in the C# project references section. Likewise with dependencies on C# output from Managed C++. It's a little easier to tell CMake where to find the output DLL file for a C# project (since the output location is relative inside the source dir). How do you guys recommend solving these dependency issues? Is there a way I can add an assembly reference to a Managed C++ project via path through CMake? I also need to use C#. Until CMake has first-class C# support, I hacked together a primitive csproj file generator in about a day and a half (excluding the wrong approach I initially took). I also had problems with how do you deal with references and how do you get the C# project to do an out-of-source build? (I don't want the C# projects touching my source tree, it's not the CMake way.) So initially I investigated calling csc.exe directly as a custom build step but that approach will have two problems: * No IntelliSense support for C# in the IDE because a C++ project is emitted. * More importantly, system references are difficult to resolve. To see what I mean, built a Hello World C# app in Visual Studio and look at the MSBuild invocation to csc.exe. Note they don't specify /reference:System.Core.dll on the command line. Instead we end up with a full path to something like /reference:C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll - which is a different path from what is used at runtime (GAC path C:\WINDOWS\assembly\GAC...). If you Google there are good reasons to link with the reference assembly and not the one installed on your system. Well it turns out that MSBuild has a complicated set of rules for resolving references, they are not well documented, and they are found in your Microsoft.Common.targets file (search for AssemblySearchPaths to see the list of 9 locations it checks). These rules are different and lengthier than the ones used by csc.exe if an absolute path is not provided. So here's my suggestion: 1. Generate a csproj file on-the-fly from a template and put it into your binary dir, given a list of source files, target name, references, etc. That solves the out-of-source build problem. Make a reusable CMake function(s) for adding C# targets which handles the steps here. 2. Use either include_external_msproject if using a VS generator, or create a custom command/target to directly invoke MSBuild if using a non-VS generator. 3. For references, if you will be using include_external_msproject (as opposed to custom target), and the reference is not an imported target, you will want to generate a project reference. Else, generate a regular reference directly to the file for the configuration. 4. You can use file(GENERATE) to make configuration-specific files that list the references for each configuration. These can then be Import'ed into the main csproj file. This lets you use generator expressions if you need to when determining the path for your reference. 5. If generating a project reference to a C++ project, you can use $TARGET_FILE_DIR:ref/../ref.vc(x)proj to get to the project file. If the project reference is to another C# project you can use the undocumented EXTERNAL_MSPROJECT target property. If it's a non-project reference then you have to provide a HintPath which can be done with $TARGET_FILE for C++ references and a custom property you'll have to maintain for C# project references. 6. Don't forget to call CMake add_dependencies() as well. Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] ninja under windows
-Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Gonzalo Garramuño Sent: Monday, August 03, 2015 17:23 To: cmake@cmake.org Subject: [CMake] ninja under windows I compiled Ninja on cygwin from git. That now works fine it seems. I am trying to compile for msvc. However, when cmake runs, I get: I wouldn't even go there... I would recommend: * Do not build anything requiring native Windows build tools from Cygwin - for example, don't call Visual C++ compiler from Cygwin. * Consider not build anything requiring native Windows build tools from MSYS/MSYS2, like Visual C++ compiler, since MSYS/MSYS2 is a fork of Cygwin. (Unless MSYS/MSYS2 maintainers patch Cygwin to resolve the problems, which you'd better research before going there.) It sounds drastic but I can tell you from experience that eventually you'll run into problems and you may be on your own. The big reason I have run into is that Cygwin's handling of stdin/out/err pipes differs from how most Windows programs (i.e. programs based on Visual C++ runtime, or based on .NET Framework) handle the pipes. They do this for POSIX compatibility reasons, I'd guess. And the Cygwin maintainers in the past have shown limited interest in being compatible with non-Cygwin programs. The end result is you end up with things like a basic/simple .NET Framework 4.0 program not working right if called from Cygwin, for example. If you want to forge ahead, I can offer two suggestions that seem to mitigate the problems - today anyway: * Set CYGWIN environment variable to contain pipe_byte. This is very important but I forget the specifics why, other than non-Cygwin programs break if this isn't set. (Search the Cygwin mailing lists for my posts on the issue). * Make a custom build of Cygwin and then set CYGWIN environment variable to contain pipe_nooverlap (a flag I added). This is also very important because if you don't, .NET Framework 4.0 apps and potentially other programs called from Cygwin will break. I submitted a patch to Cygwin maintainers but they rejected it, so you'll have to build Cygwin yourself (and rebuild it every time the maintainers release new Cygwin version). The link to the patch is here: https://cygwin.com/ml/cygwin-patches/2013-q4/msg00020/pipepatch Setting these flags maybe breaks some POSIX compatibility but in practice, I have had zero problems with common Cygwin programs (bash, coreutils). Since proper interaction with non-Cygwin programs now requires you to make a custom build of Cygwin - a big hassle - I suggest don't even go there, and keep Cygwin (and its MSYS/MSYS2) derivatives out of your build system if you require calling native Windows apps (e.g. Visual C++). There are other unrelated considerations if you want a 100% solid build environment, like you should research the (non-)reliability of forking under Cygwin/MSYS/MSYS2. I have to commend the Cygwin developers for making it work in the first place, since Windows provides no forking API. But in the end, to get POSIX working on the Win32 API, I think they are relying on a lot of undocumented Win32 stuff that works in practice but subject to breakage when new versions of Windows come out, etc. Is compiling under the microsoft compiler not an option for ninja files ( I can compile with NMake Makefiles just fine in the same project ). It is and we do it, here is how: 1. Don't build Ninja under Cygwin. IIRC the procedure would be (a) install Python for Windows, (b) go to a Visual C++ command prompt to set up VC++ environment, (c) call Ninja bootstrapper script. 2. Run CMake from a Visual C++ command prompt when you want to use the Ninja generator because Ninja generator will just look for whatever cl.exe is in the PATH. At no point does Cygwin enter into the equation. Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[cmake-developers] Silencing warning about environment when using NMake / JOM
Hi, While using the NMake and JOM generators in CMake, I have come across this warning: To use the [NMake | JOM] generator, cmake must be run from a shell that can use the compiler cl from the command line. This environment does not contain INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to work. OK, so this is kind of a minor complaint, but this is an annoying warning if you aren't actually wanting Visual C++ in your environment. What if I was wanting to use those generators without setting up a Visual C++ environment with vcvarsall.bat? Example use cases where this warning is annoying: * Using it to invoke a superbuild where: (1) the superbuild itself does not use any languages (project command says NONE for languages), (2) the superbuild sets up the VCVars environment uniquely for each ExternalProject_Add. For example, I might have ExternalProject_Add to build both 32-bit and 64-bit versions of an ExternalProject. And so I'd have ExternalProject invoke VCVarsAll.bat uniquely for each environment. In this situation, running VCVars to silence the warning before invoking superbuild is NOT good, because now I have two nested VCVars environments: (1) if the VCVars invoked by the superbuild fails, it will be masked by the first call to VCVars, meaning you could end up building for the wrong environment - without error (VCVars doesn't return proper error codes), (2) and now you have a PATH/LIB/INCLUDE that has combined paths for both 32-bit and 64-bit building. * Using the NMake/JOM generators with non-Visual C++ compilers (which DOES seem to work without issue otherwise). In that case, of course I'm not going to run VCVarsAll as a preliminary step... I examined the CMake source code and found out that if either the INCLUDE or LIB environment variables are missing, then the warning is emitted. So I've worked around it for now by setting both variables to a semicolon ; in my environment. But this hack doesn't pass the smell test for me, starting with the fact that it involves messing with my environment in a weird way and ending with relying on an undocumented detail of CMake. Can these warnings be either eliminated entirely or suppressed via a more documented method? I could probably provide a patch but I'm not sure which direction to take with it. Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] nmake/jom: Only warn about bad VS environment if compiler not found
Hi, Attached is a patch that changes the warning of nmake/jom generators when VCVarsAll.bat hasn't been run: nmake and jom generators no longer warn about missing INCLUDE/LIB environment variables unless the C/CXX compiler cannot be found. This is useful if the user does not want to use these generators with the Visual C++ compiler, or they do not want to enable any language. Sample output; this was run from a clean cmd.exe - i.e. without having run VCVarsAll.bat: C:\Users\JamesJ\AppData\Local\Temp\cmake-warn-build..\cmake-build\bin\cmake -GNMake Makefiles JOM ../cmake-warn -- The C compiler identification is unknown -- The CXX compiler identification is unknown CMake Error at CMakeLists.txt:3 (project): The CMAKE_C_COMPILER: cl is not a full path and was not found in the PATH. To use the JOM generator with Visual C++, cmake must be run from a shell that can use the compiler cl from the command line. This environment is unable to invoke the cl compiler. To fix this problem, run cmake from the Visual Studio Command Prompt (vcvarsall.bat). Tell CMake where to find the compiler by setting either the environment variable CC or the CMake cache entry CMAKE_C_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. CMake Error at CMakeLists.txt:3 (project): The CMAKE_CXX_COMPILER: cl is not a full path and was not found in the PATH. To use the JOM generator with Visual C++, cmake must be run from a shell that can use the compiler cl from the command line. This environment is unable to invoke the cl compiler. To fix this problem, run cmake from the Visual Studio Command Prompt (vcvarsall.bat). Tell CMake where to find the compiler by setting either the environment variable CXX or the CMake cache entry CMAKE_CXX_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. -- Configuring incomplete, errors occurred! See also C:/Users/JamesJ/AppData/Local/Temp/cmake-warn-build/CMakeFiles/CMakeOutput. log. See also C:/Users/JamesJ/AppData/Local/Temp/cmake-warn-build/CMakeFiles/CMakeError.l og. Best regards, James Johnston 0001-nmake-jom-Only-warn-about-bad-VS-environment-if-comp.patch Description: Binary data -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] Fix bug where CACHE ignored by get_filename_component
Hi, Multiple patches attached that improve testing of the get_filename_component command and also fix a bug where get_filename_component ignores CACHE when PROGRAM_ARGS is also provided. Best regards, James Johnston 0001-get_filename_component-Tests-now-check-for-proper-CA.patch Description: Binary data 0002-get_filename_component-Added-initial-tests-for-PROGR.patch Description: Binary data 0003-get_filename_component-Fix-bug-where-CACHE-was-ignor.patch Description: Binary data -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] string: State return value if string(FIND) doesn't find a match
Very minor documentation update clarifying what happens if string(FIND) doesn't find a match. I had to make a CMake test script and/or check CMake source code to find the answer. Best regards, James Johnston 0001-string-State-return-value-if-string-FIND-doesn-t-fin.patch Description: Binary data -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] malware?
-Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On 24/07/15 07:04, David Powell wrote: hi I downloaded cmake an hour ago from cmake.org http://cmake.org/ and found myself with an unwanted piece of software called advanced mac cleaner, an app that was hard to get rid of. I'm not certain it came from your site but it happened at the same time and I can't think of any other explanation.. The download file from cmake.org http://cmake.org/ (supposedly the latest stable dmg for mac) was much bigger (30MB) than the cmake file I subsequently downloaded from github. I don't know about that, but I just noticed that cmake.org allows HTTP (non-HTTPS) downloads. HTTP has no form of cryptographic authentication or verification, and it's incredibly easy for a MitM to attach malware to your downloads. IMO, the HTTP downloads should be removed ASAP. Two other ideas that don't require HTTPS hosting of large binary files: * On Windows, cryptographically sign the setup program using Authenticode. When the UAC prompts for elevation, Windows will show it signed by Kitware instead of a yellow warning Unknown. Probably the other operating systems have a first-class way of doing something like this as well. Downside: certificates cost some modest amount of money to renew every year. * Post SHA-1 hashes of the EXEs/DMGs/tarballs on the CMake web site, and post them over HTTPS. But downside here is that many users won't bother to check this (e.g. Windows has no well-known in-built utility for calculating a file hash). I agree the current situation of unsigned files available over HTTP only is not really ideal. Perhaps this would be a good opportunity for looking at enhancements to CMake itself in the area of code signing (e.g. code signing of individual target EXEs/DLLs, and code signing of the final setup EXE package by CPack) that hides the various operating-system-specific ways of doing this? Then, CMake itself can be modified to be built with these new features, if available. A quick Google search of cmake.org for code signing didn't yield much in the way of previous discussion or existing features... Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [MODERN] CMake 3.3 vs Qt 5.5 vs MSVC2015
-Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Nils Gladitz On 07/23/2015 03:47 PM, Konstantin Podsvirov wrote: http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-univ ersal-crt.aspx CMake uses the module InstallRequiredSystemLibraries to install dependencies. Who is in charge here on this module? Should this module to install Universal CRT (api-ms-win-crt-runtime-xxx.dll library) for MSVC14 ? 6. App-local deployment of the Universal CRT is not supported. I think that means installation should not be handled by InstallRequiredSystemLibraries. You should probably just require users to run Windows Update. That sounds horrible - asking a user to manually run Windows Update. But Windows Update packages don't have to be installed ONLY by way of visiting Windows Update manually. I have yet to mess with this stuff myself (but will be soon). But in the meantime, FTA: Currently these MSU packages are installed as part of the VCRedist installation. In a future build of Visual Studio 2015, these MSU packages will also be distributed separately as part of the Universal CRT SDK and made available for download on support.microsoft.com. So you get this just by running VCRedist - or, if you don't use VCRedist, you can get this by running the MSU packages directly (once said SDK becomes available - if it isn't already available - the blog is 4 months old). Both can be accomplished as part of a setup program. Unfortunately, I suspect the MSU packages can't be invoked from / nested inside a Windows Installer MSI like how the VC++ merge modules were done (and how we currently do); I plan to hack apart VCRedist to try to see what they are doing... Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [MODERN] CMake 3.3 vs Qt 5.5 vs MSVC2015
-Original Message- From: Nils Gladitz [mailto:nilsglad...@gmail.com] On 23.07.2015 17:24, James Johnston wrote: That sounds horrible - asking a user to manually run Windows Update. But Windows Update packages don't have to be installed ONLY by way of visiting Windows Update manually. But this will only be an issue for users which don't run windows = 10 or which don't run regular updates (I'd have assumed this comes in through automated updates as well unless disabled?). Depends on if it is an important update or an optional update... Or it may not show at all. E.g. the legacy WinHelp MSU package is not pushed via Windows Update at all, but if you want WinHelp, it's installed via a manually-downloaded MSU package that you have to get from Microsoft.com downloads. I'm curious to find out which method they choose... I rather think it is nice that this is considered an operating system component rather than a visual studio version specific runtime component (e.g. reduced application installer sizes and centralized updates) but this might work best if you also treat it as such (unless you specifically have to target e.g. outdated/unnetworked machines). To me, this is the worst of both worlds. Not only do we STILL have to distribute the version-specific components (which are not part of the universal CRT) as we always have since VS2005, we now have this MSU package IN ADDITION that has to be installed for every configuration except static runtime linking. You still have the burden of redistributing the rest of the unstable VS2015-specific runtime. So it's not like you can wait 10 years for adoption and stop worrying about any VS2015 redistributing runtime files at all. Bonus points if they find a way in Visual Studio 2020 to modify the universal CRT and somehow cause breaking changes with VS2015, even though they promised not to... This was supposedly why the VS2005 CRT newer are side-by-side installed into winsxs - to fix DLL hell from the 1990s... James -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] ExternalProject: Added new USES_TERMINAL options
Hi, I worked on a patch to allow you to pass USES_TERMINAL through ExternalProject to the underlying add_custom_command(). Here is the commit message: ExternalProject: Added new USES_TERMINAL options Added new USES_TERMINAL option to the ExternalProject_Add_Step function. This option passes USES_TERMINAL to the underlying add_custom_command call so that the Ninja console pool is used. Also, corresponding new USES_TERMINAL_step options were added to the ExternalProject_Add function. Justification: if using Ninja with a CMake superbuild, it's often desirable to limit the superbuild to ONE sub-Ninja process at a time to avoid oversubscribing the CPU. Using the console pool also makes it easy to monitor the progress of the sub-Ninja process. Independent USES_TERMINAL_step arguments are passed to ExternalProject_Add instead of one USES_TERMINAL argument that controls everything. Users may wish to run some steps in parallel but not others (e.g. parallelize configure but not build). Best regards, James Johnston 0001-ExternalProject-Added-new-USES_TERMINAL-options.patch Description: Binary data -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] C# support?
-Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Brad King Sent: Tuesday, June 30, 2015 13:49 To: cmake-developers@cmake.org Subject: Re: [cmake-developers] C# support? On 06/30/2015 03:21 AM, Stuermer, Michael SP/HZA-ZSEP wrote: it would be great if some people could step forward once everything is running from my side to help get makefile and linux support (and test other Visual Studio versions). Once you have it working in VS 2013 the other VS = 2010 versions should be easy. I'm not sure about other generators yet. If you have good coverage in the test suite updates then that will make the task of adding support to other generators easier. What about Visual Studio 2005 / 2008? In those scenarios: * The Visual C++ projects are NOT MSBuild projects (as the CMake devs I'm sure well know) * The Visual C# project *is* an MSBuild project. My guess is if targeting VS2005/2008, you'd need to somehow use code as follows: * The Visual C++ 2005/2008 projects generated as normal using VisualStudio8/9TargetGenerator classes. * The Visual C# 2005/2008 projects are MSBuild so you'd have to use the new code in VisualStudio10TargetGenerator when your CMake generator was set to Visual Studio 8/9? It sounds goofy... * And all the above projects put into one final VS2005/2008 solution file. Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] C# support?
-Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of David Cole via cmake-developers Sent: Monday, June 29, 2015 17:31 To: Brad King Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] C# support? The C# compiler, csc.exe, takes all its arguments at once in one call to build a library or executable. Listing all the sources, and its references (other libraries it depends on) all at once. You can do it as command line arguments, or as contents of a response file, or a combination or arguments plus response file. Conceptually, it's just like Java. Exactly right; it's like a combined compiler+linker. It's also worth noting that the C# and VB .NET languages doesn't have the concept of #include preprocessor directives. Header files are a non-issue. (Once you got that working, I'd imagine Java language support would be easy, too...) They do have separate project files for it with VS, though. The generators will need code to generate *.csproj files, rather than custom commands in a vcxproj file, to make it seem like it's really well-integrated with VS. Not sure if *.csproj files have evolved much over the last few releases of VS -- I'd expect the major challenge with this to be making sure CMake generates proper *.csproj files for however many versions of VS it would take to make it acceptable. Csproj files are MSBuild compatible, like how Visual C++ 2010 vcxproj files are. While Visual C++ went to MSBuild recently (VS2010), Visual C# has been MSBuild compatible since MSBuild's inception - Visual Studio 2005 if I remember right. Visual Studio 2002/2003 might be different since they pre-date MSBuild but since the VC++ 2002 generator was recently deprecated I'd argue these versions can be ignored. (if someone uses that version still, they could at least use csc.exe directly via a Makefile generator) So, since VS2005, I think you'd find small changes (new flags introduced, etc.) but no major file format overhaul like from VC++ 2008 to VC++ 2010. I'd also like to take this opportunity to point out that whoever does this might want to consider supporting VB .NET also. Everything in this discussion is EXACTLY the same, except that the compiler name is different, and project/source code file extensions are different. It would be relatively trivial to support VB .NET once you have C# working, if you wrote the generator right. (vbc.exe instead of csc.exe, vbproj instead of csproj, .vb file instead of .cs file. Compiler switches are probably almost identical... It's also MSBuild-based and also does a combined compile+link.) Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] C# support?
-Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Stuermer, Michael SP/HZA-ZSEP Sent: Friday, June 26, 2015 14:47 To: cmake-develop...@cmake.org; cmake@cmake.org Subject: [CMake] C# support? Hi and sorry for cross-posting this on both lists, I checked the mailing list history about the C#/.NET support topic and realized that the interest in C# support seems to have declined a bit. I am right now in the need of good C# support and adding external project files is not that much of an option to me. So I started hacking away everything that is needed for .csproj generation and support of mixed managed/unmanaged targets. Not yet done, but there is a light at the end of the tunnel. Now the question: is there any real interest at all in this feature? Does it have a realistic chance to be accepted for upstream or will I have to maintain my own fork of CMake? Well, I have only just recently started using CMake. So I am not speaking from a great deal of experience. But I am currently converting over a bunch of stuff into a set of CMake projects. (must be multiple CMake projects built by a superbuild via ExternalProject because we use three different C/C++ compilers and target three different CPU architectures.) Part of that stuff involves a mixture of Visual Studio projects involving (1) 100% unmanaged C++ code: this is the easy stuff to move to CMake, (2) C++/CLI mixed mode projects, (3) C# projects that consume the mixed mode C++/CLI projects. I have yet to start working on that part of the CMake migration, but I'm not looking forward to figuring out how to make the C# projects consume the build output from the C++/CLI projects and still have the Visual C# projects be easy to add/remove files from. All these particular projects are targeting Visual Studio 2008 32-bit, so it *ought* be possible to use them all from one single CMake build tree one single Visual Studio solution... I have seen include_external_msproject CMake command: http://www.cmake.org/cmake/help/v3.3/command/include_external_msproject.html But it's not clear to me how I'd make the C# project depend on other CMake targets (i.e. the mixed mode C++ projects). The best I've thought of would be to use configure_file to modify the project to substitute the compiled C++ DLLs in the references section of the project. But then it will be a pain to modify the original C# projects in SOURCE_DIR. And also, the C# project normally has relative paths, so if it gets configure_file'd into BINARY_DIR all the source code paths will break. I guess all the above is to say, I'm interested in that feature. But I may be too much of a newbie at CMake to say whether that is a good CMake way of doing things. I still need to experiment with the above command, and read up on old mailing list messages on the subject. But it seems to me the logical way for supporting C# would be: (1) it becomes a first-class language that can be mentioned in the project() command, (2) therefore, all the generators can use it, so you aren't restricted to Visual Studio generator (I like the Ninja generator because it's faster than Visual Studio), (3) Visual Studio generator would emit a solution containing generated VC++/VC# projects. Anything else feels like a bit of a hack to me. But #1 thru #3 sounds like a lot of work though... Also, C# doesn't compile to object files - does CMake currently support the concept of a language that doesn't require separate compiling/linking steps? Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [cmake-developers] [CMake] C# support?
-Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Stuermer, Michael SP/HZA-ZSEP Sent: Friday, June 26, 2015 14:47 To: cmake-developers@cmake.org; cm...@cmake.org Subject: [CMake] C# support? Hi and sorry for cross-posting this on both lists, I checked the mailing list history about the C#/.NET support topic and realized that the interest in C# support seems to have declined a bit. I am right now in the need of good C# support and adding external project files is not that much of an option to me. So I started hacking away everything that is needed for .csproj generation and support of mixed managed/unmanaged targets. Not yet done, but there is a light at the end of the tunnel. Now the question: is there any real interest at all in this feature? Does it have a realistic chance to be accepted for upstream or will I have to maintain my own fork of CMake? Well, I have only just recently started using CMake. So I am not speaking from a great deal of experience. But I am currently converting over a bunch of stuff into a set of CMake projects. (must be multiple CMake projects built by a superbuild via ExternalProject because we use three different C/C++ compilers and target three different CPU architectures.) Part of that stuff involves a mixture of Visual Studio projects involving (1) 100% unmanaged C++ code: this is the easy stuff to move to CMake, (2) C++/CLI mixed mode projects, (3) C# projects that consume the mixed mode C++/CLI projects. I have yet to start working on that part of the CMake migration, but I'm not looking forward to figuring out how to make the C# projects consume the build output from the C++/CLI projects and still have the Visual C# projects be easy to add/remove files from. All these particular projects are targeting Visual Studio 2008 32-bit, so it *ought* be possible to use them all from one single CMake build tree one single Visual Studio solution... I have seen include_external_msproject CMake command: http://www.cmake.org/cmake/help/v3.3/command/include_external_msproject.html But it's not clear to me how I'd make the C# project depend on other CMake targets (i.e. the mixed mode C++ projects). The best I've thought of would be to use configure_file to modify the project to substitute the compiled C++ DLLs in the references section of the project. But then it will be a pain to modify the original C# projects in SOURCE_DIR. And also, the C# project normally has relative paths, so if it gets configure_file'd into BINARY_DIR all the source code paths will break. I guess all the above is to say, I'm interested in that feature. But I may be too much of a newbie at CMake to say whether that is a good CMake way of doing things. I still need to experiment with the above command, and read up on old mailing list messages on the subject. But it seems to me the logical way for supporting C# would be: (1) it becomes a first-class language that can be mentioned in the project() command, (2) therefore, all the generators can use it, so you aren't restricted to Visual Studio generator (I like the Ninja generator because it's faster than Visual Studio), (3) Visual Studio generator would emit a solution containing generated VC++/VC# projects. Anything else feels like a bit of a hack to me. But #1 thru #3 sounds like a lot of work though... Also, C# doesn't compile to object files - does CMake currently support the concept of a language that doesn't require separate compiling/linking steps? Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Fixed Borland linker issue when used with Ninja generator
See updated attached patch. I've retested it to ensure the VTK 5.4.2 build I've been working with still builds correctly - and it still does. Thank you for considering it. -James -Original Message- From: Brad King [mailto:brad.k...@kitware.com] +set(CMAKE_JOB_POOL_LINK BCC32LinkPool) Hmm. What if the user sets this too? Perhaps we should allow users/projects to take control of this setting by making the whole block conditional: if(NOT DEFINED CMAKE_JOB_POOL_LINK) Fair enough. Change made. I can't think of a real-world reason why someone would want to do this (given the buggy behavior that will result), but I suppose it's better not to step in the way. (The only thing I could think of would be if you wanted both compiler and linker to use the SAME job pool, which would then have to be restricted to 1. At that point, there's no reason to using Ninja in the first place...) +get_property(_EMB_TMP_POOLS GLOBAL PROPERTY JOB_POOLS) list(APPEND +_EMB_TMP_POOLS BCC32LinkPool=1) set_property(GLOBAL PROPERTY +JOB_POOLS ${_EMB_TMP_POOLS}) This can be just set_property(GLOBAL APPEND PROPERTY JOB_POOLS BCC32LinkPool=1) Oops, I overlooked that! Much cleaner now, thanks :) 0001-Work-around-Borland-linker-issue-when-used-with-Ninj.patch Description: Binary data -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] Fixed Borland linker issue when used with Ninja generator
Hi, The attached patch is in regards to issue #15620 in mantis bug tracker (Ninja generator triggers race condition in Borland bcc32 linker causing intermittent build failure). Thanks to Brad King's suggestion, I think using job pools is a lot easier than trying my proposed workaround (which I realized would probably involve more disruptive code changes). (I'm new to both CMake/Ninja, so wasn't aware of this option). I've tested with building VTK 5.4.2. Before the patch, 5 out of 5 builds failed (sooner or later, in a big project like VTK, the race condition would trash the build). After the patch, 5 out of 5 builds work without error. Because of this issue with the linker itself, I can't think of any reason why anybody would want to change the default settings I put in Modules/Platform/Windows-Embarcadero.cmake with this patch. You simply *must* restrict the linker to one instance, without exception, or you'll have problems due to the bcc32 linker design flaws I've outlined in the bug tracker and patch comments. I was only able to think of three solutions to this problem: 1. Modify each upstream CMake project (e.g. VTK) itself to set the Ninja job pool in the Borland case (not a good option). 2. Provide a toolchain file that sets up the job pool. Awkward, since you have to do this EVERY TIME you use the Ninja generator /w bcc32 or it WILL NOT WORK. 3. Patch Windows-Embarcadero.cmake, as I propose here. (Since JOB_POOLS is a global property and not a variable, I couldn't find a way to simply pass this as a parameter to cmake.exe - not that that would be an ideal solution anyway.) Best regards, James Johnston 0001-Work-around-Borland-linker-issue-when-used-with-Ninj.patch Description: Binary data -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[CMake] Ninja race condition compiling VTK with Borland bcc32 compiler
..\..\bin\vtkzlib.dll -tWM -lS:1048576 -lSc:4098 -lH:1048576 -lHc:8192 -v import32.lib $(vtkzlib_OBJECTS) $(vtkzlib_EXTERNAL_OBJECTS) implib -c -w ..\..\bin\vtkzlib.lib ..\..\bin\vtkzlib.dll cd C:\Users\JamesJ\Documents\Repositories\SuperRepo\VTK-JOM = For what it's worth, at this time, I think this issue is limited to the linker and not to the single-unit compilation of a CPP file to OBJ file. I ran Process Monitor for a few seconds while VTK was compiling, and it seems that the only file writes to the build tree were either legitimate writes to named intermediate/output files, or else to these problematic files from the linker. Best regards, James Johnston -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake