From popizdeh at gmail.com Sun Oct 1 20:29:00 2017 From: popizdeh at gmail.com (Nikola Smiljanic) Date: Mon, 2 Oct 2017 11:29:00 +1100 Subject: [cmake-developers] Why does CMAKE_CXX_STANDARD set 'gnu' flags? Message-ID: Hello everyone, I'd like to know why CMake uses 'gnu' flags when setting C++ standard. I find this very surprising as 'gnu' mode enables non standard extensions? Thanks Nikola -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Oct 2 06:58:31 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 2 Oct 2017 06:58:31 -0400 Subject: [cmake-developers] CMP0071 In-Reply-To: <767335078.106094165.1506444910404.JavaMail.zimbra@elemtech.com> References: <2105906395.105674998.1506432728339.JavaMail.zimbra@elemtech.com> <1917044.Hax7LbVASi@blauwal> <108404554.105873617.1506439536331.JavaMail.zimbra@elemtech.com> <2204503.iKcNg7Mky5@blauwal> <767335078.106094165.1506444910404.JavaMail.zimbra@elemtech.com> Message-ID: On 09/26/2017 12:55 PM, clinton at elemtech.com wrote: > https://bugreports.qt.io/browse/QTBUG-63442 Please take a look at the proposed fix: https://codereview.qt-project.org/#/c/207327/ Thanks, -Brad From brad.king at kitware.com Mon Oct 2 07:01:15 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 2 Oct 2017 07:01:15 -0400 Subject: [cmake-developers] Why does CMAKE_CXX_STANDARD set 'gnu' flags? In-Reply-To: References: Message-ID: On 10/01/2017 08:29 PM, Nikola Smiljanic wrote: > I'd like to know why CMake uses 'gnu' flags when setting C++ standard. > I find this very surprising as 'gnu' mode enables non standard extensions? Setting the standard level should not affect the extensions, and the compiler's default mode includes extensions. There is a separate property for extensions: https://cmake.org/cmake/help/v3.9/prop_tgt/CXX_EXTENSIONS.html It is ON by default since most compilers have extensions on by default. -Brad From popizdeh at gmail.com Mon Oct 2 07:24:20 2017 From: popizdeh at gmail.com (Nikola Smiljanic) Date: Mon, 2 Oct 2017 22:24:20 +1100 Subject: [cmake-developers] Why does CMAKE_CXX_STANDARD set 'gnu' flags? In-Reply-To: References: Message-ID: Thanks Brad, so setting CXX_EXTENSIONS to off will switch me to 'standard' compliant mode? On Mon, Oct 2, 2017 at 10:01 PM, Brad King wrote: > On 10/01/2017 08:29 PM, Nikola Smiljanic wrote: > > I'd like to know why CMake uses 'gnu' flags when setting C++ standard. > > I find this very surprising as 'gnu' mode enables non standard > extensions? > > Setting the standard level should not affect the extensions, and the > compiler's > default mode includes extensions. There is a separate property for > extensions: > > https://cmake.org/cmake/help/v3.9/prop_tgt/CXX_EXTENSIONS.html > > It is ON by default since most compilers have extensions on by default. > > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Oct 2 07:32:05 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 2 Oct 2017 07:32:05 -0400 Subject: [cmake-developers] Why does CMAKE_CXX_STANDARD set 'gnu' flags? In-Reply-To: References: Message-ID: On 10/02/2017 07:24 AM, Nikola Smiljanic wrote: > Thanks Brad, so setting CXX_EXTENSIONS to off will switch me to > 'standard' compliant mode? Yes. It can be done for all targets on creation by using the CMAKE_CXX_EXTENSIONS variable: https://cmake.org/cmake/help/v3.9/variable/CMAKE_CXX_EXTENSIONS.html -Brad From gjasny at googlemail.com Mon Oct 2 09:05:41 2017 From: gjasny at googlemail.com (Gregor Jasny) Date: Mon, 2 Oct 2017 15:05:41 +0200 Subject: [cmake-developers] Extending XCode scheme generation support In-Reply-To: References: Message-ID: <07a32ef4-f830-23de-6e2f-d203cfb541ee@googlemail.com> Hello Steven, On 9/22/17 3:36 AM, Steven Velez wrote: > # Property-Centric > In this proposal, the generation of the scheme files is customized primarily by > a user setting additional, specialized properties on a given target, which then > affect the generation of the scheme files associated with that target. thank you for working an the scheme proposal. I also believe that the property-centric approach is better suited and easier to implement than the file-centrix one. Next steps would be to sequence the necessary changes and define test cases. I could imagine that adding generator-expression support would be much harder to implement that other things. Things that also should be considered are: * differences between macOS and iOS when generating a scheme * what should happen if two targets specify the same schema name Thanks, Gregor From raffi.enficiaud at mines-paris.org Mon Oct 2 09:10:23 2017 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Mon, 2 Oct 2017 15:10:23 +0200 Subject: [cmake-developers] Tools for handling cross project dependencies In-Reply-To: References: Message-ID: Le 27.09.17 ? 19:10, Egor Pugin a ?crit : >> The idea is to include several "packages" (one package ~ one project in Boost) and make those available to the build, exactly as for a regular CMakeLists.txt that adds several directories or subprojects through a sequence of calls to "add_directories". >> However, the difference here is that "packages" have inter-dependencies, and the order of the "add_directories" should honor those dependencies. > > I solved the issue of including several dirs (via 'add_directories') > using guards 'if (TARGET name); return(); endif()' in my pkg manager. > See boost libraries there: https://cppan.org/search?q=boost > Each library can be included to project separately with autoincluding > required deps for it. Hi, Thank you for your answer. What you did with CPAN is wonderful, but I think this much more than what my humble scripts are trying to address. Also the guard mechanism does not really address the issue of ordering the add_directories in some topological order. In particular, you guard because you do not want to declare several times the same target, but it does not tell when to include any other dependencies your target may have. In summary (correct me if I am wrong) what this does is (in some pseudo code): --------- if(target1, target2 ... already defined) return declare target1, target2 ... target_dependencies target1, target1.1, target1.2 ... target_dependencies target2, target2.1, target2.2 ... --------- but it does not tell when to declare target1.1, target1.2 ... and this knowledge should be encoded somewhere else in your scripts. Best, Raffi From brad.king at kitware.com Mon Oct 2 11:48:21 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 2 Oct 2017 11:48:21 -0400 Subject: [cmake-developers] CMake 3.10 feature freeze on 2017-10-02 In-Reply-To: References: Message-ID: On 09/12/2017 11:53 AM, Brad King wrote: > The feature freeze in 'master' for CMake 3.10 will be on Oct 2, 2017. > I may announce a freeze in 'stage' sometime in the preceding week so > that we can get any remaining dashboard trouble cleaned up. In order to get 'master' ready to branch for 3.10, 'stage' is now frozen to new features. After 3.10 is branched I'll announce when post-3.10 development is open. Meanwhile the following types of changes are still welcome: * Documentation updates * Regression fixes * Dashboard fixes * Fixes for bugs in features new to 3.10 or 3.9 * A few specific changes that I will handle staging. Thanks, -Brad From egor.pugin at gmail.com Mon Oct 2 12:06:02 2017 From: egor.pugin at gmail.com (Egor Pugin) Date: Mon, 2 Oct 2017 19:06:02 +0300 Subject: [cmake-developers] Tools for handling cross project dependencies In-Reply-To: References: Message-ID: Sorry, maybe I did not understand you correctly, but why do you need some order of 'add_subdirectory'? Cppan knows from config (yaml) files what deps must be included and just adds them one by one. If they're already in the tree, include guard prevents second use. One rule is not to have cyclic deps. > In summary (correct me if I am wrong) what this does is (in some pseudo code): Correct pseudo code for cppan: --- if (TARGET t1) return include(d1) # include file has i. guard include(d2) # cannot use add_subdirectory directly ... declare t1 target_deps t1 d1 d2 ... --- On 2 October 2017 at 16:10, Raffi Enficiaud wrote: > Le 27.09.17 ? 19:10, Egor Pugin a ?crit : >>> >>> The idea is to include several "packages" (one package ~ one project in >>> Boost) and make those available to the build, exactly as for a regular >>> CMakeLists.txt that adds several directories or subprojects through a >>> sequence of calls to "add_directories". >>> However, the difference here is that "packages" have inter-dependencies, >>> and the order of the "add_directories" should honor those dependencies. >> >> >> I solved the issue of including several dirs (via 'add_directories') >> using guards 'if (TARGET name); return(); endif()' in my pkg manager. >> See boost libraries there: https://cppan.org/search?q=boost >> Each library can be included to project separately with autoincluding >> required deps for it. > > > Hi, > > Thank you for your answer. What you did with CPAN is wonderful, but I think > this much more than what my humble scripts are trying to address. > > Also the guard mechanism does not really address the issue of ordering the > add_directories in some topological order. In particular, you guard because > you do not want to declare several times the same target, but it does not > tell when to include any other dependencies your target may have. > > In summary (correct me if I am wrong) what this does is (in some pseudo > code): > > --------- > if(target1, target2 ... already defined) > return > > declare target1, target2 ... > target_dependencies target1, target1.1, target1.2 ... > target_dependencies target2, target2.1, target2.2 ... > --------- > > but it does not tell when to declare target1.1, target1.2 ... and this > knowledge should be encoded somewhere else in your scripts. > > Best, > Raffi > > > > -- > > 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 -- Egor Pugin From seblist at xwmw.org Mon Oct 2 16:24:22 2017 From: seblist at xwmw.org (Sebastian Holtermann) Date: Mon, 02 Oct 2017 22:24:22 +0200 Subject: [cmake-developers] CMP0071 In-Reply-To: References: <2105906395.105674998.1506432728339.JavaMail.zimbra@elemtech.com> <767335078.106094165.1506444910404.JavaMail.zimbra@elemtech.com> Message-ID: <7651738.tf3gbDaBO9@blauwal> On Montag, 2. Oktober 2017 06:58:31 CEST Brad King wrote: > On 09/26/2017 12:55 PM, clinton at elemtech.com wrote: > > https://bugreports.qt.io/browse/QTBUG-63442 > > Please take a look at the proposed fix: > > https://codereview.qt-project.org/#/c/207327/ I dropped a few comments. -Sebastian From raffi.enficiaud at mines-paris.org Mon Oct 2 18:20:19 2017 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Tue, 3 Oct 2017 00:20:19 +0200 Subject: [cmake-developers] Tools for handling cross project dependencies In-Reply-To: References: Message-ID: Le 02.10.17 ? 18:06, Egor Pugin a ?crit : > Sorry, maybe I did not understand you correctly, but why do you need > some order of 'add_subdirectory'? I am not sure to understand why you are asking this, please let me know if I am off-topic :) I have say libOpenCV, libTIFF and libZ. libTIFF depends on libZ, libOpenCV depends on libTIFF and libZ. libTIFF and libZ are doing some magic, say they compile from source or if those libraries are available from the OS, they just include the system libraries as imported targets. In a project, I would like to link to libOpenCV, I know it depends on libTIFF and libZ, but I do not know if there is any dependencies between those libTIFF and libZ. I know that I should do an add_subdirectory(libOpenCV) and before that, do an add_subdirectory of libTIFF and libZ. Depending on the orders of the add_subdirectory, I would be able to compile or not libTIFF and subsequently libOpenCV. This should work: """"" add_subdirectory(libZ) add_subdirectory(libTIFF) add_subdirectory(libOpenCV) """"" and this should not work """"" add_subdirectory(libTIFF) add_subdirectory(libZ) add_subdirectory(libOpenCV) """"" (because the declaration of the libTIFF targets make implicit reference to headers and shared/static library of libZ.) So in a "superproject" (the one that is making the 3 calls to add_subdirectory above), there is an implicit orchestration/ordering of the add_subdirectory commands, and I would somehow like to encode this within CMake and without any other tool. Of course, in this very naive and simplified example, it is easy to address, but this does not scale up efficiently. Somehow, there is a need to encode the graph of dependencies, and to inject that graph into CMake. This is what I suggest to do: discuss about the interest and the "protocol" for encoding such a graph, and what type of information which should carry in the graph (nodes and arrows). > Cppan knows from config (yaml) files what deps must be included and > just adds them one by one. If they're already in the tree, include > guard prevents second use. Right, but there is also an explicit order in your YAML files, isn't it? I have to say I have not look very deeply. > One rule is not to have cyclic deps. Yes, the dependencies should form a Directed Acyclic Graph, otherwise we have troubles. This can be checked also very easily. >> In summary (correct me if I am wrong) what this does is (in some pseudo code): > > Correct pseudo code for cppan: > --- > if (TARGET t1) > return > > include(d1) # include file has i. guard > include(d2) # cannot use add_subdirectory directly > ... > > declare t1 > target_deps t1 d1 d2 ... > --- Also in a more complicated settings, you can certainly have the targets defined by d1/d2 sourced by another CMakeLists.txt (say libZ used for target t1=OpenCV and target t2=libYAML, those being on different CMakeLists.txt). You address this by adding an include guard. As a matter of facts, include guards are inducing a topological sort on the order of the targets declaration (roughly speaking "include guards=an implementation of topological sort"). Having access to the dependency graph is however providing a richer information and ease of maintenance, and I am pretty sure this can find many different use cases (outside of mine of course). For example: * being agnostic to the overall directory layout: in your example you only care about the targets d1/d2 being declared, not the file/location of their declaration (while the include directive enforces some directory layout) * detect cyclic dependencies * easy filtering of include or add_subdirectory calls, based on the selection of specific targets (only the direct and indirect parents of the selected target are included in the project, which is easy to do if we have access to the dependency graph) * generated installation package dependency declaration (the debian packages extract the direct dependencies from this graph) * etc... I hope I clarified better the problems I am trying to address, Best, Raffi > On 2 October 2017 at 16:10, Raffi Enficiaud > wrote: >> Le 27.09.17 ? 19:10, Egor Pugin a ?crit : >>>> >>>> The idea is to include several "packages" (one package ~ one project in >>>> Boost) and make those available to the build, exactly as for a regular >>>> CMakeLists.txt that adds several directories or subprojects through a >>>> sequence of calls to "add_directories". >>>> However, the difference here is that "packages" have inter-dependencies, >>>> and the order of the "add_directories" should honor those dependencies. >>> >>> >>> I solved the issue of including several dirs (via 'add_directories') >>> using guards 'if (TARGET name); return(); endif()' in my pkg manager. >>> See boost libraries there: https://cppan.org/search?q=boost >>> Each library can be included to project separately with autoincluding >>> required deps for it. >> >> >> Hi, >> >> Thank you for your answer. What you did with CPAN is wonderful, but I think >> this much more than what my humble scripts are trying to address. >> >> Also the guard mechanism does not really address the issue of ordering the >> add_directories in some topological order. In particular, you guard because >> you do not want to declare several times the same target, but it does not >> tell when to include any other dependencies your target may have. >> >> In summary (correct me if I am wrong) what this does is (in some pseudo >> code): >> >> --------- >> if(target1, target2 ... already defined) >> return >> >> declare target1, target2 ... >> target_dependencies target1, target1.1, target1.2 ... >> target_dependencies target2, target2.1, target2.2 ... >> --------- >> >> but it does not tell when to declare target1.1, target1.2 ... and this >> knowledge should be encoded somewhere else in your scripts. >> >> Best, >> Raffi >> >> >> >> -- >> >> 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 > > > From egor.pugin at gmail.com Tue Oct 3 05:45:41 2017 From: egor.pugin at gmail.com (Egor Pugin) Date: Tue, 3 Oct 2017 12:45:41 +0300 Subject: [cmake-developers] Tools for handling cross project dependencies In-Reply-To: References: Message-ID: I see now. >From my POV if you link opencv to your target, opencv implicitly provides all necessary deps not you. I.e. opencv -> tiff, tiff -> zlib. This is usual CMake workflow, isn't it? But you are managing these deps manually, so have to choose an order. On 3 October 2017 at 01:20, Raffi Enficiaud wrote: > Le 02.10.17 ? 18:06, Egor Pugin a ?crit : >> >> Sorry, maybe I did not understand you correctly, but why do you need >> some order of 'add_subdirectory'? > > > I am not sure to understand why you are asking this, please let me know if I > am off-topic :) > > I have say libOpenCV, libTIFF and libZ. libTIFF depends on libZ, libOpenCV > depends on libTIFF and libZ. > > libTIFF and libZ are doing some magic, say they compile from source or if > those libraries are available from the OS, they just include the system > libraries as imported targets. > > In a project, I would like to link to libOpenCV, I know it depends on > libTIFF and libZ, but I do not know if there is any dependencies between > those libTIFF and libZ. > > I know that I should do an add_subdirectory(libOpenCV) and before that, do > an add_subdirectory of libTIFF and libZ. Depending on the orders of the > add_subdirectory, I would be able to compile or not libTIFF and subsequently > libOpenCV. > > This should work: > > """"" > add_subdirectory(libZ) > add_subdirectory(libTIFF) > add_subdirectory(libOpenCV) > """"" > > and this should not work > """"" > add_subdirectory(libTIFF) > add_subdirectory(libZ) > add_subdirectory(libOpenCV) > """"" > > (because the declaration of the libTIFF targets make implicit reference to > headers and shared/static library of libZ.) > > So in a "superproject" (the one that is making the 3 calls to > add_subdirectory above), there is an implicit orchestration/ordering of the > add_subdirectory commands, and I would somehow like to encode this within > CMake and without any other tool. > > Of course, in this very naive and simplified example, it is easy to address, > but this does not scale up efficiently. Somehow, there is a need to encode > the graph of dependencies, and to inject that graph into CMake. > > This is what I suggest to do: discuss about the interest and the "protocol" > for encoding such a graph, and what type of information which should carry > in the graph (nodes and arrows). > >> Cppan knows from config (yaml) files what deps must be included and >> just adds them one by one. If they're already in the tree, include >> guard prevents second use. > > > Right, but there is also an explicit order in your YAML files, isn't it? I > have to say I have not look very deeply. > >> One rule is not to have cyclic deps. > > > Yes, the dependencies should form a Directed Acyclic Graph, otherwise we > have troubles. This can be checked also very easily. > > >>> In summary (correct me if I am wrong) what this does is (in some pseudo >>> code): >> >> >> Correct pseudo code for cppan: >> --- >> if (TARGET t1) >> return >> >> include(d1) # include file has i. guard >> include(d2) # cannot use add_subdirectory directly >> ... >> >> declare t1 >> target_deps t1 d1 d2 ... >> --- > > > Also in a more complicated settings, you can certainly have the targets > defined by > d1/d2 sourced by another CMakeLists.txt (say libZ used for target t1=OpenCV > and target > t2=libYAML, those being on different CMakeLists.txt). > > You address this by adding an include guard. > As a matter of facts, include guards are inducing a topological sort on the > order > of the targets declaration (roughly speaking "include guards=an > implementation of topological sort"). > > Having access to the dependency graph is however providing a richer > information and ease > of maintenance, and I am pretty sure this can find many different use cases > (outside of mine of course). > > For example: > > * being agnostic to the overall directory layout: in your example you only > care about the > targets d1/d2 being declared, not the file/location of their declaration > (while the include > directive enforces some directory layout) > * detect cyclic dependencies > * easy filtering of include or add_subdirectory calls, based on the > selection of specific > targets (only the direct and indirect parents of the selected target are > included in the project, > which is easy to do if we have access to the dependency graph) > * generated installation package dependency declaration (the debian packages > extract the > direct dependencies from this graph) > * etc... > > I hope I clarified better the problems I am trying to address, > > Best, > Raffi > > >> On 2 October 2017 at 16:10, Raffi Enficiaud >> wrote: >>> >>> Le 27.09.17 ? 19:10, Egor Pugin a ?crit : >>>>> >>>>> >>>>> The idea is to include several "packages" (one package ~ one project in >>>>> Boost) and make those available to the build, exactly as for a regular >>>>> CMakeLists.txt that adds several directories or subprojects through a >>>>> sequence of calls to "add_directories". >>>>> However, the difference here is that "packages" have >>>>> inter-dependencies, >>>>> and the order of the "add_directories" should honor those dependencies. >>>> >>>> >>>> >>>> I solved the issue of including several dirs (via 'add_directories') >>>> using guards 'if (TARGET name); return(); endif()' in my pkg manager. >>>> See boost libraries there: https://cppan.org/search?q=boost >>>> Each library can be included to project separately with autoincluding >>>> required deps for it. >>> >>> >>> >>> Hi, >>> >>> Thank you for your answer. What you did with CPAN is wonderful, but I >>> think >>> this much more than what my humble scripts are trying to address. >>> >>> Also the guard mechanism does not really address the issue of ordering >>> the >>> add_directories in some topological order. In particular, you guard >>> because >>> you do not want to declare several times the same target, but it does not >>> tell when to include any other dependencies your target may have. >>> >>> In summary (correct me if I am wrong) what this does is (in some pseudo >>> code): >>> >>> --------- >>> if(target1, target2 ... already defined) >>> return >>> >>> declare target1, target2 ... >>> target_dependencies target1, target1.1, target1.2 ... >>> target_dependencies target2, target2.1, target2.2 ... >>> --------- >>> >>> but it does not tell when to declare target1.1, target1.2 ... and this >>> knowledge should be encoded somewhere else in your scripts. >>> >>> Best, >>> Raffi >>> >>> >>> >>> -- >>> >>> 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 >> >> >> >> > > > -- > > 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 -- Egor Pugin From robert.maynard at kitware.com Wed Oct 4 10:21:30 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 4 Oct 2017 10:21:30 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.9.4 available for download Message-ID: We are pleased to announce that CMake 3.9.4 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.9.4 since 3.9.3: Brad King (2): FindBoost: Finish reverting "Simplify search in lists" for 3.9 CMake 3.9.4 From clinton at elemtech.com Wed Oct 4 22:01:50 2017 From: clinton at elemtech.com (clinton at elemtech.com) Date: Wed, 4 Oct 2017 20:01:50 -0600 (MDT) Subject: [cmake-developers] CMP0071 In-Reply-To: <1917044.Hax7LbVASi@blauwal> References: <2105906395.105674998.1506432728339.JavaMail.zimbra@elemtech.com> <1917044.Hax7LbVASi@blauwal> Message-ID: <816732748.13532229.1507168910486.JavaMail.zimbra@elemtech.com> ----- On Sep 26, 2017, at 9:07 AM, Sebastian Holtermann seblist at xwmw.org wrote: >> I updated and I'm getting this: >> >> CMake Warning (dev) in claro/navigation5/CMakeLists.txt: >> Policy CMP0071 is not set: Let AUTOMOC and AUTOUIC process GENERATED files. >> Run "cmake --help-policy CMP0071" for policy details. Use the cmake_policy >> command to set the policy and suppress this warning. >> >> AUTOMOC: Ignoring GENERATED header file(s): >> >> "/path/to/ui_SomeFile.h" >> "/path/to/qrc_AnotherFile.cpp" >> >> >> Those ui_* and qrc_* files do not require processing by moc. >> In this case, I was using qt5_wrap_ui() and qt5_add_resources(). >> >> I did an experiment and replaced qt5_wrap_ui() with autouic, and the warning >> went away for those ui_* files. >> >> Is there a way to not print out that policy warning on ui_* and qrc_* files >> when using qt5_wrap_ui()/qt5_add_resources()? These are the only file types >> for which I'm getting that warning. > > You can set the source file property SKIP_AUTOMOC on the GENERATED files. > See: https://cmake.org/cmake/help/v3.9/prop_sf/SKIP_AUTOMOC.html > See: https://cmake.org/cmake/help/git-master/policy/CMP0071.html > > For example like this > ``` > set_property(SOURCE /path/to/ui_SomeFile.h PROPERTY SKIP_AUTOMOC ON) > set_property(SOURCE /path/to/qrc_AnotherFile.cpp PROPERTY SKIP_AUTOMOC ON) > ``` > I'm probably pushing things here, but why not. I'm experimenting with setting AUTOMOC/AUTOUIC/AUTORCC on, and also using the qt5_* macros. I see the rcc processing only looks at *.qrc files, but the uic processing looks at files with any extension. Why not limit that to just *.ui files? I find myself setting SKIP_AUTOUIC on *.h and *.cpp files to silence CMP0071 warnings. Its obvious to me that a .cpp or .h file is not an xml file as expected by uic. I can understand having to set SKIP_AUTOMOC on files with various file extensions. I bring this up here in case something needs to change on the CMake side. Clint From seblist at xwmw.org Thu Oct 5 03:31:53 2017 From: seblist at xwmw.org (Sebastian Holtermann) Date: Thu, 05 Oct 2017 09:31:53 +0200 Subject: [cmake-developers] CMP0071 In-Reply-To: <816732748.13532229.1507168910486.JavaMail.zimbra@elemtech.com> References: <2105906395.105674998.1506432728339.JavaMail.zimbra@elemtech.com> <1917044.Hax7LbVASi@blauwal> <816732748.13532229.1507168910486.JavaMail.zimbra@elemtech.com> Message-ID: <2737450.MdKDD5myi1@blauwal> On Mittwoch, 4. Oktober 2017 20:01:50 CEST clinton at elemtech.com wrote: > ----- On Sep 26, 2017, at 9:07 AM, Sebastian Holtermann seblist at xwmw.org wrote: > >> I updated and I'm getting this: > >> > >> CMake Warning (dev) in claro/navigation5/CMakeLists.txt: > >> Policy CMP0071 is not set: Let AUTOMOC and AUTOUIC process GENERATED > >> files. > >> Run "cmake --help-policy CMP0071" for policy details. Use the > >> cmake_policy > >> command to set the policy and suppress this warning. > >> > >> AUTOMOC: Ignoring GENERATED header file(s): > >> > >> "/path/to/ui_SomeFile.h" > >> "/path/to/qrc_AnotherFile.cpp" > >> > >> > >> Those ui_* and qrc_* files do not require processing by moc. > >> In this case, I was using qt5_wrap_ui() and qt5_add_resources(). > >> > >> I did an experiment and replaced qt5_wrap_ui() with autouic, and the > >> warning went away for those ui_* files. > >> > >> Is there a way to not print out that policy warning on ui_* and qrc_* > >> files > >> when using qt5_wrap_ui()/qt5_add_resources()? These are the only file > >> types > >> for which I'm getting that warning. > > > > You can set the source file property SKIP_AUTOMOC on the GENERATED files. > > See: https://cmake.org/cmake/help/v3.9/prop_sf/SKIP_AUTOMOC.html > > See: https://cmake.org/cmake/help/git-master/policy/CMP0071.html > > > > For example like this > > ``` > > set_property(SOURCE /path/to/ui_SomeFile.h PROPERTY SKIP_AUTOMOC ON) > > set_property(SOURCE /path/to/qrc_AnotherFile.cpp PROPERTY SKIP_AUTOMOC ON) > > ``` > > I'm probably pushing things here, but why not. > I'm experimenting with setting AUTOMOC/AUTOUIC/AUTORCC on, and also using > the qt5_* macros. > > I see the rcc processing only looks at *.qrc files, but the uic processing > looks at files with any extension. Why not limit that to just *.ui files? > I find myself setting SKIP_AUTOUIC on *.h and *.cpp files to silence > CMP0071 warnings. Its obvious to me that a .cpp or .h file is not an xml > file as expected by uic. > > I can understand having to set SKIP_AUTOMOC on files with various file > extensions. > > I bring this up here in case something needs to change on the CMake side. Despite it's name might imply that, AUTOUIC doesn't care about .ui files in the target sources. It never did. AUTOUIC probes the same files as AUTOMOC, that is .h(xx/pp) and .c(xx/pp) files. In these files it searches for '#include "ui_.h"' strings and derives the .ui file names from that (for uic processing). I don't think that this can (or should) be changed. It's a reasonable behavior and a number of projects rely on it. It just is not what people might expect at a first glance. From seblist at xwmw.org Thu Oct 5 03:53:26 2017 From: seblist at xwmw.org (Sebastian Holtermann) Date: Thu, 05 Oct 2017 09:53:26 +0200 Subject: [cmake-developers] CMP0071 In-Reply-To: <816732748.13532229.1507168910486.JavaMail.zimbra@elemtech.com> References: <2105906395.105674998.1506432728339.JavaMail.zimbra@elemtech.com> <1917044.Hax7LbVASi@blauwal> <816732748.13532229.1507168910486.JavaMail.zimbra@elemtech.com> Message-ID: <1512291.IWh4qPqqZX@blauwal> > I find myself setting SKIP_AUTOUIC on *.h and *.cpp files to silence > CMP0071 warnings. It's an unfortunate situation. In many cases (qt < 5.10) it might work to just let AUTOUIC probe the (moc/uic/rcc) GENERATED files as well by setting `cmake_policy(SET CMP0071 NEW)` From sbv1976 at gmail.com Thu Oct 5 09:26:36 2017 From: sbv1976 at gmail.com (Steven Velez) Date: Thu, 5 Oct 2017 09:26:36 -0400 Subject: [cmake-developers] Extending XCode scheme generation support In-Reply-To: <07a32ef4-f830-23de-6e2f-d203cfb541ee@googlemail.com> References: <07a32ef4-f830-23de-6e2f-d203cfb541ee@googlemail.com> Message-ID: Thanks for the followup Gregor. One thing that concerns me about the property-centric approach is that I can't think of a way to use properties for generating a custom scheme that builds the ALL_BUILD target. I would assume this would run into the same issues and limitations that I have seen in google searches with trying to control the the folder for the ALL_BUILD target with the FOLDER target property (even though this would be a Visual Studio concern). It seems that is addressed now with the *_TARGETS_FOLDER global properties, so maybe an analog can be established? Regarding sequencing changes, do you mean to come up with a set of smaller logical changes/MRs so that this isn't all dumped at once? If so, I think we could implement XCODE_SCHEME_NAME and a single additional property without generator support, then add generator support, then add the balance of the properties one-by-one. Would that make sense? I have to get more familiar with CMake's testing methodologies to have any comment on that portion. If two targets specify the same schema name, then overwrite/accept latest with a warning? Regarding ios builds or perhaps having multiple build devices (I have seen some hand-made projects with 64-bit and 32-bit desktop clients selectable), then I will also have to get back to you on that. I was thinking the property definitions were generic enough to handle any needs... and I assumed that devices were handles with additional scheme files, but I realize that was a bad assumption. Will try to have that thought out soon. Thanks, Steven On Mon, Oct 2, 2017 at 9:05 AM, Gregor Jasny wrote: > Hello Steven, > > On 9/22/17 3:36 AM, Steven Velez wrote: >> # Property-Centric >> In this proposal, the generation of the scheme files is customized primarily by >> a user setting additional, specialized properties on a given target, which then >> affect the generation of the scheme files associated with that target. > thank you for working an the scheme proposal. I also believe that the > property-centric approach is better suited and easier to implement than > the file-centrix one. > > Next steps would be to sequence the necessary changes and define test > cases. I could imagine that adding generator-expression support would be > much harder to implement that other things. > > Things that also should be considered are: > * differences between macOS and iOS when generating a scheme > * what should happen if two targets specify the same schema name > > Thanks, > Gregor From brad.king at kitware.com Thu Oct 5 10:06:17 2017 From: brad.king at kitware.com (Brad King) Date: Thu, 5 Oct 2017 10:06:17 -0400 Subject: [cmake-developers] CMake 3.10 feature freeze on 2017-10-02 In-Reply-To: References: Message-ID: <04ed4c8c-91cd-13b4-6219-fb97225b87c7@kitware.com> On 10/02/2017 11:48 AM, Brad King wrote: > I'll announce when post-3.10 development is open. I've branched 'release' for 3.10. The repository is now open for post-3.10 development. Please rebase open merge requests on 'master' before staging or merging. > Meanwhile the following types of changes are still welcome: > > * Documentation updates > * Regression fixes > * Dashboard fixes > * Fixes for bugs in features new to 3.10 or 3.9 These types of changes may still be accepted to 'release' during the 3.10 release candidate cycle. The 3.10 release is now closed to new features and general bug fixes. Thanks, -Brad From robert.maynard at kitware.com Thu Oct 5 16:57:39 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 5 Oct 2017 16:57:39 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.10.0-rc1 is now ready for testing Message-ID: I am proud to announce the first CMake 3.10 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.10 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.10/release/3.10.html Some of the more significant changes in CMake 3.10 are: * The flang Fortran compiler is now supported, with compiler id "Flang". * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * "FindMPI" received a major overhaul. It now features language specific components, better Fortran support, and support for statically linked MPI implementations. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module underwent numerous improvements. It has gained support for GLVND and EGL on Linux. It now has import targets that separate the OpenGL library and OpenGL contexts. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". CMake 3.10 Release Notes ************************ Changes made since CMake 3.9 include the following. New Features ============ Platforms --------- * The flang Fortran compiler is now supported, with compiler id "Flang". * A new minimal platform file for "Midipix" was added. * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * Support for the IAR ARM Compiler was improved. Generators ---------- * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools like ccache along with the compiler for the "CUDA" language ("C" and "CXX" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * The "CodeBlocks" extra generator learned to optionally exclude files from outside the project root directory from the generated project. See the "CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES" variable. Commands -------- * The "cmake_host_system_information()" command learned more keys to get information about the processor capabilities and the host OS version. * The "configure_file()" command learned to support indented "# cmakedefine" and "# cmakedefine01". Spaces and/or tabs between the "#" character and the "cmakedefine"/"cmakedefine01" words are now understood and preserved in the output. * The "execute_process()" command gained a "RESULTS_VARIABLE" option to collect a list of results from all children in a pipeline of processes when multiple "COMMAND" arguments are given. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * The "string()" command learned a new "PREPEND" subcommand. * The "string(TIMESTAMP)" command now supports "%A" for full weekday name and "%B" for full month name. Variables --------- * A "CMAKE_DIRECTORY_LABELS" variable was added to specify labels for all tests in a directory. Properties ---------- * A "_CPPCHECK" target property and supporting "CMAKE__CPPCHECK" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "cppcheck" with the compiler for "C" and "CXX" languages. * A "LABELS" directory property was added to specify labels for all targets and tests in a directory. * A "TEST_INCLUDE_FILES" directory property was added to list any number of files to be included when running tests with "ctest(1)". This generalizes the "TEST_INCLUDE_FILE" property. * The "VS_DOTNET_REFERENCEPROP__TAG_" target property was added to support custom XML tags for reference assemblies in C# targets. * Source file properties "VS_SHADER_OUTPUT_HEADER_FILE" and "VS_SHADER_VARIABLE_NAME" have been added to specify more details of ".hlsl" sources with Visual Studio Generators. Modules ------- * The "FindCurses" module gained a "CURSES_NEED_WIDE" option to request the wide-character variant. * The "FindEXPAT" module now provides imported targets. * The "FindFreetype" module now provides imported targets. * "FindMPI" gained a number of new features, including: * Language-specific components have been added to the module. * Many more MPI environments are now supported. * The environmental support for Fortran has been improved. * A user now has fine-grained control over the MPI selection process, including passing custom parameters to the MPI compiler. * The version of the implemented MPI standard is now being exposed. * MPI-2 C++ bindings can now be detected and also suppressed if so desired. * The available Fortran bindings are now being detected and verified. * Various MPI-3 information can be requested, including the library version and Fortran capabilities of the individual bindings. * Statically linked MPI implementations are supported. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module gained support for GLVND on Linux. * The "FindOpenMP" module gained support for language-specific components. * A "FindPatch" module was added to find the "patch" command-line executable. * The "FindProtobuf" module "protobuf_generate_cpp()" command gained a "DESCRIPTORS" option to generate descriptor files. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. Unlike the source parsing approach, dynamic discovery executes the test (in 'list available tests' mode) at build time to discover tests. This is robust against unusual ways of labeling tests, provides much better support for advanced features such as parameterized tests, and does not require re-running CMake to discover added or removed tests within a test executable. * The "InstallRequiredSystemLibraries" module gained support for installing Intel compiler runtimes. Autogen ------- * When using "AUTOMOC" or "AUTOUIC" with a multi configuration generator (e.g. "Xcode"), included "*.moc", "moc_*.cpp" and "ui_*.h" files are generated in "/include_" instead of "/include". * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * When using "AUTOMOC", CMake searches for the strings "Q_OBJECT", "Q_GADGET" or "Q_NAMESPACE" in a source file to determine if it needs to be "moc" processed. The new variable "CMAKE_AUTOMOC_MACRO_NAMES" allows to register additional strings (macro names) so search for. * When using "AUTOMOC", CMake searches for the strings "Q_OBJECT", "Q_GADGET" or "Q_NAMESPACE" in a source file to determine if it needs to be "moc" processed. The new target property "AUTOMOC_MACRO_NAMES" allows to register additional strings (macro names) so search for. * When using "AUTOMOC", the new variable "CMAKE_AUTOMOC_COMPILER_PREDEFINES" allows to default enable or disable the generation of the compiler pre definitions file "moc_predefs.h". * When using "AUTOMOC", the new boolean target property "AUTOMOC_COMPILER_PREDEFINES" allows to enable or disable the generation of the compiler pre definitions file "moc_predefs.h". CTest ----- * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. CPack ----- * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "CPackDeb" module learned to set package release version in "Version" info property. See the "CPACK_DEBIAN_PACKAGE_RELEASE" variable. * The "CPackDeb" module learned more strict package version checking that complies with Debian rules. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "REPLACES" and "CHECKABLE" options. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_FILE_EXTENSION" variable to customize target binary format. * The "CPackIFW" module gained new "CPACK_IFW_REPOSITORIES_DIRECTORIES" variable to specify additional repositories dirs that will be used to resolve and repack dependent components. This feature available only since QtIFW 3.1. * Modules "CPackRPM" and "CPackDeb" learned to set package epoch version. See "CPACK_RPM_PACKAGE_EPOCH" and "CPACK_DEBIAN_PACKAGE_EPOCH" variables. Other ----- * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The graphviz output now distinguishes among the different dependency types "PUBLIC", "PRIVATE" and "INTERFACE" and represents them in the output graph as solid, dashed and dotted edges. Deprecated and Removed Features =============================== * Support for building CMake itself with C++98 compilers was dropped. CMake is now implemented using C++11. * Support for building CMake on HP-UX has been dropped pending better support for C++11 and a port of libuv. See CMake Issue 17137. Use CMake 3.9 or lower instead for HP-UX support. Other Changes ============= * On FreeBSD the C++ compiler named "c++" is now the preferred default. * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". * The "get_filename_component()" "PROGRAM" mode semantics have been revised to not tolerate unquoted spaces in the path to the program while also accepting arguments. While technically incompatible with the old behavior, it is expected that behavior under typical use cases with properly-quoted command-lines has not changed. From a.huebl at hzdr.de Fri Oct 6 05:42:55 2017 From: a.huebl at hzdr.de (Axel Huebl) Date: Fri, 6 Oct 2017 11:42:55 +0200 Subject: [cmake-developers] CMake Var for Specific Processor Type Message-ID: Dear CMake List, we are building HPC software with CMake. In many cases, we find that the performance of (auto)vectorization heavy code depends greatly on specifying the exact processor generation for optimally tuned binaries. That is no surprise, since a compiler's architecture flags just group an according set of available instructions for e.g. SIMD extensions. The question now is: Is there a generic CMake best-practice to specify the *exact* architecture -mtune/-march/-mcpu/-qarch/-x/... flags, ideally according to the currently used compiler (icc,gcc,xlc,pgc,...) just from the name of the processor generation? CMAKE_SYSTEM_PROCESSOR looks like it but its documentation is a bit short. Does it allow me to set details such as "bdver1", "corei7-avx" or "core-avx2" as targets (instead of generic "x86_64")? Note: Portability of binaries is not relevant since we can re-compile for each system (and have performance portable source code). Vice versa, is there a way already for setting the CUDA compute capabilities of a target via a CMake variable? For both cases, we currently hijack CXX flags and do switches on compilers, which is probably not the most generic way to write maintainable CMake scripts. For NVCC and Clang CUDA SM targets for PTX and SASS code embedding, we just have our own CMake variable, which is also sub-ideal for as it is not standardized. How do you usually address this? All the best, Axel -- Axel Huebl Phone +49 351 260 3582 https://www.hzdr.de/crp Computational Radiation Physics Laser Particle Acceleration Division Helmholtz-Zentrum Dresden - Rossendorf e.V. Bautzner Landstrasse 400, 01328 Dresden POB 510119, D-01314 Dresden Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey Prof. Dr.Dr.h.c. P. Joehnk VR 1693 beim Amtsgericht Dresden From robert.maynard at kitware.com Fri Oct 6 09:07:25 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 6 Oct 2017 09:07:25 -0400 Subject: [cmake-developers] CMake Var for Specific Processor Type In-Reply-To: References: Message-ID: CMAKE_SYSTEM_PROCESSOR is a read-only variable that CMake will populate to help inform projects what kind of platform they are running on X86_64/ARM/PowerPC. It will not provide the level of detail information needed to determine what specific architecture you should specify. The best place to add such information would be the cmake_host_system_information() call which already supports a limited ability to query the host system. The underlying infrastructure does support asking about the actual CPU architecture it just never has been exposed. So in summary there is no best practice on how to specify the best matching architecture flags, and currently it has been left up to each project For CUDA the FindCUDA module does have select_compute_arch.cmake which does system introspection to determine the set of CUDA flags. This can be can be used with the new native CUDA support by passing the results to CMAKE_CUDA_FLAGS or with target_compile_options and $. On Fri, Oct 6, 2017 at 5:42 AM, Axel Huebl wrote: > Dear CMake List, > > > we are building HPC software with CMake. In many cases, we find that the > performance of (auto)vectorization heavy code depends greatly on > specifying the exact processor generation for optimally tuned binaries. > That is no surprise, since a compiler's architecture flags just group an > according set of available instructions for e.g. SIMD extensions. > > The question now is: Is there a generic CMake best-practice to specify > the *exact* architecture -mtune/-march/-mcpu/-qarch/-x/... flags, > ideally according to the currently used compiler (icc,gcc,xlc,pgc,...) > just from the name of the processor generation? > > CMAKE_SYSTEM_PROCESSOR looks like it but its documentation is a bit > short. Does it allow me to set details such as "bdver1", "corei7-avx" or > "core-avx2" as targets (instead of generic "x86_64")? > > Note: Portability of binaries is not relevant since we can re-compile > for each system (and have performance portable source code). > > Vice versa, is there a way already for setting the CUDA compute > capabilities of a target via a CMake variable? > > For both cases, we currently hijack CXX flags and do switches on > compilers, which is probably not the most generic way to write > maintainable CMake scripts. For NVCC and Clang CUDA SM targets for PTX > and SASS code embedding, we just have our own CMake variable, which is > also sub-ideal for as it is not standardized. > > How do you usually address this? > > > All the best, > Axel > -- > > Axel Huebl > Phone +49 351 260 3582 > https://www.hzdr.de/crp > Computational Radiation Physics > Laser Particle Acceleration Division > Helmholtz-Zentrum Dresden - Rossendorf e.V. > > Bautzner Landstrasse 400, 01328 Dresden > POB 510119, D-01314 Dresden > Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey > Prof. Dr.Dr.h.c. P. Joehnk > VR 1693 beim Amtsgericht Dresden > -- > > 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 From a.huebl at hzdr.de Fri Oct 6 10:44:37 2017 From: a.huebl at hzdr.de (Axel Huebl) Date: Fri, 6 Oct 2017 16:44:37 +0200 Subject: [cmake-developers] CMake Var for Specific Processor Type In-Reply-To: References: Message-ID: Thank you for the detailed answer! The introspection sounds also interesting, but at least for the CPU side the arch keyword "native" is already the ideal -march if one compiles directly on the target architecture. What I was thinking/dreaming of was a workflow close to: (1) a user knows the exact target architecture by name (CPU and GPU) or a system provides CMake templates for it as a module (e.g. per HPC batch system queue). (2) the user (manually/per module) selects a host and device compiler, and cmake looks up the according architecture flag for the compiler. the value of the arch flag comes from the user or a selected system/queue-wide profile. The second step (my initial question) is similar to what CMake already abstracts for -fopenmp and -fPIC flags per compiler. Instead of -fPIC as set(CMAKE_POSITION_INDEPENDENT_CODE ON) I would set set(CMAKE_CXX_ARCH "core-avx2") set(CMAKE_CUDA_ARCH "30;50;60") or directly as property on the target set_property(TARGET libcpp PROPERTIES LINKER_LANGUAGE CXX) set_property(TARGET lib2cu PROPERTIES LINKER_LANGUAGE CUDA) set_property(TARGET libcpp PROPERTY ARCH "core-avx2") set_property(TARGET lib2cu PROPERTY HOST_ARCH "core-avx2") set_property(TARGET lib2cu PROPERTY DEVICE_ARCH "30;50;60") Of course CUDA is weird again since a target can only have one language but a CUDA target has a host *and* a device architecture... Probably per-queue/system compiler wrappers instead of (1) would serve the same purpose... Anyway, I was just wondering if that is already somehow covered in cross-compiling support (1) or compiler flag abstractions (2). Thanks again and sorry for verbose mumbling! On 06.10.2017 15:07, Robert Maynard wrote: > CMAKE_SYSTEM_PROCESSOR is a read-only variable that CMake will > populate to help inform projects what kind of platform they are > running on X86_64/ARM/PowerPC. It will not provide the level of detail > information needed to determine what specific architecture you should > specify. The best place to add such information would be the > cmake_host_system_information() call which already supports a limited > ability to query the host system. The underlying infrastructure does > support asking about the actual CPU architecture it just never has > been exposed. > > So in summary there is no best practice on how to specify the best > matching architecture flags, and currently it has been left up to each > project > > For CUDA the FindCUDA module does have select_compute_arch.cmake which > does system introspection to determine the set of CUDA flags. This can > be can be used with the new native CUDA support by passing the results > to CMAKE_CUDA_FLAGS or with target_compile_options and > $. > > On Fri, Oct 6, 2017 at 5:42 AM, Axel Huebl wrote: >> Dear CMake List, >> >> >> we are building HPC software with CMake. In many cases, we find that the >> performance of (auto)vectorization heavy code depends greatly on >> specifying the exact processor generation for optimally tuned binaries. >> That is no surprise, since a compiler's architecture flags just group an >> according set of available instructions for e.g. SIMD extensions. >> >> The question now is: Is there a generic CMake best-practice to specify >> the *exact* architecture -mtune/-march/-mcpu/-qarch/-x/... flags, >> ideally according to the currently used compiler (icc,gcc,xlc,pgc,...) >> just from the name of the processor generation? >> >> CMAKE_SYSTEM_PROCESSOR looks like it but its documentation is a bit >> short. Does it allow me to set details such as "bdver1", "corei7-avx" or >> "core-avx2" as targets (instead of generic "x86_64")? >> >> Note: Portability of binaries is not relevant since we can re-compile >> for each system (and have performance portable source code). >> >> Vice versa, is there a way already for setting the CUDA compute >> capabilities of a target via a CMake variable? >> >> For both cases, we currently hijack CXX flags and do switches on >> compilers, which is probably not the most generic way to write >> maintainable CMake scripts. For NVCC and Clang CUDA SM targets for PTX >> and SASS code embedding, we just have our own CMake variable, which is >> also sub-ideal for as it is not standardized. >> >> How do you usually address this? >> >> >> All the best, >> Axel >> -- >> >> Axel Huebl >> Phone +49 351 260 3582 >> https://www.hzdr.de/crp >> Computational Radiation Physics >> Laser Particle Acceleration Division >> Helmholtz-Zentrum Dresden - Rossendorf e.V. >> >> Bautzner Landstrasse 400, 01328 Dresden >> POB 510119, D-01314 Dresden >> Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey >> Prof. Dr.Dr.h.c. P. Joehnk >> VR 1693 beim Amtsgericht Dresden >> -- >> >> 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 > -- Axel Huebl Phone +49 351 260 3582 https://www.hzdr.de/crp Computational Radiation Physics Laser Particle Acceleration Division Helmholtz-Zentrum Dresden - Rossendorf e.V. Bautzner Landstrasse 400, 01328 Dresden POB 510119, D-01314 Dresden Vorstand: Prof. Dr.Dr.h.c. R. Sauerbrey Prof. Dr.Dr.h.c. P. Joehnk VR 1693 beim Amtsgericht Dresden From sbv1976 at gmail.com Sun Oct 8 13:18:26 2017 From: sbv1976 at gmail.com (Steven Velez) Date: Sun, 8 Oct 2017 13:18:26 -0400 Subject: [cmake-developers] Extending XCode scheme generation support In-Reply-To: References: <07a32ef4-f830-23de-6e2f-d203cfb541ee@googlemail.com> Message-ID: After spending some time trying to figure out how to affect the build "destination", it seems that destinations associated with a given scheme are not influenced by anything beyond the targets referenced as build targets for the scheme. In other words, if a scheme builds an iOS target, then the iOS destinations/devices/simulators will be present in the UI, and if it references a MacOS target, then the active computer will be available in the destinations UI. The options available in the scheme proper seem to be similar in either case, and the proposal so far is fairly agnostic to specific options, so I think the current proposal stands without modification in this respect. Does this seem like a reasonable statement? This investigation did make me realize that each scheme can specify building more than one target, so I would revise my statement that the last target referencing a given scheme name should "win". Instead, I think each target should be built by the given scheme, and the union of settings provided by each target should be present in the scheme. If multiple targets indicate a similar setting, then in this case, the last setting should win, and this should print a warning... but if order of processing the schemes/targets cannot match source order, then perhaps it should be noted that what is "last" cannot be guaranteed.... Thanks, Steven On Thu, Oct 5, 2017 at 9:26 AM, Steven Velez wrote: > Thanks for the followup Gregor. > > One thing that concerns me about the property-centric approach is that > I can't think of a way to use properties for generating a custom > scheme that builds the ALL_BUILD target. I would assume this would > run into the same issues and limitations that I have seen in google > searches with trying to control the the folder for the ALL_BUILD > target with the FOLDER target property (even though this would be a > Visual Studio concern). It seems that is addressed now with the > *_TARGETS_FOLDER global properties, so maybe an analog can be > established? > > Regarding sequencing changes, do you mean to come up with a set of > smaller logical changes/MRs so that this isn't all dumped at once? If > so, I think we could implement XCODE_SCHEME_NAME and a single > additional property without generator support, then add generator > support, then add the balance of the properties one-by-one. Would > that make sense? > > I have to get more familiar with CMake's testing methodologies to have > any comment on that portion. > > If two targets specify the same schema name, then overwrite/accept > latest with a warning? > > Regarding ios builds or perhaps having multiple build devices (I have > seen some hand-made projects with 64-bit and 32-bit desktop clients > selectable), then I will also have to get back to you on that. I was > thinking the property definitions were generic enough to handle any > needs... and I assumed that devices were handles with additional > scheme files, but I realize that was a bad assumption. > > Will try to have that thought out soon. > > Thanks, > Steven > > On Mon, Oct 2, 2017 at 9:05 AM, Gregor Jasny wrote: >> Hello Steven, >> >> On 9/22/17 3:36 AM, Steven Velez wrote: >>> # Property-Centric >>> In this proposal, the generation of the scheme files is customized primarily by >>> a user setting additional, specialized properties on a given target, which then >>> affect the generation of the scheme files associated with that target. >> thank you for working an the scheme proposal. I also believe that the >> property-centric approach is better suited and easier to implement than >> the file-centrix one. >> >> Next steps would be to sequence the necessary changes and define test >> cases. I could imagine that adding generator-expression support would be >> much harder to implement that other things. >> >> Things that also should be considered are: >> * differences between macOS and iOS when generating a scheme >> * what should happen if two targets specify the same schema name >> >> Thanks, >> Gregor From wouter.klouwen at youview.com Tue Oct 10 10:57:53 2017 From: wouter.klouwen at youview.com (Wouter Klouwen) Date: Tue, 10 Oct 2017 15:57:53 +0100 Subject: [cmake-developers] Using monotonic time in CMake & CTest Message-ID: Hi all, we've started to use CTest for our test running and it's generally running well. However, we sometimes get some odd timeouts in tests, and as such it has been noticed that ctest doesn't use monotonic test timers, but instead relies on gettimeofday(). When running on some of our devices, they start up thinking that it is the year 2000 but during the test run, NTP kicks in, and fast forwards the time to be 2017. Using gettimeofday(), a test running during this NTP operation would seem to have taken 17 years. To avoid this, it's possible to use monotonic timers instead using clock_gettime(). Is there any reason to not use this? I've raised a bug* with a proposed patch. Thanks in advance, W *: https://gitlab.kitware.com/cmake/cmake/issues/17345 This transmission contains information that may be confidential and contain personal views which are not necessarily those of YouView TV Ltd. YouView TV Ltd (Co No:7308805) is a limited liability company registered in England and Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower Thames Street, London, EC3R 6YT. For details see our web site at http://www.youview.com From ivamprettimn at gmail.com Wed Oct 11 13:58:15 2017 From: ivamprettimn at gmail.com (Ivam Pretti) Date: Wed, 11 Oct 2017 14:58:15 -0300 Subject: [cmake-developers] List of Includes Message-ID: Does cmake has an overview of the includes comands? Because I came from microcontrolers and them you receive a list with the interruptions and ram memory map to use all the resources you gonna need. By now, all I found was that this corresponding resources are inside the include files, but I haven't find any list with this resources, only basic commands. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Oct 12 12:14:42 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 12 Oct 2017 12:14:42 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.10.0-rc2 is now ready for testing Message-ID: I am proud to announce the second CMake 3.10 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.10 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.10/release/3.10.html Some of the more significant changes in CMake 3.10 are: * The flang Fortran compiler is now supported, with compiler id "Flang". * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * "FindMPI" received a major overhaul. It now features language specific components, better Fortran support, and support for statically linked MPI implementations. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module underwent numerous improvements. It has gained support for GLVND and EGL on Linux. It now has import targets that separate the OpenGL library and OpenGL contexts. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". CMake 3.10 Release Notes ************************ Changes made since CMake 3.9 include the following. New Features ============ Platforms --------- * The flang Fortran compiler is now supported, with compiler id "Flang". * A new minimal platform file for "Midipix" was added. * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * Support for the IAR ARM Compiler was improved. Generators ---------- * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools like ccache along with the compiler for the "CUDA" language ("C" and "CXX" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * The "CodeBlocks" extra generator learned to optionally exclude files from outside the project root directory from the generated project. See the "CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES" variable. Commands -------- * The "cmake_host_system_information()" command learned more keys to get information about the processor capabilities and the host OS version. * The "configure_file()" command learned to support indented "# cmakedefine" and "# cmakedefine01". Spaces and/or tabs between the "#" character and the "cmakedefine"/"cmakedefine01" words are now understood and preserved in the output. * The "execute_process()" command gained a "RESULTS_VARIABLE" option to collect a list of results from all children in a pipeline of processes when multiple "COMMAND" arguments are given. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * The "string()" command learned a new "PREPEND" subcommand. * The "string(TIMESTAMP)" command now supports "%A" for full weekday name and "%B" for full month name. Variables --------- * A "CMAKE_DIRECTORY_LABELS" variable was added to specify labels for all tests in a directory. Properties ---------- * A "_CPPCHECK" target property and supporting "CMAKE__CPPCHECK" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "cppcheck" with the compiler for "C" and "CXX" languages. * A "LABELS" directory property was added to specify labels for all targets and tests in a directory. * A "TEST_INCLUDE_FILES" directory property was added to list any number of files to be included when running tests with "ctest(1)". This generalizes the "TEST_INCLUDE_FILE" property. * The "VS_DOTNET_REFERENCEPROP__TAG_" target property was added to support custom XML tags for reference assemblies in C# targets. * Source file properties "VS_SHADER_OUTPUT_HEADER_FILE" and "VS_SHADER_VARIABLE_NAME" have been added to specify more details of ".hlsl" sources with Visual Studio Generators. Modules ------- * The "FindCurses" module gained a "CURSES_NEED_WIDE" option to request the wide-character variant. * The "FindEXPAT" module now provides imported targets. * The "FindFreetype" module now provides imported targets. * "FindMPI" gained a number of new features, including: * Language-specific components have been added to the module. * Many more MPI environments are now supported. * The environmental support for Fortran has been improved. * A user now has fine-grained control over the MPI selection process, including passing custom parameters to the MPI compiler. * The version of the implemented MPI standard is now being exposed. * MPI-2 C++ bindings can now be detected and also suppressed if so desired. * The available Fortran bindings are now being detected and verified. * Various MPI-3 information can be requested, including the library version and Fortran capabilities of the individual bindings. * Statically linked MPI implementations are supported. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module gained support for GLVND on Linux. * The "FindOpenMP" module gained support for language-specific components. * A "FindPatch" module was added to find the "patch" command-line executable. * The "FindProtobuf" module "protobuf_generate_cpp()" command gained a "DESCRIPTORS" option to generate descriptor files. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. Unlike the source parsing approach, dynamic discovery executes the test (in 'list available tests' mode) at build time to discover tests. This is robust against unusual ways of labeling tests, provides much better support for advanced features such as parameterized tests, and does not require re-running CMake to discover added or removed tests within a test executable. * The "InstallRequiredSystemLibraries" module gained support for installing Intel compiler runtimes. Autogen ------- * When using "AUTOMOC" or "AUTOUIC" with a multi configuration generator (e.g. "Xcode"), included "*.moc", "moc_*.cpp" and "ui_*.h" files are generated in "/include_" instead of "/include". * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * When using "AUTOMOC", CMake searches for the strings "Q_OBJECT", "Q_GADGET" or "Q_NAMESPACE" in a source file to determine if it needs to be "moc" processed. The new "CMAKE_AUTOMOC_MACRO_NAMES" variable and "AUTOMOC_MACRO_NAMES" target property may be set to register additional strings (macro names) to search for. * When using "AUTOMOC", the new "CMAKE_AUTOMOC_COMPILER_PREDEFINES" variable and "AUTOMOC_COMPILER_PREDEFINES" target property specify whether to enable or disable the generation of the compiler pre definitions file "moc_predefs.h". CTest ----- * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. CPack ----- * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "CPackDeb" module learned to set package release version in "Version" info property. See the "CPACK_DEBIAN_PACKAGE_RELEASE" variable. * The "CPackDeb" module learned more strict package version checking that complies with Debian rules. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "REPLACES" and "CHECKABLE" options. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_FILE_EXTENSION" variable to customize target binary format. * The "CPackIFW" module gained new "CPACK_IFW_REPOSITORIES_DIRECTORIES" variable to specify additional repositories dirs that will be used to resolve and repack dependent components. This feature is only available when using QtIFW 3.1 or later. * Modules "CPackRPM" and "CPackDeb" learned to set package epoch version. See "CPACK_RPM_PACKAGE_EPOCH" and "CPACK_DEBIAN_PACKAGE_EPOCH" variables. Other ----- * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The graphviz output now distinguishes among the different dependency types "PUBLIC", "PRIVATE" and "INTERFACE" and represents them in the output graph as solid, dashed and dotted edges. Deprecated and Removed Features =============================== * Support for building CMake itself with C++98 compilers was dropped. CMake is now implemented using C++11. * Support for building CMake on HP-UX has been dropped pending better support for C++11 and a port of libuv. See CMake Issue 17137. Use CMake 3.9 or lower instead for HP-UX support. Other Changes ============= * On FreeBSD the C++ compiler named "c++" is now the preferred default. * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". * The "get_filename_component()" "PROGRAM" mode semantics have been revised to not tolerate unquoted spaces in the path to the program while also accepting arguments. While technically incompatible with the old behavior, it is expected that behavior under typical use cases with properly-quoted command-lines has not changed. ---------------------------------------------------------------------------- Changes made since CMake 3.9.0-rc1: Andr? Apitzsch (1): FindProtobuf: fix documentation typo Brad King (10): Help: Revise 3.10 release notes FindJava: Revise version parsing to support Java 9 curl: Update script to get curl 7.56.0 curl: Update build within CMake to account for 7.56 changes Help: Minor text clarifications in cmake-language(7) manual Clang: Diagnose unsupported GNU-like clang targeting MSVC ABI ExternalProject: Avoid if() auto-dereferene in quoted arguments FindXMLRPC: Drop unnecessary exec_program code paths FindXMLRPC: Tolerate no include directories CMake 3.10.0-rc2 Christian Pfeiffer (1): FindOpenMP: Fix link flags being used for compile Craig Scott (2): Help: Fix Example appearing in target property list of contents Help: Fix wrong property reference for an app bundle's Info.plist Curl Upstream (1): curl 2017-10-04 (3ea76790) Domen Vrankar (2): CPack/Deb: CPACK_DEBIAN_PACKAGE_VERSION regex testing exception CPack/Deb: fix for regex passing even if invalid characters are present Gregor Jasny (2): Revert "Xcode: Adjust tests to drop of 32bit iOS architectures" Xcode 9: Lower iOS deployment version to get armv7 builds Matthias Maennich (4): cmcmd: let operator<< for NumberFormatter reset the stream's format flags cmGeneratorTarget: remove dead code cmProcessTools: fix minor issue introduced by 595feb3 cmInstallCommandArguments: do not access static members through `this` Robert Maynard (1): FindCUDA: Update for CUDA 9 breakup of nppi into multiple libraries Sebastian Holtermann (3): Autogen: Allow setting SKIP_AUTOUIC/GEN on .ui files not in the sources Autogen: Docs: Add examples for AUTORCC_OPTIONS and AUTOUIC_OPTIONS Autogen: Docs: Extend SKIP_AUTOUIC documentation Thomas Stenersen (1): IPO: Fix support for spaces in path to archive tools From irwin at beluga.phys.uvic.ca Thu Oct 12 23:50:36 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 12 Oct 2017 20:50:36 -0700 (PDT) Subject: [cmake-developers] CMake-3.10.0-rc2 yields good comprehensive test results for PLplot Message-ID: I just completed a comprehensive test of PLplot on Linux (Debian Jessie) using a cmake version that I built myself from the CMake-3.10.0-rc2 source code using the bootstrap method. The result was a complete success for the three different PLplot build systems (CMake-based build systems for the core build and installed examples, and a CMake-configured traditional [Makefile + pkg-config] build system for the installed examples) and the 3 major PLplot build configurations (shared libraries/dynamic devices, shared libaries/nondynamic devices, and static libraries/nondynamic devices). So from the PLplot perspective, CMake-3.10.x is looking quite promising. For further details of this comprehensive test, see the "Tested by" stanza of the git log for PLplot commit 6906798 ). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From irwin at beluga.phys.uvic.ca Fri Oct 13 00:08:09 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 12 Oct 2017 21:08:09 -0700 (PDT) Subject: [cmake-developers] Need more information concerning the Trilinos test of CMake Message-ID: A PLplot configure, build, and test is an excellent indirect test of modern CMake because PLplot currently uses cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR) and has a relatively small and fast build but with a rather complex build system for its size that has been developed over the course of the last decade. Accordingly Bill Hoffman suggested to me off-list some time ago that I configure a CMake dashboard submission that builds the master HEAD CMake version and tests it with a build and test of PLplot similarly to what is done for Trilinos. But I am only getting around to this now, and all I can find in the CMake source code with regard to Trilinos is Tests/Contracts/Trilinos. Could someone here please confirm that code is a good model for what I should set up in the PLplot case? Assuming that is the case, and I modify my local CMake git repository to add the required files in Tests/Contracts/PLplot and build that modified CMake, how would I submit an Experimental CMake dashboard to test my work? Or more directly, how would I submit an Experimental CMake dashboard to test the existing Trilinos case? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From brad.king at kitware.com Fri Oct 13 14:53:21 2017 From: brad.king at kitware.com (Brad King) Date: Fri, 13 Oct 2017 14:53:21 -0400 Subject: [cmake-developers] CMake-3.10.0-rc2 yields good comprehensive test results for PLplot In-Reply-To: References: Message-ID: On 10/12/2017 11:50 PM, Alan W. Irwin wrote: > I just completed a comprehensive test of PLplot on Linux (Debian > Jessie) using a cmake version that I built myself from the > CMake-3.10.0-rc2 source code using the bootstrap method. The result > was a complete success Great, thanks for testing! -Brad From brad.king at kitware.com Fri Oct 13 14:58:00 2017 From: brad.king at kitware.com (Brad King) Date: Fri, 13 Oct 2017 14:58:00 -0400 Subject: [cmake-developers] Need more information concerning the Trilinos test of CMake In-Reply-To: References: Message-ID: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> On 10/13/2017 12:08 AM, Alan W. Irwin wrote: > Accordingly Bill Hoffman suggested to me off-list > some time ago that I configure a CMake dashboard submission that > builds the master HEAD CMake version and tests it with a build and > test of PLplot similarly to what is done for Trilinos. > > Could someone here please confirm that code is a good model for > what I should set up in the PLplot case? Yes, that makes sense. It will help catch regressions in PLplot early. The first step is to get a normal CMake nightly build working. See instructions here: https://gitlab.kitware.com/cmake/cmake/blob/master/Help/dev/testing.rst Once that is working we can look at adding a PLplot build as a contract test. It will work as a "normal" CMake test that is enabled by local configuration of the build. The test itself will drive a PLplot build internally. Thanks, -Brad From Robert.Goulet at autodesk.com Fri Oct 13 15:02:50 2017 From: Robert.Goulet at autodesk.com (Robert Goulet) Date: Fri, 13 Oct 2017 19:02:50 +0000 Subject: [cmake-developers] Debugging tests added with cmake command 'add_test' from Visual Studio? Message-ID: Hi, Is there an easy way to launch a debugging session from Visual Studio to a specific test that failed (which was added using cmake command 'add_test') using the exact same command-line arguments and working directory for the debugging settings that were used by RUN_TESTS? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Oct 19 15:40:11 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 19 Oct 2017 15:40:11 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.10.0-rc3 is now ready for testing Message-ID: I am proud to announce the third CMake 3.10 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.10 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.10/release/3.10.html Some of the more significant changes in CMake 3.10 are: * The flang Fortran compiler is now supported, with compiler id "Flang". * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * "FindMPI" received a major overhaul. It now features language specific components, better Fortran support, and support for statically linked MPI implementations. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module underwent numerous improvements. It has gained support for GLVND and EGL on Linux. It now has import targets that separate the OpenGL library and OpenGL contexts. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". CMake 3.10 Release Notes ************************ Changes made since CMake 3.9 include the following. New Features ============ Platforms --------- * The flang Fortran compiler is now supported, with compiler id "Flang". * A new minimal platform file for "Midipix" was added. * Support for the MSVC ARM64 architecture was added. Visual Studio 2017 Update 4 and above offer an ARM64 toolchain. * Support for the IAR ARM Compiler was improved. Generators ---------- * The Makefile Generators and the "Ninja" generator learned to add compiler launcher tools like ccache along with the compiler for the "CUDA" language ("C" and "CXX" were supported previously). See the "CMAKE__COMPILER_LAUNCHER" variable and "_COMPILER_LAUNCHER" target property for details. * The "CodeBlocks" extra generator learned to optionally exclude files from outside the project root directory from the generated project. See the "CMAKE_CODEBLOCKS_EXCLUDE_EXTERNAL_FILES" variable. Commands -------- * The "cmake_host_system_information()" command learned more keys to get information about the processor capabilities and the host OS version. * The "configure_file()" command learned to support indented "# cmakedefine" and "# cmakedefine01". Spaces and/or tabs between the "#" character and the "cmakedefine"/"cmakedefine01" words are now understood and preserved in the output. * The "execute_process()" command gained a "RESULTS_VARIABLE" option to collect a list of results from all children in a pipeline of processes when multiple "COMMAND" arguments are given. * The "include_guard()" command was introduced to allow guarding CMake scripts from being included more than once. The command supports "DIRECTORY" and "GLOBAL" options to adjust the corresponding include guard scope. If no options given, include guard is similar to basic variable-based check. * The "string()" command learned a new "PREPEND" subcommand. * The "string(TIMESTAMP)" command now supports "%A" for full weekday name and "%B" for full month name. Variables --------- * A "CMAKE_DIRECTORY_LABELS" variable was added to specify labels for all tests in a directory. Properties ---------- * A "_CPPCHECK" target property and supporting "CMAKE__CPPCHECK" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "cppcheck" with the compiler for "C" and "CXX" languages. * A "LABELS" directory property was added to specify labels for all targets and tests in a directory. * A "TEST_INCLUDE_FILES" directory property was added to list any number of files to be included when running tests with "ctest(1)". This generalizes the "TEST_INCLUDE_FILE" property. * The "VS_DOTNET_REFERENCEPROP__TAG_" target property was added to support custom XML tags for reference assemblies in C# targets. * Source file properties "VS_SHADER_OUTPUT_HEADER_FILE" and "VS_SHADER_VARIABLE_NAME" have been added to specify more details of ".hlsl" sources with Visual Studio Generators. Modules ------- * The "FindCurses" module gained a "CURSES_NEED_WIDE" option to request the wide-character variant. * The "FindEXPAT" module now provides imported targets. * The "FindFreetype" module now provides imported targets. * "FindMPI" gained a number of new features, including: * Language-specific components have been added to the module. * Many more MPI environments are now supported. * The environmental support for Fortran has been improved. * A user now has fine-grained control over the MPI selection process, including passing custom parameters to the MPI compiler. * The version of the implemented MPI standard is now being exposed. * MPI-2 C++ bindings can now be detected and also suppressed if so desired. * The available Fortran bindings are now being detected and verified. * Various MPI-3 information can be requested, including the library version and Fortran capabilities of the individual bindings. * Statically linked MPI implementations are supported. * A "FindOpenACC" module was added to detect compiler support for OpenACC. Currently only supports PGI, GNU and Cray compilers. * The "FindOpenGL" module gained support for GLVND on Linux. * The "FindOpenMP" module gained support for language-specific components. * A "FindPatch" module was added to find the "patch" command-line executable. * The "FindProtobuf" module "protobuf_generate_cpp()" command gained a "DESCRIPTORS" option to generate descriptor files. * The "GoogleTest" module gained a new command "gtest_discover_tests()" implementing dynamic (build-time) test discovery. Unlike the source parsing approach, dynamic discovery executes the test (in 'list available tests' mode) at build time to discover tests. This is robust against unusual ways of labeling tests, provides much better support for advanced features such as parameterized tests, and does not require re-running CMake to discover added or removed tests within a test executable. * The "InstallRequiredSystemLibraries" module gained support for installing Intel compiler runtimes. Autogen ------- * When using "AUTOMOC" or "AUTOUIC" with a multi configuration generator (e.g. "Xcode"), included "*.moc", "moc_*.cpp" and "ui_*.h" files are generated in "/include_" instead of "/include". * When using "AUTOMOC" or "AUTOUIC", source files that are "GENERATED" will be processed as well. They were ignored by "AUTOMOC" and "AUTOUIC" in earlier releases. See policy "CMP0071". * When using "AUTOMOC", CMake searches for the strings "Q_OBJECT", "Q_GADGET" or "Q_NAMESPACE" in a source file to determine if it needs to be "moc" processed. The new "CMAKE_AUTOMOC_MACRO_NAMES" variable and "AUTOMOC_MACRO_NAMES" target property may be set to register additional strings (macro names) to search for. * When using "AUTOMOC", the new "CMAKE_AUTOMOC_COMPILER_PREDEFINES" variable and "AUTOMOC_COMPILER_PREDEFINES" target property specify whether to enable or disable the generation of the compiler pre definitions file "moc_predefs.h". CTest ----- * A "CTEST_LABELS_FOR_SUBPROJECTS" CTest module variable and CTest script variable were added to specify a list of labels that should be treated as subprojects by CDash. To use this value in both the CTest module and the ctest command line Dashboard Client mode (e.g. "ctest -S") set it in the "CTestConfig.cmake" config file. CPack ----- * CPack gained a "FREEBSD" generator for FreeBSD "pkg(8)", configured by the "CPackFreeBSD" module. * The CPack "DEB" generator, configured by the "CPackDeb" module, was enabled on Windows. While not fully featured (due to the lack of external UNIX tools) this will allow building basic cross- platform Debian packages. * The "CPackDeb" module learned to set package release version in "Version" info property. See the "CPACK_DEBIAN_PACKAGE_RELEASE" variable. * The "CPackDeb" module learned more strict package version checking that complies with Debian rules. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "REPLACES" and "CHECKABLE" options. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_FILE_EXTENSION" variable to customize target binary format. * The "CPackIFW" module gained new "CPACK_IFW_REPOSITORIES_DIRECTORIES" variable to specify additional repositories dirs that will be used to resolve and repack dependent components. This feature is only available when using QtIFW 3.1 or later. * Modules "CPackRPM" and "CPackDeb" learned to set package epoch version. See "CPACK_RPM_PACKAGE_EPOCH" and "CPACK_DEBIAN_PACKAGE_EPOCH" variables. Other ----- * The "cmake(1)" "-E" mode gained support for "sha1sum", "sha224sum", "sha256sum", "sha384sum", and "sha512sum". * The graphviz output now distinguishes among the different dependency types "PUBLIC", "PRIVATE" and "INTERFACE" and represents them in the output graph as solid, dashed and dotted edges. Deprecated and Removed Features =============================== * Support for building CMake itself with C++98 compilers was dropped. CMake is now implemented using C++11. * Support for building CMake on HP-UX has been dropped pending better support for C++11 and a port of libuv. See CMake Issue 17137. Use CMake 3.9 or lower instead for HP-UX support. Other Changes ============= * On FreeBSD the C++ compiler named "c++" is now the preferred default. * The "file(GENERATE)" command now interprets relative paths given to its "OUTPUT" and "INPUT" arguments with respect to the caller's current binary and source directories, respectively. See policy "CMP0070". * The "get_filename_component()" "PROGRAM" mode semantics have been revised to not tolerate unquoted spaces in the path to the program while also accepting arguments. While technically incompatible with the old behavior, it is expected that behavior under typical use cases with properly-quoted command-lines has not changed. ---------------------------------------------------------------------------- Changes made since CMake 3.10.0-rc2: Brad King (7): Do not initialize NO_SYSTEM_FROM_IMPORTED on INTERFACE libraries Help: Clarify documentation of NO_SYSTEM_FROM_IMPORTED cmVSSetupHelper: Factor out install location string construction cmVSSetupHelper: Fix install location encoding conversion VS: Detect compiler component in VS 2017 instances more reliably VS: Set CUDA TargetMachinePlatform explicitly on x64 CMake 3.10.0-rc3 Christian Pfeiffer (1): FindOpenMP: Improve OMP libraries search From lectem at gmail.com Sat Oct 21 10:56:24 2017 From: lectem at gmail.com (Lectem) Date: Sat, 21 Oct 2017 16:56:24 +0200 Subject: [cmake-developers] Make it easier for beginners Message-ID: <59eb601a.648c500a.25a84.6b45@mx.google.com> Hi guys. You've probably seen me whining a bit here and there about why CMake is hard to get for begginers, and thanks to Ruslo pushing me to it, I finally got the motivation to be involved and contribute to CMake. I hope this mail can be the beginning of a thought on the CMake ecosystem, and not seen as a rant. I'd like to discuss a few issues and learning barriers I've heard in the previous years concerning CMake. Those problems were even more pointed out recently when Boost decided to switch to cmake. Most of the time, people will tell you stuff like this (note that I'm not inventing those, as most were told to me by co-workers) : - "it is too hard to know what I should do, or how to do it right" - "Many articles are out there, none agree on what to do and the documentation is just an API reference, not a real documentation" - "Based my CmakeLists.txt on the wiki, and now people tell me it's bad practice" - "I don't get why it's not finding my stuff, it's frustrating" - "I managed to get a simple program running, but as soon as tried to add more stuff, nothing was working or I didn't understand the docs" ... And the list goes on. >From my point of view, it mostly comes from a misconception of what CMake now is and the fact it is hard to learn. In a sense, it's basicly the same problem as C++. CMake can be easy, but is seen as hard by some people because it has many features and ways to express the same thing, and that many people write CMakeLists.txt that do not "embrace modern CMake". So I'd like to make it easier for these people to learn CMake, and for that I need some pointers and the opinion of the current developpers. I'll make this a list of questions / proposals on which I need feedback, and try to explain my reasons behind it. Question : Would it possible to delete the wiki, or reset/reopen it ? Reason: The wiki is full of old stuff, but we can't register to edit stuff. Still, people willing to learn will end up visiting it, thinking it gives good advice. "How could it not ? It's the official wiki". At the very least I wish we could add a big red message stating it is outdated and not updated anymore. Question: Would it be ok to add tutorials to the documentation ? Reason: That's where most people will start with. Diving in the CMake documentation is hard for beginners. For example, understanding transitive properties requires that you read most of cmake-buildsystem, which is a lot to digest at once. A tutorial would help people understanding how to use it and more importantly why they should use it. Question: Add examples (in link with the tutorials) ? Reason?: Mostly the same as the previous one, having examples can help people with a quickstart and agree on what is the "latest" command/feature to use for X/Y/Z. Question: Can we add "Added in / API last updated" fields ? I'm not familiar enough with Sphynx yet to know how we could change the template for this. Or perhaps just add it as text in the rst? Reason: It is hard to know in what version some functionalities are added, and not everybody can afford to require the latest CMake version (though it would be nice). It would be nice to have this at least for new features in the next version I hope that little by little we will make CMake easier to use for the community, and to this end I'm ready to spend time updating the documentation, errors and write some tutorials / examples. I truely believe that it is as important as releasing new features. My idea is mainly to slowly move/enhance stuff from CGold (https://cgold.readthedocs.io/en/latest/) in the official documentation, so that people can rely on it. (By that I mean that people will more easily trust the documentation than CGold if they are new to CMake) Lectem -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Sun Oct 22 15:08:48 2017 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Sun, 22 Oct 2017 15:08:48 -0400 Subject: [cmake-developers] Make it easier for beginners In-Reply-To: <59eb601a.648c500a.25a84.6b45@mx.google.com> References: <59eb601a.648c500a.25a84.6b45@mx.google.com> Message-ID: <2194adbe-b31f-f470-7d19-57cb671939f2@kitware.com> On 10/21/2017 10:56 AM, Lectem wrote: > _Question :_ Would it possible to delete the wiki, or reset/reopen it ? > > _Reason:_ The wiki is full of old stuff, but we can't register to edit > stuff. Still, people willing to learn will end up visiting it, thinking > it gives good advice. "How could it not ? It's the official wiki". At > the very least I wish we could add a big red message stating it is > outdated and not updated anymore. > The wiki is still open. If people want to edit they have to send an email and let us know what they want to do. It was too hard to keep the spam off of it otherwise. So, send me an email off list and I can get you setup with a wiki account. -Bill From sbv1976 at gmail.com Mon Oct 23 22:28:13 2017 From: sbv1976 at gmail.com (Steven Velez) Date: Mon, 23 Oct 2017 22:28:13 -0400 Subject: [cmake-developers] Extending XCode scheme generation support In-Reply-To: References: <07a32ef4-f830-23de-6e2f-d203cfb541ee@googlemail.com> Message-ID: Hi Gregor, I know you are probably busy with other things, but do you see anything in the discussion so far that should prevent an implementation attempt? I don't have a whole lot of time available to work on this either, so progress will probably be slow with me squeezing in work here and there, so I don't think there will be a review burden soon. Thanks, Steven On Sun, Oct 8, 2017 at 1:18 PM, Steven Velez wrote: > After spending some time trying to figure out how to affect the build > "destination", it seems that destinations associated with a given > scheme are not influenced by anything beyond the targets referenced as > build targets for the scheme. In other words, if a scheme builds an > iOS target, then the iOS destinations/devices/simulators will be > present in the UI, and if it references a MacOS target, then the > active computer will be available in the destinations UI. > > The options available in the scheme proper seem to be similar in > either case, and the proposal so far is fairly agnostic to specific > options, so I think the current proposal stands without modification > in this respect. Does this seem like a reasonable statement? > > This investigation did make me realize that each scheme can specify > building more than one target, so I would revise my statement that the > last target referencing a given scheme name should "win". Instead, I > think each target should be built by the given scheme, and the union > of settings provided by each target should be present in the scheme. > If multiple targets indicate a similar setting, then in this case, the > last setting should win, and this should print a warning... but if > order of processing the schemes/targets cannot match source order, > then perhaps it should be noted that what is "last" cannot be > guaranteed.... > > Thanks, > Steven > > > On Thu, Oct 5, 2017 at 9:26 AM, Steven Velez wrote: >> Thanks for the followup Gregor. >> >> One thing that concerns me about the property-centric approach is that >> I can't think of a way to use properties for generating a custom >> scheme that builds the ALL_BUILD target. I would assume this would >> run into the same issues and limitations that I have seen in google >> searches with trying to control the the folder for the ALL_BUILD >> target with the FOLDER target property (even though this would be a >> Visual Studio concern). It seems that is addressed now with the >> *_TARGETS_FOLDER global properties, so maybe an analog can be >> established? >> >> Regarding sequencing changes, do you mean to come up with a set of >> smaller logical changes/MRs so that this isn't all dumped at once? If >> so, I think we could implement XCODE_SCHEME_NAME and a single >> additional property without generator support, then add generator >> support, then add the balance of the properties one-by-one. Would >> that make sense? >> >> I have to get more familiar with CMake's testing methodologies to have >> any comment on that portion. >> >> If two targets specify the same schema name, then overwrite/accept >> latest with a warning? >> >> Regarding ios builds or perhaps having multiple build devices (I have >> seen some hand-made projects with 64-bit and 32-bit desktop clients >> selectable), then I will also have to get back to you on that. I was >> thinking the property definitions were generic enough to handle any >> needs... and I assumed that devices were handles with additional >> scheme files, but I realize that was a bad assumption. >> >> Will try to have that thought out soon. >> >> Thanks, >> Steven >> >> On Mon, Oct 2, 2017 at 9:05 AM, Gregor Jasny wrote: >>> Hello Steven, >>> >>> On 9/22/17 3:36 AM, Steven Velez wrote: >>>> # Property-Centric >>>> In this proposal, the generation of the scheme files is customized primarily by >>>> a user setting additional, specialized properties on a given target, which then >>>> affect the generation of the scheme files associated with that target. >>> thank you for working an the scheme proposal. I also believe that the >>> property-centric approach is better suited and easier to implement than >>> the file-centrix one. >>> >>> Next steps would be to sequence the necessary changes and define test >>> cases. I could imagine that adding generator-expression support would be >>> much harder to implement that other things. >>> >>> Things that also should be considered are: >>> * differences between macOS and iOS when generating a scheme >>> * what should happen if two targets specify the same schema name >>> >>> Thanks, >>> Gregor From irwin at beluga.phys.uvic.ca Tue Oct 24 17:10:04 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 24 Oct 2017 14:10:04 -0700 (PDT) Subject: [cmake-developers] Need more information concerning the Trilinos test of CMake In-Reply-To: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> Message-ID: On 2017-10-13 14:58-0400 Brad King wrote: > On 10/13/2017 12:08 AM, Alan W. Irwin wrote: >> Accordingly Bill Hoffman suggested to me off-list >> some time ago that I configure a CMake dashboard submission that >> builds the master HEAD CMake version and tests it with a build and >> test of PLplot similarly to what is done for Trilinos. >> >> Could someone here please confirm that code is a good model for >> what I should set up in the PLplot case? > > Yes, that makes sense. It will help catch regressions in PLplot early. > The first step is to get a normal CMake nightly build working. > See instructions here: > > https://gitlab.kitware.com/cmake/cmake/blob/master/Help/dev/testing.rst > Hi Brad: Thanks for your reply to my question. I have just now started looking at the above instructions. It appears cmake_common.cmake only provides the capability of changing the --parallel option for the bootstrap script. Must I change that script in order to specify additional bootstrap options I normally use such as --qt-gui --system-curl or is there a less brute-force way to specify bootstrap options? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From irwin at beluga.phys.uvic.ca Tue Oct 24 17:47:10 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 24 Oct 2017 14:47:10 -0700 (PDT) Subject: [cmake-developers] Need more information concerning the Trilinos test of CMake In-Reply-To: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> Message-ID: Hi Brad: While waiting for your reply to my question concerning how to specify bootstrap script options, I decided to not specify those additional options for my initial try. I submitted that (Experimental) test by hand using ctest -S -V >& ctest.out1. The result (which was a build error) is given at . Since I essentially never get CMake build errors when building CMake by hand using the bootstrap method, I assume these build errors are due to some issue with how I set up my_dashboard.cmake. Here is the full text of that file: ________________ # Client maintainer: airwin at users.sourceforge.net set(CTEST_SITE "raven home computer") set(CTEST_BUILD_NAME "Linux-gcc") #set(CTEST_BUILD_CONFIGURATION Debug) set(CTEST_CMAKE_GENERATOR "Unix Makefiles") # Additional variables to set before include: set(dashboard_model Experimental) set(CTEST_BUILD_FLAGS -j4) include(${CTEST_SCRIPT_DIRECTORY}/cmake_common.cmake) ________________ The above -V results from ctest had very little detail about the build error. If you don't see anything obvious I should change in my_dashboard.cmake, would you like me to run ctest -S again with -VV? For what it is worth, another difference with how I normally build cmake is I specified (by accident) the environment variables CXXFLAGS=-O3 -fvisibility=hidden -Wuninitialized CFLAGS=-O3 -fvisibility=hidden -Wuninitialized for this build while for my normal builds I just use -O3 for both flags. Also, as you can see above I did not specify CTEST_BUILD_CONFIGURATION, but unlike normal builds it appears for this script that the Debug configuration is the default. How do I turn that off? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From irwin at beluga.phys.uvic.ca Tue Oct 24 20:24:04 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 24 Oct 2017 17:24:04 -0700 (PDT) Subject: [cmake-developers] Need more information concerning the Trilinos test of CMake In-Reply-To: References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> Message-ID: @Matthias: I am directly addressing you in this post because git bisect says your recent commit is the first one that shows this issue. More details below. On 2017-10-24 14:47-0700 Alan W. Irwin wrote: > Hi Brad: > > While waiting for your reply to my question concerning how to specify > bootstrap script options, I decided to not specify those additional > options for my initial try. I submitted that (Experimental) test by hand > using > > ctest -S -V >& ctest.out1. > > The result (which was a build error) is given at > . > > Since I essentially never get CMake build errors when building > CMake by hand using the bootstrap method, I assume these build > errors are due to some issue with how I set up my_dashboard.cmake. > > Here is the full text of that file: > > ________________ > # Client maintainer: airwin at users.sourceforge.net > set(CTEST_SITE "raven home computer") > set(CTEST_BUILD_NAME "Linux-gcc") > #set(CTEST_BUILD_CONFIGURATION Debug) > set(CTEST_CMAKE_GENERATOR "Unix Makefiles") > > # Additional variables to set before include: > set(dashboard_model Experimental) > set(CTEST_BUILD_FLAGS -j4) > > include(${CTEST_SCRIPT_DIRECTORY}/cmake_common.cmake) > ________________ > > The above -V results from ctest had very little detail about the > build error. If you don't see anything obvious I should change in > my_dashboard.cmake, would you like me to run ctest -S again with > -VV? > > For what it is worth, another difference with how I normally build > cmake is I specified (by accident) the environment variables > > CXXFLAGS=-O3 -fvisibility=hidden -Wuninitialized > CFLAGS=-O3 -fvisibility=hidden -Wuninitialized > > for this build while for my normal builds I just use -O3 for both flags. > > Also, as you can see above I did not specify > CTEST_BUILD_CONFIGURATION, but unlike normal builds it appears for > this script that the Debug configuration is the default. How do I > turn that off? Here is some critical information concerning this build issue that I have gained since the above post: The version of cmake source that generated the build error for me was commit 8c5050835 from the (current) HEAD of stage/master/head Running the bootstrap script for that version by hand lead to exactly the same "array used as initializer" errors as in my dashboard submission. Doing the same thing for v3.10.0-rc3 did not show that build error. git bisecting between those two commits found commit 49287eed2bf9860919a155af848e7cf49d45f504 Author: Matthias Maennich Date: Mon Oct 9 16:25:52 2017 +0200 CommandArgumentParser: avoid strcpy usage as the first commit that had the bootstrap issue. Note the rest of the results at appear to have no build errors like the ones demonstrated on my (Debian Jessie) system which is why I mentioned my g++ version above. @Brad and Matthias: If there is any further test you would like me to run concerning this build issue, please let me know. Returning to the original topic, I assume once this CMake build issue is addressed, that my dashboard submission will start working but I am still interested in the answers to my questions concerning how to specify boostrap options, and how to turn off Debug builds via my_dashboard.cmake. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From irwin at beluga.phys.uvic.ca Tue Oct 24 22:23:15 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 24 Oct 2017 19:23:15 -0700 (PDT) Subject: [cmake-developers] Need more information concerning the Trilinos test of CMake In-Reply-To: References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> Message-ID: On 2017-10-24 17:24-0700 Alan W. Irwin wrote: > Note the rest of the results at > appear to have no > build errors like the ones demonstrated on my (Debian Jessie) system > which is why I mentioned my g++ version above. Oops. I forgot to include that information so for the record that is g++ (Debian 4.9.2-10). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From eike at sf-mail.de Wed Oct 25 04:46:36 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 25 Oct 2017 10:46:36 +0200 Subject: [cmake-developers] Need more information concerning the Trilinos test of CMake In-Reply-To: References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> Message-ID: <1b96e876a47e470844c4ffc748dc43e8@sf-mail.de> Am 2017-10-25 02:24, schrieb Alan W. Irwin: > @Matthias: > > I am directly addressing you in this post because git bisect says your > recent commit is the first one that shows this issue. More details > below. > commit 49287eed2bf9860919a155af848e7cf49d45f504 > Author: Matthias Maennich > Date: Mon Oct 9 16:25:52 2017 +0200 > > CommandArgumentParser: avoid strcpy usage > > as the first commit that had the bootstrap issue. This very much looks like a change I had in a few weeks ago but removed from there because of exactly those compile failures. This works fine with newer gcc and apparently Clang versions, but older compilers do not like it. Looking on that code again: I don't think it is needed to have anything of that in the class. Just make this file static variables: static const char EmptyVariable[] = ""; static char DCURLYVariable[3] = "${"; and then drop those members from the class entirely. Maybe make them static variables in the class and initialize them in the cxx file if it is needed to have them in the class. But I don't see no reason to have them as writable, instance specific class members as those values will never change. Eike From brad.king at kitware.com Wed Oct 25 06:55:35 2017 From: brad.king at kitware.com (Brad King) Date: Wed, 25 Oct 2017 06:55:35 -0400 Subject: [cmake-developers] Need more information concerning the Trilinos test of CMake In-Reply-To: <1b96e876a47e470844c4ffc748dc43e8@sf-mail.de> References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> <1b96e876a47e470844c4ffc748dc43e8@sf-mail.de> Message-ID: <16de722c-6dd6-05bb-039a-ac26d26480c3@kitware.com> On 10/25/2017 04:46 AM, Rolf Eike Beer wrote: > This very much looks like a change I had in a few weeks ago but removed > from there because of exactly those compile failures. This is all under discussion here: https://gitlab.kitware.com/cmake/cmake/merge_requests/1402 The errors this time are slightly different but due to similar limitations on older compilers. > Just make this file static variables Good idea, thanks. -Brad From brad.king at kitware.com Wed Oct 25 06:56:29 2017 From: brad.king at kitware.com (Brad King) Date: Wed, 25 Oct 2017 06:56:29 -0400 Subject: [cmake-developers] Need more information concerning the Trilinos test of CMake In-Reply-To: References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> Message-ID: <82e90c38-d2d0-397d-c4fa-d0405d1cf3bc@kitware.com> On 10/24/2017 05:10 PM, Alan W. Irwin wrote: > It appears cmake_common.cmake only provides the capability of changing > the --parallel option for the bootstrap script. Must I change that > script in order to specify additional bootstrap options I normally use > such as --qt-gui --system-curl or is there a less brute-force > way to specify bootstrap options? Use the `dashboard_cache` option to initialize the cache with the desired options rather than having the bootstrap script do it. -Brad From brad.king at kitware.com Wed Oct 25 07:03:42 2017 From: brad.king at kitware.com (Brad King) Date: Wed, 25 Oct 2017 07:03:42 -0400 Subject: [cmake-developers] Need more information concerning the Trilinos test of CMake In-Reply-To: References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> Message-ID: <7f526ace-264e-3e8a-85d5-b5221b294a79@kitware.com> On 10/24/2017 05:47 PM, Alan W. Irwin wrote: > Since I essentially never get CMake build errors when building > CMake by hand using the bootstrap method, I assume these build > errors are due to some issue with how I set up my_dashboard.cmake. The difference is that the script is testing the nightly stage of in-flight topics that have not yet landed in `master`. You just happened to run this for the first time on one of the occasional nights that compiler errors were introduced. > set(CTEST_SITE "raven home computer") Please use a name with no spaces. > Also, as you can see above I did not specify > CTEST_BUILD_CONFIGURATION, but unlike normal builds it appears for > this script that the Debug configuration is the default. How do I > turn that off? What configuration do you want to build? Just set(CTEST_BUILD_CONFIGURATION Release) will build the Release config. -Brad From irwin at beluga.phys.uvic.ca Wed Oct 25 15:43:24 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 25 Oct 2017 12:43:24 -0700 (PDT) Subject: [cmake-developers] Need more information concerning the Trilinos test of CMake In-Reply-To: <7f526ace-264e-3e8a-85d5-b5221b294a79@kitware.com> References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> <7f526ace-264e-3e8a-85d5-b5221b294a79@kitware.com> Message-ID: On 2017-10-25 07:03-0400 Brad King wrote: > On 10/24/2017 05:47 PM, Alan W. Irwin wrote: >> Since I essentially never get CMake build errors when building >> CMake by hand using the bootstrap method, I assume these build >> errors are due to some issue with how I set up my_dashboard.cmake. > > The difference is that the script is testing the nightly stage of > in-flight topics that have not yet landed in `master`. You just > happened to run this for the first time on one of the occasional > nights that compiler errors were introduced. Hi Brad: Yes, I sure picked the exact moment of the day where my dashboard was the first to show the build error for g++ versions of 4.9 or less, but, of course, a number of other old compiler sites followed at the times when they completed their nightly tests. I notice in there is an unstage comment from you. Just out of curiosity, does that mean that commit was effectively immediately removed from stage/master/head? In any case, my dashboard submission is working now using ctest -S ~/cmake/Dashboards/Scripts/CMakeScripts/my_dashboard.cmake -VV See the raven-without-fixed-IP Experimental results at and . These results are perfect other than one CMake configure warning due to a minor system issue (misspelled COPYONLY as COPY_ONLY) with Debian Jessie Qt5 which I encounter for all my builds of cmake by hand and which has long since been fixed for more modern versions of Qt5. So what is the next step toward the goal of adding a test consisting of a build of PLplot? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From eike at sf-mail.de Wed Oct 25 17:28:07 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 25 Oct 2017 23:28:07 +0200 Subject: [cmake-developers] Need more information concerning the Trilinos test of CMake In-Reply-To: References: <7f526ace-264e-3e8a-85d5-b5221b294a79@kitware.com> Message-ID: <35933043.jfg1BPMHvk@daneel.sf-tec.de> > I notice in > there is > an unstage comment from you. Just out of curiosity, does that mean > that commit was effectively immediately removed from > stage/master/head? Yes. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From wesley.hoke at gmail.com Wed Oct 25 19:49:10 2017 From: wesley.hoke at gmail.com (Wesley Smith) Date: Wed, 25 Oct 2017 16:49:10 -0700 Subject: [cmake-developers] Make it easier for beginners In-Reply-To: <2194adbe-b31f-f470-7d19-57cb671939f2@kitware.com> References: <59eb601a.648c500a.25a84.6b45@mx.google.com> <2194adbe-b31f-f470-7d19-57cb671939f2@kitware.com> Message-ID: I agree that if you do a search for how to setup a project with cmake, it's hard to know what's best practice. As cmake has evolved, the best practice has changed and many old style techniques still return toward the top of search results. For me, the best resources have been: http://preshing.com/20170522/learn-cmakes-scripting-language-in-15-minutes/ https://www.youtube.com/watch?v=bsXLMQ6WgIk I still don't understand the scoped syntax in Daniel Pfeifer's talk (e.g. boost::boost). And CPack was really opaque to me until I bought the cmake book. I wish there were better tutorials on CPack and on how to write cmake scripts that play well as dependencies on other projects using cmake. wes On Sun, Oct 22, 2017 at 12:08 PM, Bill Hoffman wrote: > On 10/21/2017 10:56 AM, Lectem wrote: > >> _Question :_ Would it possible to delete the wiki, or reset/reopen it ? >> >> _Reason:_ The wiki is full of old stuff, but we can't register to edit >> stuff. Still, people willing to learn will end up visiting it, thinking it >> gives good advice. "How could it not ? It's the official wiki". At the very >> least I wish we could add a big red message stating it is outdated and not >> updated anymore. >> >> The wiki is still open. If people want to edit they have to send an > email and let us know what they want to do. It was too hard to keep the > spam off of it otherwise. So, send me an email off list and I can get you > setup with a wiki account. > > -Bill > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndevenish at gmail.com Thu Oct 26 04:46:20 2017 From: ndevenish at gmail.com (Nicholas Devenish) Date: Thu, 26 Oct 2017 09:46:20 +0100 Subject: [cmake-developers] Make it easier for beginners In-Reply-To: References: <59eb601a.648c500a.25a84.6b45@mx.google.com> <2194adbe-b31f-f470-7d19-57cb671939f2@kitware.com> Message-ID: On Thu, Oct 26, 2017 at 12:49 AM, Wesley Smith wrote: > I still don't understand the scoped syntax in Daniel Pfeifer's talk (e.g. > boost::boost) > Easy: It doesn't mean anything special, it's almost entirely just a name (think of :: as any other character). The advantage is, a) bookkeeping e.g. cleanly namespacing stuff (which admittedly could be done with _/prefixes) and more importantly b) If you give an undefined name e.g. "boost_notalib" (or something mis-spelled) to target_link_libraries it'll just add "-lboost_notalib" to the link command - because it doesn't know if it's a custom library that it doesn't know about, or an undefined target. A name like "Boost::NotALib" can never be a library name, so if it's not a defined target you'll get an error at configuration time rather than build time. (Caveat: I am not an expert so could be completely wrong in incomplete or subtle ways, but this is definitely one way it makes a difference) Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Thu Oct 26 08:36:58 2017 From: brad.king at kitware.com (Brad King) Date: Thu, 26 Oct 2017 08:36:58 -0400 Subject: [cmake-developers] PLplot contract test In-Reply-To: References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> <7f526ace-264e-3e8a-85d5-b5221b294a79@kitware.com> Message-ID: <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> On 10/25/2017 03:43 PM, Alan W. Irwin wrote: > In any case, my dashboard submission is working now using > > ctest -S ~/cmake/Dashboards/Scripts/CMakeScripts/my_dashboard.cmake -VV Great! > See the raven-without-fixed-IP The `-without-fixed-IP` suffix has no meaning to readers on CDash. > perfect other than one CMake configure warning due to a minor system > issue (misspelled COPYONLY as COPY_ONLY) with Debian Jessie Qt5 which We cannot let that warning persist on the dashboard because it may distract from other real warnings that show up. You could try dropping `BUILD_QtDialog:BOOL=1` to avoid it. You won't need cmake-gui built to test PLplot, and we have plenty of other builders that cover it. Once an experimental submission is clean, please switch the model to Nightly and schedule a cron job to run it sometime after 1:15am UTC. > So what is the next step toward the goal of adding a test consisting > of a build of PLplot? We need to add a contract test to CMake's source so that one of the tests that your nightly build runs is an entire build of PLplot. What is your official Git repository URL? -Brad From irwin at beluga.phys.uvic.ca Thu Oct 26 11:53:37 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 26 Oct 2017 08:53:37 -0700 (PDT) Subject: [cmake-developers] PLplot contract test In-Reply-To: <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> <7f526ace-264e-3e8a-85d5-b5221b294a79@kitware.com> <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> Message-ID: On 2017-10-26 08:36-0400 Brad King wrote: > Once an experimental submission is clean, please switch the model to > Nightly and schedule a cron job to run it sometime after 1:15am UTC. Will do. > >> So what is the next step toward the goal of adding a test consisting >> of a build of PLplot? > > We need to add a contract test to CMake's source so that one of the > tests that your nightly build runs is an entire build of PLplot. > What is your official Git repository URL? git://git.code.sf.net/p/plplot/plplot Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From brad.king at kitware.com Thu Oct 26 13:10:37 2017 From: brad.king at kitware.com (Brad King) Date: Thu, 26 Oct 2017 13:10:37 -0400 Subject: [cmake-developers] PLplot contract test In-Reply-To: References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> <7f526ace-264e-3e8a-85d5-b5221b294a79@kitware.com> <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> Message-ID: <89836f65-79ec-7457-db25-114e3b383b71@kitware.com> On 10/26/2017 11:53 AM, Alan W. Irwin wrote: > git://git.code.sf.net/p/plplot/plplot Thanks. I'll take a look at adding a test to build that when I get a chance. -Brad From irwin at beluga.phys.uvic.ca Thu Oct 26 21:58:17 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 26 Oct 2017 18:58:17 -0700 (PDT) Subject: [cmake-developers] PLplot contract test In-Reply-To: <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> <7f526ace-264e-3e8a-85d5-b5221b294a79@kitware.com> <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> Message-ID: Hi Brad: While trying to set up a clean Experimental dashboard, I have noticed a minor spelling issue (furhter ==> further in a comment in cmake_common.cmake). I also noticed a somewhat more serious issue concerning the consistency of build flags. I attempted to use consistent compile flags as follows: set(ENV{CXXFLAGS} "-O3 -DNDEBUG") set(ENV{CFLAGS} "-O3 -DNDEBUG") set(CTEST_BUILD_CONFIGURATION None) This "first" method apparently did generate consistent build flags, but the complex, complexOneConfig, Preprocess, and Qt4Deploy tests failed (see the first Experimental "raven" results on 2017-10-26 for commit fc3668). A similar test with None replaced above by Release (call this the "second" method) was headed to a similar failure (I noticed Preprocess had failed and quit the test before it encountered the other 3 failures and before a dashboard was submitted). So I fell back to using a "third" method which was unset(ENV{CXXFLAGS}) unset(ENV{CFLAGS}) # Just in case any of the Fortran tests pay attention to FFLAGS which # I often set. unset(ENV{FFLAGS}) set(CTEST_BUILD_CONFIGURATION Release) That gave a completely clean result (see the second Experimental "raven" results on 2017-10-26 for commit fc3668). I also followed up with a Nightly raven result (generated by crontab). That also gave a perfectly clean result (see the first Nightly "raven" results on 2017-10-26 for commit da363e). So it looks like I am basically in business (except for the PLplot build part of the test that you plan to work on as time permits). However, one of the deficiencies of this third method is the bootstrap script only pays attention to CXXFLAGS and CFLAGS when setting compile flags for building the preliminary version of CMake so that build is unoptimized in this case which will significantly add to the time taken to configure the build of the full version of CMake (although that time is likely negligible compared to the time required to pass all the 500 tests). If you know of a simple way to fix this inconsistency between the compile flags used to build the preliminary and final versions of CMake, please let me know. I thought the first method I tried above would do exactly that (since the adopted CXXFLAGS and CFLAGS should give you exactly the same as "Release" on Linux, but that method also causes those four test failures for unknown reasons. So if you feel the first method should be supported, then the solution of this issue would be to debug whatever is wrong on the CMake end for those 4 test failures. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From brad.king at kitware.com Fri Oct 27 07:02:13 2017 From: brad.king at kitware.com (Brad King) Date: Fri, 27 Oct 2017 07:02:13 -0400 Subject: [cmake-developers] PLplot contract test In-Reply-To: References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> <7f526ace-264e-3e8a-85d5-b5221b294a79@kitware.com> <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> Message-ID: On 10/26/2017 09:58 PM, Alan W. Irwin wrote: > While trying to set up a clean Experimental dashboard, I have noticed > a minor spelling issue (furhter ==> further in > a comment in cmake_common.cmake). Fixed, thanks. > unset(ENV{CXXFLAGS}) > unset(ENV{CFLAGS}) > unset(ENV{FFLAGS}) > set(CTEST_BUILD_CONFIGURATION Release) This is the intended way for dashboard scripts. > That gave a completely clean result (see the second Experimental > "raven" results on 2017-10-26 for commit fc3668). I also followed up > with a Nightly raven result (generated by crontab). That also gave a > perfectly clean result (see the first Nightly "raven" results on > 2017-10-26 for commit da363e). So it looks like I am basically in > business (except for the PLplot build part of the test that you > plan to work on as time permits). Great! > However, one of the deficiencies of this third method is the > bootstrap script only pays attention to CXXFLAGS and CFLAGS when > setting compile flags for building the preliminary version of CMake so > that build is unoptimized in this case which will significantly add to > the time taken to configure the build of the full version of CMake I doubt it would make much difference. Most of the configuration time is spent waiting for try_compile to complete and such, though I've never timed it. You could do this to apply flags to bootstrap and configuration steps but not to the tests: ``` set(ENV{CXXFLAGS} "-O3 -DNDEBUG") set(ENV{CFLAGS} "-O3 -DNDEBUG") set(CTEST_BUILD_CONFIGURATION "") macro(dashboard_hook_build) unset(ENV{CXXFLAGS}) unset(ENV{CFLAGS}) endmacro() ``` > debug whatever is wrong on the CMake end for those 4 test failures. That would be nice if anyone has time. However, I think at least some of them may be testing per-config behavior, so by adding `-DNDEBUG` to the all-config flags they get confused. -Brad From irwin at beluga.phys.uvic.ca Fri Oct 27 12:36:35 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 27 Oct 2017 09:36:35 -0700 (PDT) Subject: [cmake-developers] PLplot contract test In-Reply-To: References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> <7f526ace-264e-3e8a-85d5-b5221b294a79@kitware.com> <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> Message-ID: On 2017-10-27 07:02-0400 Brad King wrote: > On 10/26/2017 09:58 PM, Alan W. Irwin wrote: >> However, one of the deficiencies of this third method is the >> bootstrap script only pays attention to CXXFLAGS and CFLAGS when >> setting compile flags for building the preliminary version of CMake [...] > You could do this to apply flags to bootstrap and configuration > steps but not to the tests: > > ``` > set(ENV{CXXFLAGS} "-O3 -DNDEBUG") > set(ENV{CFLAGS} "-O3 -DNDEBUG") > set(CTEST_BUILD_CONFIGURATION "") > macro(dashboard_hook_build) > unset(ENV{CXXFLAGS}) > unset(ENV{CFLAGS}) > endmacro() > ``` Thanks for that idea which I have adopted (using set(CTEST_BUILD_CONFIGURATION "Release")). It generates perfect dashboards (see the Experimental raven result for today). Should at least some of these considerations concerning CXXFLAGS and CFLAGS (e.g., they normally should be unset to assure a standard build configuration corresponding to CTEST_BUILD_CONFIGURATION) be documented in comments in cmake_common.cmake? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From brad.king at kitware.com Mon Oct 30 11:38:01 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 30 Oct 2017 11:38:01 -0400 Subject: [cmake-developers] PLplot contract test In-Reply-To: <89836f65-79ec-7457-db25-114e3b383b71@kitware.com> References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> <7f526ace-264e-3e8a-85d5-b5221b294a79@kitware.com> <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> <89836f65-79ec-7457-db25-114e3b383b71@kitware.com> Message-ID: <94308752-9c9e-fa9a-ad28-8d79ce1647ea@kitware.com> On 10/26/2017 01:10 PM, Brad King wrote: > Thanks. I'll take a look at adding a test to build that when I get > a chance. FYI I'm refactoring the way the existing contract tests work to make it easier to add and maintain one for PLplot. Once that is done I'll look at actually adding PLplot and report back here. -Brad From irwin at beluga.phys.uvic.ca Mon Oct 30 12:54:29 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 30 Oct 2017 09:54:29 -0700 (PDT) Subject: [cmake-developers] PLplot contract test In-Reply-To: References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> <7f526ace-264e-3e8a-85d5-b5221b294a79@kitware.com> <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> Message-ID: Hi Brad: If you look at it superficially appears that some of the tests (e.g., BootstrapTest) are timing out. But if you look deeper, the output from the test is being truncated because it is over the rather small 1024 default limit. I have checked the aaargh.kitware.com dashboard, and the BootstrapTest results for that case do not show this issue, i.e., they are quite large and clearly beyond the 1024 default limit so I suspect what has occurred for aaargh.kitware.com is this problem has been corrected on an individual basis. Could I do that for the raven results by, e.g., set(CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE 10240) set(CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE 10240) in my my_dashboard.cmake file or is the fix for this truncation issue more complex than that? In any case I suggest it would be better for you to implement the fix for this issue in cmake_common.cmake so those who submit CMake dashboards don't have to fix this issue individually. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From brad.king at kitware.com Tue Oct 31 07:02:38 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 31 Oct 2017 07:02:38 -0400 Subject: [cmake-developers] PLplot contract test In-Reply-To: References: <0fc52110-c242-0ceb-494d-8f4c559c0766@kitware.com> <7f526ace-264e-3e8a-85d5-b5221b294a79@kitware.com> <0e3135a8-1225-8770-c781-117fa7d6aa43@kitware.com> Message-ID: On 10/30/2017 12:54 PM, Alan W. Irwin wrote: > superficially appears that some of the tests are timing out. No, they are passing. The time status column is for trying to detect tests that suddenly jump in time required. It's based on some kind of model of the time that takes a while for CDash to stabilize. > the output from the test is being truncated because > it is over the rather small 1024 default limit. This is done for passing tests to reduce the amount uploaded. -Brad