From damir_porobic at live.com Sat Sep 1 07:05:43 2018 From: damir_porobic at live.com (Damir Porobic) Date: Sat, 1 Sep 2018 11:05:43 +0000 Subject: [CMake] Problem with creating shared library In-Reply-To: References: , , , Message-ID: Any idea how I could fix the last issue in my shared library? Cmake seems to expect a file with version in its name (/usr/local/lib64/libkImageAnnotator.so.0.0.1) but my cmake for the shared library only creates a file without version in it's name (/usr/local/lib64/libkImageAnnotator.so) Manually creating a link seems to fix the issue, but I guess there is a way to let cmake generate it. Any idea? ________________________________ From: Damir Porobic Sent: Sunday, August 26, 2018 13:50 To: Sebasti?n Mancilla Cc: cmake at cmake.org Subject: Re: [CMake] Problem with creating shared library Ok, I've found the issue for the latest problem but I'm not sure how to fix it in the CMake file. The make was using an old version of /usr/local/lib64/libkImageAnnotator.so.0.0.1 so I removed everything with kImageAnnotato in its name from this directory and run again the sudo make install which gave me this output -- Install configuration: "Debug" -- Up-to-date: /usr/local/lib64/cmake/kImageAnnotator/kImageAnnotator-config.cmake -- Up-to-date: /usr/local/lib64/cmake/kImageAnnotator/kImageAnnotator-config-version.cmake -- Up-to-date: /usr/local/lib64/cmake/kImageAnnotator/kImageAnnotator-targets.cmake -- Up-to-date: /usr/local/lib64/cmake/kImageAnnotator/kImageAnnotator-targets-debug.cmake -- Installing: /usr/local/lib64/libkImageAnnotator.so -- Set runtime path of "/usr/local/lib64/libkImageAnnotator.so" to "/usr/local/lib64" -- Up-to-date: /usr/local/include/kImageAnnotator -- Up-to-date: /usr/local/include/kImageAnnotator/KImageAnnotator.h -- Up-to-date: /usr/local/include/kImageAnnotator/KImageAnnotatorExport.h So only libkImageAnnotator.so is created and installed, but not the one with the version at the end which cmake seems to expect: in my test project CMake Error at /usr/local/share/kImageAnnotatorConfig/cmake/kImageAnnotatorConfig.cmake:79 (message): The imported target "kImageAnnotator" references the file "/usr/local/lib64/libkImageAnnotator.so.0.0.1" but this file does not exist. When I manually create a link to the installed file: $ sudo ln -s /usr/local/lib64/libkImageAnnotator.so /usr/local/lib64/libkImageAnnotator.so.0.0.1 Everything finally works, but I need to fix this final issue with the missing link. This was working earlier I think. ________________________________ From: Damir Porobic Sent: Friday, August 24, 2018 9:37:30 PM To: Sebasti?n Mancilla Cc: cmake at cmake.org Subject: Re: [CMake] Problem with creating shared library I've fixed both issues, the second by implementing the pimpl idiom but still I can't used the library in the other project, again I get the error with undefined reference to the constructor (and a method that I've added): [ 75%] Linking CXX executable testApp CMakeFiles/testApp.dir/main.cpp.o: In function `main': /home/dporobic/projects/testApp/main.cpp:9: undefined reference to `KImageAnnotator::KImageAnnotator(QPixmap const&)' /home/dporobic/projects/testApp/main.cpp:11: undefined reference to `KImageAnnotator::testMethod()' collect2: error: ld returned 1 exit status But the constructor and the method don't seem to be private anymore: dporobic at linux ~/projects/kImageAnnotator/build (sharedLibTestBranch) $ nm -g lib/libkImageAnnotator.so | c++filt | grep "::testMethod\|::KImage" 0000000000014f08 T KImageAnnotator::testMethod() 0000000000014b18 T KImageAnnotator::KImageAnnotator(QPixmap const&) 0000000000014b18 T KImageAnnotator::KImageAnnotator(QPixmap const&) Also, after the constructor call and before the call to the test method in my test project, there is a call to an inherited method (show()) from QWidget and the linker is not complaining about this one: auto kImageAnnotator = new KImageAnnotator(pixmap); kImageAnnotator->show(); kImageAnnotator->testMethod(); ________________________________ From: Sebasti?n Mancilla Sent: Thursday, August 23, 2018 22:13 To: Damir Porobic Cc: cmake at cmake.org Subject: Re: [CMake] Problem with creating shared library I forgot to update the include path in the patch I sent you. It should be like this (note that it contains just "include", not "include/kImageAnnotator"): target_include_directories(kImageAnnotator PUBLIC $ $ $ ) And kImageAnnotator.h should change the export include to: #include "kImageAnnotatorExport.h" You still have a bigger problem, though. kImageAnnotator.h is including private headers #include "../../src/gui/VisibilitySwitcher.h" #include "../../src/annotations/core/AnnotationArea.h" #include "../../src/backend/Config.h" #include "../../src/widgets/ToolPicker.h" #include "../../src/widgets/ColorPicker.h" #include "../../src/widgets/SizePicker.h" #include "../../src/widgets/FillPicker.h" If those are required by your clients, then they should be in the "include/kImageAnnotator" directory and installed along with "kImageAnnotator.h". Otherwise, consider using the pimpl idiom and remove the includes from the public header. El mi?., 22 de ago. de 2018 a la(s) 17:08, Damir Porobic (damir_porobic at live.com) escribi?: Thanks you Sebasti?n for finding the issue and fixing the CMake, probably would have never found out that it was set to private. The kImageAnnotator-example is working now as expected. Do I need something else, except installing the lib, in order to use it in different projects? I've created a second project which is identical to the kImageAnnotator-example but I get following when I try to build it: [ 50%] Building CXX object CMakeFiles/testApp.dir/main.cpp.o In file included from /home/dporobic/projects/testApp/main.cpp:2:0: /usr/local/include/kImageAnnotator/KImageAnnotator.h:31:35: fatal error: KImageAnnotatorExport.h: No such file or directory #include ^ compilation terminated. The includes look like this: #include #include And the CMake looks like this: find_package(kImageAnnotator REQUIRED) add_executable(testApp main.cpp) target_link_libraries(testApp kImageAnnotator) Am I missing something again? ________________________________ From: Sebasti?n Mancilla > Sent: Wednesday, August 22, 2018 00:51 To: Eric Noulard Cc: Damir Porobic; cmake at cmake.org Subject: Re: [CMake] Problem with creating shared library I fixed your problem. Get the attached patch and apply it with "git apply ". The kImageAnnotator constructor was private to the library (I just learned that Qt does that when creating shared libraries), and that's why you get the undefined reference error. You could have checked it with: nm lib/libkImageAnnotator.so | c++filt | grep ::KImage 00000000000141f6 t KImageAnnotator::KImageAnnotator(QPixmap const&) 00000000000141f6 t KImageAnnotator::KImageAnnotator(QPixmap const&) The "t" shows it is private. You have to set the proper export macros to make it visible: https://wiki.qt.io/How_to_create_a_library_with_Qt_and_use_it_in_an_application http://doc.qt.io/qt-5/sharedlibra How to create a library with Qt and use it in an application wiki.qt.io This tutorial illustrates different approaches for using a custom library in your application on Windows. The first part explains how to create a shared library and how to link against it in your application. The second part is about creating and using a static library. Creating a shared library ... ry.html The patch does that, and now the example links with the library just fine. The kImageAnnotatorExport.h header defines the macro, the compile definition is set for the shared library target in the CMakeLists.txt. I guess you'll have to do the same for all classes used by the unit tests, no sure of the Qt development practices. I also reworked your CMake files a bit. I am sending a single patch, though. Sorry. El mar., 21 de ago. de 2018 a la(s) 14:29, Eric Noulard (eric.noulard at gmail.com) escribi?: Le lun. 20 ao?t 2018 ? 19:05, Damir Porobic > a ?crit : Hi Eric, yes, this is the project. I have pushed my current state to this branch https://github.com/DamirPorobic/kImageAnnotator/tree/sharedLibTestBranch I've tried also without the generate_export_headers (cleaned everything up before trying out) but I get the same result. KImageAnnotator::KImageAnnotator(QPixmap const&)should be exposed by the handwritten file, that's true, I think I got something mixed up there and I don't actually need the generate_export_headers, but as said, even without the line, it's not working. I'm quite lost with the file layout. in example/main.cpp you do: #include so I guess you expect that target_link_libraries(kImageAnnotator-example PRIVATE kImageAnnotator::kImageAnnotator) will bring you the include path to "kImageAnnotator/KImageAnnotator.h" along with the [imported] target in your main tree (not in example) there is a trick because you did: add_library(kImageAnnotator::kImageAnnotator ALIAS kImageAnnotator) and then in the test directory you do: target_link_libraries(${UnitTestName} Qt5::Test kimageannotator_LIB) with add_library(kimageannotator_LIB STATIC ${kimageannotator_SRCS}) so AFAIU you compile your kImageAnnotator library twice. Once for building the target you expect to use in example/ subdir and another time as a STATIC lib for the unit test. So the unit test is not linking to the same object lib at all ?? I am not used to KDE development but all this seems very fuzzy to me. May be you could get more precise help from people who know better about KDE dev and the specific CMake machinery that comes along like ECM (https://github.com/KDE/extra-cmake-modules) you seems to be using. -- Eric -- Sebastian Mancilla Matta CCTVal, UTFSM Valpara?so, Chile -- Sebastian Mancilla -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.W.Irwin1234 at gmail.com Sun Sep 2 18:54:05 2018 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Sun, 2 Sep 2018 15:54:05 -0700 (PDT) Subject: [CMake] Happy Birthday CMake! In-Reply-To: <32cb836d-d4cf-83da-6c75-5b7958d9f1a8@kitware.com> References: <32cb836d-d4cf-83da-6c75-5b7958d9f1a8@kitware.com> Message-ID: On 2018-08-31 14:33-0400 Bill Hoffman wrote: > http://public.kitware.com/pipermail/insight-developers/2000-August/024248.html > > Thanks to everyone that has contributed or used CMake! And thanks to you for coming up with such a useful tool in the first place! Can you recommend a site that gives a (fairly) short history of CMake that at least lists the most fundamental changes made to this software since its inception? For example, I am pretty sure you have stated before that it did not start out as a C++ project. If so, when did it switch to C++? I did look at , but the history paragraph there includes nothing about the fundamental changes made along the way in the development of CMake. Alan __________________________ Alan W. Irwin 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 sancelot at numalliance.com Mon Sep 3 03:53:42 2018 From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=) Date: Mon, 3 Sep 2018 09:53:42 +0200 Subject: [CMake] Happy Birthday CMake! In-Reply-To: <32cb836d-d4cf-83da-6c75-5b7958d9f1a8@kitware.com> References: <32cb836d-d4cf-83da-6c75-5b7958d9f1a8@kitware.com> Message-ID: <3224fb4a-7988-f93b-2a57-a8676eb710ef@numalliance.com> Congratulations. Really a great work. Le 31/08/2018 ? 20:33, Bill Hoffman a ?crit?: > > http://public.kitware.com/pipermail/insight-developers/2000-August/024248.html > > Thanks to everyone that has contributed or used CMake! > > -Bill > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Sep 4 08:43:02 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 4 Sep 2018 08:43:02 -0400 Subject: [CMake] are target_compile_definitions not transitive in cmake 3.12.1? In-Reply-To: <9f05ce41-8511-5dae-d830-0074a93fd717@emmenlauer.de> References: <9f05ce41-8511-5dae-d830-0074a93fd717@emmenlauer.de> Message-ID: target_compile_definitions is transitive for PUBLIC/INTERFACE definitions. Can you provide an example where that is failing? On Thu, Aug 30, 2018 at 6:32 PM Mario Emmenlauer wrote: > > Sorry if this has been discussed before, I searched the mailing > list and google but could not find this exact issue (only [1] and > [2] that refer to library dependencies). > > I have a case where it seems target_compile_definitions() is not > transitive (it is not passed down via libraries), is that possible? > I have a project that sets a PUBLIC definition on libA, and during > the build of libB that links libA the definition is applied. But the > definition does not pass down to executables linking libB. This is > confusing for me because library dependencies and includes seem to > be transitive (linking libB also links libA automatically). > > Is it by design that target_compile_definitions() is not transitive > in cmake 3.12.1? Or am I doing something wrong? > > [2] https://gitlab.kitware.com/cmake/cmake/issues/17633 > [1] https://gitlab.kitware.com/cmake/cmake/issues/12435 > > All the best, > > Mario Emmenlauer > > > -- > BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 > Balanstr. 43 mailto: memmenlauer * biodataanalysis.de > D-81669 M?nchen http://www.biodataanalysis.de/ > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiji.vinitha at gmail.com Wed Sep 5 02:47:26 2018 From: jiji.vinitha at gmail.com (Vinitha) Date: Wed, 5 Sep 2018 12:17:26 +0530 Subject: [CMake] cmake prebuilt binaries won't work if bin folder is renamed. Message-ID: Hi, I have downloaded cmake binaries from cmake website. As I had to keep cmake binaries for different platforms in specific folder as per my build system requirements, I have renamed the 'bin' folder to for eg. lin, win, mac etc. This seems to work fine till cmake version 3.7. From this version onwards, I get the following error while invoking cmake after renaming the bin folder. *$pwd* */home/neo/cmake/cmake-3.10.2-Linux-x86_64/lin86* *$ * *$./cmake --version* *CMake Error: Could not find CMAKE_ROOT !!!* *CMake has most likely not been installed correctly.* *Modules directory not found in* *cmake version 3.10.2* *CMake suite maintained and supported by Kitware (kitware.com/cmake ).* If I am renaming back to bin directory, there is no issues observed. I have observed that, from version 3.7 onwards cmake has a new configure flag introduced to specify bin directory name, *--bindir=DIR*. So now if I want to use any other name for 'bin' dir, I need to configure and build the cmake while specifiying the bin directory name I need. Is there a way by using any environment variable or something I can modify the bin directory name of the downloaded cmake binary from cmake website and use it without the above mentioned error ? Regards, Vinitha -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Wed Sep 5 04:49:32 2018 From: d3ck0r at gmail.com (J Decker) Date: Wed, 5 Sep 2018 01:49:32 -0700 Subject: [CMake] cmake prebuilt binaries won't work if bin folder is renamed. In-Reply-To: References: Message-ID: You will need to rename the directory containing bin; the share folder scripts is often very dependant on the bin (or vice versa) ... better to just keep like 'cmake' and then 'cmake-3.xx' directories containing the whole cmake package... On Tue, Sep 4, 2018 at 11:47 PM Vinitha wrote: > Hi, > I have downloaded cmake binaries from cmake website. As I had to keep > cmake binaries for different platforms in specific folder as per my build > system requirements, I have renamed the 'bin' folder to for eg. lin, win, > mac etc. This seems to work fine till cmake version 3.7. From this version > onwards, I get the following error while invoking cmake after renaming the > bin folder. > > *$pwd* > */home/neo/cmake/cmake-3.10.2-Linux-x86_64/lin86* > *$ * > *$./cmake --version* > *CMake Error: Could not find CMAKE_ROOT !!!* > > *CMake has most likely not been installed correctly.* > *Modules directory not found in* > > *cmake version 3.10.2* > > *CMake suite maintained and supported by Kitware (kitware.com/cmake > ).* > > > If I am renaming back to bin directory, there is no issues observed. > I have observed that, from version 3.7 onwards cmake has a new configure > flag introduced to specify bin directory name, *--bindir=DIR*. > > So now if I want to use any other name for 'bin' dir, I need to configure > and build the cmake while specifiying the bin directory name I need. > > Is there a way by using any environment variable or something I can modify > the bin directory name of the downloaded cmake binary from cmake website > and use it without the above mentioned error ? > > > Regards, > > Vinitha > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.eiband at brainlab.com Wed Sep 5 05:00:00 2018 From: daniel.eiband at brainlab.com (Daniel Eiband) Date: Wed, 5 Sep 2018 09:00:00 +0000 Subject: [CMake] Specify extra files for display in IDE In-Reply-To: References: Message-ID: Hi, I managed to solve the presentation of object libraries by renaming the targets and hiding certain targets in folders. I think this solution is acceptable. The issue with the display of header only libraries in IDEs, which are implemented as interface libraries, is still unsolved. The add_library() command doesn?t accept any sources. Also setting the SOURCES property of an interface library target is rejected by CMake. I haven?t found any other way of adding the files to the interface library so that they are presented in the IDE. I know the workaround of adding an empty custom target. This is however not really satisfying, because Visual Studio for example displays them with a completely different icon and the suffix ?(utility target)?. Doesn?t look like a C++ library any longer. It also sort of highlights the library because of the non-C++ icon and I have to hide even more targets (the real interface libraries). From a CMake interface perspective this is also an asymmetry: Why can I add arbitrary files to executable and static/shared library targets being displayed in IDEs without contributing to the build artifact while this is not possible for interface libraries? I think, the restriction on interface libraries should not be that they don?t have any source files. Interface libraries must not have source files which produce build artifacts. Is this worth an enhancement bug or has this already been discussed? Daniel From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Daniel Eiband Sent: Donnerstag, 30. August 2018 15:47 To: Eric Noulard Cc: CMake Mailinglist Subject: Re: [CMake] Specify extra files for display in IDE Hi Eric, Thank you for your answers! Visual Studio supports the source_group command, but it cannot be used to add sources. It only controls where source files of targets are displayed. > I do very often add non source file (like README.md) to any targets This is what I also do for non-build related files such as readme files. It works except for interface libraries (read below). In the object library case I can add non-build related files, but for let's say 'logical' reasons I would like to show the build related files such as cpp files also in the shared library target which links to the object library. > At least the "never displayed" header only library looks like a bug of the Visual Studio generator to me. The situation for interface libraries (header only) is different: CMake won't allow me to add any sources to the target, not even headers. As a result configure fails with an error. I'm pretty sure if I could add headers to interface libraries then they will show up in Visual Studio with this target. So I think it's not a generator bug, but a short-coming of CMake itself. Daniel From: Eric Noulard [mailto:eric.noulard at gmail.com] Sent: Donnerstag, 30. August 2018 14:40 To: Daniel Eiband > Cc: CMake Mailinglist > Subject: Re: [CMake] Specify extra files for display in IDE Le jeu. 30 ao?t 2018 ? 12:32, Daniel Eiband > a ?crit : Hi, I?m currently migrating a code base from a proprietary MSBuild based generator to CMake 3.11 which is shipped with Visual Studio. There are two aspects to this task: 1) Integration of custom build steps 2) Presentation in the IDE The first aspect of integrating all of our custom build steps as custom commands works really well. At one point I use an object library to be able to use the object files as input to such a custom tool and to link a shared library. Both the object library and the shared library are from the programmers perspective one logical unit. The object library is just an implementation detail. However, as for the second point, the source files are displayed with the object library target in the IDE while the shared library has no sources. This makes sense from the build targets point of view, but surprises the developers. My approach is to hide all targets which are sort of implementation detail into a folder. To make this work I would like to display the sources with the shared library which consumes the object files of the object library. Currently this seems to be impossible. Another inconsistency I noticed regarding the second point is the following: I implemented header only libraries as interface libraries in CMake. This works fine from the build perspective. Interface libraries however don?t allow me to list sources, not even headers. As a result, the headers of this header only library are not displayed anywhere in the IDE. This is odd, because in executable targets for example I can list all headers even if they don?t contribute to the build process directly and they are displayed in the IDE. Using empty custom targets to present the header files works, but they are not displayed as C++ libraries in Visual Studio any longer. This also litters the solution with lots of extra empty targets. I?m going to rephrase both described presentation problems into one more fundamental question, solutions or workarounds for either of both presentation problems are of course welcome: Can I specify sources used for builds and files used for display in IDEs separately? I think they are two different things. For my use case it would also be sufficient to be able to add extra files for display in IDEs to any target. I'm afraid that your question may be generator-specific and I'm no sure Visual Studio generator behaves in the same way as others I'm using. I do very often add non source file (like README.md) to any targets (add_executable, add_library, add_custom_target) in order to make them editable in the IDE. Since those file are guessed as not being compilable they inherit the HEADER_FILE_ONLY (https://cmake.org/cmake/help/v3.11/prop_sf/HEADER_FILE_ONLY.html) automatically and they show up in IDE just fine. My particular IDE being either qtcreator, vscode+cmaketools or eclipse and this works well for those. Moreover, in qtcreator (for example) header only libraries appear on their own with editable header file AND as subdir of every other targets their are used by. This subdir contains the headers. This is not the case with object libraries though :-( Concerning the visual grouping you must already being using source_group (https://cmake.org/cmake/help/latest/command/source_group.html) source_group does not seems to have any effect in my favorite IDEs... In the end I don't know if there is currently any ways to do what you want. At least the "never displayed" header only library looks like a bug of the Visual Studio generator to me. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Wed Sep 5 05:21:53 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 5 Sep 2018 11:21:53 +0200 Subject: [CMake] Specify extra files for display in IDE In-Reply-To: References: Message-ID: Le mer. 5 sept. 2018 ? 11:00, Daniel Eiband a ?crit : > Hi, > > > > I managed to solve the presentation of object libraries by renaming the > targets and hiding certain targets in folders. I think this solution is > acceptable. > > > > The issue with the display of header only libraries in IDEs, which are > implemented as interface libraries, is still unsolved. The add_library() > command doesn?t accept any sources. > For an interface library you can add sources with target_sources(yourlib INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/whatever.h) You need the INTERFACE keyword though: https://cmake.org/cmake/help/latest/command/add_library.html#interface-libraries is this not working for you? Could you provide a strip-down archive which exhibit this issue I may try it on my side? > Also setting the SOURCES property of an interface library target is > rejected by CMake. > This is because you can only populate INTERFACE_SOURCES on an INTERFACE target: https://cmake.org/cmake/help/latest/prop_tgt/INTERFACE_SOURCES.html https://cmake.org/cmake/help/latest/command/target_sources.html#command:target_sources > I haven?t found any other way of adding the files to the interface library > so that they are presented in the IDE. > Like I said in a previous email on my side, interface library (INTERFACE) sources are displayed in vscode and qtcreator, may be the fact that they are not displayed by Visual Studio is a Visual Studio bug? By the way there is an old issue on this subject: https://gitlab.kitware.com/cmake/cmake/issues/15234 > I know the workaround of adding an empty custom target. This is however > not really satisfying, because Visual Studio for example displays them with > a completely different icon and the suffix ?(utility target)?. Doesn?t look > like a C++ library any longer. It also sort of highlights the library > because of the non-C++ icon and I have to hide even more targets (the real > interface libraries). > > > > From a CMake interface perspective this is also an asymmetry: Why can I > add arbitrary files to executable and static/shared library targets being > displayed in IDEs without contributing to the build artifact while this is > not possible for interface libraries? I think, the restriction on interface > libraries should not be that they don?t have any source files. Interface > libraries must not have source files which produce build artifacts. > Agreed and I think it would more "natural" to be able to simply target_sources / add_library "as usual" and promote SOURCES to INTERFACE_SOURCES automatically since the target is an INTERFACE lib. > > Is this worth an enhancement bug or has this already been discussed? > The only one I am aware of is this one: https://gitlab.kitware.com/cmake/cmake/issues/15234 -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Wed Sep 5 07:56:43 2018 From: antoine at python.org (Antoine Pitrou) Date: Wed, 5 Sep 2018 13:56:43 +0200 Subject: [CMake] ExternalProject, continuous integration and caching builds Message-ID: Hello, On our project (Apache Arrow - https://arrow.apache.org/) we're using CMake for the C++ source tree and have many external dependencies fetched using ExternalProject. In turn building those dependencies can make up a significant portion of build times on CI services, especially AppVeyor. So I've been looking for a solution to cache those third-party builds from one CI run to the other. Right now, what I'm trying to do is to set EP_BASE to a well-known base directory and ask AppVeyor to cache and restore that directory in each new build. The AppVeyor caching seems to work fine (the EP_BASE directory is saved and restored). However, it seems that nevertheless CMake will rebuild all those projects again, despite the cached build results. This is with CMake 3.12.1 on Windows. Here is the log for an example build step, here the zstd library: https://ci.appveyor.com/project/pitrou/arrow/build/1.0.700/job/i4tj6tifp4xq1mjn?fullLog=true#L803 As you can see, CMake notices the downloaded tarball is up-to-date and doesn't download it again, but it still extracts it again (why?) and builds the source code anew. Yet the entire EP_BASE directory (here "C:/Users/appveyor/arrow-externals") is cached and restored by AppVeyor. Did someone manage to make this work, and/or is there another solution? Thank you Regards Antoine. From craig.scott at crascit.com Wed Sep 5 08:28:46 2018 From: craig.scott at crascit.com (Craig Scott) Date: Wed, 5 Sep 2018 22:28:46 +1000 Subject: [CMake] ExternalProject, continuous integration and caching builds In-Reply-To: References: Message-ID: On Wed, Sep 5, 2018 at 9:56 PM, Antoine Pitrou wrote: > > Hello, > > On our project (Apache Arrow - https://arrow.apache.org/) we're using > CMake for the C++ source tree and have many external dependencies > fetched using ExternalProject. In turn building those dependencies can > make up a significant portion of build times on CI services, especially > AppVeyor. So I've been looking for a solution to cache those > third-party builds from one CI run to the other. > > Right now, what I'm trying to do is to set EP_BASE to a well-known base > directory and ask AppVeyor to cache and restore that directory in each > new build. The AppVeyor caching seems to work fine (the EP_BASE > directory is saved and restored). However, it seems that nevertheless > CMake will rebuild all those projects again, despite the cached build > results. > When AppVeyor restores the cached directories and files, does it also preserve their timestamps? If not, that might explain why it always rebuilds. > > This is with CMake 3.12.1 on Windows. > > Here is the log for an example build step, here the zstd library: > https://ci.appveyor.com/project/pitrou/arrow/build/1. > 0.700/job/i4tj6tifp4xq1mjn?fullLog=true#L803 > > As you can see, CMake notices the downloaded tarball is up-to-date and > doesn't download it again, but it still extracts it again (why?) and > builds the source code anew. Yet the entire EP_BASE directory (here > "C:/Users/appveyor/arrow-externals") is cached and restored by AppVeyor. > > Did someone manage to make this work, and/or is there another solution? > > -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From antoine at python.org Wed Sep 5 08:37:45 2018 From: antoine at python.org (Antoine Pitrou) Date: Wed, 5 Sep 2018 14:37:45 +0200 Subject: [CMake] ExternalProject, continuous integration and caching builds In-Reply-To: References: Message-ID: <58ac20c6-f4d9-4ad1-78fa-4dad8d82665e@python.org> Le 05/09/2018 ? 14:28, Craig Scott a ?crit?: > > > On Wed, Sep 5, 2018 at 9:56 PM, Antoine Pitrou > wrote: > > > Hello, > > On our project (Apache Arrow - https://arrow.apache.org/) we're using > CMake for the C++ source tree and have many external dependencies > fetched using ExternalProject.? In turn building those dependencies can > make up a significant portion of build times on CI services, especially > AppVeyor.? So I've been looking for a solution to cache those > third-party builds from one CI run to the other. > > Right now, what I'm trying to do is to set EP_BASE to a well-known base > directory and ask AppVeyor to cache and restore that directory in each > new build.? The AppVeyor caching seems to work fine (the EP_BASE > directory is saved and restored).? However, it seems that nevertheless > CMake will rebuild all those projects again, despite the cached build > results. > > > When AppVeyor restores the cached directories and files, does it also > preserve their timestamps? If not, that might explain why it always > rebuilds. I do not know. I've found out this utility: https://github.com/iboB/mtime_cache and will experiment with it. Regards Antoine. From antoine at python.org Wed Sep 5 10:02:44 2018 From: antoine at python.org (Antoine Pitrou) Date: Wed, 5 Sep 2018 16:02:44 +0200 Subject: [CMake] ExternalProject, continuous integration and caching builds In-Reply-To: <58ac20c6-f4d9-4ad1-78fa-4dad8d82665e@python.org> References: <58ac20c6-f4d9-4ad1-78fa-4dad8d82665e@python.org> Message-ID: <069c6e87-18ab-bf54-c7a0-ff5871ad01ea@python.org> Le 05/09/2018 ? 14:37, Antoine Pitrou a ?crit?: > >> When AppVeyor restores the cached directories and files, does it also >> preserve their timestamps? If not, that might explain why it always >> rebuilds. > > I do not know. I've found out this utility: > https://github.com/iboB/mtime_cache and will experiment with it. It turns out that doesn't solve the issue. One likely explanation is that fixing the timestamps on cached contents is not useful if ExternalProject unpacks the downloaded tarball again and overwrites the source files. One thing is that we build many of those dependencies in-source (using BUILD_IN_SOURCE), since they don't necessarily support out-of-tree builds... Regards Antoine. From alaitsev at gmail.com Wed Sep 5 10:49:51 2018 From: alaitsev at gmail.com (Innokentiy Alaytsev) Date: Wed, 5 Sep 2018 07:49:51 -0700 (MST) Subject: [CMake] ExternalProject, continuous integration and caching builds In-Reply-To: <069c6e87-18ab-bf54-c7a0-ff5871ad01ea@python.org> References: <58ac20c6-f4d9-4ad1-78fa-4dad8d82665e@python.org> <069c6e87-18ab-bf54-c7a0-ff5871ad01ea@python.org> Message-ID: <1536158991313-0.post@n2.nabble.com> Hello! You may try to perform some "caching" actions yourself: store some kind of a checksum for the archive with the downloaded sources and only build ExternalProject if the checksum changes or if there is no previously built ExternalProject with the same checksum. It is also possible to only store checksum for the archive link if it is guaranteed to be different for different dependency versions. Here is an ugly implementation of a similar logic for downloaded project. Best regards, Innokentiy -- Sent from: http://cmake.3232098.n2.nabble.com/ From alaitsev at gmail.com Wed Sep 5 10:55:46 2018 From: alaitsev at gmail.com (Innokentiy Alaytsev) Date: Wed, 5 Sep 2018 07:55:46 -0700 (MST) Subject: [CMake] ExternalProject, continuous integration and caching builds In-Reply-To: <069c6e87-18ab-bf54-c7a0-ff5871ad01ea@python.org> References: <58ac20c6-f4d9-4ad1-78fa-4dad8d82665e@python.org> <069c6e87-18ab-bf54-c7a0-ff5871ad01ea@python.org> Message-ID: <1536159346583-0.post@n2.nabble.com> Hello! You may try to perform some kind of "caching" actions yourself: store a checksum for the downloaded dependency archive and only build it if its checksum changes or the dependency with this checksum hasn't been already built. You may only store the checksum for the archive download link if it is possible to guarantee that the link is different for different versions of the dependency. Here you may find an ugly implementation of a similar logic. Best regards, Innokentiy -- Sent from: http://cmake.3232098.n2.nabble.com/ From daniel.eiband at brainlab.com Wed Sep 5 11:53:33 2018 From: daniel.eiband at brainlab.com (Daniel Eiband) Date: Wed, 5 Sep 2018 15:53:33 +0000 Subject: [CMake] Specify extra files for display in IDE In-Reply-To: References: Message-ID: <265bba5184cd4a1480d5ef17a63f5e3e@despmsx01.brainlab.net> Hi, I tried to add interface sources to interface libraries with both, the CMake 3.11.18040201-MSVC_2 integration of Visual Studio (with Ninja), which I?m using most of the time, and the ?Visual Studio 15 2017 Win64? generator of CMake 3.12.1: - The Visual Studio integration shows the target in the ?CMake Targets View?, but it contains only one file: CMakeLists.txt. There is no difference if I set header only interface sources or no sources. If this differs from the intended behavior of the CMake generators then I will follow this up with the Visual Studio team. - The Visual Studio generator doesn?t show interface libraries at all. Is this the intended behavior of the Visual Studio generator? Unclear to me is, what the semantics of header only interface sources are? Should headers be INTERFACE_SOURCES? I don?t see a point in propagating them to targets which link to the interface library. To my understanding this is what interface source means. Maybe there is more to it. When headers of the public interface of a library are supposed to be interface sources, then this means, that I should put headers of regular libraries in the PUBLIC section, right? Daniel From: Eric Noulard [mailto:eric.noulard at gmail.com] Sent: Mittwoch, 5. September 2018 11:22 To: Daniel Eiband Cc: CMake Mailinglist Subject: Re: [CMake] Specify extra files for display in IDE Le mer. 5 sept. 2018 ? 11:00, Daniel Eiband > a ?crit : Hi, I managed to solve the presentation of object libraries by renaming the targets and hiding certain targets in folders. I think this solution is acceptable. The issue with the display of header only libraries in IDEs, which are implemented as interface libraries, is still unsolved. The add_library() command doesn?t accept any sources. For an interface library you can add sources with target_sources(yourlib INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/whatever.h) You need the INTERFACE keyword though: https://cmake.org/cmake/help/latest/command/add_library.html#interface-libraries is this not working for you? Could you provide a strip-down archive which exhibit this issue I may try it on my side? Also setting the SOURCES property of an interface library target is rejected by CMake. This is because you can only populate INTERFACE_SOURCES on an INTERFACE target: https://cmake.org/cmake/help/latest/prop_tgt/INTERFACE_SOURCES.html https://cmake.org/cmake/help/latest/command/target_sources.html#command:target_sources I haven?t found any other way of adding the files to the interface library so that they are presented in the IDE. Like I said in a previous email on my side, interface library (INTERFACE) sources are displayed in vscode and qtcreator, may be the fact that they are not displayed by Visual Studio is a Visual Studio bug? By the way there is an old issue on this subject: https://gitlab.kitware.com/cmake/cmake/issues/15234 I know the workaround of adding an empty custom target. This is however not really satisfying, because Visual Studio for example displays them with a completely different icon and the suffix ?(utility target)?. Doesn?t look like a C++ library any longer. It also sort of highlights the library because of the non-C++ icon and I have to hide even more targets (the real interface libraries). From a CMake interface perspective this is also an asymmetry: Why can I add arbitrary files to executable and static/shared library targets being displayed in IDEs without contributing to the build artifact while this is not possible for interface libraries? I think, the restriction on interface libraries should not be that they don?t have any source files. Interface libraries must not have source files which produce build artifacts. Agreed and I think it would more "natural" to be able to simply target_sources / add_library "as usual" and promote SOURCES to INTERFACE_SOURCES automatically since the target is an INTERFACE lib. Is this worth an enhancement bug or has this already been discussed? The only one I am aware of is this one: https://gitlab.kitware.com/cmake/cmake/issues/15234 -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.p.f at mail.com Wed Sep 5 12:27:21 2018 From: george.p.f at mail.com (George PF) Date: Wed, 5 Sep 2018 18:27:21 +0200 Subject: [CMake] Joining an OBJECT and a SHARED library Message-ID: Hi, is there a way to "join" an the OBJECT library with a SHARED library it creates? The abclib and its component abc_tmp, all .c file have #include "foo.h": add_library(abc_tmp OBJECT z1. z2.c) # generate... add_library(abclib SHARED $ generated.c) Then adding the library foo, which adds the include path to "foo.h" - but this only works for 'generated.c', the include path for z1/z1 is not extended: target_link_libraries(abclib PUBLIC foo) Repeating the same for 'abc_tmp' is really cumbersome, I want to this to apply to everything which goes into creating the abclib, directly or indirectly, is that possible? Regards GPF From isaiah.norton at gmail.com Thu Sep 6 00:30:25 2018 From: isaiah.norton at gmail.com (Isaiah Norton) Date: Thu, 6 Sep 2018 00:30:25 -0400 Subject: [CMake] ExternalProject, continuous integration and caching builds In-Reply-To: References: Message-ID: > > CMake notices the downloaded tarball is up-to-date and > doesn't download it again, but it still extracts it again >From what I can tell, the 'check|download tarball' and 'extract tarball' commands are independent parts of the "download step": as long as the download step runs at all, it will re-extract the tarball, even if it skipped re-downloading. So the issue (design questions aside) is what triggers the download step. The minimal dependency for that step looks like "LIBNAME-gitinfo.txt" file somewhere in the stamp directory, so you could check the mtime preservation there. I don't know if there are other dependencies added for the download target added separately. On Wed, Sep 5, 2018 at 8:06 AM Antoine Pitrou wrote: > > Hello, > > On our project (Apache Arrow - https://arrow.apache.org/) we're using > CMake for the C++ source tree and have many external dependencies > fetched using ExternalProject. In turn building those dependencies can > make up a significant portion of build times on CI services, especially > AppVeyor. So I've been looking for a solution to cache those > third-party builds from one CI run to the other. > > Right now, what I'm trying to do is to set EP_BASE to a well-known base > directory and ask AppVeyor to cache and restore that directory in each > new build. The AppVeyor caching seems to work fine (the EP_BASE > directory is saved and restored). However, it seems that nevertheless > CMake will rebuild all those projects again, despite the cached build > results. > > This is with CMake 3.12.1 on Windows. > > Here is the log for an example build step, here the zstd library: > > https://ci.appveyor.com/project/pitrou/arrow/build/1.0.700/job/i4tj6tifp4xq1mjn?fullLog=true#L803 > > As you can see, CMake notices the downloaded tarball is up-to-date and > doesn't download it again, but it still extracts it again (why?) and > builds the source code anew. Yet the entire EP_BASE directory (here > "C:/Users/appveyor/arrow-externals") is cached and restored by AppVeyor. > > Did someone manage to make this work, and/or is there another solution? > > Thank you > > Regards > > Antoine. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris+cmake at qwirx.com Thu Sep 6 01:26:30 2018 From: chris+cmake at qwirx.com (Chris Wilson) Date: Thu, 6 Sep 2018 06:26:30 +0100 Subject: [CMake] Fwd: ExternalProject, continuous integration and caching builds In-Reply-To: References: Message-ID: Hi all, I faced exactly the same issue with Box Backup, and "solved" it by caching completely built packages in tarballs, replacing the ExternalProject with a different one that uses the cached package if it hasn't been invalidated (which we determine based on the CMakeLists.txt having changed). You can see the superbuild file here: https://github.com/boxbackup/boxbackup/blob/s3_support/ infrastructure/cmake/windows/CMakeLists.txt We define a function that extracts a cached package: function(ExternalProject_Use_Cache project_name package_file install_path) message(STATUS "Will use cached package file: ${package_file}") ExternalProject_Add(${project_name} DOWNLOAD_COMMAND ${CMAKE_COMMAND} -E echo "No download step needed (using cached package)" CONFIGURE_COMMAND ${CMAKE_COMMAND} -E echo "No configure step needed (using cached package)" BUILD_COMMAND ${CMAKE_COMMAND} -E echo "No build step needed (using cached package)" INSTALL_COMMAND ${CMAKE_COMMAND} -E echo "No install step needed (using cached package)" ) # We want our tar files to contain the Install/ prefix (not for any # very special reason, only for consistency and so that we can identify them # in the extraction logs) which means that we must extract them in the # binary (top-level build) directory to have them installed in the right # place for subsequent ExternalProjects to pick them up. It seems that the # only way to control the working directory is with Add_Step! ExternalProject_Add_Step(${project_name} extract ALWAYS 1 COMMAND ${CMAKE_COMMAND} -E echo "Extracting ${package_file} to ${install_path}" COMMAND ${CMAKE_COMMAND} -E tar xzvf ${package_file} ${install_path} WORKING_DIRECTORY ${CMAKE_BINARY_DIR} ) ExternalProject_Add_StepTargets(${project_name} extract) endfunction() And a function to create a new cached package: function(ExternalProject_Create_Cache project_name package_file install_path) if(NOT EXISTS ${package_file}) # Note: because this is evaluated when CMake is run, not when make is run, you will # need to rerun CMake to stop it repackaging your already-packaged sources. This # works well enough for the main use case, which is speeding up AppVeyor builds, # since the cache from a previous run is always restored before CMake is run, so if # we already have a package then this code will never be run. message(STATUS "Will create cached package file: ${package_file}") ExternalProject_Add_Step(${project_name} package DEPENDEES install BYPRODUCTS ${package_file} COMMAND ${CMAKE_COMMAND} -E echo "Updating cached package file: ${package_file}" COMMAND ${CMAKE_COMMAND} -E tar czvf ${package_file} ${install_path} ) ExternalProject_Add_StepTargets(${project_name} package) endif() endfunction() And call them like this: file(MD5 ${CMAKE_CURRENT_LIST_FILE} cmake_lists_hash) set(zlib_install_dir "${install_dir}/zlib") set(zlib_package_file "${cache_dir}/zlib_${cmake_lists_hash}.tgz") if(EXISTS ${zlib_package_file}) ExternalProject_Use_Cache(zlib ${zlib_package_file} ${zlib_install_dir}) else() ExternalProject_Add(...) ExternalProject_Create_Cache(zlib ${zlib_package_file} ${zlib_install_dir}) endif() These package files are cached and restored by our AppVeyor configuration , and also the source tarballs used to rebuild them, but not the CMake build directory. This cuts about 10 minutes off our normal build time for each configuration on AppVeyor (80 minutes total per commit tested, with 8 different configurations). But it does make local superbuilds a bit more tricky, as described in the comments: we often have to rerun CMake to use previously built cached packages instead of rebuilding them. I hope this is interesting/helpful to others too. Thanks, Chris. On 6 September 2018 at 05:30, Isaiah Norton wrote: > CMake notices the downloaded tarball is up-to-date and >> doesn't download it again, but it still extracts it again > > > From what I can tell, the 'check|download tarball' and 'extract tarball' > commands are independent parts of the "download step": as long as the > download step runs at all, it will re-extract the tarball, even if it > skipped re-downloading. So the issue (design questions aside) is what > triggers the download step. The minimal dependency for that step looks like > "LIBNAME-gitinfo.txt" file somewhere in the stamp directory, so you could > check the mtime preservation there. I don't know if there are other > dependencies added for the download target added separately. > > On Wed, Sep 5, 2018 at 8:06 AM Antoine Pitrou wrote: > >> >> Hello, >> >> On our project (Apache Arrow - https://arrow.apache.org/) we're using >> CMake for the C++ source tree and have many external dependencies >> fetched using ExternalProject. In turn building those dependencies can >> make up a significant portion of build times on CI services, especially >> AppVeyor. So I've been looking for a solution to cache those >> third-party builds from one CI run to the other. >> >> Right now, what I'm trying to do is to set EP_BASE to a well-known base >> directory and ask AppVeyor to cache and restore that directory in each >> new build. The AppVeyor caching seems to work fine (the EP_BASE >> directory is saved and restored). However, it seems that nevertheless >> CMake will rebuild all those projects again, despite the cached build >> results. >> >> This is with CMake 3.12.1 on Windows. >> >> Here is the log for an example build step, here the zstd library: >> https://ci.appveyor.com/project/pitrou/arrow/build/1.0.700/ >> job/i4tj6tifp4xq1mjn?fullLog=true#L803 >> >> As you can see, CMake notices the downloaded tarball is up-to-date and >> doesn't download it again, but it still extracts it again (why?) and >> builds the source code anew. Yet the entire EP_BASE directory (here >> "C:/Users/appveyor/arrow-externals") is cached and restored by AppVeyor. >> >> Did someone manage to make this work, and/or is there another solution? >> >> Thank you >> >> Regards >> >> Antoine. >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org/mailman/listinfo/cmake >> > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k1.ebrahimpour at gmail.com Fri Sep 7 08:07:02 2018 From: k1.ebrahimpour at gmail.com (K. Ebrahimp.) Date: Fri, 7 Sep 2018 14:07:02 +0200 Subject: [CMake] CheckSymbolExists / CheckCXXSymbolExists Message-ID: hi all can anybody help me with a working example of CheckSymbolExists / CheckCXXSymbolExists I want to check if a some define exists in my header file example1.h of clib1 and/or c++lib2 depending on the result I want to add/remove some tests thanks in advance Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgt at lanl.gov Fri Sep 7 10:03:01 2018 From: kgt at lanl.gov (Thompson, KT) Date: Fri, 7 Sep 2018 14:03:01 +0000 Subject: [CMake] CheckSymbolExists / CheckCXXSymbolExists In-Reply-To: References: Message-ID: Kevin, I use something like this: # Is HOST_NAME_MAX available? include( CheckSymbolExists ) check_symbol_exists( HOST_NAME_MAX ?unistd.h winsock2.h? HAVE_HOST_NAME_MAX ) -kt From: CMake On Behalf Of K. Ebrahimp. Sent: Friday, September 7, 2018 6:07 AM To: cmake at cmake.org Subject: [CMake] CheckSymbolExists / CheckCXXSymbolExists hi all can anybody help me with a working example of CheckSymbolExists / CheckCXXSymbolExists I want to check if a some define exists in my header file example1.h of clib1 and/or c++lib2 depending on the result I want to add/remove some tests thanks in advance Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Fri Sep 7 12:58:48 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 7 Sep 2018 12:58:48 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.12.2 available for download Message-ID: We are pleased to announce that CMake 3.12.2 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.12.2 since 3.12.1: Brad King (5): Android: Add support for NDK r18 CheckIPOSupported: Simplify result reporting logic CheckIPOSupported: Tolerate backslashes in output of failed checks VS: Restore CMakeLists.txt references in each target CMake 3.12.2 Craig Scott (2): EXPORT_PROPERTIES: Add test for an undefined property EXPORT_PROPERTIES: Prevent null dereference for undefined property David Demelier (1): Help: Fix typo in clang-tidy example -checks option Igor Kostenko (1): FindBoost: Fix context discovery for 1.60 and below Kenta Kubo (1): FindCUDA: Do not find cublas_device on CUDA >= 9.2 Raffi Enficiaud (1): FindMatlab: Remove erroneous duplicate code Robert Maynard (1): CUDA: Avoid using deprecated cublas_device to identify device lib dirs Shane Parris (1): cmState: Clear GlobVerificationManager state on Reset From fifteenknots505 at gmail.com Fri Sep 7 14:08:03 2018 From: fifteenknots505 at gmail.com (Martin Weber) Date: Fri, 07 Sep 2018 20:08:03 +0200 Subject: [CMake] Need info on how cmake messages output is formatted Message-ID: <5192846.zIR503lXrL@linux> Hi all, subject says most of it. I'm trying parse the output of cmake from the generation phase (-G option) in order to create error markers in Eclipse. Are there any general rules on how the output is structured, especially those multi-line messages? Any pointers to cmake sources are also welcome. TIA Martin -- Cd wrttn wtht vwls s mch trsr. From mateusz at loskot.net Fri Sep 7 14:48:27 2018 From: mateusz at loskot.net (Mateusz Loskot) Date: Fri, 7 Sep 2018 20:48:27 +0200 Subject: [CMake] Need info on how cmake messages output is formatted In-Reply-To: <5192846.zIR503lXrL@linux> References: <5192846.zIR503lXrL@linux> Message-ID: On Fri, 7 Sep 2018 at 20:08, Martin Weber wrote: > Any pointers to cmake sources are also welcome. AFAIC, the message is printed via cmMessenger::DisplayMessage called by cmMessenger::IssueMessage which is typically called by cmake::IssueMessage So, searching the CMake sources for invocations of ->IssueMessage and uses of cmake::MessageType and its members eg. cmake::FATAL_ERROR may help to collect a picture on how messages are composed. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From chujingjun at gmail.com Fri Sep 7 19:39:28 2018 From: chujingjun at gmail.com (Alvin Chu) Date: Fri, 7 Sep 2018 16:39:28 -0700 Subject: [CMake] [CMAKE] cmake_device_link.o: nvcc fatal: Unknown option 'Wl, -start-group' Message-ID: Hi cmake team, I'm using cmake 3.12.1, and building a project which has cuda codes, the cmake file looks like, list(APPEND ALL_OBJECTS $) list(APPEND ALL_OBJECTS $) add_library(lib1 SHARED ${ALL_OBJECTS}) list(APPEND ALL_LIBRARIES -Wl,-start-group) list(APPEND ALL_LIBRARIES ${SOME_LIBS}) list(APPEND ALL_LIBRARIES -Wl,-end-group) target_link_libraries(lib1 ${ALL_LIBRARIES}) Now for this project, cmake will generate a cmake_device_link.o, using the link flags in lib1, then I got error nvcc fatal : Unknown option 'Wl,-start-group' I checked cmake source code, and seems cmake doesn't check if the link flags in lib1 is supported by nvcc or not, and it directly passed all the flag to nvcc which caused the problem. Maybe this is one way to fix this issue. I also noticed cmMakefileLibraryTargetGenerator::WriteStaticLibraryRules will check CUDA_RESOLVE_DEVICE_SYMBOLS to decide if need generate cmake_device_link.o or not, but cmMakefileLibraryTargetGenerator::WriteSharedLibraryRules don't, I tried add this check in cmMakefileLibraryTargetGenerator::WriteSharedLibraryRules, and my build can success w/o cmake_device_link.o, so maybe this is also a way to fix the issue. I'm new to cmake, so if there's any better way to solve my problem, please let me know. Thanks. Alvin -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at gmail.com Sat Sep 8 02:45:39 2018 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Sat, 8 Sep 2018 08:45:39 +0200 Subject: [CMake] [CMAKE] cmake_device_link.o: nvcc fatal: Unknown option 'Wl, -start-group' In-Reply-To: References: Message-ID: Hi, To avoid this, put link flags in ?LINK_FLAGS? target properly. ?target_link_libraries? is populating ?LINK_LIBRARIES? target property. Le sam. 8 sept. 2018 ? 01:40, Alvin Chu a ?crit : > Hi cmake team, > I'm using cmake 3.12.1, and building a project which has cuda codes, the > cmake file looks like, > list(APPEND ALL_OBJECTS $) > list(APPEND ALL_OBJECTS $) > add_library(lib1 SHARED ${ALL_OBJECTS}) > list(APPEND ALL_LIBRARIES -Wl,-start-group) > list(APPEND ALL_LIBRARIES ${SOME_LIBS}) > list(APPEND ALL_LIBRARIES -Wl,-end-group) > target_link_libraries(lib1 ${ALL_LIBRARIES}) > > Now for this project, cmake will generate a cmake_device_link.o, using > the link flags in lib1, then I got error > nvcc fatal : Unknown option 'Wl,-start-group' > > I checked cmake source code, and seems cmake doesn't check if the link > flags in lib1 is supported by nvcc or not, and it directly passed all the > flag to nvcc which caused the problem. Maybe this is one way to fix this > issue. > > I also noticed cmMakefileLibraryTargetGenerator::WriteStaticLibraryRules > will check CUDA_RESOLVE_DEVICE_SYMBOLS to decide if need generate > cmake_device_link.o or not, > but cmMakefileLibraryTargetGenerator::WriteSharedLibraryRules don't, I > tried add this check in cmMakefileLibraryTargetGenerator::WriteSharedLibraryRules, > and my build can success w/o cmake_device_link.o, so maybe this is also a > way to fix the issue. > > I'm new to cmake, so if there's any better way to solve my problem, please > let me know. > > Thanks. > Alvin > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robfi680 at gmail.com Sun Sep 9 00:52:20 2018 From: robfi680 at gmail.com (Robert Finch) Date: Sun, 9 Sep 2018 00:52:20 -0400 Subject: [CMake] unknown cmake command Message-ID: Hi, cmake is new to me. I?m attempting to use cmake to build a backend for LLVM. CMake fails with an ?unknown cmake command? error. It doesn?t seem to be able to find or execute modules or macros. I tried setting the CMAKE_MODULE_PATH, LLVM_CMAKE_DIR, LLVM_DIR, and LLVM_TABLEGEN variables. I wonder if this would be a problem spawning executables ? Security ? Nothing is written to the log file. tablegen is in the path and can be run manually, but cmake fails to run it. Cmake successfully built and installed LLVM. The file cmake fails with is Cmakelists.txt. The OS is Windows 10 pro build 1803. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chujingjun at gmail.com Sun Sep 9 00:59:14 2018 From: chujingjun at gmail.com (Alvin Chu) Date: Sat, 8 Sep 2018 21:59:14 -0700 Subject: [CMake] [CMAKE] cmake_device_link.o: nvcc fatal: Unknown option 'Wl, -start-group' In-Reply-To: References: Message-ID: Thank you Marc, here we have to put " -Wl,-start-group" and " -Wl,-end-group" in target_link_libraries because these two link flags are special, must used between link targets. Now my way to fix is to use "-Xlinker -start-group" and "-Xlinker -end-group" instead. Thanks. Alvin On Fri, Sep 7, 2018 at 11:45 PM Marc CHEVRIER wrote: > Hi, > > To avoid this, put link flags in ?LINK_FLAGS? target properly. > ?target_link_libraries? is populating ?LINK_LIBRARIES? target property. > > Le sam. 8 sept. 2018 ? 01:40, Alvin Chu a ?crit : > >> Hi cmake team, >> I'm using cmake 3.12.1, and building a project which has cuda codes, the >> cmake file looks like, >> list(APPEND ALL_OBJECTS $) >> list(APPEND ALL_OBJECTS $) >> add_library(lib1 SHARED ${ALL_OBJECTS}) >> list(APPEND ALL_LIBRARIES -Wl,-start-group) >> list(APPEND ALL_LIBRARIES ${SOME_LIBS}) >> list(APPEND ALL_LIBRARIES -Wl,-end-group) >> target_link_libraries(lib1 ${ALL_LIBRARIES}) >> >> Now for this project, cmake will generate a cmake_device_link.o, using >> the link flags in lib1, then I got error >> nvcc fatal : Unknown option 'Wl,-start-group' >> >> I checked cmake source code, and seems cmake doesn't check if the link >> flags in lib1 is supported by nvcc or not, and it directly passed all the >> flag to nvcc which caused the problem. Maybe this is one way to fix this >> issue. >> >> I also noticed cmMakefileLibraryTargetGenerator::WriteStaticLibraryRules >> will check CUDA_RESOLVE_DEVICE_SYMBOLS to decide if need generate >> cmake_device_link.o or not, >> but cmMakefileLibraryTargetGenerator::WriteSharedLibraryRules don't, I >> tried add this check in cmMakefileLibraryTargetGenerator::WriteSharedLibraryRules, >> and my build can success w/o cmake_device_link.o, so maybe this is also >> a way to fix the issue. >> >> I'm new to cmake, so if there's any better way to solve my problem, >> please let me know. >> >> Thanks. >> Alvin >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org/mailman/listinfo/cmake >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Sun Sep 9 07:28:52 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Sun, 9 Sep 2018 13:28:52 +0200 Subject: [CMake] unknown cmake command In-Reply-To: References: Message-ID: Le dim. 9 sept. 2018 ? 06:52, Robert Finch a ?crit : > Hi, cmake is new to me. I?m attempting to use cmake to build a backend for > LLVM. CMake fails with an ?unknown cmake command? error. It doesn?t seem to > be able to find or execute modules or macros. I tried setting the > CMAKE_MODULE_PATH, LLVM_CMAKE_DIR, LLVM_DIR, and LLVM_TABLEGEN variables. I > wonder if this would be a problem spawning executables ? Security ? Nothing > is written to the log file. tablegen is in the path and can be run > manually, but cmake fails to run it. Cmake successfully built and installed > LLVM. The file cmake fails with is Cmakelists.txt. The OS is Windows 10 > pro build 1803. > If the project is public is would be easier to help you if you point out the repo of the project. You should at least provide the full CMake error message your are getting along with CMake version and CMake generator you use (VIsual Studio, etc...) I do build LLVM/clang and some tooling which are not bundled with it like IWYU (https://include-what-you-use.org/) it appears that LLVM has specific CMake macros that ought to be used in the right way. e.g. for IWYU something different is done if it's built in-source (along with LLVM+clang source tree) or out-of-source.You may have a look at: https://github.com/include-what-you-use/include-what-you-use/blob/master/CMakeLists.txt to see what they do for that. However from (https://llvm.org/docs/WritingAnLLVMBackend.html#preliminaries) I bet that building a backend is very different from building a clang-based extra tool. Did you get in touch on some LLVM mailing list about that? I bet your issue may be more related on "how to use LLVM cmake build system" than a generic CMake issue. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From fifteenknots505 at gmail.com Sun Sep 9 09:33:37 2018 From: fifteenknots505 at gmail.com (Martin Weber) Date: Sun, 09 Sep 2018 15:33:37 +0200 Subject: [CMake] Need info on how cmake messages output is formatted In-Reply-To: References: <5192846.zIR503lXrL@linux> Message-ID: <3502496.HeFxFSc7bv@linux> Am Freitag, 7. September 2018, 20:48:27 CEST schrieb Mateusz Loskot: > On Fri, 7 Sep 2018 at 20:08, Martin Weber wrote: > > Any pointers to cmake sources are also welcome. Thank you! > > AFAIC, the message is printed via > cmMessenger::DisplayMessage > called by > cmMessenger::IssueMessage > which is typically called by > cmake::IssueMessage > > So, searching the CMake sources for > invocations of ->IssueMessage > and uses of cmake::MessageType and its members eg. cmake::FATAL_ERROR > may help to collect a picture on how messages are composed. Uuh, 383 references found -- Cd wrttn wtht vwls s mch trsr. From sancelot at numalliance.com Mon Sep 10 08:34:26 2018 From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=) Date: Mon, 10 Sep 2018 14:34:26 +0200 Subject: [CMake] overriding -03 -DNDEBUG Release flags Message-ID: <468573b4-97b2-9d63-ae08-c85429895fb1@numalliance.com> Hi, In one project I need to compile with -O2 option , how to set it and remove -O3 -DNDEBUG flags for this project ? Regards, Steph From eric.noulard at gmail.com Mon Sep 10 09:12:20 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Mon, 10 Sep 2018 15:12:20 +0200 Subject: [CMake] overriding -03 -DNDEBUG Release flags In-Reply-To: <468573b4-97b2-9d63-ae08-c85429895fb1@numalliance.com> References: <468573b4-97b2-9d63-ae08-c85429895fb1@numalliance.com> Message-ID: Le lun. 10 sept. 2018 ? 14:34, St?phane Ancelot a ?crit : > Hi, > > In one project I need to compile with -O2 option , how to set it and > remove -O3 -DNDEBUG flags for this project ? > May be you can create a new Build Type with appropriate flags: https://gitlab.kitware.com/cmake/community/wikis/FAQ#how-can-i-extend-the-build-modes-with-a-custom-made-one- and set it as the default build type for this particular project? https://gitlab.kitware.com/cmake/community/wikis/FAQ#how-can-i-change-the-default-build-mode-and-see-it-reflected-in-the-gui https://blog.kitware.com/cmake-and-the-default-build-type/ > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Mon Sep 10 13:36:56 2018 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon, 10 Sep 2018 13:36:56 -0400 Subject: [CMake] Happy Birthday CMake! In-Reply-To: References: <32cb836d-d4cf-83da-6c75-5b7958d9f1a8@kitware.com> Message-ID: <8f57ddd0-2363-8ac2-cbab-62f35edb118b@kitware.com> On 9/2/2018 6:54 PM, Alan W. Irwin wrote: > > And thanks to you for coming up with such a useful tool in the first > place! > > Can you recommend a site that gives a (fairly) short history of CMake > that at least lists the most fundamental changes made to this software > since its inception?? For example, I am pretty sure you have stated > before that it > did not start out as a C++ project.? If so, when did it switch to C++? > I did look at , but the history > paragraph there includes nothing about the fundamental changes made along > the way in the development of CMake. CMake has always been in C++.?? The idea was that all that would be required would be a C++ compiler.? With that, you could build CMake.? Since CMake was designed to build C++ projects, it was assumed that the user would at least have a C++ compiler. Should be some history these talks: https://www.youtube.com/watch?v=8Ut9o4OdSC0&feature=youtube_gdata https://www.youtube.com/watch?v=TqjtN8NGtl4 I don't think there is anything written. -Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From jperez at accuray.com Mon Sep 10 14:25:19 2018 From: jperez at accuray.com (Jeffrey Perez) Date: Mon, 10 Sep 2018 18:25:19 +0000 Subject: [CMake] Specifying path of nvcc for CUDA projects using project command Message-ID: Hello, I have a project which uses the CMake 3.10.1 and CUDA nvcc compiler and I am using the new project(projectName LANGUAGES CUDA) instead of find_package(CUDA) to do so. I want CMake to use a different (explicitly defined) path for nvcc compiler than the installed version. Before calling project(projectName LANGUAGES CUDA), I declare CUDA_TOOLKIT_ROOT_DIR via an include of a file which defines our third party library variables, but it always finds the installed version. I know that CUDA_TOOLKIT_ROOT_DIR was meant for the find_package(CUDA) script, but the documentation doesn't seem to specify how to use the new project method of including nvcc. Is there a way to specify a different nvcc location using the new format? Excerpt from CMakeLists.txt: ... include(${CMAKE_CURRENT_SOURCE_DIR}/../../../build/thirdparty_versions.cmake) #defines CUDA_TOOLKIT_ROOT_DIR to specified CUDA root with bin/nvcc below it. message(---------------CUDA_TOOLKIT_ROOT_DIR:${ CUDA_TOOLKIT_ROOT_DIR}) project(projectName LANGUAGES CUDA) ... Below is a portion of my output: ... ---------------CUDA_TOOLKIT_ROOT_DIR:C:/thirdparty/CUDA/v8.0 -- Selecting Windows SDK version 10.0.14393.0 to target Windows 10.0.17134. -- The CUDA compiler identification is NVIDIA 8.0.44 -- Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v8.0/bin/nvcc.exe You can see that the CUDA compiler found was the intalled version, not C:/thirdparty/CUDA/v8.0 Thanks, Jeff Perez -- WARNING - CONFIDENTIAL INFORMATION: The information contained in the e-mail may contain confidential and privileged information and is intended solely for the use of the intended recipient(s). Access for any review, re-transmission, dissemination or other use of, or taking of any action in regard and reliance upon this e-mail by persons or entities other than the intended recipient(s) is unauthorized and prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From smith at whoop.com Mon Sep 10 15:06:06 2018 From: smith at whoop.com (Richard A. Smith) Date: Mon, 10 Sep 2018 15:06:06 -0400 Subject: [CMake] Add compile flags or defines without adding to ASM_ settings Message-ID: I'm having a tough time figuring out how to get some compile flags added to one of my targets without it breaking the ASM source file compile. I currently have a build with a C_CLAGS setting that looks like below: set(CMAKE_C_FLAGS "${GCC_PROCESSOR_FLAGS} ${GCC_OPTIMIZATION_FLAGS} ${GCC_WARNING_FLAGS} ${GCC_DEBUG_FLAGS} ${GCC_C_FLAGS} ") The only important part of the above is the GCC_DEBUG_FLAGS which looks like this: set(GCC_DEBUG_FLAGS "-g3 -ggdb -DDEBUG -DMXC_ASSERT_ENABLE") I'm in the process of creating a "release" build. I'd prefer to make a release target instead of generating with 'cmake -D RELEASE' For my release build. I'd like to have the same options as above except for ${GCC_DEBUG_FLAGS}. Those should be omitted. However, I'd still like them included for all the other targets. So I changed CMAKE_C_FLAGS to the following: set(CMAKE_C_FLAGS "${GCC_PROCESSOR_FLAGS} ${GCC_OPTIMIZATION_FLAGS} ${GCC_WARNING_FLAGS} ${GCC_C_FLAGS} ") Essentially removing setting the debug flags by default. Now my release target works fine. No debug settings. The problem comes when I try to add those debug options back into the other builds using the per target config methods. Doesn't matter if I use target_compile_options() or set_target_properties() and change the COMPILE_FLAGS or COMPILE_OPTIONS property the result is the same. What happens is that all the options that I specify also get added to the ASM_FLAGS setting. In my sources list what looks similar to the following: set(PROJ_SOURCES ${PROJ_DIRECTORY}/file1.c ${PROJ_DIRECTORY}/file2.c ${PROJ_DIRECTORY}/asm_file.S ) When -DDEBUG -DMXC_ASSERT_ENABLE get added to ASM_FLAGS then the assembler chokes on -DDEBUG /usr/bin/arm-none-eabi-as: unrecognized option '-EBUG' I've also tried breaking the options apart so that the -D options are on their own and I used target_compile_definitions() to set just the defines. The result is still the same but instead of getting added to ASM_FLAGS they get added to ASM_DEFINES but the assembler still chokes. How can I add compile options to my targets that only get added to C_FLAGS and not to my ASM_FLAGS? Thanks. -- Richard A. Smith smith at whoop.com From robert.maynard at kitware.com Mon Sep 10 17:21:43 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 10 Sep 2018 17:21:43 -0400 Subject: [CMake] Specifying path of nvcc for CUDA projects using project command In-Reply-To: References: Message-ID: You can specify the location by setting the CUDACXX environment variable ( https://cmake.org/cmake/help/v3.12/envvar/CUDACXX.html ). On Mon, Sep 10, 2018 at 2:40 PM Jeffrey Perez via CMake wrote: > > Hello, > > > > I have a project which uses the CMake 3.10.1 and CUDA nvcc compiler and I am using the new project(projectName LANGUAGES CUDA) instead of find_package(CUDA) to do so. I want CMake to use a different (explicitly defined) path for nvcc compiler than the installed version. Before calling project(projectName LANGUAGES CUDA), I declare CUDA_TOOLKIT_ROOT_DIR via an include of a file which defines our third party library variables, but it always finds the installed version. I know that CUDA_TOOLKIT_ROOT_DIR was meant for the find_package(CUDA) script, but the documentation doesn't seem to specify how to use the new project method of including nvcc. > > > > Is there a way to specify a different nvcc location using the new format? > > > > Excerpt from CMakeLists.txt: > > ? > > include(${CMAKE_CURRENT_SOURCE_DIR}/../../../build/thirdparty_versions.cmake) #defines CUDA_TOOLKIT_ROOT_DIR to specified CUDA root with bin/nvcc below it. > > message(---------------CUDA_TOOLKIT_ROOT_DIR:${ CUDA_TOOLKIT_ROOT_DIR}) > project(projectName LANGUAGES CUDA) > > ? > > > > Below is a portion of my output: > > ? > > ---------------CUDA_TOOLKIT_ROOT_DIR:C:/thirdparty/CUDA/v8.0 > > -- Selecting Windows SDK version 10.0.14393.0 to target Windows 10.0.17134. > > -- The CUDA compiler identification is NVIDIA 8.0.44 > > -- Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v8.0/bin/nvcc.exe > > > > You can see that the CUDA compiler found was the intalled version, not C:/thirdparty/CUDA/v8.0 > > > > Thanks, > > Jeff Perez > > > > -- WARNING - CONFIDENTIAL INFORMATION: The information contained in the e-mail may contain confidential and privileged information and is intended solely for the use of the intended recipient(s). Access for any review, re-transmission, dissemination or other use of, or taking of any action in regard and reliance upon this e-mail by persons or entities other than the intended recipient(s) is unauthorized and prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachments. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake From andrew.amaclean at gmail.com Mon Sep 10 18:26:02 2018 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 11 Sep 2018 08:26:02 +1000 Subject: [CMake] Happy Birthday CMake! In-Reply-To: References: Message-ID: Hi Bill, In the pre-Cmake days I remember building VTK on Windows with a program that configured VTK for the build. Do you remember what it was called? This was back around 2000! Regards Andrew > ---------- Forwarded message ---------- > From: Bill Hoffman > To: "Alan W. Irwin" > Cc: CMake Mailinglist , cmake-developers at cmake.org > Bcc: > Date: Mon, 10 Sep 2018 13:36:56 -0400 > Subject: Re: [CMake] Happy Birthday CMake! > > On 9/2/2018 6:54 PM, Alan W. Irwin wrote: > > > And thanks to you for coming up with such a useful tool in the first > place! > > Can you recommend a site that gives a (fairly) short history of CMake > that at least lists the most fundamental changes made to this software > since its inception? For example, I am pretty sure you have stated before > that it > did not start out as a C++ project. If so, when did it switch to C++? > I did look at > , but the history > paragraph there includes nothing about the fundamental changes made along > the way in the development of CMake. > > CMake has always been in C++. The idea was that all that would be > required would be a C++ compiler. With that, you could build CMake. Since > CMake was designed to build C++ projects, it was assumed that the user > would at least have a C++ compiler. > > Should be some history these talks: > https://www.youtube.com/watch?v=8Ut9o4OdSC0&feature=youtube_gdata > https://www.youtube.com/watch?v=TqjtN8NGtl4 > > I don't think there is anything written. > > -Bill > > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Sep 10 19:54:08 2018 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 10 Sep 2018 16:54:08 -0700 Subject: [CMake] Happy Birthday CMake! In-Reply-To: References: Message-ID: Pcmaker, Ken Martin wrote it. On Mon, Sep 10, 2018, 3:26 PM Andrew Maclean wrote: > Hi Bill, > In the pre-Cmake days I remember building VTK on Windows with a program > that configured VTK for the build. Do you remember what it was called? This > was back around 2000! > > Regards > Andrew > > > >> ---------- Forwarded message ---------- >> From: Bill Hoffman >> To: "Alan W. Irwin" >> Cc: CMake Mailinglist , cmake-developers at cmake.org >> Bcc: >> Date: Mon, 10 Sep 2018 13:36:56 -0400 >> Subject: Re: [CMake] Happy Birthday CMake! >> >> On 9/2/2018 6:54 PM, Alan W. Irwin wrote: >> >> >> And thanks to you for coming up with such a useful tool in the first >> place! >> >> Can you recommend a site that gives a (fairly) short history of CMake >> that at least lists the most fundamental changes made to this software >> since its inception? For example, I am pretty sure you have stated >> before that it >> did not start out as a C++ project. If so, when did it switch to C++? >> I did look at >> , but the history >> paragraph there includes nothing about the fundamental changes made along >> the way in the development of CMake. >> >> CMake has always been in C++. The idea was that all that would be >> required would be a C++ compiler. With that, you could build CMake. Since >> CMake was designed to build C++ projects, it was assumed that the user >> would at least have a C++ compiler. >> >> Should be some history these talks: >> https://www.youtube.com/watch?v=8Ut9o4OdSC0&feature=youtube_gdata >> https://www.youtube.com/watch?v=TqjtN8NGtl4 >> >> I don't think there is anything written. >> >> -Bill >> >> >> >> -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Mon Sep 10 22:43:55 2018 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 11 Sep 2018 12:43:55 +1000 Subject: [CMake] Happy Birthday CMake! In-Reply-To: References: Message-ID: Thanks, Bill. I remember it now! Andrew Maclean On 11 Sep 2018 09:54, "Bill Lorensen" wrote: Pcmaker, Ken Martin wrote it. On Mon, Sep 10, 2018, 3:26 PM Andrew Maclean wrote: > Hi Bill, > In the pre-Cmake days I remember building VTK on Windows with a program > that configured VTK for the build. Do you remember what it was called? This > was back around 2000! > > Regards > Andrew > > > >> ---------- Forwarded message ---------- >> From: Bill Hoffman >> To: "Alan W. Irwin" >> Cc: CMake Mailinglist , cmake-developers at cmake.org >> Bcc: >> Date: Mon, 10 Sep 2018 13:36:56 -0400 >> Subject: Re: [CMake] Happy Birthday CMake! >> >> On 9/2/2018 6:54 PM, Alan W. Irwin wrote: >> >> >> And thanks to you for coming up with such a useful tool in the first >> place! >> >> Can you recommend a site that gives a (fairly) short history of CMake >> that at least lists the most fundamental changes made to this software >> since its inception? For example, I am pretty sure you have stated >> before that it >> did not start out as a C++ project. If so, when did it switch to C++? >> I did look at >> , but the history >> paragraph there includes nothing about the fundamental changes made along >> the way in the development of CMake. >> >> CMake has always been in C++. The idea was that all that would be >> required would be a C++ compiler. With that, you could build CMake. Since >> CMake was designed to build C++ projects, it was assumed that the user >> would at least have a C++ compiler. >> >> Should be some history these talks: >> https://www.youtube.com/watch?v=8Ut9o4OdSC0&feature=youtube_gdata >> https://www.youtube.com/watch?v=TqjtN8NGtl4 >> >> I don't think there is anything written. >> >> -Bill >> >> >> >> -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From world at masterdevops.eu Tue Sep 11 05:59:34 2018 From: world at masterdevops.eu (world at masterdevops.eu) Date: Tue, 11 Sep 2018 11:59:34 +0200 Subject: [CMake] Problems with static jpeg library Message-ID: Hi, I am trying to compile the project libgd (https://github.com/libgd/libgd) with the option ENABLE_JPEG enabled. I.e. first I downloaded the source code of libjpeg-turbo from https://sourceforge.net/projects/libjpeg-turbo/files/2.0.0/, compiled it and afterwards I started to compile libgd with this command: > cmake -G "Unix Makefiles" \ -DENABLE_JPEG=ON \ -DJPEG_INCLUDE_DIR="../${JPEG_DIR}" \ -DJPEG_LIBRARY="../${JPEG_DIR}/libjpeg.a" \ . You can check the CMakeLists.txt in that project (https://github.com/libgd/libgd/blob/master/CMakeLists.txt) As you can see, I want to compile libgd with a static libjpeg library. But I get several errors like this one: > /usr/bin/ld: .../libjpeg-turbo-2.0.0/libjpeg.a(jcmainct.c.o): > relocation R_X86_64_32S against `.text' can not be used when making a > shared object; recompile with -fPIC When I use the shared library version of libjpeg, i.e. I try to compile libgd with the shared version of libjpeg, i.e. > cmake -G "Unix Makefiles" \ -DENABLE_JPEG=ON \ -DJPEG_INCLUDE_DIR="../${JPEG_DIR}" \ -DJPEG_LIBRARY="../${JPEG_DIR}/libjpeg.so" \ . then there is no error. Is this a problem of CMake or a problem of the CMakeLists.txt of the libgd project? From eike at sf-mail.de Tue Sep 11 07:47:50 2018 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 11 Sep 2018 13:47:50 +0200 Subject: [CMake] Problems with static jpeg library In-Reply-To: References: Message-ID: <2008343.dkjVQFmuBS@daneel.sf-tec.de> world at masterdevops.eu wrote: > Hi, > > I am trying to compile the project libgd > (https://github.com/libgd/libgd) with the option ENABLE_JPEG enabled. > > I.e. first I downloaded the source code of libjpeg-turbo from > https://sourceforge.net/projects/libjpeg-turbo/files/2.0.0/, compiled it You need to make sure that this compile includes -fPIC in the compileflags of libjpeg. > But I get several errors like this one: > > /usr/bin/ld: .../libjpeg-turbo-2.0.0/libjpeg.a(jcmainct.c.o): > > relocation R_X86_64_32S against `.text' can not be used when making a > > shared object; recompile with -fPIC As said here. Eike -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From robert.maynard at kitware.com Tue Sep 11 08:00:12 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 11 Sep 2018 08:00:12 -0400 Subject: [CMake] Joining an OBJECT and a SHARED library In-Reply-To: References: Message-ID: I believe what you are looking for in the CMake 3.12 improvements to object libraries. In 3.12 the target_link_libraries command now supports linking to an object library to embed the object files ( only on direct dependencies, no propagation of .objs ) and also propagates usage requirements like any other library. On Wed, Sep 5, 2018 at 12:27 PM George PF wrote: > > Hi, > > is there a way to "join" an the OBJECT library with a SHARED library it creates? > > The abclib and its component abc_tmp, all .c file have #include "foo.h": > > add_library(abc_tmp OBJECT z1. z2.c) > # generate... > add_library(abclib SHARED $ generated.c) > > Then adding the library foo, which adds the include path to "foo.h" - but this only > works for 'generated.c', the include path for z1/z1 is not extended: > > target_link_libraries(abclib PUBLIC foo) > > Repeating the same for 'abc_tmp' is really cumbersome, I want to this to apply to everything > which goes into creating the abclib, directly or indirectly, is that possible? > > > Regards > > GPF > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake From world at masterdevops.eu Tue Sep 11 10:10:21 2018 From: world at masterdevops.eu (world at masterdevops.eu) Date: Tue, 11 Sep 2018 16:10:21 +0200 Subject: [CMake] Problems with static jpeg library In-Reply-To: <2008343.dkjVQFmuBS@daneel.sf-tec.de> References: <2008343.dkjVQFmuBS@daneel.sf-tec.de> Message-ID: Hi, thank you for your reply. I could solve the problem. The part I didn't knew was that static libraries also needed to be compiled with -fPIC. I've found a good summary of this topic at https://lists.debian.org/debian-devel/2016/05/msg00309.html I want to share it for those, who also stumble upon this problem. On 2018-09-11 13:47, Rolf Eike Beer wrote: > world at masterdevops.eu wrote: >> Hi, >> >> I am trying to compile the project libgd >> (https://github.com/libgd/libgd) with the option ENABLE_JPEG enabled. >> >> I.e. first I downloaded the source code of libjpeg-turbo from >> https://sourceforge.net/projects/libjpeg-turbo/files/2.0.0/, compiled >> it > > You need to make sure that this compile includes -fPIC in the > compileflags of > libjpeg. > >> But I get several errors like this one: >> > /usr/bin/ld: .../libjpeg-turbo-2.0.0/libjpeg.a(jcmainct.c.o): >> > relocation R_X86_64_32S against `.text' can not be used when making a >> > shared object; recompile with -fPIC > > As said here. > > Eike > -- -- German DevPos site: https://www.masterdevops.eu From eric.noulard at gmail.com Tue Sep 11 11:14:34 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 11 Sep 2018 17:14:34 +0200 Subject: [CMake] Problems with static jpeg library In-Reply-To: References: <2008343.dkjVQFmuBS@daneel.sf-tec.de> Message-ID: Le mar. 11 sept. 2018 ? 16:10, a ?crit : > Hi, > > thank you for your reply. I could solve the problem. The part I didn't > knew was that static libraries also needed to be compiled with -fPIC. > I've found a good summary of this topic at > https://lists.debian.org/debian-devel/2016/05/msg00309.html > I want to share it for those, who also stumble upon this problem. > And for project using CMake as build system one can use, POSITION_INDEPENDENT_CODE target property: https://cmake.org/cmake/help/latest/prop_tgt/POSITION_INDEPENDENT_CODE.html#prop_tgt:POSITION_INDEPENDENT_CODE or globally: https://cmake.org/cmake/help/latest/variable/CMAKE_POSITION_INDEPENDENT_CODE.html#variable:CMAKE_POSITION_INDEPENDENT_CODE in order to enable such flags. > > On 2018-09-11 13:47, Rolf Eike Beer wrote: > > world at masterdevops.eu wrote: > >> Hi, > >> > >> I am trying to compile the project libgd > >> (https://github.com/libgd/libgd) with the option ENABLE_JPEG enabled. > >> > >> I.e. first I downloaded the source code of libjpeg-turbo from > >> https://sourceforge.net/projects/libjpeg-turbo/files/2.0.0/, compiled > >> it > > > > You need to make sure that this compile includes -fPIC in the > > compileflags of > > libjpeg. > > > >> But I get several errors like this one: > >> > /usr/bin/ld: .../libjpeg-turbo-2.0.0/libjpeg.a(jcmainct.c.o): > >> > relocation R_X86_64_32S against `.text' can not be used when making a > >> > shared object; recompile with -fPIC > > > > As said here. > > > > Eike > > -- > > -- > German DevPos site: https://www.masterdevops.eu > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Tue Sep 11 11:57:51 2018 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Tue, 11 Sep 2018 11:57:51 -0400 Subject: [CMake] Appending to CMAKE_CXX_FLAGS Message-ID: <84269D28-3F03-456B-BF20-358E9ECAF988@bluequartz.net> What is the ?modern? way to append to CMAKE_CXX_FLAGS? This is the logic that I would like: If (MSVC) ??????????????? Set(CMAKE_CXX_FLAGS ${ CMAKE_CXX_FLAGS} ?/MP?) Endif() I have always heard that appending to the compile flags in this way is ?bad?. What is the best practice for doing this? Thanks -- Michael Jackson | Owner, President BlueQuartz Software [e] mike.jackson at bluequartz.net [w] www.bluequartz.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at gmail.com Tue Sep 11 13:03:56 2018 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Tue, 11 Sep 2018 19:03:56 +0200 Subject: [CMake] Appending to CMAKE_CXX_FLAGS In-Reply-To: <84269D28-3F03-456B-BF20-358E9ECAF988@bluequartz.net> References: <84269D28-3F03-456B-BF20-358E9ECAF988@bluequartz.net> Message-ID: The best approach is to use properties (see https://cmake.org/cmake/help/git-master/manual/cmake-properties.7.html). At directory level and target level you can use property 'COMPILE_OPTIONS'. These properties can be updated using, respectively 'add_compile_options' and 'target_compile_options'. Be aware that variable 'CMAKE_CXX_FLAGS' is a string so to extend it you have to use: string(APPEND CMAKE_CXX_FLAGS "flag1 flag2") Le mar. 11 sept. 2018 ? 17:58, Michael Jackson a ?crit : > What is the ?modern? way to append to CMAKE_CXX_FLAGS? This is the logic > that I would like: > > > > If (MSVC) > > Set(CMAKE_CXX_FLAGS ${ CMAKE_CXX_FLAGS} ?/MP?) > > Endif() > > > > I have always heard that appending to the compile flags in this way is > ?bad?. What is the best practice for doing this? > > > > Thanks > > -- > > Michael Jackson | Owner, President > > BlueQuartz Software > > [e] mike.jackson at bluequartz.net > > [w] www.bluequartz.net > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Tue Sep 11 13:19:26 2018 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Tue, 11 Sep 2018 13:19:26 -0400 Subject: [CMake] Appending to CMAKE_CXX_FLAGS In-Reply-To: References: <84269D28-3F03-456B-BF20-358E9ECAF988@bluequartz.net> Message-ID: <1AFA8C3B-0494-4ACB-924B-413D6E75F3A9@bluequartz.net> Hmm. The idea for the ?/MP? flags for those that don?t use Visual Studio is that it will inform the compiler to use all the cores on the system to compile. Much like Ninja does automatically and ?make -jN? does for makefiles. Essentially I want to automatically add the ?/MP? flag anytime that I configure using Visual Studio (2015/2017) as the generator. I guess I could put the append string fairly high up in the CMake hierarchy. I am not seeing a property (from the first link you sent) that would allow me to do that. -- Michael Jackson | Owner, President BlueQuartz Software [e] mike.jackson at bluequartz.net [w] www.bluequartz.net From: Marc CHEVRIER Date: Tuesday, September 11, 2018 at 1:04 PM To: Michael Jackson Cc: CMake Subject: Re: [CMake] Appending to CMAKE_CXX_FLAGS The best approach is to use properties (see https://cmake.org/cmake/help/git-master/manual/cmake-properties.7.html). At directory level and target level you can use property 'COMPILE_OPTIONS'. These properties can be updated using, respectively 'add_compile_options' and 'target_compile_options'. Be aware that variable 'CMAKE_CXX_FLAGS' is a string so to extend it you have to use: string(APPEND CMAKE_CXX_FLAGS "flag1 flag2") Le mar. 11 sept. 2018 ? 17:58, Michael Jackson a ?crit : What is the ?modern? way to append to CMAKE_CXX_FLAGS? This is the logic that I would like: If (MSVC) Set(CMAKE_CXX_FLAGS ${ CMAKE_CXX_FLAGS} ?/MP?) Endif() I have always heard that appending to the compile flags in this way is ?bad?. What is the best practice for doing this? Thanks -- Michael Jackson | Owner, President BlueQuartz Software [e] mike.jackson at bluequartz.net [w] www.bluequartz.net -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at gmail.com Tue Sep 11 13:28:01 2018 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Tue, 11 Sep 2018 19:28:01 +0200 Subject: [CMake] Appending to CMAKE_CXX_FLAGS In-Reply-To: <1AFA8C3B-0494-4ACB-924B-413D6E75F3A9@bluequartz.net> References: <84269D28-3F03-456B-BF20-358E9ECAF988@bluequartz.net> <1AFA8C3B-0494-4ACB-924B-413D6E75F3A9@bluequartz.net> Message-ID: If you set directory property at the top level CMakeList.txt, before any target definition, all targets will inherit this value. And, because property 'COMPILE_OPTIONS' supports generator expressions (see https://cmake.org/cmake/help/v3.12/manual/cmake-generator-expressions.7.html), you can specify: add_compile_options("$<$:/MP>") Le mar. 11 sept. 2018 ? 19:19, Michael Jackson a ?crit : > Hmm. The idea for the ?/MP? flags for those that don?t use Visual Studio > is that it will inform the compiler to use all the cores on the system to > compile. Much like Ninja does automatically and ?make -jN? does for > makefiles. > > Essentially I want to automatically add the ?/MP? flag anytime that I > configure using Visual Studio (2015/2017) as the generator. I guess I could > put the append string fairly high up in the CMake hierarchy. I am not > seeing a property (from the first link you sent) that would allow me to do > that. > > > > -- > > Michael Jackson | Owner, President > > BlueQuartz Software > > [e] mike.jackson at bluequartz.net > > [w] www.bluequartz.net > > > > *From: *Marc CHEVRIER > *Date: *Tuesday, September 11, 2018 at 1:04 PM > *To: *Michael Jackson > *Cc: *CMake > *Subject: *Re: [CMake] Appending to CMAKE_CXX_FLAGS > > > > The best approach is to use properties (see > https://cmake.org/cmake/help/git-master/manual/cmake-properties.7.html). > > > > At directory level and target level you can use property > 'COMPILE_OPTIONS'. These properties can be updated using, respectively > 'add_compile_options' and 'target_compile_options'. > > > > Be aware that variable 'CMAKE_CXX_FLAGS' is a string so to extend it you > have to use: > > string(APPEND CMAKE_CXX_FLAGS "flag1 flag2") > > > > > > Le mar. 11 sept. 2018 ? 17:58, Michael Jackson < > mike.jackson at bluequartz.net> a ?crit : > > What is the ?modern? way to append to CMAKE_CXX_FLAGS? This is the logic > that I would like: > > > > If (MSVC) > > Set(CMAKE_CXX_FLAGS ${ CMAKE_CXX_FLAGS} ?/MP?) > > Endif() > > > > I have always heard that appending to the compile flags in this way is > ?bad?. What is the best practice for doing this? > > > > Thanks > > -- > > Michael Jackson | Owner, President > > BlueQuartz Software > > [e] mike.jackson at bluequartz.net > > [w] www.bluequartz.net > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alaitsev at gmail.com Tue Sep 11 13:28:39 2018 From: alaitsev at gmail.com (Innokentiy Alaytsev) Date: Tue, 11 Sep 2018 10:28:39 -0700 (MST) Subject: [CMake] Appending to CMAKE_CXX_FLAGS In-Reply-To: <1AFA8C3B-0494-4ACB-924B-413D6E75F3A9@bluequartz.net> References: <84269D28-3F03-456B-BF20-358E9ECAF988@bluequartz.net> <1AFA8C3B-0494-4ACB-924B-413D6E75F3A9@bluequartz.net> Message-ID: <1536686919525-0.post@n2.nabble.com> Hello! Did you consider adding the flag manually during project configuration? I do not know you use case, but after some thinking about the best way of achieving multiprocess compilation under MSVS with CMake I decided, that the simplest, most portable and flexible is to just add this flag manually. One of the reasons for such a decision is that I do not know how the project may be built and multiprocess compilation may cause problems under some hardware configurations. Best regards, Innokentiy -- Sent from: http://cmake.3232098.n2.nabble.com/ From smith at whoop.com Tue Sep 11 14:40:57 2018 From: smith at whoop.com (Richard A. Smith) Date: Tue, 11 Sep 2018 14:40:57 -0400 Subject: [CMake] Appending to CMAKE_CXX_FLAGS In-Reply-To: References: <84269D28-3F03-456B-BF20-358E9ECAF988@bluequartz.net> Message-ID: <7d97b3ec-7ea4-6df2-fc8b-d3d06994259c@whoop.com> On 09/11/2018 01:03 PM, Marc CHEVRIER wrote: > The best approach is to use properties (see > https://cmake.org/cmake/help/git-master/manual/cmake-properties.7.html). > > At directory level and target level you can use property > 'COMPILE_OPTIONS'.? These properties can be updated using, respectively > 'add_compile_options' and 'target_compile_options'. If you have assembly files you may run into trouble. See my question: https://www.mail-archive.com/cmake at cmake.org/msg59526.html I don't have a solution yet. > > Le?mar. 11 sept. 2018 ??17:58, Michael Jackson > > a ?crit?: > > What is the ?modern? way to append to CMAKE_CXX_FLAGS? This is the > logic that I would like:____ > > __ __ > > If (MSVC)____ > > ??????????????? Set(CMAKE_CXX_FLAGS ${ CMAKE_CXX_FLAGS} ?/MP?)____ > > Endif()____ > > __ __ > > I have always heard that appending to the compile flags in this way > is ?bad?. What is the best practice for doing this?____ > > __ __ > > Thanks____ > > --____ > > Michael Jackson | Owner, President____ > > ? ????BlueQuartz Software____ > > [e] mike.jackson at bluequartz.net ____ > > [w] www.bluequartz.net ____ -- Richard A. Smith smith at whoop.com From mike.jackson at bluequartz.net Tue Sep 11 15:35:37 2018 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Tue, 11 Sep 2018 15:35:37 -0400 Subject: [CMake] Appending to CMAKE_CXX_FLAGS In-Reply-To: References: <84269D28-3F03-456B-BF20-358E9ECAF988@bluequartz.net> <1AFA8C3B-0494-4ACB-924B-413D6E75F3A9@bluequartz.net> Message-ID: Just to be clear I _only_ need it when the generator is Visual Studio so I did the following: if(MSVC_IDE) ? add_compile_options(/MP) endif() >From a clean build directory that did not add it to the CMAKE_CXX_FLAGS when viewed in CMake-Gui. -- Mike Jackson From: Marc CHEVRIER Date: Tuesday, September 11, 2018 at 1:28 PM To: Michael Jackson Cc: CMake Subject: Re: [CMake] Appending to CMAKE_CXX_FLAGS If you set directory property at the top level CMakeList.txt, before any target definition, all targets will inherit this value. And, because property 'COMPILE_OPTIONS' supports generator expressions (see https://cmake.org/cmake/help/v3.12/manual/cmake-generator-expressions.7.html), you can specify: add_compile_options("$<$:/MP>") Le mar. 11 sept. 2018 ? 19:19, Michael Jackson a ?crit : Hmm. The idea for the ?/MP? flags for those that don?t use Visual Studio is that it will inform the compiler to use all the cores on the system to compile. Much like Ninja does automatically and ?make -jN? does for makefiles. Essentially I want to automatically add the ?/MP? flag anytime that I configure using Visual Studio (2015/2017) as the generator. I guess I could put the append string fairly high up in the CMake hierarchy. I am not seeing a property (from the first link you sent) that would allow me to do that. -- Michael Jackson | Owner, President BlueQuartz Software [e] mike.jackson at bluequartz.net [w] www.bluequartz.net From: Marc CHEVRIER Date: Tuesday, September 11, 2018 at 1:04 PM To: Michael Jackson Cc: CMake Subject: Re: [CMake] Appending to CMAKE_CXX_FLAGS The best approach is to use properties (see https://cmake.org/cmake/help/git-master/manual/cmake-properties.7.html). At directory level and target level you can use property 'COMPILE_OPTIONS'. These properties can be updated using, respectively 'add_compile_options' and 'target_compile_options'. Be aware that variable 'CMAKE_CXX_FLAGS' is a string so to extend it you have to use: string(APPEND CMAKE_CXX_FLAGS "flag1 flag2") Le mar. 11 sept. 2018 ? 17:58, Michael Jackson a ?crit : What is the ?modern? way to append to CMAKE_CXX_FLAGS? This is the logic that I would like: If (MSVC) Set(CMAKE_CXX_FLAGS ${ CMAKE_CXX_FLAGS} ?/MP?) Endif() I have always heard that appending to the compile flags in this way is ?bad?. What is the best practice for doing this? Thanks -- Michael Jackson | Owner, President BlueQuartz Software [e] mike.jackson at bluequartz.net [w] www.bluequartz.net -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Tue Sep 11 16:09:39 2018 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Tue, 11 Sep 2018 16:09:39 -0400 Subject: [CMake] Appending to CMAKE_CXX_FLAGS In-Reply-To: <1536686919525-0.post@n2.nabble.com> References: <84269D28-3F03-456B-BF20-358E9ECAF988@bluequartz.net> <1AFA8C3B-0494-4ACB-924B-413D6E75F3A9@bluequartz.net> <1536686919525-0.post@n2.nabble.com> Message-ID: I add it manually each and every time. I have to tell all new developers to remember to add the flag otherwise they are still sitting after an hour waiting on our code to compile wondering why it takes so long. Then it hits us, "Oh, Yeah. Open CMake-Gui and set the /MP flag". I'm frustrated at the situation but not sure how to fix it. I tried the other suggestions and just nothing works. This is one of those things that I poke at once a year and figure out that nothing has changed. Been this way since VS 2013. Someday it will change. -- Mike Jackson ?On 9/11/18, 1:28 PM, "CMake on behalf of Innokentiy Alaytsev" wrote: Hello! Did you consider adding the flag manually during project configuration? I do not know you use case, but after some thinking about the best way of achieving multiprocess compilation under MSVS with CMake I decided, that the simplest, most portable and flexible is to just add this flag manually. One of the reasons for such a decision is that I do not know how the project may be built and multiprocess compilation may cause problems under some hardware configurations. Best regards, Innokentiy -- Sent from: http://cmake.3232098.n2.nabble.com/ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake From kgt at lanl.gov Tue Sep 11 17:27:54 2018 From: kgt at lanl.gov (Thompson, KT) Date: Tue, 11 Sep 2018 21:27:54 +0000 Subject: [CMake] Appending to CMAKE_CXX_FLAGS In-Reply-To: References: <84269D28-3F03-456B-BF20-358E9ECAF988@bluequartz.net> <1AFA8C3B-0494-4ACB-924B-413D6E75F3A9@bluequartz.net> <1536686919525-0.post@n2.nabble.com> Message-ID: <3433e75c823b4acb844612e0cad575bc@lanl.gov> Michael, I agree heartily with your frustration concerning how CMake handles compiler flags -- especially when the FLAG strings seen in cmake-gui don't match the baseline flags used by the build. I use a heavy handed, old-fashioned approach to solve this problem. I ignore all of CMake's default compiler flags. Instead of using CMake's defaults, I set these flags manually for every supported build environment. For example, I have a setflags.cmake file included from my top level CMakeLists.txt that contains logic that looks something like this: if( NOT C_FLAGS_INITIALIZED ) # only do this on the first pass through to avoid overwriting user added options. set( C_FLAGS_INITIALIZED "yes" CACHE INTERNAL "Are compiler flags already set?" ) # Overwrite CMake's defaults... if( "${CMAKE_C_COMPILER_ID}" STREQUAL "GNU") set( CMAKE_C_FLAGS "-Wall -pedantic -Wunused-macros" ) set( CMAKE_C_FLAGS_DEBUG "-g -DDEBUG") set( CMAKE_C_FLAGS_RELEASE "-O3 -DNDEBUG" ) set( CMAKE_C_FLAGS_MINSIZEREL "${CMAKE_C_FLAGS_RELEASE}" ) set( CMAKE_C_FLAGS_RELWITHDEBINFO "-O3 -g -gdwarf-3" ) # in a similar fashion, provide CXX_FLAGS and Fortran_FLAGS elseif( "${CMAKE_C_COMPILER_ID}" STREQUAL "MSVC" ) set( CMAKE_C_FLAGS "/fp:precise /DWIN32 /D_WINDOWS /MP" ) ... endif() endif() # Save the current compiler flags to the cache every time cmake configures the project. set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS}" CACHE STRING "compiler flags" FORCE) set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG}" CACHE STRING "compiler flags" FORCE) set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE}" CACHE STRING "compiler flags" FORCE) set(CMAKE_C_FLAGS_MINSIZEREL "${CMAKE_C_FLAGS_MINSIZEREL}" CACHE STRING "compiler flags" FORCE) set(CMAKE_C_FLAGS_RELWITHDEBINFO "${CMAKE_C_FLAGS_RELWITHDEBINFO}" CACHE STRING "compiler flags" FORCE) # and similar for CXX_FLAGS and Fortran_FLAGS... With this logic, I have customized baseline compiler flags that show up for everyone and they match the strings found in CMakeCache.txt (and via cmake-gui). If I modify the flags via ccmake or cmake-gui, the new options are saved to the cache and are used by the build. I manually set many more flags for my default set than I show in the example above and I have extra logic to check compiler version or option availability (e.g.: if (CMAKE_CXX_COMPILER_VERSION VERSION_GREATER 8.0) -> add some gcc-8 flags). I also have some logic that looks for flags set in the environment and these options are appended to these strings before the strings are saved to the cache. There are a few downsides to this approach: - I build on many different platforms with many different compilers, so I have a significant amount of cmake code to manage. - Some flags that are set automagically set by cmake don't show up in the _FLAGS strings. For example, setting CMAKE_CXX_STANDARD will add appropriate compiler flags like '-std=c++14' but you don't see them in cmake-gui. In a few cases I also use per-sourcefile, per-target, and per-directory properties (sometimes via generator expressions) as other have described in replying to your question. In most cases, I have found that the default flags that are set by the top level of my build system prevent me from needing to customize compile flags for individual targets. I hope this helps. -kt -----Original Message----- From: CMake On Behalf Of Michael Jackson Sent: Tuesday, September 11, 2018 2:10 PM To: cmake at cmake.org Subject: Re: [CMake] Appending to CMAKE_CXX_FLAGS I add it manually each and every time. I have to tell all new developers to remember to add the flag otherwise they are still sitting after an hour waiting on our code to compile wondering why it takes so long. Then it hits us, "Oh, Yeah. Open CMake-Gui and set the /MP flag". I'm frustrated at the situation but not sure how to fix it. I tried the other suggestions and just nothing works. This is one of those things that I poke at once a year and figure out that nothing has changed. Been this way since VS 2013. Someday it will change. -- Mike Jackson ?On 9/11/18, 1:28 PM, "CMake on behalf of Innokentiy Alaytsev" wrote: Hello! Did you consider adding the flag manually during project configuration? I do not know you use case, but after some thinking about the best way of achieving multiprocess compilation under MSVS with CMake I decided, that the simplest, most portable and flexible is to just add this flag manually. One of the reasons for such a decision is that I do not know how the project may be built and multiprocess compilation may cause problems under some hardware configurations. Best regards, Innokentiy -- Sent from: http://cmake.3232098.n2.nabble.com/ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake From rjvbertin at gmail.com Tue Sep 11 17:54:21 2018 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 11 Sep 2018 23:54:21 +0200 Subject: [CMake] SOVERSION and Mac library id in shared library made from assembly files Message-ID: <2206246.sEjFjaY3zl@portia.local> Hi, I have a little project that creates a shared library from a pair of assembly files. I've been trying to follow examples such that the generated library - has versioning (libFastCompression.1.dylib on Mac or libFastCompression.so.1 on Linux) - has the full path as its ID on Mac I get this in the projects I used as example, but not in this particular project. Am I overlooking/forgetting something, or is what I'm looking for not implemented/supported for libraries built exclusively from assembly files? The project: github.com/RJVB/lzvn Thanks! Ren? From eric.noulard at gmail.com Wed Sep 12 02:19:03 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 12 Sep 2018 08:19:03 +0200 Subject: [CMake] Appending to CMAKE_CXX_FLAGS In-Reply-To: References: <84269D28-3F03-456B-BF20-358E9ECAF988@bluequartz.net> <1AFA8C3B-0494-4ACB-924B-413D6E75F3A9@bluequartz.net> <1536686919525-0.post@n2.nabble.com> Message-ID: Le mar. 11 sept. 2018 ? 22:09, Michael Jackson a ?crit : > I add it manually each and every time. I have to tell all new developers > to remember to add the flag otherwise they are still sitting after an hour > waiting on our code to compile wondering why it takes so long. Then it hits > us, "Oh, Yeah. Open CMake-Gui and set the /MP flag". I'm frustrated at the > situation but not sure how to fix it. I tried the other suggestions and > just nothing works. This is one of those things that I poke at once a year > and figure out that nothing has changed. Been this way since VS 2013. > Someday it will change. > I don't know your constraint on using msbuild but if the "main" issue is to automatically exploit parallel build did you try to switch to ninja instead of msbuild? Visual C++ Tools for CMake seems to [begin to] support that path as well: https://blogs.msdn.microsoft.com/vcblog/2017/05/10/cmake-support-in-visual-studio-whats-new-in-2017-15-3-update/ -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjm324 at cornell.edu Wed Sep 12 11:17:17 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Wed, 12 Sep 2018 08:17:17 -0700 Subject: [CMake] Relation Between CMP0074 and Installed Config Files Message-ID: Hello, I am on the task force for modernizing the CMake build system of a large project, the Point Cloud Library (PCL). Satisfying policy CMP0074 [1] has us somewhat confused about what we should be doing. At *build time*, we understand. Our numerous FindStuff.cmake modules (some of which we will be removing, e.g., Eigen, some we cannot, e.g., libusb-1.0) should be checked and verified that when finding paths / libraries, we need to verify that we also check both ${Package_ROOT} and $ENV{Package_ROOT} in the search paths. This makes sense and is relatively straightforward to check for each of our Find modules. Where we are confused is about PCLConfig.cmake [2]. Ignoring the fact that the file needs some love in general, the current scheme needs modification to fully satisfy CMP0074. Choosing an arbitrary example, here is what is done for qhull macro(find_qhull) if(PCL_ALL_IN_ONE_INSTALLER) set(QHULL_ROOT "${PCL_ROOT}/3rdParty/Qhull") elseif(NOT QHULL_ROOT) get_filename_component(QHULL_ROOT "@QHULL_INCLUDE_DIRS@" PATH) endif(PCL_ALL_IN_ONE_INSTALLER) set(QHULL_USE_STATIC @QHULL_USE_STATIC@) find_package(Qhull) endmacro(find_qhull) When considering the usage of this in a consuming project that issues a find_package(PCL X.Y.Z REQUIRED), the motivation behind this approach was to help facilitate that the library path that was used when PCL was built will be recovered, unless the consuming project defines / is configured with -DQHULL_ROOT=/some/path. In other words, the scheme here was created to make sure that the same dependencies that were found when *compiling* PCL are found when *using* PCL. I asked about this on the cpplang slack, and one of the cmake devs (whose word I generally follow blindly without question xD) told me this > basically provide the necessary find modules themselves, but don't cache the results of your find calls when installing. AKA instead of renaming these variables e.g. QHULL_ROOT -> PCL_QHULL_ROOT to satisfy CMP0074, we should delete them. The conversation was brief and I did not include much context, but I am wondering if people here could share their thoughts on this. (a) Why is providing measures to make sure the same libraries used at compilation of PCL are the same ones found when using PCL bad? (b) Even if we create proper imported interface libraries to do target_link_libraries(pcl PUBLIC qhull::qhull), this will not help us in terms of installation -- the find modules still need to be installed / called in PCLConfig.cmake, right? (c) Since we need to more carefully analyze our project with respect to CMP0074, is it advisable to set it to OLD for the imminent release? The release will go out before we have time to properly update our CMake code for this policy, and we want to make sure that setting it to OLD (rather than just *not* setting it to NEW) is the correct approach *for this release only*. Thank you for any insights! [1]: https://cmake.org/cmake/help/latest/policy/CMP0074.html [2]: https://github.com/PointCloudLibrary/pcl/blob/master/PCLConfig.cmake.in P.S. To the original advisor who told me not to cache the results, I apologize in advance for having the audacity to doubt your infinite CMake wisdom. I don't understand why caching the results for installation is bad / what can go wrong by this, and would like to ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From sjm324 at cornell.edu Thu Sep 13 09:57:12 2018 From: sjm324 at cornell.edu (Stephen McDowell) Date: Thu, 13 Sep 2018 06:57:12 -0700 Subject: [CMake] [cmake-developers] libc++ usage in CMake with Clang? In-Reply-To: References: <56e8f08e75e049bbb36bd84a4865329f@lanl.gov> Message-ID: Hello, I wanted to revisit this topic. Craig gave a great answer for using add_{compile,link}_options which mostly answers the question -- this is the most modern way at this time. However, I believe that CMake would really benefit from standardizing this. For example, CMAKE_CXX_STL_TYPE. I would argue that this should also be a public "compile feature" in some form, so that it propagates to consuming targets. Some projects I work with do what Craig suggested and when Clang is detected, default to using libc++ and also usually libc++-abi. While kind of nice, it's mostly annoying to me. You're forcing an incompatible ABI on me for Linux, when there's no reason to. If I want to install to /usr/local and use this with other dependencies say from my package manager installs, I cannot because libc++ and libstdc++ are not compatible. Instead of asking projects to do some kind of option(MYLIB_USE_LIBCXX ...) and do their own detection logic, setting the default to ON when Clang is the compiler or whatever, if CMake supports this natively it would be a great feature. For example, I can compile with clang and use libstdc++ on Linux no problem. Similarly, when compiling with gcc, I *can* also use libc++ (assuming it's installed of course). A rough prototype of the values accepted (modelled after the android module): - gnustl_shared (GNU libstdc++ shared) - gnustl_static (GNU libstdc++ static) - c++_shared (LLVM libc++ shared) - c++_shared (LLVM libc++ static) - c++_abi_shared (LLVM libc++-abi sharedi) - c++_abi_static (LLVM libc++-abi static) Where I do not have answers is how to make libc++ and libc++-abi more ubiquitous. As far as I know (which is not very far), libc++-abi cannot be used unless you are also using libc++. So I guess c++_abi_shared implies c++_abi? What about default values? Linux: gnustl_shared seems like a reasonable choice, regardless of compiler (e.g., don't always default to libc++ with clang [???]). MacOS: ??? Windows: ??? I don't feel there is an immediate need for this, but long term I think having CMAKE_CXX_STL_TYPE as well as a compile feature cxx_stl_type would be really useful. I started looking at possible implementation (hence the long pause here), but ultimately gave up because I always try and implement things for CMake that are beyond my capabilities of doing correctly. Just soliciting feedback as to what people think about having this kind of cmake-level STL type support, especially with respect to choosing defaults, and in extra-specific case of Windows, ummm, what to do in general. -Stephen P.S. I think if CMAKE_CROSSCOMPILING is set then if the user sets either CMAKE_CXX_STL_TYPE or cxx_stl_type this should be an error (informing them to possibly instead set CMAKE_ANDROID_STL_TYPE if applicable)? I don't know what to do about cross compiling in general, but an agreement should be reached on what to do when these proposed new variable / features are used in conjunction with cross compiling. On Wed, Aug 22, 2018 at 2:05 AM, Craig Scott wrote: > > > On Wed, Aug 22, 2018 at 1:39 PM, Ian Henriksen gmail.com> wrote: > >> >> >> On Tue, Aug 21, 2018 at 6:40 PM Craig Scott >> wrote: >> >>> >>> On Wed, Aug 22, 2018 at 7:18 AM, Robert Dailey >> > wrote: >>> >>>> On Tue, Aug 21, 2018 at 3:47 PM Craig Scott >>>> wrote: >>>> > Excuse the brevity, but it sounds like you might be looking for the >>>> CXX_EXTENSIONS target property (sorry if I've misunderstood your problem, >>>> let me know why it isn't appropriate if so). See the following article for >>>> a more complete overview of this and related properties: >>>> > >>>> > https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/ >>>> >>>> Unfortunately that's not the same. Extensions manage C++ language >>>> features and STL capabilities, but -stdlib is for selecting an STL >>>> implementation, AFAIK. Such as GNU STL and LLVM STL (which is libc++ >>>> to clang). >>>> >>> >>> Sorry, yes I misunderstood your problem. After a little digging, it >>> seems like you probably shouldn't be using the -stdlib option on Linux >>> anyway. FWIW, for >>> Android, the roadmap >>> >>> is converging on a single STL implementation too. >>> >> >> All that first link says is that -stdlib is a flag that is specific to >> clang and that it shouldn't be used with gcc. You can use clang on Linux >> with either libstdc++ or libc++. I often use libc++ on Linux by setting >> CMAKE_CXX_FLAGS on the command line, though I'll admit that for me it's >> usually just to check if problems that come up are OS dependent, compiler >> dependent, or standard library dependent. You have to be careful since >> libstdc++ and libc++ have incompatible ABIs, but it's a useful feature. >> That said, I have no idea if specifying the standard library implementation >> merits handling at the CMake level since only clang supports switching >> anyway. >> > > > Good clarification, thanks. I was only thinking GCC on Linux and wasn't > considering clang (which was a bit dumb on my part - blame the lack of > coffee early in the morning ;) ). > > Getting back to Robert's original query, the only part of the CMake code > base that I can see attempting to account for a -stdlib option is for > detection of gcc include paths, and this is only for Eclipse and CodeBlocks > generators (according to the comments in Modules/ > CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake). It > doesn't seem to be related to providing any support for manipulating it in > a project. The only other place -stdlib seems to be mentioned is in the > setup of the macOS release build of CMake itself, which isn't relevant to > the discussion here. > > If CMake were to offer direct support for -stdlib, it sounds like it would > be a clang-specific feature, so a clang-specific target property and/or > variable may be a way forward, analogous to the way it is done for Android. > Alternatively, maybe it could be done with generator expressions, but it > would be a bit verbose and harder to ensure the same -stdlib was used > consistently throughout if many targets were involved. But maybe just a > fairly simple check is good enough here, something like this (using > directory properties instead of variables): > > if (CMAKE_CXX_COMPILER_ID MATCHES "Clang" AND NOT ANDROID) > add_compile_options(-stdlib=libc++) > # Presumably need the above for linking too, maybe other options > missing as well > add_link_options(-stdlib=libc++) # New command on CMake master, not > in 3.12 release > endif() > > The linking comments above are in response to discussions in a recent > issue also related > to the -stdlib option. One down side of the above is no transitive > dependency details, something that a target property could achieve. I'll > pause here and see what others think. > > > > >> >> Just my two cents though. >> >> Best, >> >> Ian >> >> >>> Regarding your earlier comment: >>> >>> I'll explain a bit why I'm asking. I noticed that for code bases that >>>> work on Android plus other UNIX platforms, they unconditionally >>>> specify `-stdlib=libc++`, however this doesn't work on Ubuntu by >>>> default, which uses gnu stl + gcc/clang. So you get compiler errors. >>>> There's no way for me to "search" a platform to see if it is eligible >>>> for the libc++ flag, I simply have to either disable it completely or >>>> conditionally include it based on target platform and/or toolchain. >>>> None of these really address the root cause. >>> >>> If you are trying to control which STL to use for Android builds, CMake variables like CMAKE_ANDROID_STL_TYPE are probably the more appropriate way to do that rather than hard-coding compiler flags. This would also mean that non-Android builds won't be affected since they would simply ignore that variable (and target properties it may affect) and should then pick up the right STL implementation automatically.The Android-specific variable would ideally be set in a toolchain file rather than in the project itself. >>> >>> >>> -- >>> >>> Craig Scott >>> Melbourne, Australia >>> https://crascit.com >>> >>> New book released: Professional CMake: A Practical Guide >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> https://cmake.org/mailman/listinfo/cmake >>> >> > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > > New book released: Professional CMake: A Practical Guide > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hedley.rafe at yahoo.com Thu Sep 13 10:47:20 2018 From: hedley.rafe at yahoo.com (Rafe Hedley) Date: Thu, 13 Sep 2018 14:47:20 +0000 (UTC) Subject: [CMake] Good way to add arguments to CMAKE_STRIP on macOS References: <254846069.4332148.1536850040492.ref@mail.yahoo.com> Message-ID: <254846069.4332148.1536850040492@mail.yahoo.com> Hello, I am trying to override CMAKE_STRIP to do this command: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip -x mylib.dylib so I tried a basic : set(CMAKE_STRIP "${CMAKE_STRIP} -x") and? set(CMAKE_STRIP ${CMAKE_STRIP} -x) Unfortunately, this overriding does not work and there is the final command that I get in cmake_install.cmake : ? ? if(CMAKE_INSTALL_DO_STRIP)? ? ? execute_process(COMMAND "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip -x" "$ENV{DESTDIR}/Users/user/mylib.dylib")? ? endif() or ? ? if(CMAKE_INSTALL_DO_STRIP)? ? ? execute_process(COMMAND "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip;-x" "$ENV{DESTDIR}/Users/user/mylib.dylib")? ? endif() This does not work and the final command must be : ? ? ? execute_process(COMMAND "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip" "-x" "$ENV{DESTDIR}/Users/user/mylib.dylib") What is the best way to override this ? I found a really dirty trick that I can add for each target but I don't want to do that: add_custom_command(TARGET myTarget POST_BUILD COMMAND $<$:${CMAKE_STRIP}> $<$:-x> $<$:$>) Thank you for your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From burlen.loring at gmail.com Thu Sep 13 16:46:04 2018 From: burlen.loring at gmail.com (Burlen Loring) Date: Thu, 13 Sep 2018 13:46:04 -0700 Subject: [CMake] FindMPI.cmake in 3.11.4 Message-ID: <35a0aefa-799b-e81a-6fbf-2b6afb56406b@gmail.com> Hi, I'm trying to transition from cmake 3.8.2 to cmake 3.11.4. There are a number of changes the way FindMPI.cmake behaves in 3.11 that are making this difficult. In 3.11 how do I override the settings? For instance I want to set MPI_C_LIBRARIES, MPI_C_INCLUDE_DIRS? In 3.8 all I had to do was set those variables myself, before find_package(MPI), and my setting were used. in 3.11 find_package(MPI) ignores, and wipes out my settings, and then fails. Isn't it a defacto standard of cmake to be able to override find modules by setting the libraries and include dirs before the module runs? Burlen From chuck.atkins at kitware.com Fri Sep 14 13:32:01 2018 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Fri, 14 Sep 2018 13:32:01 -0400 Subject: [CMake] FindMPI.cmake in 3.11.4 In-Reply-To: <35a0aefa-799b-e81a-6fbf-2b6afb56406b@gmail.com> References: <35a0aefa-799b-e81a-6fbf-2b6afb56406b@gmail.com> Message-ID: Hi Burlen, _LIBRARIES and _INCLUDE_DIRS are non-cached output variables. The new functionality should be documented as to how to guide the current FindMPI: https://cmake.org/cmake/help/v3.12/module/FindMPI.html#variables-for-locating-mpi . That being said, is it incorrectl6y detecting or determine the MPI installation? If that's the case then we should probably fix that issue instead. ---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc. (518) 881-1183 On Thu, Sep 13, 2018 at 4:46 PM Burlen Loring wrote: > Hi, > > I'm trying to transition from cmake 3.8.2 to cmake 3.11.4. There are a > number of changes the way FindMPI.cmake behaves in 3.11 that are making > this difficult. > > In 3.11 how do I override the settings? For instance I want to set > MPI_C_LIBRARIES, MPI_C_INCLUDE_DIRS? In 3.8 all I had to do was set > those variables myself, before find_package(MPI), and my setting were > used. in 3.11 find_package(MPI) ignores, and wipes out my settings, and > then fails. > > Isn't it a defacto standard of cmake to be able to override find modules > by setting the libraries and include dirs before the module runs? > > Burlen > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From burlen.loring at gmail.com Fri Sep 14 14:56:54 2018 From: burlen.loring at gmail.com (Burlen Loring) Date: Fri, 14 Sep 2018 11:56:54 -0700 Subject: [CMake] FindMPI.cmake in 3.11.4 In-Reply-To: References: <35a0aefa-799b-e81a-6fbf-2b6afb56406b@gmail.com> Message-ID: <88884277-099a-b778-75c9-0e989835e77c@gmail.com> Of course I read the documentation. Alas after trying various settings described there in, nothing worked. my settings are ignored and erased. why did they MPI_C_LIBRARIES and MPI_C_INCLUDE_DIRS/PATH get changed from cache variables to not chached variables? that seems to be the cause of the issue.? Now how does one override the detection and tell it what to use in the new module? Burlen On 09/14/2018 10:32 AM, Chuck Atkins wrote: > Hi Burlen, > _LIBRARIES and _INCLUDE_DIRS are non-cached output variables.? The new > functionality should be documented as to how to guide the current > FindMPI: > https://cmake.org/cmake/help/v3.12/module/FindMPI.html#variables-for-locating-mpi > .? That being said, is it incorrectl6y detecting or determine the MPI > installation?? If that's the case then we should probably fix that > issue instead. > > ---------- > Chuck Atkins > Staff R&D Engineer, Scientific Computing > Kitware, Inc. > (518) 881-1183 > > > On Thu, Sep 13, 2018 at 4:46 PM Burlen Loring > wrote: > > Hi, > > I'm trying to transition from cmake 3.8.2 to cmake 3.11.4. There > are a > number of changes the way FindMPI.cmake behaves in 3.11 that are > making > this difficult. > > In 3.11 how do I override the settings? For instance I want to set > MPI_C_LIBRARIES, MPI_C_INCLUDE_DIRS? In 3.8 all I had to do was set > those variables myself, before find_package(MPI), and my setting were > used. in 3.11 find_package(MPI) ignores, and wipes out my > settings, and > then fails. > > Isn't it a defacto standard of cmake to be able to override find > modules > by setting the libraries and include dirs before the module runs? > > Burlen > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. > For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mateusz at loskot.net Fri Sep 14 15:30:46 2018 From: mateusz at loskot.net (Mateusz Loskot) Date: Fri, 14 Sep 2018 21:30:46 +0200 Subject: [CMake] FindMPI.cmake in 3.11.4 In-Reply-To: <88884277-099a-b778-75c9-0e989835e77c@gmail.com> References: <35a0aefa-799b-e81a-6fbf-2b6afb56406b@gmail.com> <88884277-099a-b778-75c9-0e989835e77c@gmail.com> Message-ID: On Fri, 14 Sep 2018 at 20:57, Burlen Loring wrote: > why did they MPI_C_LIBRARIES and MPI_C_INCLUDE_DIRS/PATH get changed from cache variables to not chached variables? Possibly, that change was due to clean up to correct the module according to the actual CMake conventions https://cmake.org/cmake/help/latest/manual/cmake-developer.7.html#standard-variable-names """ Xxx_INCLUDE_DIRS The final set of include directories listed in one variable for use by client code. This should not be a cache entry. Xxx_LIBRARIES The libraries to link against to use Xxx. These should include full paths. This should not be a cache entry. """ Also, find_package_handle_standard_args description also gives similar hint on the naming: https://cmake.org/cmake/help/latest/module/FindPackageHandleStandardArgs.html """ Therefore these should typically be cache entries such as FOO_LIBRARY and not output variables like FOO_LIBRARIES. """ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From robb at datalogics.com Fri Sep 14 16:05:52 2018 From: robb at datalogics.com (Rob Boehne) Date: Fri, 14 Sep 2018 20:05:52 +0000 Subject: [CMake] Shared library building Message-ID: All, I?m switching to CMake for a complex project that supports many operating systems, and consists of C++ shared libraries and plugins. I tend to use ${ORIGIN} (in Linux/Solaris parlance) and -z defs at library creation time to support relative hard-coded library lookup paths and prevent problems with unresolved symbols (respectively). Both of these translate into many different flags for different compilers and linkers, and I was curious if there were facilities in CMake for handling this, or a home-grown module that can take care of that for me. Thanks, Rob [cid:image002.png at 01D3D0E3.DCFE6710] Rob Boehne Senior Software Architect | Datalogics, Inc. +1.312.853.8351 | robb at datalogics.com datalogics.com | blogs.datalogics.com Connect with us: Facebook | Twitter | LinkedIn | YouTube -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 124449 bytes Desc: image001.png URL: From mark at cognomen.co.uk Fri Sep 14 17:38:54 2018 From: mark at cognomen.co.uk (Mark Ferry) Date: Fri, 14 Sep 2018 22:38:54 +0100 Subject: [CMake] overriding -03 -DNDEBUG Release flags In-Reply-To: <468573b4-97b2-9d63-ae08-c85429895fb1@numalliance.com> References: <468573b4-97b2-9d63-ae08-c85429895fb1@numalliance.com> Message-ID: <20180914213854.aulhbqofarpachb2@canard.local> Have just worked through this and I think in short there is no *good* way. The method I decided to live with is caching the CFLAGS in the toolchain file. If you don't have a custom toolchain file for that project, create one. Assuming you're using a GNU-derived toolchain try this: set(CMAKE_C_FLAGS_RELEASE "-O2" CACHE STRING "Some description") include(Compiler/GNU) Pass the toolchain file to cmake: cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/my/toolchain-file.cmake ... The downside is you can no longer change the C_FLAGS from a cmake UI (like ccmake) though you *can* change them from the command line. ( cmake -DCMAKE_C_FLAGS_RELEASE=... ) What doesn't work and why: * Setting CMAKE_CFLAGS_RELEASE in a CMakeLists.txt -> Obviously. It's too late, we're past toolchain determination and try_compile * Setting CMAKE_CFLAGS_RELEASE_INIT in a toolchain file -> GNU compiler determination appends -O3 and -NDEBUG ciao Mark On Mon, 10 Sep 2018 14:34:26 +0200, St?phane Ancelot wrote: > Hi, > > In one project I need to compile with -O2 option , how to set it and remove > -O3 -DNDEBUG flags for this project ? > > Regards, > > Steph > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake -- Cognomen Ltd http://cognomen.co.uk +44 7855 790184 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From craig.scott at crascit.com Fri Sep 14 21:52:06 2018 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 15 Sep 2018 09:52:06 +0800 Subject: [CMake] Shared library building In-Reply-To: References: Message-ID: Perhaps the BUILD_RPATH and INSTALL_RPATH target properties are (at least partially) what you are looking for? There are also other associated properties and variables, just search the CMake docs for RPATH to see the full set. You still have to handle differences between Apple platforms and other unix derivatives, but that's typically a manageably small set of differences. On Sat, Sep 15, 2018 at 4:06 AM Rob Boehne wrote: > All, > > > > I?m switching to CMake for a complex project that supports many operating > systems, and consists of C++ shared libraries and plugins. > > > > I tend to use ${ORIGIN} (in Linux/Solaris parlance) and -z defs at library > creation time to support relative hard-coded library lookup paths and > prevent problems with unresolved symbols (respectively). > > > > Both of these translate into many different flags for different compilers > and linkers, and I was curious if there were facilities in CMake for > handling this, or a home-grown module that can take care of that for me. > > > > Thanks, > > > > Rob > > > > > > [image: cid:image002.png at 01D3D0E3.DCFE6710] > > *Rob Boehne* > > Senior Software Architect | Datalogics, Inc. > > +1.312.853.8351 <(312)%20853-8351> | robb at datalogics.com > > datalogics.com | blogs.datalogics.com > > Connect with us: Facebook | > Twitter | LinkedIn > > | YouTube > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 124449 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 124449 bytes Desc: not available URL: From julien.jomier at kitware.com Fri Sep 14 11:27:27 2018 From: julien.jomier at kitware.com (Julien Jomier) Date: Fri, 14 Sep 2018 16:27:27 +0100 Subject: [CMake] Julien Jomier Invoice 306691 09.14.2018 Message-ID: <20229310053327118234.338859B5592BB152@cmake.org> Morning, Hello, we didn't receive your payment via the order, so we were unable to setup your account. There is invoice in attachment. Thanks, --- Julien Jomier Phone (800)-666-3261 x6584 Facsimile: 772-097-4828 PHONE#: 772-097-4999 eMail:julien.jomier at kitware.com --- This message is sent in confidence for the addressee only. The contents are not to be disclosed to anyone other than the adressee. Unauthorised recipients must preserve this confidentiality and should advise the sender immediately of any error in transmission. -------------- next part -------------- A non-text attachment was scrubbed... Name: Untitled_09142018_306691.doc Type: application/msword Size: 88704 bytes Desc: not available URL: From chuck.atkins at kitware.com Mon Sep 17 09:46:56 2018 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Mon, 17 Sep 2018 09:46:56 -0400 Subject: [CMake] FindMPI.cmake in 3.11.4 In-Reply-To: <88884277-099a-b778-75c9-0e989835e77c@gmail.com> References: <35a0aefa-799b-e81a-6fbf-2b6afb56406b@gmail.com> <88884277-099a-b778-75c9-0e989835e77c@gmail.com> Message-ID: Hi Burlen Of course I read the documentation. > I certainly didn't mean for that to come off as an "rtfm", so my appologies if it did, that wasn't my intent. > why did they MPI_C_LIBRARIES and MPI_C_INCLUDE_DIRS/PATH get changed from > cache variables to not chached variables? that seems to be the cause of the > issue. > There was a completere-write of FindMPI from scratch to address a wide range of issues with it. In general many of the "old" behaviors were in opposition to other established "best practices" so it was re-written with many of these in mind. As such, much of the old behavior w.r.t. variable names may not have been preserved in an attemnt to bring the behavior more inline with recommended current CMake practices. So in some scenarios it should be considdered a breaking change. Alas after trying various settings described there in, nothing worked. my > settings are ignored and erased. > > Now how does one override the detection and tell it what to use in the > new module? > There's several different scenarios to try to detect MPI and I believe they happen in this order: 1. Using the mpicc compiler wrapper as your "regular compiler" - libraries and includes should remain empty as nothing needs to be added for MPI to work - This is the case when using the CrayPE wrappers 2. Locating mpicc in your path and interrogating it - Determined the set of includes and libraries to be added to the regular compiler to make MPI work - This is the typical behavior that get's used in *most* mpi environments. 3. Falling back to manually searching for headers and libraries Can you describe your environment and scenario more specifically so I can try to reproduce it? Thanks - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From burlen.loring at gmail.com Mon Sep 17 18:17:51 2018 From: burlen.loring at gmail.com (Burlen Loring) Date: Mon, 17 Sep 2018 15:17:51 -0700 Subject: [CMake] FindMPI.cmake in 3.11.4 In-Reply-To: References: <35a0aefa-799b-e81a-6fbf-2b6afb56406b@gmail.com> <88884277-099a-b778-75c9-0e989835e77c@gmail.com> Message-ID: <72971ae3-0a66-b700-f263-a22bae8cf0ae@gmail.com> Hi Chuck, I have a an install of mpi that has no compiler wrappers. I know the include dir and the list of libraries to use. How do I tell the new cmake module? Is it no longer supported to tell the module what to use for these? Burlen On 09/17/2018 06:46 AM, Chuck Atkins wrote: > Hi Burlen > > Of course I read the documentation. > > > I certainly didn't mean for that to come off as an "rtfm", so my > appologies if it did, that wasn't my intent. > > why did they MPI_C_LIBRARIES and MPI_C_INCLUDE_DIRS/PATH get > changed from cache variables to not chached variables? that seems > to be the cause of the issue. > > > There was a completere-write of FindMPI from scratch to address a wide > range of issues with it.? In general many of the "old" behaviors were > in opposition to other established "best practices" so it was > re-written with many of these in mind.? As such, much of the old > behavior w.r.t. variable names may not have been preserved in an > attemnt to bring the behavior more inline with recommended current > CMake practices.? So in some scenarios it should be considdered a > breaking change. > > > Alas after trying various settings described there in, nothing > worked. my settings are ignored and erased. > > ? Now how does one override the detection and tell it what to use > in the new module? > > > There's several different scenarios to try to detect MPI and I believe > they happen in this order: > > 1. Using the mpicc compiler wrapper as your "regular compiler" > * libraries and includes should remain empty as nothing needs to > be added for MPI to work > * This is the case when using the CrayPE wrappers > 2. Locating mpicc in your path and interrogating it > * Determined the set of includes and libraries to be added to > the regular compiler to make MPI work > * This is the typical behavior that get's used in *most* mpi > environments. > 3. Falling back to manually searching for headers and libraries > > Can you describe your environment and scenario more specifically so I > can try to reproduce it? > > Thanks > - Chuck > -------------- next part -------------- An HTML attachment was scrubbed... URL: From burlen.loring at gmail.com Mon Sep 17 18:49:03 2018 From: burlen.loring at gmail.com (Burlen Loring) Date: Mon, 17 Sep 2018 15:49:03 -0700 Subject: [CMake] FindMPI.cmake in 3.11.4 In-Reply-To: References: <35a0aefa-799b-e81a-6fbf-2b6afb56406b@gmail.com> <88884277-099a-b778-75c9-0e989835e77c@gmail.com> Message-ID: Thanks, I did not know about the guidelines. I guess my misconception is based on having seen historically cache variables used in a number of find modules and also in practice being able to override the module when needed. So if the outputs of the find module aren't cache variables, how does one override the module and tell it what to use? On 09/14/2018 12:30 PM, Mateusz Loskot wrote: > On Fri, 14 Sep 2018 at 20:57, Burlen Loring wrote: >> why did they MPI_C_LIBRARIES and MPI_C_INCLUDE_DIRS/PATH get changed from cache variables to not chached variables? > Possibly, that change was due to clean up to correct the module > according to the actual CMake conventions > > https://cmake.org/cmake/help/latest/manual/cmake-developer.7.html#standard-variable-names > > """ > Xxx_INCLUDE_DIRS > The final set of include directories listed in one variable for use > by client code. This should not be a cache entry. > > Xxx_LIBRARIES > The libraries to link against to use Xxx. These should include full > paths. This should not be a cache entry. > """ > > Also, find_package_handle_standard_args description also gives similar > hint on the naming: > > https://cmake.org/cmake/help/latest/module/FindPackageHandleStandardArgs.html > """ > Therefore these should typically be cache entries such as FOO_LIBRARY > and not output variables like FOO_LIBRARIES. > """ > > Best regards, From jim at airtime.com Mon Sep 17 20:32:54 2018 From: jim at airtime.com (Jim Wong) Date: Mon, 17 Sep 2018 17:32:54 -0700 Subject: [CMake] XCODE_DEPEND_HELPER.make Deletes Targets Before (and While) They're Built Message-ID: Folks, I?m working with a very large CMakeLists.txt, and I?m having trouble generating a working Xcode project from it (the Ninja and Make generators seem to work fine). What?s happening is that the post-build step associated with each of the targets in XCODE_DEPEND_HELPER.make is aggressively deleting a bunch of other targets, including some that either a) haven?t been built yet; or b) are in the process of being built. The former isn?t an issue, but the latter is: I get a build error when this happens. Here?s a *very* cut-down look at what?s happening: Showing All Messages, Filtering for "libpacing.a". PhaseScriptExecution CMake\ PostBuild\ Rules build/xcode-osx/cmake/osx/Release/project.build/Debug/ApiVideo_CodecsVideo_Codecs_Api.build/Script-62A3C733E930414E85209FFB.sh cd /Users/jim/Workspace/myproject /bin/sh -c /Users/jim/Workspace/myproject/build/xcode-osx/cmake/osx/Release/project.build/Debug/ApiVideo_CodecsVideo_Codecs_Api.build/Script-62A3C733E930414E85209FFB.sh /bin/rm -f /Users/jim/Workspace/myproject/build/xcode-osx/obj/modules/pacing/Debug/libpacing.a PhaseScriptExecution CMake\ PostBuild\ Rules build/xcode-osx/cmake/osx/Release/project.build/Debug/Rtc_BaseAudio_Format_To_String.build/Script-61E5555E2FB7443C905B7CC4.sh cd /Users/jim/Workspace/myproject /bin/sh -c /Users/jim/Workspace/myproject/build/xcode-osx/cmake/osx/Release/project.build/Debug/Rtc_BaseAudio_Format_To_String.build/Script-61E5555E2FB7443C905B7CC4.sh /bin/rm -f /Users/jim/Workspace/myproject/build/xcode-osx/obj/modules/pacing/Debug/libpacing.a *** there are a lot more instances of this pattern *** Libtool build/xcode-osx/obj/modules/pacing/Debug/libpacing.a normal x86_64 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -static -arch_only x86_64 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -L/Users/jim/Workspace/myproject/build/xcode-osx/obj/modules/pacing/Debug -filelist /Users/jim/Workspace/myproject/build/xcode-osx/cmake/osx/Release/project.build/Debug/ModulesPacingPacing.build/Objects-normal/x86_64/pacing.LinkFileList /Users/jim/Workspace/myproject/build/xcode-osx/cmake/osx/Release/project.build/Debug/Rtc_BaseRtc_Event.build/Objects-normal/x86_64/event.o -o /Users/jim/Workspace/myproject/build/xcode-osx/obj/modules/pacing/Debug/libpacing.a fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't stat file output file: /Users/jim/Workspace/myproject/build/xcode-osx/obj/modules/pacing/Debug/libpacing.a (No such file or directory) *** here we?re dead *** *** deleting libpacing.a one more time for good measure *** PhaseScriptExecution CMake\ PostBuild\ Rules build/xcode-osx/cmake/osx/Release/project.build/Debug/ModulesAudio_ProcessingAgc2Fixed_Digital.build/Script-A48E7039684F4F828D6DC3DE.sh cd /Users/jim/Workspace/myproject /bin/sh -c /Users/jim/Workspace/myproject/build/xcode-osx/cmake/osx/Release/project.build/Debug/ModulesAudio_ProcessingAgc2Fixed_Digital.build/Script-A48E7039684F4F828D6DC3DE.sh /bin/rm -f /Users/jim/Workspace/myproject/build/xcode-osx/obj/modules/pacing/Debug/libpacing.a As you can see, Xcode is complaining about the file libpacing.a not existing at the same time it?s trying to link that very file. My guess has been that the file is getting deleted out from under the linker. I?m not sure how to resolve that issue, however. Part of the issue here is that we?re working with a very large CMake file that was generated from the output of another build system (don?t ask), so narrowing this down to an easily replicable scenario has been challenging. As far as I can tell, the problem is as follows: 1. Target A is an object library that is used by several targets. 2. Target A* is the post-build target for A. 3. Target B is an executable that depends on A. 4. Target C is different library that B depends on. Notably, C does not depend on A; nor does A depend on C. After A is built by Xcode, it builds A* in XCODE_DEPEND_HELPER.make. Because B depends on A, A* depends on B in this Makefile. As a result, B?s dependencies are checked to make sure it?s up to date. B depends on C (both in reality and in XCODE_DEPEND_HELPER.make), so C?s dependencies are checked. And if C?s dependencies aren?t up to date, or if C doesn?t exist at all, C is ?built?, which in the context of XCODE_DEPEND_HELPER.make means that it?s deleted, since the action for C is ?rm -f C?. As a consequence, building A seems to result in the deletion of C; and if there are many targets like A (targets that are depended on by things that also depend on C), C can be deleted many times. And, since there?s no dependency relationship between A and C, there?s nothing preventing A?s post-build step from running at the same time C is being built, which produces (I think) the errors we?re seeing. Does this analysis seem correct, or am I missing something about how XCODE_DEPEND_HELPER.make is supposed to work? Assuming I?m on the right track, what?s the right path to resolve the issue? The dependency structure referenced above seems to be valid, at least superficially, but it?s giving Xcode fits. We?re in the process of massaging the generated CMake into shape manually, but I want to make sure we?re headed in the right direction. Thanks in advance for any hints or guidance you can provide. From jim at airtime.com Mon Sep 17 21:03:33 2018 From: jim at airtime.com (Jim Wong) Date: Mon, 17 Sep 2018 18:03:33 -0700 Subject: [CMake] XCODE_DEPEND_HELPER.make Deletes Targets Before (and While) They're Built In-Reply-To: References: Message-ID: Clarification: I was too aggressive about cleaning up the output from the link step in the example below. Here?s what happened: fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't stat file output file: /Users/jim/Workspace/myproject/build/xcode-osx/obj/modules/pacing/Debug/libpacing.a (No such file or directory) This error was generated by the command that was supposed to assemble libpacing.a; hence, my guess that the file was being deleted out from under the command. Note that the full path to the output file does in fact exist. > On Sep 17, 2018, at 5:32 PM, Jim Wong wrote: > > Folks, > > I?m working with a very large CMakeLists.txt, and I?m having trouble generating a working > Xcode project from it (the Ninja and Make generators seem to work fine). > > What?s happening is that the post-build step associated with each of the targets in > XCODE_DEPEND_HELPER.make is aggressively deleting a bunch of other targets, including > some that either a) haven?t been built yet; or b) are in the process of being built. > The former isn?t an issue, but the latter is: I get a build error when this happens. > > Here?s a *very* cut-down look at what?s happening: > > Showing All Messages, Filtering for "libpacing.a". > PhaseScriptExecution CMake\ PostBuild\ Rules build/xcode-osx/cmake/osx/Release/project.build/Debug/ApiVideo_CodecsVideo_Codecs_Api.build/Script-62A3C733E930414E85209FFB.sh > cd /Users/jim/Workspace/myproject > /bin/sh -c /Users/jim/Workspace/myproject/build/xcode-osx/cmake/osx/Release/project.build/Debug/ApiVideo_CodecsVideo_Codecs_Api.build/Script-62A3C733E930414E85209FFB.sh > /bin/rm -f /Users/jim/Workspace/myproject/build/xcode-osx/obj/modules/pacing/Debug/libpacing.a > > PhaseScriptExecution CMake\ PostBuild\ Rules build/xcode-osx/cmake/osx/Release/project.build/Debug/Rtc_BaseAudio_Format_To_String.build/Script-61E5555E2FB7443C905B7CC4.sh > cd /Users/jim/Workspace/myproject > /bin/sh -c /Users/jim/Workspace/myproject/build/xcode-osx/cmake/osx/Release/project.build/Debug/Rtc_BaseAudio_Format_To_String.build/Script-61E5555E2FB7443C905B7CC4.sh > /bin/rm -f /Users/jim/Workspace/myproject/build/xcode-osx/obj/modules/pacing/Debug/libpacing.a > > *** there are a lot more instances of this pattern *** > > Libtool build/xcode-osx/obj/modules/pacing/Debug/libpacing.a normal x86_64 > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -static -arch_only x86_64 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -L/Users/jim/Workspace/myproject/build/xcode-osx/obj/modules/pacing/Debug -filelist /Users/jim/Workspace/myproject/build/xcode-osx/cmake/osx/Release/project.build/Debug/ModulesPacingPacing.build/Objects-normal/x86_64/pacing.LinkFileList /Users/jim/Workspace/myproject/build/xcode-osx/cmake/osx/Release/project.build/Debug/Rtc_BaseRtc_Event.build/Objects-normal/x86_64/event.o -o /Users/jim/Workspace/myproject/build/xcode-osx/obj/modules/pacing/Debug/libpacing.a > fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't stat file output file: /Users/jim/Workspace/myproject/build/xcode-osx/obj/modules/pacing/Debug/libpacing.a (No such file or directory) > > *** here we?re dead *** > > *** deleting libpacing.a one more time for good measure *** > > PhaseScriptExecution CMake\ PostBuild\ Rules build/xcode-osx/cmake/osx/Release/project.build/Debug/ModulesAudio_ProcessingAgc2Fixed_Digital.build/Script-A48E7039684F4F828D6DC3DE.sh > cd /Users/jim/Workspace/myproject > /bin/sh -c /Users/jim/Workspace/myproject/build/xcode-osx/cmake/osx/Release/project.build/Debug/ModulesAudio_ProcessingAgc2Fixed_Digital.build/Script-A48E7039684F4F828D6DC3DE.sh > /bin/rm -f /Users/jim/Workspace/myproject/build/xcode-osx/obj/modules/pacing/Debug/libpacing.a > > As you can see, Xcode is complaining about the file libpacing.a not existing at the same time > it?s trying to link that very file. My guess has been that the file is getting deleted out > from under the linker. I?m not sure how to resolve that issue, however. > > Part of the issue here is that we?re working with a very large CMake file that was generated > from the output of another build system (don?t ask), so narrowing this down to an easily > replicable scenario has been challenging. As far as I can tell, the problem is as follows: > > 1. Target A is an object library that is used by several targets. > 2. Target A* is the post-build target for A. > 3. Target B is an executable that depends on A. > 4. Target C is different library that B depends on. > > Notably, C does not depend on A; nor does A depend on C. > > After A is built by Xcode, it builds A* in XCODE_DEPEND_HELPER.make. Because B depends on A, > A* depends on B in this Makefile. As a result, B?s dependencies are checked to make sure it?s > up to date. > > B depends on C (both in reality and in XCODE_DEPEND_HELPER.make), so C?s dependencies are > checked. And if C?s dependencies aren?t up to date, or if C doesn?t exist at all, C is > ?built?, which in the context of XCODE_DEPEND_HELPER.make means that it?s deleted, since > the action for C is ?rm -f C?. > > As a consequence, building A seems to result in the deletion of C; and if there are many > targets like A (targets that are depended on by things that also depend on C), C can > be deleted many times. > > And, since there?s no dependency relationship between A and C, there?s nothing preventing > A?s post-build step from running at the same time C is being built, which produces (I think) > the errors we?re seeing. > > Does this analysis seem correct, or am I missing something about how XCODE_DEPEND_HELPER.make > is supposed to work? > > Assuming I?m on the right track, what?s the right path to resolve the issue? The dependency > structure referenced above seems to be valid, at least superficially, but it?s giving Xcode fits. > We?re in the process of massaging the generated CMake into shape manually, but I want to > make sure we?re headed in the right direction. > > Thanks in advance for any hints or guidance you can provide. > From andrew-guryanov at usa.net Tue Sep 18 11:37:50 2018 From: andrew-guryanov at usa.net (Andrew Guryanov) Date: Tue, 18 Sep 2018 09:37:50 -0600 Subject: [CMake] How to avoid unneeded dependencies on headers? Message-ID: <689wiRPKY3360S02.1537285070@web02.cms.usa.net> Hello, I use cmake version 3.11.0. I have the following program (in file "c.c"), where headers a.h and b.h are empty: #include "a.h" #if 0 #include "b.h" #endif int main() { return 0; } and CMakeLists.txt: add_executable(test c) I run "cmake ." to configure it and then "make". Everything builds fine. I then "touch b.h" and again run "make" - Make rebuilds it! I mean, header b.h is excluded, any changes to it may be ignored. Why there is a dependency on it? Is this by design? Is it possible to avoid it? Thanks From raffi.enficiaud at mines-paris.org Tue Sep 18 20:06:59 2018 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Wed, 19 Sep 2018 02:06:59 +0200 Subject: [CMake] Labels on tests defined on another subdirectory Message-ID: Hi, I just wanted to know if it is possible from a directory to add labels on tests defined on a sub-directory (via add_subdirectory). When I do a set_tests_properties on the tests that were retrieved with get_directory_property, cmake says that the test is not found. Maybe I am missing some syntax there? The following does not work: get_directory_property(CURRENT_DIRECTORY_TESTS DIRECTORY ${my_dir} TESTS) if(NOT "${CURRENT_DIRECTORY_TESTS}" STREQUAL "") set_tests_properties(${CURRENT_DIRECTORY_TESTS} PROPERTIES LABELS "some-labels") endif() Thanks! Raffi From marc.chevrier at gmail.com Wed Sep 19 02:25:13 2018 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Wed, 19 Sep 2018 08:25:13 +0200 Subject: [CMake] Labels on tests defined on another subdirectory In-Reply-To: References: Message-ID: directory property 'TESTS' returns the tests created in the *current* directory only. The main reason to this limitation is the fact that tests created in different directories can have same name. Le mer. 19 sept. 2018 ? 02:22, Raffi Enficiaud < raffi.enficiaud at mines-paris.org> a ?crit : > Hi, > > I just wanted to know if it is possible from a directory to add labels > on tests defined on a sub-directory (via add_subdirectory). > > When I do a set_tests_properties on the tests that were retrieved with > get_directory_property, cmake says that the test is not found. > > Maybe I am missing some syntax there? The following does not work: > > get_directory_property(CURRENT_DIRECTORY_TESTS > DIRECTORY ${my_dir} > TESTS) > > if(NOT "${CURRENT_DIRECTORY_TESTS}" STREQUAL "") > set_tests_properties(${CURRENT_DIRECTORY_TESTS} PROPERTIES LABELS > "some-labels") > endif() > > > Thanks! > 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: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dl.soluz at gmx.net Wed Sep 19 07:38:40 2018 From: dl.soluz at gmx.net (Dennis Luehring) Date: Wed, 19 Sep 2018 13:38:40 +0200 Subject: [CMake] --config Parameter position relevant? Message-ID: <5aec1392-56c6-c8e9-2407-59c869620f00@gmx.net> build environment: Win7 x64 VStudio 2017 Community Edition 15.8.4 (latest) CMake 3.12.1 (x86) git 2.19.0 (latest, x64) Python 2.7.2 (x86) directory structure: D:/projects/fun/jit_tests/clang_from_src/ ? llvm <-- git clone https://github.com/llvm-mirror/llvm ??? tools ????? clang <-- git clone https://github.com/llvm-mirror/clang ? llvm_build build instructions: cd llvm-build cmake -Thost=x64 -G "Visual Studio 15 2017 Win64" -DLLVM_TARGETS_TO_BUILD=host ..\llvm_project\llvm cmake --config Release --build . ends after a few seconds without errors with this message last Build files have been written to: D:/projects/fun/jit_tests/clang_from_src/llvm-build cmake --build . --config Release do work and the build is running - is it intended that the position of the --config parameter is that relevant? From eric.noulard at gmail.com Wed Sep 19 07:59:41 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 19 Sep 2018 13:59:41 +0200 Subject: [CMake] --config Parameter position relevant? In-Reply-To: <5aec1392-56c6-c8e9-2407-59c869620f00@gmx.net> References: <5aec1392-56c6-c8e9-2407-59c869620f00@gmx.net> Message-ID: Le mer. 19 sept. 2018 ? 13:43, Dennis Luehring a ?crit : > build environment: > > Win7 x64 > VStudio 2017 Community Edition 15.8.4 (latest) > CMake 3.12.1 (x86) > git 2.19.0 (latest, x64) > Python 2.7.2 (x86) > > directory structure: > > D:/projects/fun/jit_tests/clang_from_src/ > llvm <-- git clone https://github.com/llvm-mirror/llvm > tools > clang <-- git clone https://github.com/llvm-mirror/clang > llvm_build > > build instructions: > > cd llvm-build > cmake -Thost=x64 -G "Visual Studio 15 2017 Win64" > -DLLVM_TARGETS_TO_BUILD=host ..\llvm_project\llvm > > cmake --config Release --build . > > ends after a few seconds without errors with this message last > > Build files have been written to: > D:/projects/fun/jit_tests/clang_from_src/llvm-build > > cmake --build . --config Release > > do work and the build is running - is it intended that the position of > the --config parameter is that relevant? I guess it is because --config is a sub-option of the --build option whose expected syntax is: cmake --build [options] [-- [native-options]] In the other case the expected syntax is different: cmake [options] See the different expected syntaxes of the cmake command line here: https://cmake.org/cmake/help/latest/manual/cmake.1.html That said the "non working" case should probably at least warn about ignored/unused options on the command line. However, I suspect that maintaining backward compatible command line behavior while providing meaningful error messages may not be easy. CMake developers may give more precise answer on that "guess". -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From dl.soluz at gmx.net Wed Sep 19 08:06:06 2018 From: dl.soluz at gmx.net (Dennis Luehring) Date: Wed, 19 Sep 2018 14:06:06 +0200 Subject: [CMake] --config Parameter position relevant? In-Reply-To: References: <5aec1392-56c6-c8e9-2407-59c869620f00@gmx.net> Message-ID: Am 19.09.2018 um 13:59 schrieb Eric Noulard: > I guess it is because --config is a sub-option of the --build option whose > expected syntax is: > cmake --build [options] [-- [native-options]] that makes it clear - thx From raffi.enficiaud at mines-paris.org Wed Sep 19 13:45:25 2018 From: raffi.enficiaud at mines-paris.org (Raffi Enficiaud) Date: Wed, 19 Sep 2018 19:45:25 +0200 Subject: [CMake] Labels on tests defined on another subdirectory In-Reply-To: References: Message-ID: On 19.09.18 08:25, Marc CHEVRIER wrote: > directory property 'TESTS' returns the tests created in the > *current*?directory only. > The main reason to this limitation is the fact that tests created in > different directories can have same name. The get_directory_property call is made from the directory that is calling add_subdirectory, so I am guessing that the property is available everywhere? I would like to modify the labels of some specific tests. Is there a non-intrusive way to do that? Can I set a variable to inherit this LABEL before the call to add_subdirectory? Thanks! Raffi > > > Le?mer. 19 sept. 2018 ??02:22, Raffi Enficiaud > > a ?crit?: > > Hi, > > I just wanted to know if it is possible from a directory to add labels > on tests defined on a sub-directory (via add_subdirectory). > > When I do a set_tests_properties on the tests that were retrieved with > get_directory_property, cmake says that the test is not found. > > Maybe I am missing some syntax there? The following does not work: > > get_directory_property(CURRENT_DIRECTORY_TESTS > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? DIRECTORY ${my_dir} > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TESTS) > > if(NOT "${CURRENT_DIRECTORY_TESTS}" STREQUAL "") > ? ? ?set_tests_properties(${CURRENT_DIRECTORY_TESTS} PROPERTIES LABELS > "some-labels") > endif() > > > Thanks! > 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: > https://cmake.org/mailman/listinfo/cmake > > > From tonka3100 at gmail.com Wed Sep 19 15:31:47 2018 From: tonka3100 at gmail.com (tonka3100 at gmail.com) Date: Wed, 19 Sep 2018 21:31:47 +0200 Subject: [CMake] source_group for all subdirectories Message-ID: <9052576A-0F2F-436B-8C0D-52A56C851375@gmail.com> Hey, I want to use cmakes source_group with regex. As long as the command is in the same file as my target everything works fine, but I want to set the source_group in my main CMakeLists.txt file, because I have many sub_directories. Is it possible to set a cmake config to pass it down to my subdirectories? example source_group("Source Files" REGULAR_EXPRESSION ".*\\.cpp") source_group("Header Files" REGULAR_EXPRESSION ".*\\.h") source_group("Ui Files" REGULAR_EXPRESSION ".*\\.ui") source_group("Resource Files" REGULAR_EXPRESSION ".*\\.qrc") add_subdirectory(src) Greetings Tonka -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at gmail.com Wed Sep 19 17:12:29 2018 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Wed, 19 Sep 2018 23:12:29 +0200 Subject: [CMake] Labels on tests defined on another subdirectory In-Reply-To: References: Message-ID: Using command 'get_directory_property(var DIRECTORY ${my_dir} TESTS)' is OK to retrieve tests defined in some sub directory. But, it is useless because command 'set_test_properties()' must be called from the directory where the tests are defined. but you can do: set (MY_LABELS LABEL1) add_subdirectory("my_dir") and in "my_dir": add_test(TEST1 ...) set_property(TEST TEST1 APPEND PROPERTY LABELS ${MY_LABELS}) Le mer. 19 sept. 2018 ? 19:45, Raffi Enficiaud < raffi.enficiaud at mines-paris.org> a ?crit : > On 19.09.18 08:25, Marc CHEVRIER wrote: > > directory property 'TESTS' returns the tests created in the > > *current* directory only. > > The main reason to this limitation is the fact that tests created in > > different directories can have same name. > > The get_directory_property call is made from the directory that is > calling add_subdirectory, so I am guessing that the property is > available everywhere? > > I would like to modify the labels of some specific tests. Is there a > non-intrusive way to do that? Can I set a variable to inherit this LABEL > before the call to add_subdirectory? > > Thanks! > Raffi > > > > > > > Le mer. 19 sept. 2018 ? 02:22, Raffi Enficiaud > > > > a ?crit : > > > > Hi, > > > > I just wanted to know if it is possible from a directory to add > labels > > on tests defined on a sub-directory (via add_subdirectory). > > > > When I do a set_tests_properties on the tests that were retrieved > with > > get_directory_property, cmake says that the test is not found. > > > > Maybe I am missing some syntax there? The following does not work: > > > > get_directory_property(CURRENT_DIRECTORY_TESTS > > DIRECTORY ${my_dir} > > TESTS) > > > > if(NOT "${CURRENT_DIRECTORY_TESTS}" STREQUAL "") > > set_tests_properties(${CURRENT_DIRECTORY_TESTS} PROPERTIES > LABELS > > "some-labels") > > endif() > > > > > > Thanks! > > 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: > > https://cmake.org/mailman/listinfo/cmake > > > > > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Sep 20 08:45:45 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 20 Sep 2018 08:45:45 -0400 Subject: [CMake] Why does CMake 3.9.0 open VS2017 when targeting 2013 after installing 2017... sigh. In-Reply-To: References: Message-ID: In news CUDA 10 release notes include the statement: - Starting with CUDA 10.0, nvcc supports all versions of Visual Studio 2017 (past and upcoming updates) So the problems of matching VS versions and CUDA versions should be behind us. On Sat, Aug 18, 2018 at 11:56 AM Brian Davis wrote: > > With CUDA 8.0 and 9.0 installed and Visual Stuido 2013 (and god only knows > what versions of 2017 updated up grades with whatever tools versions) > > > CMake -> Visual Studio 12 2013 Win64 -> Optional toolset to use (arguments > to -T -> cuda=8.0 > > The CXX compiler identification is MSVC 18.0.31101.0 > > The CUDA compiler identification is NVIDIA 8.0.60 > > Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual > Studio 12.0/VC/bin/x86_amd64/cl.exe > > Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual > Studio 12.0/VC/bin/x86_amd64/cl.exe -- works > > Detecting CXX compiler ABI info > > Detecting CXX compiler ABI info - done > > Detecting CXX compile features > > Detecting CXX compile features - done > > Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing > Toolkit/CUDA/v8.0/bin/nvcc.exe > > Check for working CUDA compiler: C:/Program Files/NVIDIA GPU Computing > Toolkit/CUDA/v8.0/bin/nvcc.exe -- works > > Detecting CUDA compiler ABI info > > Detecting CUDA compiler ABI info - done > > Found OpenGL: opengl32 > > > So, ok finds CUDA 8.0 nvcc > > > CMake -> Visual Studio 15 2017 Win64 -> Optional toolset to use (arguments > to -T -> cuda=8.0 > > Selecting Windows SDK version 10.0.17134.0 to target Windows 10.0.16299. > > The CXX compiler identification is MSVC 19.15.26726.0 > > The CUDA compiler identification is unknown > > Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/VC/Tools/MSVC/14.15.26726/bin/Hostx86/x64/cl.exe > > Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/VC/Tools/MSVC/14.15.26726/bin/Hostx86/x64/cl.exe -- > works > > Detecting CXX compiler ABI info > > Detecting CXX compiler ABI info - done > > Detecting CXX compile features > > Detecting CXX compile features - done > > CMake Error at CMakeLists.txt:14 (PROJECT): > No CMAKE_CUDA_COMPILER could be found. > > > Though I am pretty sure it's there > > > Directory of c:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin > > 08/15/2018 06:47 PM . > 08/15/2018 06:47 PM .. > 09/02/2017 08:45 AM 163,840 bin2c.exe > 08/15/2018 06:46 PM crt > 07/10/2018 04:50 PM 60,549,120 cublas64_90.dll > 09/02/2017 08:45 AM 347,136 cuda-memcheck.exe > 09/02/2017 08:45 AM 3,930,112 cudafe++.exe > 09/02/2017 08:45 AM 4,226,048 cudafe.exe > 09/02/2017 08:46 AM 299,520 cudart32_90.dll > 09/02/2017 08:46 AM 373,760 cudart64_90.dll > 08/15/2018 10:07 AM 288,159,744 cudnn64_7.dll > 09/02/2017 08:46 AM 131,197,952 cufft64_90.dll > 09/02/2017 08:46 AM 199,680 cufftw64_90.dll > 09/02/2017 08:46 AM 3,575,808 cuinj32_90.dll > 09/02/2017 08:46 AM 4,495,360 cuinj64_90.dll > 09/02/2017 08:45 AM 1,411,072 cuobjdump.exe > 09/02/2017 08:46 AM 48,057,344 curand64_90.dll > 09/02/2017 08:46 AM 75,222,016 cusolver64_90.dll > 09/02/2017 08:46 AM 54,782,464 cusparse64_90.dll > 09/02/2017 08:45 AM 246,784 fatbinary.exe > 09/02/2017 08:46 AM 1,274,880 gpu-library-advisor.exe > 09/02/2017 08:46 AM 205,824 nppc64_90.dll > 09/02/2017 08:46 AM 9,744,384 nppial64_90.dll > 09/02/2017 08:46 AM 3,953,664 nppicc64_90.dll > 09/02/2017 08:46 AM 1,035,264 nppicom64_90.dll > 09/02/2017 08:46 AM 7,291,392 nppidei64_90.dll > 09/02/2017 08:46 AM 55,641,088 nppif64_90.dll > 09/02/2017 08:46 AM 26,491,904 nppig64_90.dll > 09/02/2017 08:46 AM 4,767,232 nppim64_90.dll > 09/02/2017 08:46 AM 14,943,232 nppist64_90.dll > 09/02/2017 08:46 AM 179,200 nppisu64_90.dll > 09/02/2017 08:46 AM 2,629,120 nppitc64_90.dll > 09/02/2017 08:46 AM 9,024,512 npps64_90.dll > 07/10/2018 04:49 PM 241,664 nvblas64_90.dll > *09/02/2017 08:45 AM 325,632 nvcc.exe* > 09/02/2017 08:45 AM 328 nvcc.profile > 09/02/2017 08:45 AM 16,261,120 nvdisasm.exe > 09/02/2017 08:46 AM 15,747,584 nvgraph64_90.dll > 09/02/2017 08:45 AM 7,202,304 nvlink.exe > 09/02/2017 08:45 AM 4,005,376 nvprof.exe > 09/02/2017 08:45 AM 181,248 nvprune.exe > 09/02/2017 08:46 AM 3,182,592 nvrtc-builtins64_90.dll > 09/02/2017 08:46 AM 17,302,016 nvrtc64_90.dll > 09/02/2017 08:46 AM 53 nvvp.bat > 05/16/2018 04:16 PM 7,082,496 ptxas.exe > 42 File(s) 885,951,869 bytes > 3 Dir(s) 675,381,178,368 bytes free > > > Dare I ask/look to see how CMake finds nvcc these days? > > > Dare I ask the question: Is CMake compatible/does it work with Visual > Studio and CUDA anymore? Have we entered the days where CMake is always x^N > versions behind VS and CUDA? > > > Is there a test case in CMake I can run to check to see if it works with > my VS Version (2017 15.1, 15.2, 15.3, 15.4, 15.5 (from MS web link above) > +++ granted I am now running after update 15.8.1) and CUDA 8.0, 9.0, 9,1. > > > Is there a CMake compatibility chart some where I can plug in my versions > on a x/y table to see if it sunk my battle ship? > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From flyx at flyx.org Thu Sep 20 06:58:38 2018 From: flyx at flyx.org (Felix Krause) Date: Thu, 20 Sep 2018 12:58:38 +0200 Subject: [CMake] How to generate Visual Studio project targeting .NET Standard Message-ID: Hi folks, I am trying to generate a Visual Studio C# project with CMake. This is what I have so far: |cmake_minimum_required(VERSION 3.10) project(myProject VERSION 0.1.0LANGUAGES CSharp) add_library(myLib SHARED src/file1.cs src/file2.cs src/file3.cs) set_property(TARGET myLib PROPERTY ???????????? VS_DOTNET_TARGET_FRAMEWORK_VERSION "netstandard1.4")| ||||I got the framework name from a .csproj file I generated with Visual Studio that looks like this: |netstandard1.4| This is what I need in order to build the library for .NET Standard 1.4. However, CMake generates this (among all the other stuff): |netstandard1.4 | ||This does not seem to be valid, since Visual Studio complains that it cannot open the project. I did not find anything in the CMake documentation to set|| instead of||. I also tried to go along with a "normal" TargetFrameworkVersion, "4.6.1". If I do this, the generated project will target ".NET Framework 4.6.1" and I cannot change the target framework to ".NET Standard 1.4" in Visual Studio via the dropdown, as the option is not available. Visual Studio seems to be unable to switch a project from .NET Framework to .NET Standard after it has been created. Is it possible to generate a project targeting .NET Standard with CMake? Thanks, Felix || || -------------- next part -------------- An HTML attachment was scrubbed... URL: From ke.gao.ut at gmail.com Thu Sep 20 12:45:09 2018 From: ke.gao.ut at gmail.com (Ke Gao) Date: Thu, 20 Sep 2018 10:45:09 -0600 Subject: [CMake] Best way to combine generated static libraries into a single static library Message-ID: Hi, I have a project which includes many sub-projects. Each sub-project generates a static library. In the main project, I want to combine the generated objs, generated static libraries from other sub-projects, and some other third party static libraries together into a single static library. Is there an elegant way to do this, or maybe an existing function? Thank you very much. -- .............................................................................................................................................. Ke Gao -------------- next part -------------- An HTML attachment was scrubbed... URL: From djobet at tower-research.com Fri Sep 21 03:33:44 2018 From: djobet at tower-research.com (David Jobet) Date: Fri, 21 Sep 2018 08:33:44 +0100 Subject: [CMake] Best way to combine generated static libraries into a single static library In-Reply-To: References: Message-ID: Hello, I had a similar issue lately and wanted to "pack" several static libs into a dynamic one. (Not even talking about an INTERFACE lib since I really wanted that .so) I made it work with 3 different solutions, none of them being "clean" from my point of view. 1- OBJECT libs on sub projects : add_library(lib1 OBJECT SOURCES) and for the single static lib : add_library(single_static_lib STATIC $ ...) Problem I faced : since OBJECT libs do not support target_link_libraries(), I had to remove the existing one and move them instead to the target_include_directories() using generators. e.g : target_include_directories(lib1 PUBLIC $) Because I had a dependency to a protobuf generated lib, I also had to add manual add_dependencies to respect proper build order. Not clean at all 2- add_library(mysharedlib STATIC CMakeLists.txt) target_linked_libraries(mysharedlib PUBLIC lib1 ...) Maybe the cleanest way I found. The trick with CMakeLists.txt is that add_library needs at least one source file. You can put any kind of files you want. CMakeLists.txt is not compilable, so no extra compilation step, no need for dummy empty source file and add_library is happy. It did not work in my case because of problems related to how our .so are used/generated. (problems at runtime with duplicated symbols in protobufs) 3- a variation around 1 instead of defining OBJECT libs, define a variable holding all the sources for lib1, another for lib2, ... then just do add_library(mysharedlib STATIC ${SOURCES_FOR_lib1} ${SOURCES_FOR_lib2}) It works a little bit like 1) but does not have any of its problems (target_link, add_dependencies, generators, ...) It has new problems of its own though : if your libs live in different subfolders, the variables might not be visible from your add_library(mysharedlib...) call. To work around that, you can use PARENT_SCOPE (not sure if that works accross several levels), or includes (defines those variables into separate files living in each subfolders and include them in the parent CMakeLists). Hope this helps (and I'd be happy to know of other ways) David On Thu, Sep 20, 2018 at 5:45 PM Ke Gao wrote: > > Hi, > > I have a project which includes many sub-projects. Each sub-project generates a static library. In the main project, I want to combine the generated objs, generated static libraries from other sub-projects, and some other third party static libraries together into a single static library. Is there an elegant way to do this, or maybe an existing function? > > Thank you very much. > > -- > .............................................................................................................................................. > Ke Gao > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake From dbahadir at benocs.com Fri Sep 21 08:07:12 2018 From: dbahadir at benocs.com (Deniz Bahadir) Date: Fri, 21 Sep 2018 14:07:12 +0200 Subject: [CMake] Best way to combine generated static libraries into a single static library In-Reply-To: References: Message-ID: <909a4532-2180-c817-7289-a8f19b7532e3@benocs.com> Am 21.09.2018 um 09:33 schrieb David Jobet: > Hello, > > I had a similar issue lately and wanted to "pack" several static libs > into a dynamic one. (Not even talking about an INTERFACE lib since I > really wanted that .so) > I made it work with 3 different solutions, none of them being "clean" > from my point of view. > > 1- OBJECT libs on sub projects : add_library(lib1 OBJECT SOURCES) and > for the single static lib : add_library(single_static_lib STATIC > $ ...) > Problem I faced : since OBJECT libs do not support > target_link_libraries(), I had to remove the existing one and move > them instead to the target_include_directories() using generators. This is no longer true. Since CMake 3.12 `target_link_libraries` fully supports OBJECT libraries. You just need to pay attention to the special case of linking an OBJECT library with keyword "PUBLIC". (Object-files are always private and inherited object-files are therefore never further inherited. See: https://cmake.org/cmake/help/v3.12/command/target_link_libraries.html#linking-object-libraries) > e.g : target_include_directories(lib1 PUBLIC > $) > Because I had a dependency to a protobuf generated lib, I also had to > add manual add_dependencies to respect proper build order. > Not clean at all > > 2- add_library(mysharedlib STATIC CMakeLists.txt) > target_linked_libraries(mysharedlib PUBLIC lib1 ...) > Maybe the cleanest way I found. > The trick with CMakeLists.txt is that add_library needs at least one > source file. You can put any kind of files you want. CMakeLists.txt is > not compilable, so no extra compilation step, no need for dummy empty > source file and add_library is happy. > It did not work in my case because of problems related to how our .so > are used/generated. (problems at runtime with duplicated symbols in > protobufs) > > 3- a variation around 1 > instead of defining OBJECT libs, define a variable holding all the > sources for lib1, another for lib2, ... > then just do add_library(mysharedlib STATIC ${SOURCES_FOR_lib1} > ${SOURCES_FOR_lib2}) > It works a little bit like 1) but does not have any of its problems > (target_link, add_dependencies, generators, ...) > It has new problems of its own though : if your libs live in different > subfolders, the variables might not be visible from your > add_library(mysharedlib...) call. > To work around that, you can use PARENT_SCOPE (not sure if that works > accross several levels), or includes (defines those variables into > separate files living in each subfolders and include them in the > parent CMakeLists). > > Hope this helps (and I'd be happy to know of other ways) > > David > On Thu, Sep 20, 2018 at 5:45 PM Ke Gao wrote: >> >> Hi, >> >> I have a project which includes many sub-projects. Each sub-project generates a static library. In the main project, I want to combine the generated objs, generated static libraries from other sub-projects, and some other third party static libraries together into a single static library. Is there an elegant way to do this, or maybe an existing function? >> >> Thank you very much. >> >> -- >> .............................................................................................................................................. >> Ke Gao Hope that information was of value, Deniz From mailinglists at xgm.de Fri Sep 21 09:55:18 2018 From: mailinglists at xgm.de (Florian Lindner) Date: Fri, 21 Sep 2018 15:55:18 +0200 Subject: [CMake] Finding a pkg-config file Message-ID: <435d34cc-3272-65c1-f895-cec66e7bd620@xgm.de> Hello, on a really weird configured system (but I can't change it), there is a pkg-config file which I want to find with cmake: set(ENV{PKG_CONFIG_PATH} "$ENV{PKG_CONFIG_PATH}:$ENV{PETSC_DIR}/lib/pkgconfig") set(CMAKE_PREFIX_PATH "$ENV{PETSC_DIR}/lib/pkgconfig") find_package(PkgConfig REQUIRED) pkg_check_modules(PETSC REQUIRED craypetsc_real) but -- Checking for module 'craypetsc_real' -- No package 'craypetsc_real' found CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:363 (message): A required package was not found > cat $PETSC_DIR/lib/pkgconfig/craypetsc_real.pc VERSION=3.8.4.0 PE=GNU pe=gnu GENCOMP=7.1 CPU_TARGET=haswell install_prefix=/opt/cray/pe root=${install_prefix}/petsc/3.8.4.0/real prefix=${root}/${PE}/${GENCOMP}/${CPU_TARGET} libdir=${prefix}/lib includedir=${prefix}/include cray_as_needed= cray_no_as_needed= Name: craypetsc_real Description: Scientific libraries Version: ${VERSION} Libs: -L${libdir} ${cray_as_needed}-lcraypetsc_gnu_71_real${cray_no_as_needed} -fopenmp Libs.private: Requires: Requires.private: mpich >= 7.0 sci_mp >= 13.0 cray-tpsl >= 16.03.1 hdf5_parallel Conflicts: hdf5 Cflags: -I${includedir} pkg-config also finds it: > PKG_CONFIG_PATH=$PETSC_DIR/lib/pkgconfig pkg-config --print-variables craypetsc_real cray_as_needed prefix libdir [...] CMakeError.log does not exist, CMakeOutput.log I have attached. Thanks! Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: CMakeOutput.log Type: text/x-log Size: 35513 bytes Desc: not available URL: From mike.jackson at bluequartz.net Fri Sep 21 10:13:12 2018 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Fri, 21 Sep 2018 10:13:12 -0400 Subject: [CMake] How to have Visual Studio 15 2017 actually use a 64 bit toolchain. Message-ID: The easy answer is to use ?ninja? from a VS tools X64 Native command prompt. For those that want to actually use Visual Studio 15 2017 is there anything in CMake or an environment variable that can be set? The issue is that when I configure I select ?Visual Studio 15 2017 Win64? BUT the actual tool chain that VS is using under the hood is a 32 bit compiler. I have verified this through stack overflow and looking at the task manager. https://stackoverflow.com/questions/46056263/use-the-64-bit-visual-c-toolset-in-visual-studio-2017 https://stackoverflow.com/questions/19820718/how-to-make-visual-studio-use-the-native-amd64-toolchain/25626630#25626630 Is there a CMake variable that I can set to tell Visual Studio to use the X64 toolchain? Thanks -- Michael Jackson | Owner, President BlueQuartz Software [e] mike.jackson at bluequartz.net [w] www.bluequartz.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mateusz at loskot.net Fri Sep 21 10:27:54 2018 From: mateusz at loskot.net (Mateusz Loskot) Date: Fri, 21 Sep 2018 16:27:54 +0200 Subject: [CMake] How to have Visual Studio 15 2017 actually use a 64 bit toolchain. In-Reply-To: References: Message-ID: On Fri, 21 Sep 2018 at 16:13, Michael Jackson wrote: > > For those that want to actually use Visual Studio 15 2017 is there anything in CMake or an environment variable that can be set? Isn't host=x64 for that purpose? https://cmake.org/cmake/help/v3.12/variable/CMAKE_GENERATOR_TOOLSET.html Best regards -- Mateusz Loskot, http://mateusz.loskot.net From r030t1 at gmail.com Fri Sep 21 10:41:20 2018 From: r030t1 at gmail.com (R0b0t1) Date: Fri, 21 Sep 2018 16:41:20 +0200 Subject: [CMake] How to have Visual Studio 15 2017 actually use a 64 bit toolchain. In-Reply-To: References: Message-ID: On Fri, Sep 21, 2018 at 4:13 PM, Michael Jackson wrote: > The easy answer is to use ?ninja? from a VS tools X64 Native command prompt. > For those that want to actually use Visual Studio 15 2017 is there anything > in CMake or an environment variable that can be set? > > > The issue is that when I configure I select ?Visual Studio 15 2017 Win64? > BUT the actual tool chain that VS is using under the hood is a 32 bit > compiler. I have verified this through stack overflow and looking at the > task manager. > > > > https://stackoverflow.com/questions/46056263/use-the-64-bit-visual-c-toolset-in-visual-studio-2017 > > https://stackoverflow.com/questions/19820718/how-to-make-visual-studio-use-the-native-amd64-toolchain/25626630#25626630 > > > > Is there a CMake variable that I can set to tell Visual Studio to use the > X64 toolchain? > You select x64 when selecting the generator. Use "Visual Studio VV YYYY Win64" where VV is version and YYYY is year. > > Thanks > > -- > > Michael Jackson | Owner, President > > BlueQuartz Software > > [e] mike.jackson at bluequartz.net > > [w] www.bluequartz.net > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > From volker.enderlein at ifm-chemnitz.de Fri Sep 21 10:27:22 2018 From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein) Date: Fri, 21 Sep 2018 16:27:22 +0200 Subject: [CMake] How to have Visual Studio 15 2017 actually use a 64 bit toolchain. In-Reply-To: References: Message-ID: <57cc475e-0de5-3cc4-0c69-67909428466d@ifm-chemnitz.de> Hi Michael, I use the CMake generator toolset option "-T host=x64" when generating the solutions to force the 64 bit compiler being used. Cheers, Volker Am 21.09.2018 um 16:13 schrieb Michael Jackson: > > The easy answer is to use ?ninja? from a VS tools X64 Native command > prompt. For those that want to actually use Visual Studio 15 2017 is > there anything in CMake or an environment variable that can be set? > > > The issue is that when I configure I select ?Visual Studio 15 2017 > Win64? BUT the actual tool chain that VS is using under the hood is a > 32 bit compiler. I have verified this through stack overflow and > looking at the task manager. > > https://stackoverflow.com/questions/46056263/use-the-64-bit-visual-c-toolset-in-visual-studio-2017 > > https://stackoverflow.com/questions/19820718/how-to-make-visual-studio-use-the-native-amd64-toolchain/25626630#25626630 > > Is there a CMake variable that I can set to tell Visual Studio to use > the X64 toolchain? > > > Thanks > > -- > > Michael Jackson | Owner, President > > ????BlueQuartz Software > > [e] mike.jackson at bluequartz.net > > [w] www.bluequartz.net > > -- From mike.jackson at bluequartz.net Fri Sep 21 10:44:20 2018 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Fri, 21 Sep 2018 10:44:20 -0400 Subject: [CMake] How to have Visual Studio 15 2017 actually use a 64 bit toolchain. In-Reply-To: References: Message-ID: That will NOT use the x64 tool chain. It will use the 32 bit tool chain to produce a 64 bit binary, but NOT use the 64 bit compiler. Looks like there are 3 ways to do it: https://stackoverflow.com/questions/46683300/use-64-bit-compiler-in-visual-studio Either hack the project file or set an environment variable or use the -T host=x64" option with compiling (as Volker just mentioned). -- Michael Jackson | Owner, President BlueQuartz Software [e] mike.jackson at bluequartz.net [w] www.bluequartz.net ?On 9/21/18, 10:41 AM, "R0b0t1" wrote: You select x64 when selecting the generator. Use "Visual Studio VV YYYY Win64" where VV is version and YYYY is year. From mike.jackson at bluequartz.net Fri Sep 21 11:26:18 2018 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Fri, 21 Sep 2018 11:26:18 -0400 Subject: [CMake] How to have Visual Studio 15 2017 actually use a 64 bit toolchain. In-Reply-To: References: Message-ID: <85AD8B27-516F-4126-A716-005EFE6895A0@bluequartz.net> So I tried using "-DCMAKE_GENERATOR_TOOLSET=x64" while configuring a clean build directory but it still picked up the x86 compiler. I ended up going into the "Settings" of Windows 10 and added the environment variable PreferredToolArchitecture=x64 to my account. Logged out, Logged back in and then did another configuration run and now during the cmake configuration run the proper 64 bit compiler is picked up and used. Still probably missing something obvious in the CMake file that I can add.... -- Mike Jackson ?On 9/21/18, 10:28 AM, "CMake on behalf of Mateusz Loskot" wrote: On Fri, 21 Sep 2018 at 16:13, Michael Jackson wrote: > > For those that want to actually use Visual Studio 15 2017 is there anything in CMake or an environment variable that can be set? Isn't host=x64 for that purpose? https://cmake.org/cmake/help/v3.12/variable/CMAKE_GENERATOR_TOOLSET.html Best regards -- Mateusz Loskot, http://mateusz.loskot.net -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake From ke.gao.ut at gmail.com Fri Sep 21 11:52:18 2018 From: ke.gao.ut at gmail.com (Ke Gao) Date: Fri, 21 Sep 2018 09:52:18 -0600 Subject: [CMake] Best way to combine generated static libraries into a single static library In-Reply-To: <909a4532-2180-c817-7289-a8f19b7532e3@benocs.com> References: <909a4532-2180-c817-7289-a8f19b7532e3@benocs.com> Message-ID: Thank you all for the help. I finally use a way quite similar to David's first approach. I first generate all sub-projects into object libraries using add_library(lib1 OBJECT SOURCES). Then in the final library, I use add_library(single_static_lib STATIC SOURCES) and target_link_libraries( single_static_lib lib1 lib2 ...). Note that I didn't use " $" in the final "add_library" and also didn't use "PUBLIC" keyword in the final "target_link_libraries". It works on CMake v3.12.2 and gives me a single static lib which combines all the objs I want. But currently I still have problems of further combining third party static libraries into the final generated static single_static_lib. Can anybody provide a solution for this? Thank you very much. Ke On Fri, Sep 21, 2018 at 6:15 AM Deniz Bahadir wrote: > Am 21.09.2018 um 09:33 schrieb David Jobet: > > Hello, > > > > I had a similar issue lately and wanted to "pack" several static libs > > into a dynamic one. (Not even talking about an INTERFACE lib since I > > really wanted that .so) > > I made it work with 3 different solutions, none of them being "clean" > > from my point of view. > > > > 1- OBJECT libs on sub projects : add_library(lib1 OBJECT SOURCES) and > > for the single static lib : add_library(single_static_lib STATIC > > $ ...) > > Problem I faced : since OBJECT libs do not support > > target_link_libraries(), I had to remove the existing one and move > > them instead to the target_include_directories() using generators. > > This is no longer true. Since CMake 3.12 `target_link_libraries` fully > supports OBJECT libraries. You just need to pay attention to the special > case of linking an OBJECT library with keyword "PUBLIC". (Object-files > are always private and inherited object-files are therefore never > further inherited. See: > > https://cmake.org/cmake/help/v3.12/command/target_link_libraries.html#linking-object-libraries > ) > > > e.g : target_include_directories(lib1 PUBLIC > > $) > > Because I had a dependency to a protobuf generated lib, I also had to > > add manual add_dependencies to respect proper build order. > > Not clean at all > > > > 2- add_library(mysharedlib STATIC CMakeLists.txt) > > target_linked_libraries(mysharedlib PUBLIC lib1 ...) > > Maybe the cleanest way I found. > > The trick with CMakeLists.txt is that add_library needs at least one > > source file. You can put any kind of files you want. CMakeLists.txt is > > not compilable, so no extra compilation step, no need for dummy empty > > source file and add_library is happy. > > It did not work in my case because of problems related to how our .so > > are used/generated. (problems at runtime with duplicated symbols in > > protobufs) > > > > 3- a variation around 1 > > instead of defining OBJECT libs, define a variable holding all the > > sources for lib1, another for lib2, ... > > then just do add_library(mysharedlib STATIC ${SOURCES_FOR_lib1} > > ${SOURCES_FOR_lib2}) > > It works a little bit like 1) but does not have any of its problems > > (target_link, add_dependencies, generators, ...) > > It has new problems of its own though : if your libs live in different > > subfolders, the variables might not be visible from your > > add_library(mysharedlib...) call. > > To work around that, you can use PARENT_SCOPE (not sure if that works > > accross several levels), or includes (defines those variables into > > separate files living in each subfolders and include them in the > > parent CMakeLists). > > > > Hope this helps (and I'd be happy to know of other ways) > > > > David > > On Thu, Sep 20, 2018 at 5:45 PM Ke Gao wrote: > >> > >> Hi, > >> > >> I have a project which includes many sub-projects. Each sub-project > generates a static library. In the main project, I want to combine the > generated objs, generated static libraries from other sub-projects, and > some other third party static libraries together into a single static > library. Is there an elegant way to do this, or maybe an existing function? > >> > >> Thank you very much. > >> > >> -- > >> > .............................................................................................................................................. > >> Ke Gao > > > Hope that information was of value, > Deniz > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -- .............................................................................................................................................. Ke Gao -------------- next part -------------- An HTML attachment was scrubbed... URL: From djobet at tower-research.com Fri Sep 21 12:05:54 2018 From: djobet at tower-research.com (David Jobet) Date: Fri, 21 Sep 2018 17:05:54 +0100 Subject: [CMake] Best way to combine generated static libraries into a single static library In-Reply-To: References: <909a4532-2180-c817-7289-a8f19b7532e3@benocs.com> Message-ID: Hello, glad that could help you. For your newer problem, you don't describe them, so it's tough to know what kind of problems you're facing. Maybe a small example of your CMakeLists.txt + a capture of the error cmake gives you could help ? David On Fri, Sep 21, 2018 at 4:52 PM Ke Gao wrote: > > Thank you all for the help. > > I finally use a way quite similar to David's first approach. I first generate all sub-projects into object libraries using add_library(lib1 OBJECT SOURCES). Then in the final library, I use add_library(single_static_lib STATIC SOURCES) and target_link_libraries( single_static_lib lib1 lib2 ...). Note that I didn't use " $" in the final "add_library" and also didn't use "PUBLIC" keyword in the final "target_link_libraries". It works on CMake v3.12.2 and gives me a single static lib which combines all the objs I want. > > But currently I still have problems of further combining third party static libraries into the final generated static single_static_lib. Can anybody provide a solution for this? > > Thank you very much. > > Ke > > On Fri, Sep 21, 2018 at 6:15 AM Deniz Bahadir wrote: >> >> Am 21.09.2018 um 09:33 schrieb David Jobet: >> > Hello, >> > >> > I had a similar issue lately and wanted to "pack" several static libs >> > into a dynamic one. (Not even talking about an INTERFACE lib since I >> > really wanted that .so) >> > I made it work with 3 different solutions, none of them being "clean" >> > from my point of view. >> > >> > 1- OBJECT libs on sub projects : add_library(lib1 OBJECT SOURCES) and >> > for the single static lib : add_library(single_static_lib STATIC >> > $ ...) >> > Problem I faced : since OBJECT libs do not support >> > target_link_libraries(), I had to remove the existing one and move >> > them instead to the target_include_directories() using generators. >> >> This is no longer true. Since CMake 3.12 `target_link_libraries` fully >> supports OBJECT libraries. You just need to pay attention to the special >> case of linking an OBJECT library with keyword "PUBLIC". (Object-files >> are always private and inherited object-files are therefore never >> further inherited. See: >> https://cmake.org/cmake/help/v3.12/command/target_link_libraries.html#linking-object-libraries) >> >> > e.g : target_include_directories(lib1 PUBLIC >> > $) >> > Because I had a dependency to a protobuf generated lib, I also had to >> > add manual add_dependencies to respect proper build order. >> > Not clean at all >> > >> > 2- add_library(mysharedlib STATIC CMakeLists.txt) >> > target_linked_libraries(mysharedlib PUBLIC lib1 ...) >> > Maybe the cleanest way I found. >> > The trick with CMakeLists.txt is that add_library needs at least one >> > source file. You can put any kind of files you want. CMakeLists.txt is >> > not compilable, so no extra compilation step, no need for dummy empty >> > source file and add_library is happy. >> > It did not work in my case because of problems related to how our .so >> > are used/generated. (problems at runtime with duplicated symbols in >> > protobufs) >> > >> > 3- a variation around 1 >> > instead of defining OBJECT libs, define a variable holding all the >> > sources for lib1, another for lib2, ... >> > then just do add_library(mysharedlib STATIC ${SOURCES_FOR_lib1} >> > ${SOURCES_FOR_lib2}) >> > It works a little bit like 1) but does not have any of its problems >> > (target_link, add_dependencies, generators, ...) >> > It has new problems of its own though : if your libs live in different >> > subfolders, the variables might not be visible from your >> > add_library(mysharedlib...) call. >> > To work around that, you can use PARENT_SCOPE (not sure if that works >> > accross several levels), or includes (defines those variables into >> > separate files living in each subfolders and include them in the >> > parent CMakeLists). >> > >> > Hope this helps (and I'd be happy to know of other ways) >> > >> > David >> > On Thu, Sep 20, 2018 at 5:45 PM Ke Gao wrote: >> >> >> >> Hi, >> >> >> >> I have a project which includes many sub-projects. Each sub-project generates a static library. In the main project, I want to combine the generated objs, generated static libraries from other sub-projects, and some other third party static libraries together into a single static library. Is there an elegant way to do this, or maybe an existing function? >> >> >> >> Thank you very much. >> >> >> >> -- >> >> .............................................................................................................................................. >> >> Ke Gao >> >> >> Hope that information was of value, >> Deniz >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org/mailman/listinfo/cmake > > > > -- > .............................................................................................................................................. > Ke Gao From ke.gao.ut at gmail.com Fri Sep 21 12:38:45 2018 From: ke.gao.ut at gmail.com (Ke Gao) Date: Fri, 21 Sep 2018 10:38:45 -0600 Subject: [CMake] Best way to combine generated static libraries into a single static library In-Reply-To: References: <909a4532-2180-c817-7289-a8f19b7532e3@benocs.com> Message-ID: Hi David, It didn't give me error info. It can produce the final static library, but the contents of third party static libraries are not included. Also, sorry for the mistake I have made in my previous email. Deniz is right, the keyword "PUBLIC" should be used in target_link_librarie(). Thanks On Fri, Sep 21, 2018 at 10:06 AM David Jobet wrote: > Hello, > > glad that could help you. > For your newer problem, you don't describe them, so it's tough to know > what kind of problems you're facing. > Maybe a small example of your CMakeLists.txt + a capture of the error > cmake gives you could help ? > > David > On Fri, Sep 21, 2018 at 4:52 PM Ke Gao wrote: > > > > Thank you all for the help. > > > > I finally use a way quite similar to David's first approach. I first > generate all sub-projects into object libraries using add_library(lib1 > OBJECT SOURCES). Then in the final library, I use > add_library(single_static_lib STATIC SOURCES) and target_link_libraries( > single_static_lib lib1 lib2 ...). Note that I didn't use " > $" in the final "add_library" and also didn't use > "PUBLIC" keyword in the final "target_link_libraries". It works on CMake > v3.12.2 and gives me a single static lib which combines all the objs I want. > > > > But currently I still have problems of further combining third party > static libraries into the final generated static single_static_lib. Can > anybody provide a solution for this? > > > > Thank you very much. > > > > Ke > > > > On Fri, Sep 21, 2018 at 6:15 AM Deniz Bahadir > wrote: > >> > >> Am 21.09.2018 um 09:33 schrieb David Jobet: > >> > Hello, > >> > > >> > I had a similar issue lately and wanted to "pack" several static libs > >> > into a dynamic one. (Not even talking about an INTERFACE lib since I > >> > really wanted that .so) > >> > I made it work with 3 different solutions, none of them being "clean" > >> > from my point of view. > >> > > >> > 1- OBJECT libs on sub projects : add_library(lib1 OBJECT SOURCES) and > >> > for the single static lib : add_library(single_static_lib STATIC > >> > $ ...) > >> > Problem I faced : since OBJECT libs do not support > >> > target_link_libraries(), I had to remove the existing one and move > >> > them instead to the target_include_directories() using generators. > >> > >> This is no longer true. Since CMake 3.12 `target_link_libraries` fully > >> supports OBJECT libraries. You just need to pay attention to the special > >> case of linking an OBJECT library with keyword "PUBLIC". (Object-files > >> are always private and inherited object-files are therefore never > >> further inherited. See: > >> > https://cmake.org/cmake/help/v3.12/command/target_link_libraries.html#linking-object-libraries > ) > >> > >> > e.g : target_include_directories(lib1 PUBLIC > >> > $) > >> > Because I had a dependency to a protobuf generated lib, I also had to > >> > add manual add_dependencies to respect proper build order. > >> > Not clean at all > >> > > >> > 2- add_library(mysharedlib STATIC CMakeLists.txt) > >> > target_linked_libraries(mysharedlib PUBLIC lib1 ...) > >> > Maybe the cleanest way I found. > >> > The trick with CMakeLists.txt is that add_library needs at least one > >> > source file. You can put any kind of files you want. CMakeLists.txt is > >> > not compilable, so no extra compilation step, no need for dummy empty > >> > source file and add_library is happy. > >> > It did not work in my case because of problems related to how our .so > >> > are used/generated. (problems at runtime with duplicated symbols in > >> > protobufs) > >> > > >> > 3- a variation around 1 > >> > instead of defining OBJECT libs, define a variable holding all the > >> > sources for lib1, another for lib2, ... > >> > then just do add_library(mysharedlib STATIC ${SOURCES_FOR_lib1} > >> > ${SOURCES_FOR_lib2}) > >> > It works a little bit like 1) but does not have any of its problems > >> > (target_link, add_dependencies, generators, ...) > >> > It has new problems of its own though : if your libs live in different > >> > subfolders, the variables might not be visible from your > >> > add_library(mysharedlib...) call. > >> > To work around that, you can use PARENT_SCOPE (not sure if that works > >> > accross several levels), or includes (defines those variables into > >> > separate files living in each subfolders and include them in the > >> > parent CMakeLists). > >> > > >> > Hope this helps (and I'd be happy to know of other ways) > >> > > >> > David > >> > On Thu, Sep 20, 2018 at 5:45 PM Ke Gao wrote: > >> >> > >> >> Hi, > >> >> > >> >> I have a project which includes many sub-projects. Each sub-project > generates a static library. In the main project, I want to combine the > generated objs, generated static libraries from other sub-projects, and > some other third party static libraries together into a single static > library. Is there an elegant way to do this, or maybe an existing function? > >> >> > >> >> Thank you very much. > >> >> > >> >> -- > >> >> > .............................................................................................................................................. > >> >> Ke Gao > >> > >> > >> Hope that information was of value, > >> Deniz > >> > >> -- > >> > >> Powered by www.kitware.com > >> > >> Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > >> > >> Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > >> > >> CMake Support: http://cmake.org/cmake/help/support.html > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > >> Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > >> > >> Follow this link to subscribe/unsubscribe: > >> https://cmake.org/mailman/listinfo/cmake > > > > > > > > -- > > > .............................................................................................................................................. > > Ke Gao > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -- .............................................................................................................................................. Ke Gao -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbahadir at benocs.com Fri Sep 21 14:33:51 2018 From: dbahadir at benocs.com (Deniz Bahadir) Date: Fri, 21 Sep 2018 20:33:51 +0200 Subject: [CMake] Best way to combine generated static libraries into a single static library In-Reply-To: References: <909a4532-2180-c817-7289-a8f19b7532e3@benocs.com> Message-ID: <25873c06-51b4-fa17-307e-2692e6dde99d@benocs.com> Am 21.09.2018 um 18:38 schrieb Ke Gao: > Hi David, > > It didn't give me error info. It can produce the final static library, > but the contents of third party static libraries are not included. Some clarification regarding STATIC and OBJECT library targets and how they interact with each other using `target_link_libraries`: A STATIC library target A can be linked (via `target_link_libraries`) to another STATIC library target B. `target_link_libraries(A STATIC PUBLIC B)` However, the resulting library file libB does not contain the information (aka object-files) of libA. Instead, CMake makes sure to link both static library files libB and libA when e.g. creating an executable exeC1 using target C1 which just links (via `target_link_libraries`) to target B. `target_link_libraries(C1 EXECUTABLE PUBLIC B)` (Instead of an executable exeC1 you could have created a shared library libC1 instead. The behavior is the same.) If you instead want to create a combined, single STATIC library libC2, which contains the object-files archived in both static library files libA and libB created from targets A and B, then you somehow need to extract the archived object-files from libA and libB. I am not sure if CMake provides a (simple) way to do this. For OBJECT libraries the behavior is like this: An OBJECT library target X can be linked (via `target_link_libraries`) to another OBJECT library target Y. `target_link_libraries(Y OBJECT PUBLIC X)` This, however, only transports the usage-requirements (preprocessor-defines, include-paths etc.) from X to Y. The object-files of X are in no way referenced by Y. So, if you then create a STATIC target Z1 that links (via `target_link_libraries`) to Y,... `target_link_libraries(Z1 STATIC PUBLIC Y)` ... Z1 will reference/contain the usage-requirements of X and Y and the object-files of Y, but not the object-files of X. (The static library file libZ1 resulting from Z1 will contain the object-libraries of Y but not of X.) What you should do instead is not to link the OBJECT targets X and Y together but instead only link them (explicitly) to the STATIC target Z2: `target_link_libraries(Z2 STATIC PUBLIC Y X)` Z2 then references the usage-requirements as-well-as object-files of both OBJECT targets X and Y and the resulting static library file libZ2 will then contain the object-files of both library targets, X and Y. > > Also, sorry for the mistake I have made in my previous email. Deniz is > right, the keyword "PUBLIC" should be used in target_link_librarie(). > > Thanks You're welcome. Deniz > > On Fri, Sep 21, 2018 at 10:06 AM David Jobet > wrote: > > Hello, > > glad that could help you. > For your newer problem, you don't describe them, so it's tough to know > what kind of problems you're facing. > Maybe a small example of your CMakeLists.txt + a capture of the error > cmake gives you could help ? > > David > On Fri, Sep 21, 2018 at 4:52 PM Ke Gao > wrote: > > > > Thank you all for the help. > > > > I finally use a way quite similar to David's first approach. I > first generate all sub-projects into object libraries using > add_library(lib1 OBJECT SOURCES). Then in the final library, I use > add_library(single_static_lib STATIC SOURCES) and > target_link_libraries( single_static_lib lib1 lib2 ...). Note that I > didn't use " $" in the final "add_library" and > also didn't use "PUBLIC" keyword in the final > "target_link_libraries". It works on CMake v3.12.2 and gives me a > single static lib which combines all the objs I want. > > > > But currently I still have problems of further combining third > party static libraries into the final generated static > single_static_lib. Can anybody provide a solution for this? > > > > Thank you very much. > > > > Ke > > > > On Fri, Sep 21, 2018 at 6:15 AM Deniz Bahadir > > wrote: > >> > >> Am 21.09.2018 um 09:33 schrieb David Jobet: > >> > Hello, > >> > > >> > I had a similar issue lately and wanted to "pack" several > static libs > >> > into a dynamic one. (Not even talking about an INTERFACE lib > since I > >> > really wanted that .so) > >> > I made it work with 3 different solutions, none of them being > "clean" > >> > from my point of view. > >> > > >> > 1- OBJECT libs on sub projects : add_library(lib1 OBJECT > SOURCES) and > >> > for the single static lib : add_library(single_static_lib STATIC > >> > $ ...) > >> > Problem I faced : since OBJECT libs do not support > >> > target_link_libraries(), I had to remove the existing one and move > >> > them instead to the target_include_directories() using generators. > >> > >> This is no longer true. Since CMake 3.12 `target_link_libraries` > fully > >> supports OBJECT libraries. You just need to pay attention to the > special > >> case of linking an OBJECT library with keyword "PUBLIC". > (Object-files > >> are always private and inherited object-files are therefore never > >> further inherited. See: > >> > https://cmake.org/cmake/help/v3.12/command/target_link_libraries.html#linking-object-libraries) > >> > >> > e.g : target_include_directories(lib1 PUBLIC > >> > $) > >> > Because I had a dependency to a protobuf generated lib, I also > had to > >> > add manual add_dependencies to respect proper build order. > >> > Not clean at all > >> > > >> > 2- add_library(mysharedlib STATIC CMakeLists.txt) > >> > target_linked_libraries(mysharedlib PUBLIC lib1 ...) > >> > Maybe the cleanest way I found. > >> > The trick with CMakeLists.txt is that add_library needs at > least one > >> > source file. You can put any kind of files you want. > CMakeLists.txt is > >> > not compilable, so no extra compilation step, no need for > dummy empty > >> > source file and add_library is happy. > >> > It did not work in my case because of problems related to how > our .so > >> > are used/generated. (problems at runtime with duplicated > symbols in > >> > protobufs) > >> > > >> > 3- a variation around 1 > >> > instead of defining OBJECT libs, define a variable holding all the > >> > sources for lib1, another for lib2, ... > >> > then just do add_library(mysharedlib STATIC ${SOURCES_FOR_lib1} > >> > ${SOURCES_FOR_lib2}) > >> > It works a little bit like 1) but does not have any of its > problems > >> > (target_link, add_dependencies, generators, ...) > >> > It has new problems of its own though : if your libs live in > different > >> > subfolders, the variables might not be visible from your > >> > add_library(mysharedlib...) call. > >> > To work around that, you can use PARENT_SCOPE (not sure if > that works > >> > accross several levels), or includes (defines those variables into > >> > separate files living in each subfolders and include them in the > >> > parent CMakeLists). > >> > > >> > Hope this helps (and I'd be happy to know of other ways) > >> > > >> > David > >> > On Thu, Sep 20, 2018 at 5:45 PM Ke Gao > wrote: > >> >> > >> >> Hi, > >> >> > >> >> I have a project which includes many sub-projects. Each > sub-project generates a static library. In the main project, I want > to combine the generated objs, generated static libraries from other > sub-projects, and some other third party static libraries together > into a single static library. Is there an elegant way to do this, or > maybe an existing function? > >> >> > >> >> Thank you very much. > >> >> > >> >> -- > >> >> > .............................................................................................................................................. > >> >> Ke Gao > >> > >> > >> Hope that information was of value, > >> Deniz > >> > >> -- > >> > >> Powered by www.kitware.com > >> > >> Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > >> > >> Kitware offers various services to support the CMake community. > For more information on each offering, please visit: > >> > >> CMake Support: http://cmake.org/cmake/help/support.html > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > >> Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > >> > >> Follow this link to subscribe/unsubscribe: > >> https://cmake.org/mailman/listinfo/cmake > > > > > > > > -- > > > .............................................................................................................................................. > > Ke Gao > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > > > > -- > .............................................................................................................................................. > Ke Gao > > From ke.gao.ut at gmail.com Fri Sep 21 15:23:37 2018 From: ke.gao.ut at gmail.com (Ke Gao) Date: Fri, 21 Sep 2018 13:23:37 -0600 Subject: [CMake] Best way to combine generated static libraries into a single static library In-Reply-To: <25873c06-51b4-fa17-307e-2692e6dde99d@benocs.com> References: <909a4532-2180-c817-7289-a8f19b7532e3@benocs.com> <25873c06-51b4-fa17-307e-2692e6dde99d@benocs.com> Message-ID: So I guess in order to include the object-files from a third party static library, the only way would be to first extract it's object-files and then combine them? On Fri, Sep 21, 2018 at 12:34 PM Deniz Bahadir wrote: > Am 21.09.2018 um 18:38 schrieb Ke Gao: > > Hi David, > > > > It didn't give me error info. It can produce the final static library, > > but the contents of third party static libraries are not included. > > Some clarification regarding STATIC and OBJECT library targets and how > they interact with each other using `target_link_libraries`: > > > A STATIC library target A can be linked (via `target_link_libraries`) to > another STATIC library target B. > > `target_link_libraries(A STATIC PUBLIC B)` > > However, the resulting library file libB does not contain the > information (aka object-files) of libA. > Instead, CMake makes sure to link both static library files libB and > libA when e.g. creating an executable exeC1 using target C1 which just > links (via `target_link_libraries`) to target B. > > `target_link_libraries(C1 EXECUTABLE PUBLIC B)` > > (Instead of an executable exeC1 you could have created a shared library > libC1 instead. The behavior is the same.) > > > If you instead want to create a combined, single STATIC library libC2, > which contains the object-files archived in both static library files > libA and libB created from targets A and B, then you somehow need to > extract the archived object-files from libA and libB. I am not sure if > CMake provides a (simple) way to do this. > > > > For OBJECT libraries the behavior is like this: > > > An OBJECT library target X can be linked (via `target_link_libraries`) > to another OBJECT library target Y. > > `target_link_libraries(Y OBJECT PUBLIC X)` > > This, however, only transports the usage-requirements > (preprocessor-defines, include-paths etc.) from X to Y. The object-files > of X are in no way referenced by Y. > > So, if you then create a STATIC target Z1 that links (via > `target_link_libraries`) to Y,... > > `target_link_libraries(Z1 STATIC PUBLIC Y)` > > ... Z1 will reference/contain the usage-requirements of X and Y and the > object-files of Y, but not the object-files of X. (The static library > file libZ1 resulting from Z1 will contain the object-libraries of Y but > not of X.) > > > What you should do instead is not to link the OBJECT targets X and Y > together but instead only link them (explicitly) to the STATIC target Z2: > > `target_link_libraries(Z2 STATIC PUBLIC Y X)` > > Z2 then references the usage-requirements as-well-as object-files of > both OBJECT targets X and Y and the resulting static library file libZ2 > will then contain the object-files of both library targets, X and Y. > > > > > > Also, sorry for the mistake I have made in my previous email. Deniz is > > right, the keyword "PUBLIC" should be used in target_link_librarie(). > > > > Thanks > > You're welcome. > > Deniz > > > > > > On Fri, Sep 21, 2018 at 10:06 AM David Jobet > > wrote: > > > > Hello, > > > > glad that could help you. > > For your newer problem, you don't describe them, so it's tough to > know > > what kind of problems you're facing. > > Maybe a small example of your CMakeLists.txt + a capture of the error > > cmake gives you could help ? > > > > David > > On Fri, Sep 21, 2018 at 4:52 PM Ke Gao > > wrote: > > > > > > Thank you all for the help. > > > > > > I finally use a way quite similar to David's first approach. I > > first generate all sub-projects into object libraries using > > add_library(lib1 OBJECT SOURCES). Then in the final library, I use > > add_library(single_static_lib STATIC SOURCES) and > > target_link_libraries( single_static_lib lib1 lib2 ...). Note that I > > didn't use " $" in the final "add_library" and > > also didn't use "PUBLIC" keyword in the final > > "target_link_libraries". It works on CMake v3.12.2 and gives me a > > single static lib which combines all the objs I want. > > > > > > But currently I still have problems of further combining third > > party static libraries into the final generated static > > single_static_lib. Can anybody provide a solution for this? > > > > > > Thank you very much. > > > > > > Ke > > > > > > On Fri, Sep 21, 2018 at 6:15 AM Deniz Bahadir > > > wrote: > > >> > > >> Am 21.09.2018 um 09:33 schrieb David Jobet: > > >> > Hello, > > >> > > > >> > I had a similar issue lately and wanted to "pack" several > > static libs > > >> > into a dynamic one. (Not even talking about an INTERFACE lib > > since I > > >> > really wanted that .so) > > >> > I made it work with 3 different solutions, none of them being > > "clean" > > >> > from my point of view. > > >> > > > >> > 1- OBJECT libs on sub projects : add_library(lib1 OBJECT > > SOURCES) and > > >> > for the single static lib : add_library(single_static_lib > STATIC > > >> > $ ...) > > >> > Problem I faced : since OBJECT libs do not support > > >> > target_link_libraries(), I had to remove the existing one and > move > > >> > them instead to the target_include_directories() using > generators. > > >> > > >> This is no longer true. Since CMake 3.12 `target_link_libraries` > > fully > > >> supports OBJECT libraries. You just need to pay attention to the > > special > > >> case of linking an OBJECT library with keyword "PUBLIC". > > (Object-files > > >> are always private and inherited object-files are therefore never > > >> further inherited. See: > > >> > > > https://cmake.org/cmake/help/v3.12/command/target_link_libraries.html#linking-object-libraries > ) > > >> > > >> > e.g : target_include_directories(lib1 PUBLIC > > >> > $) > > >> > Because I had a dependency to a protobuf generated lib, I also > > had to > > >> > add manual add_dependencies to respect proper build order. > > >> > Not clean at all > > >> > > > >> > 2- add_library(mysharedlib STATIC CMakeLists.txt) > > >> > target_linked_libraries(mysharedlib PUBLIC lib1 ...) > > >> > Maybe the cleanest way I found. > > >> > The trick with CMakeLists.txt is that add_library needs at > > least one > > >> > source file. You can put any kind of files you want. > > CMakeLists.txt is > > >> > not compilable, so no extra compilation step, no need for > > dummy empty > > >> > source file and add_library is happy. > > >> > It did not work in my case because of problems related to how > > our .so > > >> > are used/generated. (problems at runtime with duplicated > > symbols in > > >> > protobufs) > > >> > > > >> > 3- a variation around 1 > > >> > instead of defining OBJECT libs, define a variable holding all > the > > >> > sources for lib1, another for lib2, ... > > >> > then just do add_library(mysharedlib STATIC ${SOURCES_FOR_lib1} > > >> > ${SOURCES_FOR_lib2}) > > >> > It works a little bit like 1) but does not have any of its > > problems > > >> > (target_link, add_dependencies, generators, ...) > > >> > It has new problems of its own though : if your libs live in > > different > > >> > subfolders, the variables might not be visible from your > > >> > add_library(mysharedlib...) call. > > >> > To work around that, you can use PARENT_SCOPE (not sure if > > that works > > >> > accross several levels), or includes (defines those variables > into > > >> > separate files living in each subfolders and include them in > the > > >> > parent CMakeLists). > > >> > > > >> > Hope this helps (and I'd be happy to know of other ways) > > >> > > > >> > David > > >> > On Thu, Sep 20, 2018 at 5:45 PM Ke Gao > > wrote: > > >> >> > > >> >> Hi, > > >> >> > > >> >> I have a project which includes many sub-projects. Each > > sub-project generates a static library. In the main project, I want > > to combine the generated objs, generated static libraries from other > > sub-projects, and some other third party static libraries together > > into a single static library. Is there an elegant way to do this, or > > maybe an existing function? > > >> >> > > >> >> Thank you very much. > > >> >> > > >> >> -- > > >> >> > > > .............................................................................................................................................. > > >> >> Ke Gao > > >> > > >> > > >> Hope that information was of value, > > >> Deniz > > >> > > >> -- > > >> > > >> Powered by www.kitware.com > > >> > > >> Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > >> > > >> Kitware offers various services to support the CMake community. > > For more information on each offering, please visit: > > >> > > >> CMake Support: http://cmake.org/cmake/help/support.html > > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > > >> CMake Training Courses: > http://cmake.org/cmake/help/training.html > > >> > > >> Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > >> > > >> Follow this link to subscribe/unsubscribe: > > >> https://cmake.org/mailman/listinfo/cmake > > > > > > > > > > > > -- > > > > > > .............................................................................................................................................. > > > Ke Gao > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For > > more information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > https://cmake.org/mailman/listinfo/cmake > > > > > > > > -- > > > .............................................................................................................................................. > > Ke Gao > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -- .............................................................................................................................................. Ke Gao -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Sep 21 16:02:24 2018 From: d3ck0r at gmail.com (J Decker) Date: Fri, 21 Sep 2018 13:02:24 -0700 Subject: [CMake] How to have Visual Studio 15 2017 actually use a 64 bit toolchain. In-Reply-To: <85AD8B27-516F-4126-A716-005EFE6895A0@bluequartz.net> References: <85AD8B27-516F-4126-A716-005EFE6895A0@bluequartz.net> Message-ID: "C:/tools/unix/cmake/bin/cmake.exe" -G "Visual Studio 15 2016 Win64" -T "v140" .. C:\tools\unix\cmake\bin\cmake.exe --build . --config "Debug" --target "INSTALL" On Fri, Sep 21, 2018 at 8:26 AM Michael Jackson wrote: > So I tried using "-DCMAKE_GENERATOR_TOOLSET=x64" while configuring a clean > build directory but it still picked up the x86 compiler. I ended up going > into the "Settings" of Windows 10 and added the environment variable > PreferredToolArchitecture=x64 to my account. Logged out, Logged back in and > then did another configuration run and now during the cmake configuration > run the proper 64 bit compiler is picked up and used. Still probably > missing something obvious in the CMake file that I can add.... > > -- > Mike Jackson > > ?On 9/21/18, 10:28 AM, "CMake on behalf of Mateusz Loskot" < > cmake-bounces at cmake.org on behalf of mateusz at loskot.net> wrote: > > On Fri, 21 Sep 2018 at 16:13, Michael Jackson > wrote: > > > > For those that want to actually use Visual Studio 15 2017 is there > anything in CMake or an environment variable that can be set? > > Isn't host=x64 for that purpose? > > > https://cmake.org/cmake/help/v3.12/variable/CMAKE_GENERATOR_TOOLSET.html > > Best regards > -- > Mateusz Loskot, http://mateusz.loskot.net > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Fri Sep 21 16:31:58 2018 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Fri, 21 Sep 2018 16:31:58 -0400 Subject: [CMake] How to have Visual Studio 15 2017 actually use a 64 bit toolchain. In-Reply-To: References: <85AD8B27-516F-4126-A716-005EFE6895A0@bluequartz.net> Message-ID: Nope. That just tells what _version_ of the compiler suite to use, but not the architecture. -- The C compiler identification is MSVC 19.0.24234.1 -- The CXX compiler identification is MSVC 19.0.24234.1 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/cl.exe -- works C:\Users\mjackson\DREAM3D-Dev\DREAM3D-Builds\Test>set PreferredToolArchitecture=x64 C:\Users\mjackson\DREAM3D-Dev\DREAM3D-Builds\Test>cmake -G "Visual Studio 15 2017 Win64" -T "v140" -DDREAM3D_SDK=C:/DREAM3D_SDK ../../DREAM3D -- * -- ******************************************************* -- The C compiler identification is MSVC 19.0.24234.1 -- The CXX compiler identification is MSVC 19.0.24234.1 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe -- works _________________________________________________________ Mike Jackson mike.jackson at bluequartz.net On Fri, Sep 21, 2018 at 4:02 PM J Decker wrote: > "C:/tools/unix/cmake/bin/cmake.exe" -G "Visual Studio 15 2016 Win64" -T > "v140" .. > C:\tools\unix\cmake\bin\cmake.exe --build . --config "Debug" --target > "INSTALL" > > On Fri, Sep 21, 2018 at 8:26 AM Michael Jackson < > mike.jackson at bluequartz.net> wrote: > >> So I tried using "-DCMAKE_GENERATOR_TOOLSET=x64" while configuring a >> clean build directory but it still picked up the x86 compiler. I ended up >> going into the "Settings" of Windows 10 and added the environment variable >> PreferredToolArchitecture=x64 to my account. Logged out, Logged back in and >> then did another configuration run and now during the cmake configuration >> run the proper 64 bit compiler is picked up and used. Still probably >> missing something obvious in the CMake file that I can add.... >> >> -- >> Mike Jackson >> >> ?On 9/21/18, 10:28 AM, "CMake on behalf of Mateusz Loskot" < >> cmake-bounces at cmake.org on behalf of mateusz at loskot.net> wrote: >> >> On Fri, 21 Sep 2018 at 16:13, Michael Jackson >> wrote: >> > >> > For those that want to actually use Visual Studio 15 2017 is there >> anything in CMake or an environment variable that can be set? >> >> Isn't host=x64 for that purpose? >> >> >> https://cmake.org/cmake/help/v3.12/variable/CMAKE_GENERATOR_TOOLSET.html >> >> Best regards >> -- >> Mateusz Loskot, http://mateusz.loskot.net >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For >> more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org/mailman/listinfo/cmake >> >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org/mailman/listinfo/cmake >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Sep 21 16:45:02 2018 From: d3ck0r at gmail.com (J Decker) Date: Fri, 21 Sep 2018 13:45:02 -0700 Subject: [CMake] How to have Visual Studio 15 2017 actually use a 64 bit toolchain. In-Reply-To: References: <85AD8B27-516F-4126-A716-005EFE6895A0@bluequartz.net> Message-ID: On Fri, Sep 21, 2018 at 1:32 PM Michael Jackson wrote: > Nope. That just tells what _version_ of the compiler suite to use, but not > the architecture. > Oh right, I understand now. -- The C compiler identification is MSVC 19.0.24215.1 -- The CXX compiler identification is MSVC 19.0.24215.1 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/amd64/cl.exe -- works do this first. set PreferredToolArchitecture=x64 > > -- The C compiler identification is MSVC 19.0.24234.1 > -- The CXX compiler identification is MSVC 19.0.24234.1 > -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual > Studio 14.0/VC/bin/x86_amd64/cl.exe > -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual > Studio 14.0/VC/bin/x86_amd64/cl.exe -- works > > C:\Users\mjackson\DREAM3D-Dev\DREAM3D-Builds\Test>set > PreferredToolArchitecture=x64 > C:\Users\mjackson\DREAM3D-Dev\DREAM3D-Builds\Test>cmake -G "Visual Studio > 15 2017 Win64" -T "v140" -DDREAM3D_SDK=C:/DREAM3D_SDK ../../DREAM3D > -- * > -- ******************************************************* > -- The C compiler identification is MSVC 19.0.24234.1 > -- The CXX compiler identification is MSVC 19.0.24234.1 > -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual > Studio 14.0/VC/bin/amd64/cl.exe > -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual > Studio 14.0/VC/bin/amd64/cl.exe -- works > > > _________________________________________________________ > Mike Jackson mike.jackson at bluequartz.net > > > > On Fri, Sep 21, 2018 at 4:02 PM J Decker wrote: > >> "C:/tools/unix/cmake/bin/cmake.exe" -G "Visual Studio 15 2016 Win64" -T >> "v140" .. >> C:\tools\unix\cmake\bin\cmake.exe --build . --config "Debug" --target >> "INSTALL" >> >> On Fri, Sep 21, 2018 at 8:26 AM Michael Jackson < >> mike.jackson at bluequartz.net> wrote: >> >>> So I tried using "-DCMAKE_GENERATOR_TOOLSET=x64" while configuring a >>> clean build directory but it still picked up the x86 compiler. I ended up >>> going into the "Settings" of Windows 10 and added the environment variable >>> PreferredToolArchitecture=x64 to my account. Logged out, Logged back in and >>> then did another configuration run and now during the cmake configuration >>> run the proper 64 bit compiler is picked up and used. Still probably >>> missing something obvious in the CMake file that I can add.... >>> >>> -- >>> Mike Jackson >>> >>> ?On 9/21/18, 10:28 AM, "CMake on behalf of Mateusz Loskot" < >>> cmake-bounces at cmake.org on behalf of mateusz at loskot.net> wrote: >>> >>> On Fri, 21 Sep 2018 at 16:13, Michael Jackson >>> wrote: >>> > >>> > For those that want to actually use Visual Studio 15 2017 is there >>> anything in CMake or an environment variable that can be set? >>> >>> Isn't host=x64 for that purpose? >>> >>> >>> https://cmake.org/cmake/help/v3.12/variable/CMAKE_GENERATOR_TOOLSET.html >>> >>> Best regards >>> -- >>> Mateusz Loskot, http://mateusz.loskot.net >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For >>> more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> https://cmake.org/mailman/listinfo/cmake >>> >>> >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> https://cmake.org/mailman/listinfo/cmake >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.W.Irwin1234 at gmail.com Fri Sep 21 16:49:31 2018 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Fri, 21 Sep 2018 13:49:31 -0700 (PDT) Subject: [CMake] Finding a pkg-config file In-Reply-To: <435d34cc-3272-65c1-f895-cec66e7bd620@xgm.de> References: <435d34cc-3272-65c1-f895-cec66e7bd620@xgm.de> Message-ID: On 2018-09-21 15:55+0200 Florian Lindner wrote: > Hello, > > on a really weird configured system (but I can't change it), there is a pkg-config file which I want to find with cmake: > > set(ENV{PKG_CONFIG_PATH} "$ENV{PKG_CONFIG_PATH}:$ENV{PETSC_DIR}/lib/pkgconfig") > set(CMAKE_PREFIX_PATH "$ENV{PETSC_DIR}/lib/pkgconfig") > find_package(PkgConfig REQUIRED) > pkg_check_modules(PETSC REQUIRED craypetsc_real) > > but > > -- Checking for module 'craypetsc_real' > -- No package 'craypetsc_real' found > CMake Error at /usr/share/cmake/Modules/FindPkgConfig.cmake:363 (message): > A required package was not found > > > >> cat $PETSC_DIR/lib/pkgconfig/craypetsc_real.pc > > VERSION=3.8.4.0 > PE=GNU > pe=gnu > GENCOMP=7.1 > CPU_TARGET=haswell > > install_prefix=/opt/cray/pe > root=${install_prefix}/petsc/3.8.4.0/real > prefix=${root}/${PE}/${GENCOMP}/${CPU_TARGET} > libdir=${prefix}/lib > includedir=${prefix}/include > > cray_as_needed= > cray_no_as_needed= > > Name: craypetsc_real > Description: Scientific libraries > Version: ${VERSION} > Libs: -L${libdir} ${cray_as_needed}-lcraypetsc_gnu_71_real${cray_no_as_needed} -fopenmp > Libs.private: > Requires: > Requires.private: mpich >= 7.0 sci_mp >= 13.0 cray-tpsl >= 16.03.1 hdf5_parallel > Conflicts: hdf5 > Cflags: -I${includedir} > > pkg-config also finds it: > >> PKG_CONFIG_PATH=$PETSC_DIR/lib/pkgconfig pkg-config --print-variables craypetsc_real > cray_as_needed > prefix > libdir > [...] > > > CMakeError.log does not exist, CMakeOutput.log I have attached. Hi Florian: What happens if you set PKG_CONFIG_PATH outside cmake rather than inside? e.g., env PKG_CONFIG_PATH=$PETSC_DIR/lib/pkgconfig cmake .... with both set(ENV{PKG_CONFIG_PATH} "$ENV{PKG_CONFIG_PATH}:$ENV{PETSC_DIR}/lib/pkgconfig") set(CMAKE_PREFIX_PATH "$ENV{PETSC_DIR}/lib/pkgconfig") commented out inside your CMakeList.txt file? That method has always worked for me. And if it works for you, then I would think attempting to set the enviroment variable PKG_CONFIG_PATH inside your CMakeLists.txt file with just set(ENV{PKG_CONFIG_PATH} "$ENV{PKG_CONFIG_PATH}:$ENV{PETSC_DIR}/lib/pkgconfig") (setting CMAKE_PREFIX_PATH should not be required) should just work, but it is always possible (although I haven't checked documentation to see) there is some incorrect syntax in that line so I would also use message to print out the PKG_CONFIG_PATH environment variable to see what you have actually set it to within CMake. Alan __________________________ Alan W. Irwin 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 ke.gao.ut at gmail.com Fri Sep 21 17:59:54 2018 From: ke.gao.ut at gmail.com (Ke Gao) Date: Fri, 21 Sep 2018 15:59:54 -0600 Subject: [CMake] How to duplicate a source file and rename it Message-ID: Hi, In a project, I need to first duplicate a source file and rename it. For example, I want to change "file.c" to "aaa_file.c", and after compiling, I will delete it. This is similar to using "cp file.c aaa_file.c". How to easily do this in CMake? I found "file" command doesn't work well for this. Thank you very much. -- .............................................................................................................................................. Ke Gao -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Sep 21 18:09:46 2018 From: d3ck0r at gmail.com (J Decker) Date: Fri, 21 Sep 2018 15:09:46 -0700 Subject: [CMake] How to duplicate a source file and rename it In-Reply-To: References: Message-ID: On Fri, Sep 21, 2018 at 3:00 PM Ke Gao wrote: > Hi, > > In a project, I need to first duplicate a source file and rename it. For > example, I want to change "file.c" to "aaa_file.c", and after compiling, I > will delete it. This is similar to using "cp file.c aaa_file.c". How to > easily do this in CMake? I found "file" command doesn't work well for this. > > add_custom_command( OUTPUT aaa_file.c DEPENDS file.c COMMAND ${CMAKE_COMMAND} -E copy_if_different file.c aaa_file.c ) then you just have to reference the source file 'aaa_file.c' and it will get updated if file.c is different. I also do COMMAND ${CMAKE_COMMAND} -E touch aaa_file.c just to make sure it is new. > Thank you very much. > > -- > > .............................................................................................................................................. > Ke Gao > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ke.gao.ut at gmail.com Fri Sep 21 18:24:07 2018 From: ke.gao.ut at gmail.com (Ke Gao) Date: Fri, 21 Sep 2018 16:24:07 -0600 Subject: [CMake] How to duplicate a source file and rename it In-Reply-To: References: Message-ID: Thanks. I forgot to say my CMakeList.txt is not located together with the source files. So I used the following, it seems not working: add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/../../aaa_file.c DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/../../file.c COMMAND ${CMAKE_COMMAND} -E copy_if_different ${CMAKE_CURRENT_SOURCE_DIR}/../../file.c ${CMAKE_CURRENT_SOURCE_DIR}/../../ aaa_file.c ) Is there an easier way to do this? On Fri, Sep 21, 2018 at 4:10 PM J Decker wrote: > > > On Fri, Sep 21, 2018 at 3:00 PM Ke Gao wrote: > >> Hi, >> >> In a project, I need to first duplicate a source file and rename it. For >> example, I want to change "file.c" to "aaa_file.c", and after compiling, I >> will delete it. This is similar to using "cp file.c aaa_file.c". How to >> easily do this in CMake? I found "file" command doesn't work well for this. >> >> > add_custom_command( OUTPUT aaa_file.c > DEPENDS file.c > COMMAND ${CMAKE_COMMAND} -E copy_if_different > file.c aaa_file.c > ) > > then you just have to reference the source file 'aaa_file.c' and it will > get updated if file.c is different. I also do > COMMAND ${CMAKE_COMMAND} -E touch aaa_file.c > > just to make sure it is new. > > > >> Thank you very much. >> >> -- >> >> .............................................................................................................................................. >> Ke Gao >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org/mailman/listinfo/cmake >> > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -- .............................................................................................................................................. Ke Gao -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Sep 21 18:29:22 2018 From: d3ck0r at gmail.com (J Decker) Date: Fri, 21 Sep 2018 15:29:22 -0700 Subject: [CMake] How to duplicate a source file and rename it In-Reply-To: References: Message-ID: On Fri, Sep 21, 2018 at 3:24 PM Ke Gao wrote: > Thanks. I forgot to say my CMakeList.txt is not located together with the > source files. So I used the following, it seems not working: > add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/../../aaa_file.c > DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/../../ > file.c > COMMAND ${CMAKE_COMMAND} -E copy_if_different > ${CMAKE_CURRENT_SOURCE_DIR}/../../file.c > ${CMAKE_CURRENT_SOURCE_DIR}/../../aaa_file.c > ) > Is there an easier way to do this? > not really... NOt sure why it wouldn't work unless current_source_dir isn't what you think it is. I actually copy mine into COMMAND ${CMAKE_COMMAND} -E copy_if_different ${SOURCE} ${CMAKE_BINARY_DIR}/${BASENAME} (basename is the path part of the ${SOURCE}) > > > On Fri, Sep 21, 2018 at 4:10 PM J Decker wrote: > >> >> >> On Fri, Sep 21, 2018 at 3:00 PM Ke Gao wrote: >> >>> Hi, >>> >>> In a project, I need to first duplicate a source file and rename it. For >>> example, I want to change "file.c" to "aaa_file.c", and after compiling, I >>> will delete it. This is similar to using "cp file.c aaa_file.c". How to >>> easily do this in CMake? I found "file" command doesn't work well for this. >>> >>> >> add_custom_command( OUTPUT aaa_file.c >> DEPENDS file.c >> COMMAND ${CMAKE_COMMAND} -E copy_if_different >> file.c aaa_file.c >> ) >> >> then you just have to reference the source file 'aaa_file.c' and it will >> get updated if file.c is different. I also do >> COMMAND ${CMAKE_COMMAND} -E touch aaa_file.c >> >> just to make sure it is new. >> >> >> >>> Thank you very much. >>> >>> -- >>> >>> .............................................................................................................................................. >>> Ke Gao >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> https://cmake.org/mailman/listinfo/cmake >>> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org/mailman/listinfo/cmake >> > > > -- > > .............................................................................................................................................. > Ke Gao > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaffar.sidek10 at gmail.com Fri Sep 21 18:30:24 2018 From: jaffar.sidek10 at gmail.com (Jaffar Sidek) Date: Sat, 22 Sep 2018 06:30:24 +0800 Subject: [CMake] CMake accessibility, or the lack of it with latest updtes Message-ID: <43cea13b-ea82-c538-e201-d3105b27760c@gmail.com> ??? ??? ??? ??? ??? HI.? I am a blind software developer very dependent on CMake for my development work.? I have noticed that since version 3.1X, the gui version of CMake is no longer accessible.? Let me clarify.? I use a screen reader for voice output in order for me to be able to use the computer independently.? In the earlier versions of CMake, My screen reader could access a large part of the interface of CMake to enable me to use the program Quickly and efficiently.? But since version 3.1X and the latest version 3.2X, I have had to revert to using the command line.? I noticed that the earlier versions were coded with QT, is that not the case anymore?? QT5 has added accessibility these days, and I would appreciate it if the accessibility features of earlier versions of CMake could be re-implemented.? Thanks and cheers! From d3ck0r at gmail.com Fri Sep 21 18:32:06 2018 From: d3ck0r at gmail.com (J Decker) Date: Fri, 21 Sep 2018 15:32:06 -0700 Subject: [CMake] How to duplicate a source file and rename it In-Reply-To: References: Message-ID: On Fri, Sep 21, 2018 at 3:29 PM J Decker wrote: > > > On Fri, Sep 21, 2018 at 3:24 PM Ke Gao wrote: > >> Thanks. I forgot to say my CMakeList.txt is not located together with the >> source files. So I used the following, it seems not working: >> add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/../../aaa_file.c >> DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/../../ >> file.c >> COMMAND ${CMAKE_COMMAND} -E copy_if_different >> ${CMAKE_CURRENT_SOURCE_DIR}/../../file.c >> ${CMAKE_CURRENT_SOURCE_DIR}/../../aaa_file.c >> ) >> Is there an easier way to do this? >> > not really... > NOt sure why it wouldn't work unless current_source_dir isn't what you > think it is. > I actually copy mine into > It also wouldn't work if you didn't use ${CMAKE_CURRENT_SORUCE_DIR}/../../aaa_file.c in another target. (and by the same path... which is partially why I copy into BINARY_DIR, then it's in a known place for all projects int he tree > > > COMMAND ${CMAKE_COMMAND} -E copy_if_different > ${SOURCE} ${CMAKE_BINARY_DIR}/${BASENAME} > > (basename is the path part of the ${SOURCE}) > >> >> >> On Fri, Sep 21, 2018 at 4:10 PM J Decker wrote: >> >>> >>> >>> On Fri, Sep 21, 2018 at 3:00 PM Ke Gao wrote: >>> >>>> Hi, >>>> >>>> In a project, I need to first duplicate a source file and rename it. >>>> For example, I want to change "file.c" to "aaa_file.c", and after >>>> compiling, I will delete it. This is similar to using "cp file.c >>>> aaa_file.c". How to easily do this in CMake? I found "file" command doesn't >>>> work well for this. >>>> >>>> >>> add_custom_command( OUTPUT aaa_file.c >>> DEPENDS file.c >>> COMMAND ${CMAKE_COMMAND} -E copy_if_different >>> file.c aaa_file.c >>> ) >>> >>> then you just have to reference the source file 'aaa_file.c' and it will >>> get updated if file.c is different. I also do >>> COMMAND ${CMAKE_COMMAND} -E touch aaa_file.c >>> >>> just to make sure it is new. >>> >>> >>> >>>> Thank you very much. >>>> >>>> -- >>>> >>>> .............................................................................................................................................. >>>> Ke Gao >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: >>>> http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For >>>> more information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> https://cmake.org/mailman/listinfo/cmake >>>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> https://cmake.org/mailman/listinfo/cmake >>> >> >> >> -- >> >> .............................................................................................................................................. >> Ke Gao >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ke.gao.ut at gmail.com Fri Sep 21 18:39:36 2018 From: ke.gao.ut at gmail.com (Ke Gao) Date: Fri, 21 Sep 2018 16:39:36 -0600 Subject: [CMake] How to duplicate a source file and rename it In-Reply-To: References: Message-ID: It just can't copy to the same source directory. On Fri, Sep 21, 2018 at 4:32 PM J Decker wrote: > > > On Fri, Sep 21, 2018 at 3:29 PM J Decker wrote: > >> >> >> On Fri, Sep 21, 2018 at 3:24 PM Ke Gao wrote: >> >>> Thanks. I forgot to say my CMakeList.txt is not located together with >>> the source files. So I used the following, it seems not working: >>> add_custom_command( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/../../aaa_file.c >>> DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/../../ >>> file.c >>> COMMAND ${CMAKE_COMMAND} -E copy_if_different >>> ${CMAKE_CURRENT_SOURCE_DIR}/../../file.c >>> ${CMAKE_CURRENT_SOURCE_DIR}/../../aaa_file.c >>> ) >>> Is there an easier way to do this? >>> >> not really... >> NOt sure why it wouldn't work unless current_source_dir isn't what you >> think it is. >> I actually copy mine into >> > > It also wouldn't work if you didn't use > ${CMAKE_CURRENT_SORUCE_DIR}/../../aaa_file.c in another target. > (and by the same path... which is partially why I copy into BINARY_DIR, > then it's in a known place for all projects int he tree > >> >> > >> COMMAND ${CMAKE_COMMAND} -E copy_if_different >> ${SOURCE} ${CMAKE_BINARY_DIR}/${BASENAME} >> >> (basename is the path part of the ${SOURCE}) >> >>> >>> >>> On Fri, Sep 21, 2018 at 4:10 PM J Decker wrote: >>> >>>> >>>> >>>> On Fri, Sep 21, 2018 at 3:00 PM Ke Gao wrote: >>>> >>>>> Hi, >>>>> >>>>> In a project, I need to first duplicate a source file and rename it. >>>>> For example, I want to change "file.c" to "aaa_file.c", and after >>>>> compiling, I will delete it. This is similar to using "cp file.c >>>>> aaa_file.c". How to easily do this in CMake? I found "file" command doesn't >>>>> work well for this. >>>>> >>>>> >>>> add_custom_command( OUTPUT aaa_file.c >>>> DEPENDS file.c >>>> COMMAND ${CMAKE_COMMAND} -E >>>> copy_if_different file.c aaa_file.c >>>> ) >>>> >>>> then you just have to reference the source file 'aaa_file.c' and it >>>> will get updated if file.c is different. I also do >>>> COMMAND ${CMAKE_COMMAND} -E touch >>>> aaa_file.c >>>> >>>> just to make sure it is new. >>>> >>>> >>>> >>>>> Thank you very much. >>>>> >>>>> -- >>>>> >>>>> .............................................................................................................................................. >>>>> Ke Gao >>>>> -- >>>>> >>>>> Powered by www.kitware.com >>>>> >>>>> Please keep messages on-topic and check the CMake FAQ at: >>>>> http://www.cmake.org/Wiki/CMake_FAQ >>>>> >>>>> Kitware offers various services to support the CMake community. For >>>>> more information on each offering, please visit: >>>>> >>>>> CMake Support: http://cmake.org/cmake/help/support.html >>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>>> >>>>> Visit other Kitware open-source projects at >>>>> http://www.kitware.com/opensource/opensource.html >>>>> >>>>> Follow this link to subscribe/unsubscribe: >>>>> https://cmake.org/mailman/listinfo/cmake >>>>> >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: >>>> http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For >>>> more information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> https://cmake.org/mailman/listinfo/cmake >>>> >>> >>> >>> -- >>> >>> .............................................................................................................................................. >>> Ke Gao >>> >> -- .............................................................................................................................................. Ke Gao -------------- next part -------------- An HTML attachment was scrubbed... URL: From deniz.bahadir at benocs.com Sat Sep 22 05:41:51 2018 From: deniz.bahadir at benocs.com (Deniz Bahadir) Date: Sat, 22 Sep 2018 11:41:51 +0200 Subject: [CMake] Best way to combine generated static libraries into a single static library In-Reply-To: References: <909a4532-2180-c817-7289-a8f19b7532e3@benocs.com> <25873c06-51b4-fa17-307e-2692e6dde99d@benocs.com> Message-ID: Am 21.09.2018 um 21:23 schrieb Ke Gao: > So I guess in order to include the object-files from a third party > static library, the only way would be to first extract it's object-files > and then combine them? That is how I understand it, yes. > > On Fri, Sep 21, 2018 at 12:34 PM Deniz Bahadir > wrote: > > Am 21.09.2018 um 18:38 schrieb Ke Gao: > > Hi David, > > > > It didn't give me error info. It can produce the final static > library, > > but the contents of third party static libraries are not included. > > Some clarification regarding STATIC and OBJECT library targets and how > they interact with each other using `target_link_libraries`: > > > A STATIC library target A can be linked (via > `target_link_libraries`) to > another STATIC library target B. > > ? ?`target_link_libraries(A STATIC PUBLIC B)` > > However, the resulting library file libB does not contain the > information (aka object-files) of libA. > Instead, CMake makes sure to link both static library files libB and > libA when e.g. creating an executable exeC1 using target C1 which just > links (via `target_link_libraries`) to target B. > > ? ?`target_link_libraries(C1 EXECUTABLE PUBLIC B)` > > (Instead of an executable exeC1 you could have created a shared library > libC1 instead. The behavior is the same.) > > > If you instead want to create a combined, single STATIC library libC2, > which contains the object-files archived in both static library files > libA and libB created from targets A and B, then you somehow need to > extract the archived object-files from libA and libB. I am not sure if > CMake provides a (simple) way to do this. > > > > For OBJECT libraries the behavior is like this: > > > An OBJECT library target X can be linked (via `target_link_libraries`) > to another OBJECT library target Y. > > ? ?`target_link_libraries(Y OBJECT PUBLIC X)` > > This, however, only transports the usage-requirements > (preprocessor-defines, include-paths etc.) from X to Y. The > object-files > of X are in no way referenced by Y. > > So, if you then create a STATIC target Z1 that links (via > `target_link_libraries`) to Y,... > > ? ?`target_link_libraries(Z1 STATIC PUBLIC Y)` > > ... Z1 will reference/contain the usage-requirements of X and Y and the > object-files of Y, but not the object-files of X. (The static library > file libZ1 resulting from Z1 will contain the object-libraries of Y but > not of X.) > > > What you should do instead is not to link the OBJECT targets X and Y > together but instead only link them (explicitly) to the STATIC > target Z2: > > ? ?`target_link_libraries(Z2 STATIC PUBLIC Y X)` > > Z2 then references the usage-requirements as-well-as object-files of > both OBJECT targets X and Y and the resulting static library file libZ2 > will then contain the object-files of both library targets, X and Y. > > > > > > Also, sorry for the mistake I have made in my previous email. > Deniz is > > right, the keyword "PUBLIC" should be used in target_link_librarie(). > > > > Thanks > > You're welcome. > > Deniz > > > > > > On Fri, Sep 21, 2018 at 10:06 AM David Jobet > > > >> wrote: > > > >? ? ?Hello, > > > >? ? ?glad that could help you. > >? ? ?For your newer problem, you don't describe them, so it's > tough to know > >? ? ?what kind of problems you're facing. > >? ? ?Maybe a small example of your CMakeLists.txt + a capture of > the error > >? ? ?cmake gives you could help ? > > > >? ? ?David > >? ? ?On Fri, Sep 21, 2018 at 4:52 PM Ke Gao > >? ? ?>> wrote: > >? ? ? > > >? ? ? > Thank you all for the help. > >? ? ? > > >? ? ? > I finally use a way quite similar to David's first approach. I > >? ? ?first generate all sub-projects into object libraries using > >? ? ?add_library(lib1 OBJECT SOURCES). Then in the final library, > I use > >? ? ?add_library(single_static_lib STATIC SOURCES) and > >? ? ?target_link_libraries( single_static_lib lib1 lib2 ...). Note > that I > >? ? ?didn't use " $" in the final > "add_library" and > >? ? ?also didn't use "PUBLIC" keyword in the final > >? ? ?"target_link_libraries". It works on CMake v3.12.2 and gives me a > >? ? ?single static lib which combines all the objs I want. > >? ? ? > > >? ? ? > But currently I still have problems of further combining third > >? ? ?party static libraries into the final generated static > >? ? ?single_static_lib. Can anybody provide a solution for this? > >? ? ? > > >? ? ? > Thank you very much. > >? ? ? > > >? ? ? > Ke > >? ? ? > > >? ? ? > On Fri, Sep 21, 2018 at 6:15 AM Deniz Bahadir > >? ? ? > >> wrote: > >? ? ? >> > >? ? ? >> Am 21.09.2018 um 09:33 schrieb David Jobet: > >? ? ? >> > Hello, > >? ? ? >> > > >? ? ? >> > I had a similar issue lately and wanted to "pack" several > >? ? ?static libs > >? ? ? >> > into a dynamic one. (Not even talking about an > INTERFACE lib > >? ? ?since I > >? ? ? >> > really wanted that .so) > >? ? ? >> > I made it work with 3 different solutions, none of them > being > >? ? ?"clean" > >? ? ? >> > from my point of view. > >? ? ? >> > > >? ? ? >> > 1- OBJECT libs on sub projects : add_library(lib1 OBJECT > >? ? ?SOURCES) and > >? ? ? >> > for the single static lib : > add_library(single_static_lib STATIC > >? ? ? >> > $ ...) > >? ? ? >> > Problem I faced : since OBJECT libs do not support > >? ? ? >> > target_link_libraries(), I had to remove the existing > one and move > >? ? ? >> > them instead to the target_include_directories() using > generators. > >? ? ? >> > >? ? ? >> This is no longer true. Since CMake 3.12 > `target_link_libraries` > >? ? ?fully > >? ? ? >> supports OBJECT libraries. You just need to pay attention > to the > >? ? ?special > >? ? ? >> case of linking an OBJECT library with keyword "PUBLIC". > >? ? ?(Object-files > >? ? ? >> are always private and inherited object-files are > therefore never > >? ? ? >> further inherited. See: > >? ? ? >> > > > https://cmake.org/cmake/help/v3.12/command/target_link_libraries.html#linking-object-libraries) > >? ? ? >> > >? ? ? >> > e.g : target_include_directories(lib1 PUBLIC > >? ? ? >> > $) > >? ? ? >> > Because I had a dependency to a protobuf generated lib, > I also > >? ? ?had to > >? ? ? >> > add manual add_dependencies to respect proper build order. > >? ? ? >> > Not clean at all > >? ? ? >> > > >? ? ? >> > 2- add_library(mysharedlib STATIC CMakeLists.txt) > >? ? ? >> > target_linked_libraries(mysharedlib PUBLIC lib1 ...) > >? ? ? >> > Maybe the cleanest way I found. > >? ? ? >> > The trick with CMakeLists.txt is that add_library needs at > >? ? ?least one > >? ? ? >> > source file. You can put any kind of files you want. > >? ? ?CMakeLists.txt is > >? ? ? >> > not compilable, so no extra compilation step, no need for > >? ? ?dummy empty > >? ? ? >> > source file and add_library is happy. > >? ? ? >> > It did not work in my case because of problems related > to how > >? ? ?our .so > >? ? ? >> > are used/generated. (problems at runtime with duplicated > >? ? ?symbols in > >? ? ? >> > protobufs) > >? ? ? >> > > >? ? ? >> > 3- a variation around 1 > >? ? ? >> > instead of defining OBJECT libs, define a variable > holding all the > >? ? ? >> > sources for lib1, another for lib2, ... > >? ? ? >> > then just do add_library(mysharedlib STATIC > ${SOURCES_FOR_lib1} > >? ? ? >> > ${SOURCES_FOR_lib2}) > >? ? ? >> > It works a little bit like 1) but does not have any of its > >? ? ?problems > >? ? ? >> > (target_link, add_dependencies, generators, ...) > >? ? ? >> > It has new problems of its own though : if your libs > live in > >? ? ?different > >? ? ? >> > subfolders, the variables might not be visible from your > >? ? ? >> > add_library(mysharedlib...) call. > >? ? ? >> > To work around that, you can use PARENT_SCOPE (not sure if > >? ? ?that works > >? ? ? >> > accross several levels), or includes (defines those > variables into > >? ? ? >> > separate files living in each subfolders and include > them in the > >? ? ? >> > parent CMakeLists). > >? ? ? >> > > >? ? ? >> > Hope this helps (and I'd be happy to know of other ways) > >? ? ? >> > > >? ? ? >> > David > >? ? ? >> > On Thu, Sep 20, 2018 at 5:45 PM Ke Gao > > >? ? ?>> wrote: > >? ? ? >> >> > >? ? ? >> >> Hi, > >? ? ? >> >> > >? ? ? >> >> I have a project which includes many sub-projects. Each > >? ? ?sub-project generates a static library. In the main project, > I want > >? ? ?to combine the generated objs, generated static libraries > from other > >? ? ?sub-projects, and some other third party static libraries > together > >? ? ?into a single static library. Is there an elegant way to do > this, or > >? ? ?maybe an existing function? > >? ? ? >> >> > >? ? ? >> >> Thank you very much. > >? ? ? >> >> > >? ? ? >> >> -- > >? ? ? >> >> > > > ?.............................................................................................................................................. > >? ? ? >> >> Ke Gao > >? ? ? >> > >? ? ? >> > >? ? ? >> Hope that information was of value, > >? ? ? >> Deniz > >? ? ? >> > >? ? ? >> -- > >? ? ? >> > >? ? ? >> Powered by www.kitware.com > > >? ? ? >> > >? ? ? >> Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > >? ? ? >> > >? ? ? >> Kitware offers various services to support the CMake > community. > >? ? ?For more information on each offering, please visit: > >? ? ? >> > >? ? ? >> CMake Support: http://cmake.org/cmake/help/support.html > >? ? ? >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >? ? ? >> CMake Training Courses: > http://cmake.org/cmake/help/training.html > >? ? ? >> > >? ? ? >> Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > >? ? ? >> > >? ? ? >> Follow this link to subscribe/unsubscribe: > >? ? ? >> https://cmake.org/mailman/listinfo/cmake > >? ? ? > > >? ? ? > > >? ? ? > > >? ? ? > -- > >? ? ? > > > > ?.............................................................................................................................................. > >? ? ? > Ke Gao > >? ? ?-- > > > >? ? ?Powered by www.kitware.com > > > > >? ? ?Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > >? ? ?Kitware offers various services to support the CMake > community. For > >? ? ?more information on each offering, please visit: > > > >? ? ?CMake Support: http://cmake.org/cmake/help/support.html > >? ? ?CMake Consulting: http://cmake.org/cmake/help/consulting.html > >? ? ?CMake Training Courses: http://cmake.org/cmake/help/training.html > > > >? ? ?Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > >? ? ?Follow this link to subscribe/unsubscribe: > > https://cmake.org/mailman/listinfo/cmake > > > > > > > > -- > > > .............................................................................................................................................. > > Ke Gao > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > > > > -- > .............................................................................................................................................. > Ke Gao -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Reuchlinstr. 10 D 10553 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir at benocs.com www.benocs.com Advisory Board (Chairman): Oliver Fietz Board of Management: Stephan Schr?der, Dr.-Ing. Oliver Holschke, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378 From robert.maynard at kitware.com Sun Sep 23 11:37:21 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Sun, 23 Sep 2018 08:37:21 -0700 Subject: [CMake] CMake accessibility, or the lack of it with latest updtes In-Reply-To: <43cea13b-ea82-c538-e201-d3105b27760c@gmail.com> References: <43cea13b-ea82-c538-e201-d3105b27760c@gmail.com> Message-ID: Hi Jaffar, CMake is still using Qt for the GUI, but we have moved from Qt4 to Qt5. If you are able to tell me the explicit version of the GUI that last worked for you that will help track down what is causing this regression. On Fri, Sep 21, 2018 at 3:30 PM Jaffar Sidek wrote: > HI. I am a blind software developer very dependent > on CMake for my development work. I have noticed that since version > 3.1X, the gui version of CMake is no longer accessible. Let me > clarify. I use a screen reader for voice output in order for me to be > able to use the computer independently. In the earlier versions of > CMake, My screen reader could access a large part of the interface of > CMake to enable me to use the program Quickly and efficiently. But > since version 3.1X and the latest version 3.2X, I have had to revert to > using the command line. I noticed that the earlier versions were coded > with QT, is that not the case anymore? QT5 has added accessibility > these days, and I would appreciate it if the accessibility features of > earlier versions of CMake could be re-implemented. Thanks and cheers! > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Sun Sep 23 14:11:18 2018 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Sun, 23 Sep 2018 20:11:18 +0200 Subject: [CMake] CMake accessibility, or the lack of it with latest updtes In-Reply-To: References: <43cea13b-ea82-c538-e201-d3105b27760c@gmail.com> Message-ID: <57EF392D-18F6-496F-9BC8-44D579008DE3@hendrik-sattler.de> Maybe it's related to this blog entry: http://blog.qt.io/blog/2018/02/20/qt-5-11-brings-new-accessibility-backend-windows/ Am 23. September 2018 17:37:21 MESZ schrieb Robert Maynard : >Hi Jaffar, > >CMake is still using Qt for the GUI, but we have moved from Qt4 to Qt5. >If >you are able to tell me the explicit version of the GUI that last >worked >for you that will help track down what is causing this regression. > >On Fri, Sep 21, 2018 at 3:30 PM Jaffar Sidek >wrote: > >> HI. I am a blind software developer very >dependent >> on CMake for my development work. I have noticed that since version >> 3.1X, the gui version of CMake is no longer accessible. Let me >> clarify. I use a screen reader for voice output in order for me to >be >> able to use the computer independently. In the earlier versions of >> CMake, My screen reader could access a large part of the interface of >> CMake to enable me to use the program Quickly and efficiently. But >> since version 3.1X and the latest version 3.2X, I have had to revert >to >> using the command line. I noticed that the earlier versions were >coded >> with QT, is that not the case anymore? QT5 has added accessibility >> these days, and I would appreciate it if the accessibility features >of >> earlier versions of CMake could be re-implemented. Thanks and >cheers! >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For >more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org/mailman/listinfo/cmake >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From djobet at tower-research.com Tue Sep 25 11:53:27 2018 From: djobet at tower-research.com (David Jobet) Date: Tue, 25 Sep 2018 16:53:27 +0100 Subject: [CMake] protobuf and imports relative to root (and --proto_path) In-Reply-To: <4057870.Fgg1o8KiqT@linux-l7nd> References: <4057870.Fgg1o8KiqT@linux-l7nd> Message-ID: > What I do have a problem is rerunning protoc automatically on proto-files which > import proto files that have been modified. > How do you handle this ? I just found out I don't. Any idea on that one ? Otherwise I'm going to create a small .proto parser (python) that will just list the imports recursively. I will add that as DEPENDS to the add_custom_command. David On Thu, Aug 23, 2018 at 9:36 PM Alexander Neundorf wrote: > > On 2018 M08 23, Thu 12:50:14 CEST David Jobet wrote: > > Hello, > > > > I'm trying to port an existing project from premake to cmake. > > I'm trying to avoid modifying the source files while doing so. > > > > Right now, we have several libraries (read in different directories) using > > proto files with imports between them. > > All imports are made relative to the root of the project. > > > > e.g : > > work/lib1/sublib1/a.proto > > work/lib1/sublib1/b.proto > > > > with a.proto having a link to b.proto like this "import > > lib1/sublib1/b.proto" > > > > If I compile this with an unchanged FindProtobuf.cmake, I do this : > > > > protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS a.proto b.proto) > > add_library(...) > > > > the problem being that it looks like the "namespaces" generated by protoc > > in b.proto do not match the one used in a.proto : it does not compile. > > do you mean protoc fails, or that the C++ compiler fails when compiling the > generated file ? > I'm also using proto files with imports between them and don't have problems > with finding them. > Are you setting the PROTOBUF_IMPORT_DIRS variable ? > > What I do have a problem is rerunning protoc automatically on proto-files which > import proto files that have been modified. > How do you handle this ? > > > Is there a way to make this work ? > > > > Otherwise, I made the patch below which solves my problem. Do you think it > > could be included in cmake ? > > it defines a new option PROTO_PATH, so the decl above becomes > > protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS PROTO_PATH ${CMAKE_SOURCE_DIR} > > a.proto b.proto) > > > > With regards > > > > David > > > > $ diff share/cmake-3.10/Modules/FindProtobuf.cmake.orig > > share/cmake-3.10/Modules/FindProtobuf.cmake > > can you please use diff -bup ? > This makes the patch easier to read. > > Thanks > Alex > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake From neundorf at kde.org Tue Sep 25 16:15:54 2018 From: neundorf at kde.org (Alexander Neundorf) Date: Tue, 25 Sep 2018 22:15:54 +0200 Subject: [CMake] protobuf and imports relative to root (and --proto_path) In-Reply-To: References: <4057870.Fgg1o8KiqT@linux-l7nd> Message-ID: <1899232.0hvGUhRN49@linux-l7nd> On 2018 M09 25, Tue 16:53:27 CEST David Jobet wrote: > > What I do have a problem is rerunning protoc automatically on proto-files > > which import proto files that have been modified. > > How do you handle this ? > > I just found out I don't. > Any idea on that one ? here are some suggestions: https://cmake.org/pipermail/cmake-developers/2018-May/030664.html Alex From cerobison at utexas.edu Tue Sep 25 17:58:07 2018 From: cerobison at utexas.edu (Christopher E Robison) Date: Tue, 25 Sep 2018 21:58:07 +0000 Subject: [CMake] Moving static library to separate project Message-ID: I've got a situation I've searched for answers on, and though I've found similar questions, I've found no generally-applicable answers, or at least ones I can use. Apologies in advance for a beginner-level question. I have a group of applications that all use some common functionality I've located in a static library (for logging in this case). we'll call it libmylog here. Libmylog is pretty simple, but at some point I wanted to solve some thread safety situations, so I included some synchronization features that now require me to link with pthreads. Easy enough, "target_link_libraries(mylog pthread)" takes care of it. I've recently begun developing a separate application which doesn't belong in the same tree, and so I've put it in its own new project. I've decided I'd like this new application to use libmylog as well, and so now I've moved mylog into its own separate project too. I've added install directives and the library (libmylog.a) and its header file end up in the correct spots in /usr/local when I do a "make install". Looks good so far. The problem is when I compile any of my executables, the link fails with undefined reference errors since after removing libmylog from the same build tree every application I've written that uses it must now link with libpthread as well. This is an odd thing to have to specify for small utilities that don't have threads and shouldn't need to care about them. I look at libmylog.a with nm and all the references to pthreads symbols are undefined. More critically, it seems that since the build process for libmylog doesn't generate an executable, the "target_link_libraries(mylog pthread) line is now _silently ignored_. What is the Right Way of dealing with this in CMake? I'd like a way to tell the linker to force the inclusion of the relevant code in the static library, but if there's a more canonical approach I'd appreciate the advice. (For example, do I need to [learn how to] create a CMake "package" for my libmylog installation -- would this help propagate the -lpthread requirement to the build for the executables?) Thanks! Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik.greving.smi at gmail.com Tue Sep 25 23:20:43 2018 From: hendrik.greving.smi at gmail.com (Hendrik Greving) Date: Tue, 25 Sep 2018 20:20:43 -0700 Subject: [CMake] LOCATION target property, generator expressions Message-ID: Hello, our cmake setup is using LOCATION property for two targets to compute a relative path from these two, and adds this to LINK_FLAGS (for rpath, but irrelevant in this context). In order to update our cmake w.r.t. CMP0026, I don't know how to get LINK_FLAGS consume a generator expression. In other cases file(GENERATE.. writing a set(var TARGET_FILE..) into a file, and reading the file to obtain 'var' worked. Thanks in advance! -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at gmail.com Wed Sep 26 01:45:15 2018 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Wed, 26 Sep 2018 07:45:15 +0200 Subject: [CMake] LOCATION target property, generator expressions In-Reply-To: References: Message-ID: LINK_FLAGS does not support expressions. However, property LINK_OPTIONS (and INTERFACE counterpart) support generator expressions. These properties are new for version 3.13 which will be available soon (probably next month). Le mer. 26 sept. 2018 ? 05:21, Hendrik Greving < hendrik.greving.smi at gmail.com> a ?crit : > Hello, > > our cmake setup is using LOCATION property for two targets to compute a > relative path from these two, and adds this to LINK_FLAGS (for rpath, but > irrelevant in this context). In order to update our cmake w.r.t. CMP0026, I > don't know how to get LINK_FLAGS consume a generator expression. In other > cases file(GENERATE.. writing a set(var TARGET_FILE..) into a file, and > reading the file to obtain 'var' worked. Thanks in advance! > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas-Naumann at gmx.net Wed Sep 26 03:56:29 2018 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Wed, 26 Sep 2018 09:56:29 +0200 Subject: [CMake] Moving static library to separate project In-Reply-To: References: Message-ID: <617c614f-1789-9a5b-dde8-b1e9895c1193@gmx.net> Dear Chris, you have several ways to cope with that. First, you should write a MyLogConfig.cmake-File [2], which imports your static library as import library [1] and sets the include path. The same file also defines the dependency on pthread via target_link_library. Your project with the executable then uses find_package(MyLog ) to insert the library into the project. The second way uses the install(Export ...) directive to create export files. These files contain the transitivie dependencies and the include paths at once. In this case, your executable project has to use the export-File via find_file / input. Hope that helps a little bit, Andreas [1] https://cmake.org/cmake/help/v3.5/command/add_library.html [2] https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html Am 25.09.2018 um 23:58 schrieb Christopher E Robison: > I've got a situation I've searched for answers on, and though I've > found similar questions, I've found no generally-applicable answers, > or at least ones I can use. Apologies in advance for a beginner-level > question. > > I have a group of applications that all use some common functionality > I've located in a static library (for logging in this case). we'll > call it libmylog here. Libmylog is pretty simple, but at some point I > wanted to solve some thread safety situations, so I included some > synchronization features that now require me to link with pthreads. > Easy enough, "target_link_libraries(mylog pthread)" takes care of it. > > I've recently begun developing a separate application which doesn't > belong in the same tree, and so I've put it in its own new project. > I've decided I'd like this new application to use libmylog as well, > and so now I've moved mylog into its own separate project too. I've > added install directives and the library (libmylog.a) and its header > file end up in the correct spots in /usr/local when I do a "make > install". Looks good so far. > > The problem is when I compile any of my executables, the link fails > with undefined reference errors since after removing libmylog from the > same build tree every application I've written that uses it must now > link with libpthread as well. This is an odd thing to have to specify > for small utilities that don't have threads and shouldn't need to care > about them. I look at libmylog.a with nm and all the references to > pthreads symbols are undefined. > > More critically, it seems that since the build process for libmylog > doesn't generate an executable, the "target_link_libraries(mylog > pthread) line is now _silently ignored_. > > What is the Right Way of dealing with this in CMake? I'd like a way to > tell the linker to force the inclusion of the relevant code in the > static library, but if there's a more canonical approach I'd > appreciate the advice. (For example, do I need to [learn how to] > create a CMake "package" for my libmylog installation -- would this > help propagate the -lpthread requirement to the build for the > executables?) > > > Thanks! > Chris > > > > > > > > From hendrik.greving.smi at gmail.com Wed Sep 26 10:23:50 2018 From: hendrik.greving.smi at gmail.com (Hendrik Greving) Date: Wed, 26 Sep 2018 07:23:50 -0700 Subject: [CMake] LOCATION target property, generator expressions In-Reply-To: References: Message-ID: Is there any way before 3.13 to achieve what I need? Right now we modify LINK_FLAGS based on something that is computed with values from LOCATION. For CMP0026, I'd like to get rid of LOCATION. As pointed out earlier, unclear how this would work e.g. by using file(GENERATE.. in this case. Thanks in advance On Tue, Sep 25, 2018, 10:45 PM Marc CHEVRIER wrote: > LINK_FLAGS does not support expressions. > However, property LINK_OPTIONS (and INTERFACE counterpart) support > generator expressions. These properties are new for version 3.13 which will > be available soon (probably next month). > Le mer. 26 sept. 2018 ? 05:21, Hendrik Greving < > hendrik.greving.smi at gmail.com> a ?crit : > >> Hello, >> >> our cmake setup is using LOCATION property for two targets to compute a >> relative path from these two, and adds this to LINK_FLAGS (for rpath, but >> irrelevant in this context). In order to update our cmake w.r.t. CMP0026, I >> don't know how to get LINK_FLAGS consume a generator expression. In other >> cases file(GENERATE.. writing a set(var TARGET_FILE..) into a file, and >> reading the file to obtain 'var' worked. Thanks in advance! >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org/mailman/listinfo/cmake >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdorier at anl.gov Thu Sep 27 04:41:52 2018 From: mdorier at anl.gov (Dorier, Matthieu) Date: Thu, 27 Sep 2018 08:41:52 +0000 Subject: [CMake] How to produce a -config.cmake file Message-ID: Hi, I'm using cmake to build a library (damaris). Once installed, I would like users to be able to find it and its dependencies using find_package(damaris). If I understand correctly, the way to do that is to have cmake create and install a "damaris-config.cmake" file. Is there a tutorial somewhere on how to do that? Here is some more information: the library depends on - Boost (using the default FindBoost.cmake installed with cmake) - XercesC (using a custom FindXercesC.cmake located in my source tree) - XSD (using a custom FindXSD.cmake as well) Additionally, it may have been built with the following optional dependencies: - CppUnit (using a custom FindCppUnit.cmake) - HDF5 (using the default FindHDF5.cmake shipped with cmake) - VisIt (using a custom FindVisIt.cmake) - ParaView (relying on the ParaViewConfig.cmake produced when installing ParaView). Thanks, Matthieu -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tomas.Kukosa at ixperta.com Thu Sep 27 05:51:32 2018 From: Tomas.Kukosa at ixperta.com (=?utf-8?B?S3Vrb3NhIFRvbcOhxaE=?=) Date: Thu, 27 Sep 2018 09:51:32 +0000 Subject: [CMake] file(TO_NATIVE_PATH ... ) and cross-compiling In-Reply-To: <585d5b5e-a46f-9d43-3fc0-62823fad1aa6@gmail.com> References: <08587f73-c14e-dda2-dc8a-2ef9b45cd136@gmail.com> <4FAA990D-C8EF-4FF1-9C71-A94E530A7156@cornell.edu> <585d5b5e-a46f-9d43-3fc0-62823fad1aa6@gmail.com> Message-ID: <29423b77-1fa7-8f73-a04d-8124f55346fb@ixperta.com> Unfortunately I encountered exactly the same problem. It would be nice to describe in documentation that file(TO_NATIVE_PATH ...) means "native for target system" and also would be nice to introduce the file(TO_HOST_NATIVE_PATH ...) subcommand. On 26.3.2018 19:40, Miroslav Ke? wrote: > I'm cross-compiling in Windows to another target system (VxWorks) but this is not so important. > > I thought the idea behind the TO_NATIVE_PATH option was that the internal CMake path representation could be transformed to the system native path so that external programs that rely on the native path convention could be easily used during the build. > > Either this my assumption is wrong or the CMake implementation is wrong. And the documentation should be more detailed on the exact behavior. > > Mira > > On 03/21/2018 09:29 PM, Stephen McDowell wrote: >> Disclaimer: I cannot speak to intent, and have never used these before. >> >> So since you?re cross compiling, when looking at the docs (?https://cmake.org/cmake/help/v3.0/command/file.html?), I?*think*?you can get away with using TO_CMAKE_PATH. ?I do?*not*?know how you actually determine this, but the idea would be >> >> if (CMAKE_CROSSCOMPILING) >> ? if (? host is windows ?) >> ? ? ? if (? target is unix ?) >> ? ? ? ? ? use TO_CMAKE_PATH ? >> ? ? ? else() >> ? ? ? ? ? use TO_NATIVE_PATH ? >> ? ? ? endif() >> ? else() # ? host is unix ? >> ? ? if (? target is unix ?) >> ? ? ? ? use TO_CMAKE_PATH or TO_NATIVE_PATH ? >> ? ? else() # ? target is windows >> ? ? ? ? PROBLEM ? >> ? ? endif() >> endif() >> >> That is, I think if you are compiling?*on*?Windows?*for*?Unix, you can cheat and use TO_CMAKE_PATH to get unix style paths. ?But if you are compiling?*on*?unix?*for*?Windows, I don?t know how you get it to be Windows paths. >> >> But if this does solve Windows -> Unix, you could maybe just message(FATAL_ERROR ?) saying that cross compiling for Windows from Unix is not supported. ?You could also take a look at the implementation of TO_NATIVE_PATH and just snag the Windows code and make your own function that converts it, maybe calling it to_windows_path() or something? >> >> I hope that is helpful, but I really don?t know if anything in the above is possible :/ >> >> >> From romain.leguay at gmail.com Thu Sep 27 06:43:24 2018 From: romain.leguay at gmail.com (Romain LEGUAY) Date: Thu, 27 Sep 2018 12:43:24 +0200 Subject: [CMake] How to append a string on list inside a function In-Reply-To: References: Message-ID: <3F04BEB4-BFF9-49C7-9F84-9B6BF79FEEF9@gmail.com> Hello everyone, I try to append a string (target name) on a list inside a function called in other CMakeLists. I have the following project?s tree: ??? CMakeLists.txt ??? test ??? CMakeLists.txt ??? app ??? CMakeLists.txt ??? appA ? ??? CMakeLists.txt ? ??? main.cpp ??? appB ??? CMakeLists.txt ??? main.cpp Inside the test/CMakeLists.txt, I defined an internal variable like this: set(allTestsList "" CACHE INTERNAL "All executable tests.'') And my function: function(addTest targetName) # create the executable with all the souces add_executable(${targetName} ${ARGN}) list(APPEND allTestsList ${targetName}) message("inside addTestFunction. allTestsList: " ${allTestsList}) endfunction() I call this function inside the test/app/appA and test/app/appB CMakeLists.txt like this: addTest(appA main.cpp) addTest(appB main.cpp) I expected to have as final result: inside addTestFunction. allTestsList: appA;appB But I only have: inside addTestFunction. allTestsList: appB I suspect that a new variable is created at each call of the function. Is it possible to use a global variable? (I tried to use PARENT_SCOPE with no success). Thank you, Romain From brad.king at kitware.com Thu Sep 27 10:29:36 2018 From: brad.king at kitware.com (Brad King) Date: Thu, 27 Sep 2018 10:29:36 -0400 Subject: [CMake] LOCATION target property, generator expressions In-Reply-To: References: Message-ID: <16167c00-884a-4513-0024-3d9a07ff79f4@kitware.com> On 09/26/2018 10:23 AM, Hendrik Greving wrote: > Is there any way before 3.13 to achieve what I need? Right now we > modify LINK_FLAGS based on something that is computed with values > from LOCATION. [snip] > our cmake setup is using LOCATION property for two targets to compute > a relative path from these two, and adds this to LINK_FLAGS > (for rpath, but irrelevant in this context). To at least see if 3.13 will support your use case, you could try a nightly binary from here: https://cmake.org/files/dev/?C=M;O=D Use `$/..` to refer to a path relative to the target file location. I've never seen a need to adjust link flags based on the target location. CMake has several features for RPATH support. What are you really trying to do? -Brad From kgt at lanl.gov Thu Sep 27 10:30:33 2018 From: kgt at lanl.gov (Thompson, KT) Date: Thu, 27 Sep 2018 14:30:33 +0000 Subject: [CMake] How to produce a -config.cmake file In-Reply-To: References: Message-ID: Matthieu, I think are asking about the CMakePackageConfigHelpers CMake module (https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html) that defines the macro 'configure_package_config_file'. You can probably find several tutorials or examples by searching github or stackoverflow, etc. for 'CMakePackageConfigHelpers'. It is also covered in some detail in the e-book "Professional CMake" by Craig Scott (requires a purchase). -kt From: CMake On Behalf Of Dorier, Matthieu Sent: Thursday, September 27, 2018 2:42 AM To: cmake at cmake.org Subject: [CMake] How to produce a -config.cmake file Hi, I'm using cmake to build a library (damaris). Once installed, I would like users to be able to find it and its dependencies using find_package(damaris). If I understand correctly, the way to do that is to have cmake create and install a "damaris-config.cmake" file. Is there a tutorial somewhere on how to do that? Here is some more information: the library depends on - Boost (using the default FindBoost.cmake installed with cmake) - XercesC (using a custom FindXercesC.cmake located in my source tree) - XSD (using a custom FindXSD.cmake as well) Additionally, it may have been built with the following optional dependencies: - CppUnit (using a custom FindCppUnit.cmake) - HDF5 (using the default FindHDF5.cmake shipped with cmake) - VisIt (using a custom FindVisIt.cmake) - ParaView (relying on the ParaViewConfig.cmake produced when installing ParaView). Thanks, Matthieu -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at gmail.com Thu Sep 27 11:11:36 2018 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Thu, 27 Sep 2018 17:11:36 +0200 Subject: [CMake] How to append a string on list inside a function In-Reply-To: <3F04BEB4-BFF9-49C7-9F84-9B6BF79FEEF9@gmail.com> References: <3F04BEB4-BFF9-49C7-9F84-9B6BF79FEEF9@gmail.com> Message-ID: Using a cache variable seems not required. A function creates a new scope and inherit a copy of all variables defined in the upper scope. So, by adding a set command using PARENT_SCOPE in your function you can update the variable in the parent scope: function(addTest targetName) # create the executable with all the souces add_executable(${targetName} ${ARGN}) list(APPEND allTestsList ${targetName}) *set (allTestsList ${allTestsList} PARENT_SCOPE) * message("inside addTestFunction. allTestsList: " ${allTestsList}) endfunction() Le jeu. 27 sept. 2018 ? 12:43, Romain LEGUAY a ?crit : > Hello everyone, > > I try to append a string (target name) on a list inside a function called > in other CMakeLists. > > I have the following project?s tree: > > ??? CMakeLists.txt > ??? test > ??? CMakeLists.txt > ??? app > ??? CMakeLists.txt > ??? appA > ? ??? CMakeLists.txt > ? ??? main.cpp > ??? appB > ??? CMakeLists.txt > ??? main.cpp > > Inside the test/CMakeLists.txt, I defined an internal variable like this: > set(allTestsList "" CACHE INTERNAL "All executable tests.'') > And my function: > function(addTest targetName) > # create the executable with all the souces > add_executable(${targetName} ${ARGN}) > list(APPEND allTestsList ${targetName}) > message("inside addTestFunction. allTestsList: " > ${allTestsList}) > endfunction() > > I call this function inside the test/app/appA and test/app/appB > CMakeLists.txt like this: > addTest(appA main.cpp) > addTest(appB main.cpp) > > I expected to have as final result: > inside addTestFunction. allTestsList: appA;appB > > But I only have: > inside addTestFunction. allTestsList: appB > > I suspect that a new variable is created at each call of the function. > > Is it possible to use a global variable? (I tried to use PARENT_SCOPE with > no success). > > Thank you, > > Romain > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Thu Sep 27 14:26:31 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 27 Sep 2018 20:26:31 +0200 Subject: [CMake] CMake Cookbook is out!! Message-ID: Hi CMakers, Hi try not do that too often but here comes a little promotion for a book which (I think) deserve attention. The CMake Cookbook by Radovan Bast, Roberto Di Remigio https://www.packtpub.com/application-development/cmake-cookbook I'm not the author but I participate in the book review and I think the authors did a great job and the book contains a lot of good stuff for CMake users. There is companion github project: https://github.com/dev-cafe/cmake-cookbook/ which contains all the recipes of example of code used in the book. All the recipes are tested to various CI in order to ensure they work as expected. Happy building for everyone. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Thu Sep 27 14:46:33 2018 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Thu, 27 Sep 2018 14:46:33 -0400 Subject: [CMake] Issues with Python, Locale, CTest and MacOS Message-ID: <464E4423-91E8-431B-8079-36F05ECDDB8D@bluequartz.net> As part of our build we use ?mkdocs? to generate our documentation. Last night I thought I made an innocuous change to our CMake files which ended up blowing up all of our macOS builds (10.10 and 10.13 systems). It is all related to trying to get Python/Mkdocs/Click to use a locale that is UTF-8 and not ASCII. Part of the error is: Error File "/usr/local/anaconda3/lib/python3.6/site-packages/click/_unicodefun.py", line 118, in _verify_python3_env 'for mitigation steps.' + extra) RuntimeError: Click will abort further execution because Python 3 was configured to use ASCII as encoding for the environment. Consult http://click.pocoo.org/python3/for mitigation steps. This system lists a couple of UTF-8 supporting locales that you can pick from. The following suitable locales where discovered: af_ZA.UTF-8, am_ET.UTF-8, be_BY.UTF-8, bg_BG.UTF-8, ca_ES.UTF-8, cs_CZ.UTF-8, da_DK.UTF-8, de_AT.UTF-8, de_CH.UTF-8, de_DE.UTF-8, el_GR.UTF-8, en_AU.UTF-8, en_CA.UTF-8, en_GB.UTF-8, en_IE.UTF-8, en_NZ.UTF-8, en_US.UTF-8, es_ES.UTF-8, et_EE.UTF-8, eu_ES.UTF-8, fi_FI.UTF-8, fr_BE.UTF-8, fr_CA.UTF-8, fr_CH.UTF-8, fr_FR.UTF-8, he_IL.UTF-8, hr_HR.UTF-8, hu_HU.UTF-8, hy_AM.UTF-8, is_IS.UTF-8, it_CH.UTF-8, it_IT.UTF-8, ja_JP.UTF-8, kk_KZ.UTF-8, ko_KR.UTF-8, lt_LT.UTF-8, nl_BE.UTF-8, nl_NL.UTF-8, no_NO.UTF-8, pl_PL.UTF-8, pt_BR.UTF-8, pt_PT.UTF-8, ro_RO.UTF-8, ru_RU.UTF-8, sk_SK.UTF-8, sl_SI.UTF-8, sr_YU.UTF-8, sv_SE.UTF-8, tr_TR.UTF-8, uk_UA.UTF-8, zh_CN.UTF-8, zh_HK.UTF-8, zh_TW.UTF-8 The whole build can be found at The _only_ way I seem to be able to get this to work is to use the built in python 2.7 at /usr/bin/python on the systems. I tried anaconda3 and python.org and neither of those worked. I can't be the only person to encounter this issue in CTest on a mac? If I build from the command line everything works just fine no matter which Python distribution that I use. The Ctest script is launched through "launchd" on the mac. I have exported environment variables, set environment variables for the locale in each bash script file that gets called? I am just plain out of ideas. Thanks for any help. -- Michael Jackson | Owner, President BlueQuartz Software [e] mike.jackson at bluequartz.net [w] www.bluequartz.net From mdorier at anl.gov Thu Sep 27 17:13:06 2018 From: mdorier at anl.gov (Dorier, Matthieu) Date: Thu, 27 Sep 2018 21:13:06 +0000 Subject: [CMake] How to produce a -config.cmake file In-Reply-To: References: , Message-ID: Thanks, those pointers helped a lot! Matthieu ________________________________ From: Thompson, KT Sent: Thursday, September 27, 2018 3:30:33 PM To: Dorier, Matthieu; cmake at cmake.org Subject: RE: How to produce a -config.cmake file Matthieu, I think are asking about the CMakePackageConfigHelpers CMake module (https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html) that defines the macro ?configure_package_config_file?. You can probably find several tutorials or examples by searching github or stackoverflow, etc. for ?CMakePackageConfigHelpers?. It is also covered in some detail in the e-book ?Professional CMake? by Craig Scott (requires a purchase). -kt From: CMake On Behalf Of Dorier, Matthieu Sent: Thursday, September 27, 2018 2:42 AM To: cmake at cmake.org Subject: [CMake] How to produce a -config.cmake file Hi, I'm using cmake to build a library (damaris). Once installed, I would like users to be able to find it and its dependencies using find_package(damaris). If I understand correctly, the way to do that is to have cmake create and install a "damaris-config.cmake" file. Is there a tutorial somewhere on how to do that? Here is some more information: the library depends on - Boost (using the default FindBoost.cmake installed with cmake) - XercesC (using a custom FindXercesC.cmake located in my source tree) - XSD (using a custom FindXSD.cmake as well) Additionally, it may have been built with the following optional dependencies: - CppUnit (using a custom FindCppUnit.cmake) - HDF5 (using the default FindHDF5.cmake shipped with cmake) - VisIt (using a custom FindVisIt.cmake) - ParaView (relying on the ParaViewConfig.cmake produced when installing ParaView). Thanks, Matthieu -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdorier at anl.gov Thu Sep 27 17:34:35 2018 From: mdorier at anl.gov (Dorier, Matthieu) Date: Thu, 27 Sep 2018 21:34:35 +0000 Subject: [CMake] Problem with FindXercesC.cmake Message-ID: Hi, I'm using cmake 3.11.4 and the FindXercesC.cmake file shipped with it. When I call find_package(XercesC REQUIRED) and XercesC is not in a standard location, I have to set XercesC_INCLUDE_DIR to its include directory and XercesC_LIBRARY to the location of the library. If I set XercesC_LIBRARY to the directory containing the library (not to the fullpath of the library itself), cmake finds XercesC but sets XercesC_LIBRARIES to the folder instead of the library, and the same for the XercesC::XercesC target. It seems I truly have to set XercesC_LIBRARY to the name of the library rather than the path to the folder containing it, which kinds of defies the point of find_package... I use to rely on a custom FindXercesC.cmake file that was using XercesC_ROOT to figure all this out. Is there any way to do the same here? Thanks, Matthieu -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.W.Irwin1234 at gmail.com Thu Sep 27 17:47:02 2018 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Thu, 27 Sep 2018 14:47:02 -0700 (PDT) Subject: [CMake] CMake Cookbook is out!! In-Reply-To: References: Message-ID: On 2018-09-27 20:26+0200 Eric Noulard wrote: > Hi CMakers, > > Hi try not do that too often but here comes a little promotion for a book > which (I think) deserve attention. > The CMake Cookbook by Radovan Bast, Roberto Di Remigio > https://www.packtpub.com/application-development/cmake-cookbook I don't buy e-books unless they are DRM-free. (See for why DRM is such a concern to knowledgable readers of e-books.) Thus, I was very happy to see the e-book form of the above book is DRM-free. Alan __________________________ Alan W. Irwin 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 mateusz at loskot.net Thu Sep 27 17:55:03 2018 From: mateusz at loskot.net (Mateusz Loskot) Date: Thu, 27 Sep 2018 23:55:03 +0200 Subject: [CMake] Problem with FindXercesC.cmake In-Reply-To: References: Message-ID: On Thu, 27 Sep 2018 at 23:34, Dorier, Matthieu wrote: > > When I call find_package(XercesC REQUIRED) and XercesC is not in a standard location, I have to set XercesC_INCLUDE_DIR to its include directory and XercesC_LIBRARY to the location of the library. Correct. If Find-module can not guess, you help it by setting FOO_INCLUDE_DIR and FOO_LIBRARY. > If I set XercesC_LIBRARY to the directory containing the library (not to the fullpath of the library itself), cmake finds XercesC but sets XercesC_LIBRARIES to the folder instead of the library, and the same for the XercesC::XercesC target. It seems I truly have to set XercesC_LIBRARY to the name of the library rather than the path to the folder containing it, which kinds of defies the point of find_package... Find-modules are guessers and as such they do not guarantee they will find anything. Sometimes you need to help it, by setting some standard variables, https://cmake.org/cmake/help/latest/manual/cmake-developer.7.html Xxx_INCLUDE_DIR - Where to find headers for using the Xxx library. Xxx_LIBRARY - The path of the Xxx library Then, Find-module can also perform extra checks of the explicitly specified library for eg. version, symbols, functions, etc. > I use to rely on a custom FindXercesC.cmake file that was using XercesC_ROOT to figure all this out. > Is there any way to do the same here? There seem to be no Xxx_ROOT_DIR handled by this module https://cmake.org/cmake/help/latest/module/FindXercesC.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From mellery451 at gmail.com Thu Sep 27 18:01:29 2018 From: mellery451 at gmail.com (Michael Ellery) Date: Thu, 27 Sep 2018 15:01:29 -0700 Subject: [CMake] Problem with FindXercesC.cmake In-Reply-To: References: Message-ID: > On Sep 27, 2018, at 2:55 PM, Mateusz Loskot wrote: > > > >> I use to rely on a custom FindXercesC.cmake file that was using XercesC_ROOT to figure all this out. >> Is there any way to do the same here? > > There seem to be no Xxx_ROOT_DIR handled by this module > https://cmake.org/cmake/help/latest/module/FindXercesC.html > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > ? although, if I understand correctly, it sounds like cmake 3.12 with policy 0074 set might give you the xx_ROOT functionality without changing the find module: https://cmake.org/cmake/help/latest/policy/CMP0074.html From rleigh at codelibre.net Thu Sep 27 18:05:08 2018 From: rleigh at codelibre.net (Roger Leigh) Date: Thu, 27 Sep 2018 23:05:08 +0100 Subject: [CMake] Problem with FindXercesC.cmake In-Reply-To: References: Message-ID: <5b7d4d2b-c155-cb2f-7b46-567e085c3d9f@codelibre.net> On 27/09/18 22:55, Mateusz Loskot wrote: > On Thu, 27 Sep 2018 at 23:34, Dorier, Matthieu wrote: >> >> When I call find_package(XercesC REQUIRED) and XercesC is not in a standard location, I have to set XercesC_INCLUDE_DIR to its include directory and XercesC_LIBRARY to the location of the library. [?] >> I use to rely on a custom FindXercesC.cmake file that was using XercesC_ROOT to figure all this out. >> Is there any way to do the same here? > > There seem to be no Xxx_ROOT_DIR handled by this module > https://cmake.org/cmake/help/latest/module/FindXercesC.html No, but CMAKE_PREFIX_PATH should be sufficient. We can certainly add XercesC_ROOT, but is it really needed? Matthieu, did you try CMAKE_PREFIX_PATH at all? (I'm not sure what the CMake policy is on this point. Is CMAKE_PREFIX_PATH support alone sufficient for Find modules?) If the consensus is that Find modules should all provide ROOT_DIR type variables, then I'm sure patches to FindXercesC and FindXalanC would be appreciated. Regards, Roger From hendrik.greving.smi at gmail.com Thu Sep 27 20:03:43 2018 From: hendrik.greving.smi at gmail.com (Hendrik Greving) Date: Thu, 27 Sep 2018 17:03:43 -0700 Subject: [CMake] LOCATION target property, generator expressions In-Reply-To: <16167c00-884a-4513-0024-3d9a07ff79f4@kitware.com> References: <16167c00-884a-4513-0024-3d9a07ff79f4@kitware.com> Message-ID: Thanks. Ok one step back. What we want is to have the same relative path from binary/executable to linked library in build and install tree (which we assume is the same for us). Looks like by default, e.g. cmake 3.9, puts in an absolute path. The current (c-)makefiles compute the relative part of an executable -> library by using LOCATION and add this to -Wl,-rpath=$ORIGIN/[relative part]. We want to do the same w/o LOCATION (i.e. resolving CMP0026) On Thu, Sep 27, 2018 at 7:29 AM Brad King wrote: > On 09/26/2018 10:23 AM, Hendrik Greving wrote: > > Is there any way before 3.13 to achieve what I need? Right now we > > modify LINK_FLAGS based on something that is computed with values > > from LOCATION. > [snip] > > our cmake setup is using LOCATION property for two targets to compute > > a relative path from these two, and adds this to LINK_FLAGS > > (for rpath, but irrelevant in this context). > > To at least see if 3.13 will support your use case, you could > try a nightly binary from here: > > https://cmake.org/files/dev/?C=M;O=D > > Use `$/..` to refer to a path relative > to the target file location. > > I've never seen a need to adjust link flags based on the target > location. CMake has several features for RPATH support. What > are you really trying to do? > > -Brad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Fri Sep 28 02:40:15 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 28 Sep 2018 08:40:15 +0200 Subject: [CMake] CMake Cookbook is out!! In-Reply-To: References: Message-ID: Le jeu. 27 sept. 2018 ? 23:49, Alan W. Irwin a ?crit : > On 2018-09-27 20:26+0200 Eric Noulard wrote: > > > Hi CMakers, > > > > Hi try not do that too often but here comes a little promotion for a book > > which (I think) deserve attention. > > The CMake Cookbook by Radovan Bast, Roberto Di Remigio > > https://www.packtpub.com/application-development/cmake-cookbook > > I don't buy e-books unless they are DRM-free. (See < > https://en.wikipedia.org/wiki/Digital_rights_management#Opposition> for > why DRM is such a concern to knowledgable readers of e-books.) > Hi Alan, I'm am well aware of the DRM plague However I shall admit that for this time I didn't checked before accepting the book review because I was pleased to help people do what I didn't manage to do myself: write a CMake book. I know both authors now and I'm pretty sure they don't want to put any knowledge in a cage. > Thus, I was very happy to see the e-book form of the above book is > DRM-free. > Yes precisely and the reason is a clear no go for DRM on the publisher side: https://hub.packtpub.com/packt-and-day-against-drm/ Don't take my words as bare advertisement but as enthusiasm for freedom. Next exchange on this off-topic will go off the CMake Mailing List. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From sancelot at numalliance.com Fri Sep 28 03:33:30 2018 From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=) Date: Fri, 28 Sep 2018 09:33:30 +0200 Subject: [CMake] CMake Cookbook is out!! In-Reply-To: References: Message-ID: <48f5db1b-ad1f-1df9-8053-6e473a9d117b@numalliance.com> Hi, Noisy, Unfortunately, at this time, there is only a table of contents . Regards, S.Ancelot Le 27/09/2018 ? 20:26, Eric Noulard a ?crit?: > Hi CMakers, > > Hi try not do that too often but here comes a little promotion for a > book which (I think) deserve attention. > The CMake Cookbook by?Radovan Bast, Roberto Di Remigio > https://www.packtpub.com/application-development/cmake-cookbook > > I'm not the author but I participate in the book review and I think > the authors did a great job and the book contains a lot of good stuff > for CMake users. > > There is companion github project: > https://github.com/dev-cafe/cmake-cookbook/ > which contains all the recipes of example of code? used in the book. > All the recipes are tested to various CI in order to ensure they work > as expected. > > Happy building for everyone. > -- > Eric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdorier at anl.gov Fri Sep 28 05:59:11 2018 From: mdorier at anl.gov (Dorier, Matthieu) Date: Fri, 28 Sep 2018 09:59:11 +0000 Subject: [CMake] Making variables visible in ccmake Message-ID: Hi, How do I make a variable visible in the ccmake tool? For example I would like the user to be able to edit BOOST_ROOT when calling ccmake, how can I do that? Right now all I see when first running ccmake is "EMPTY_CACHE", and when typing "c" to configure (which fails because some variables aren't properly set) then "e" to exit, I see the variables I have defined with "option", and I can toggle those, but I don't see other variables. I have tried the following: if(NOT DEFINED BOOST_ROOT) set(BOOST_ROOT "/usr" CACHE PATH "Root of the Boost installation") endif(NOT DEFINED BOOST_ROOT) But I still don't see it in the list of variables. Additionally, is there a way to have set of variables (namely the options, as well as things like BOOST_ROOT, CMAKE_CXX_COMPILER, CMAKE_C_COMPILER) show up when first calling ccmake, instead of EMPTY_CACHE? Thanks, Matthieu -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Fri Sep 28 06:30:31 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 28 Sep 2018 12:30:31 +0200 Subject: [CMake] Making variables visible in ccmake In-Reply-To: References: Message-ID: Le ven. 28 sept. 2018 ? 11:59, Dorier, Matthieu a ?crit : > Hi, > > > How do I make a variable visible in the ccmake tool? > > For example I would like the user to be able to edit BOOST_ROOT when > calling ccmake, how can I do that? > > > Right now all I see when first running ccmake is "EMPTY_CACHE", and when > typing "c" to configure (which fails because some variables aren't properly > set) then "e" to exit, I see the variables I have defined with "option", > and I can toggle those, but I don't see other variables. I have tried the > following: > > > if(NOT DEFINED BOOST_ROOT) > set(BOOST_ROOT "/usr" CACHE PATH "Root of the Boost installation") > endif(NOT DEFINED BOOST_ROOT) > > > But I still don't see it in the list of variables. > CACHE variables are "Advanced Variables" which are not displayed unless you toggle display advanced var in either ccmake or cmake-gui. In ccmake you have to hit 't' in order to see advanced variables. > > Additionally, is there a way to have set of variables (namely the options, > as well as things like BOOST_ROOT, CMAKE_CXX_COMPILER, CMAKE_C_COMPILER) > show up when first calling ccmake, instead of EMPTY_CACHE? > I don't know, CMAKE__COMPILER is not meant to be set with cmake UI, they ought to be set in a toolchain or outside. As noted in CMakeForceCompiler module you should not force them, use toolchain or env var before calling cmake* tool. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdorier at anl.gov Fri Sep 28 07:03:18 2018 From: mdorier at anl.gov (Dorier, Matthieu) Date: Fri, 28 Sep 2018 11:03:18 +0000 Subject: [CMake] Making variables visible in ccmake In-Reply-To: References: , Message-ID: Ah then maybe I don't understand correctly what is supposed to be displayed by ccmake. In general, how can I have in the ccmake screen some variables displayed to configure some paths to some libraries? Thanks, Matthieu ________________________________ From: Eric Noulard Sent: Friday, September 28, 2018 11:30:31 AM To: Dorier, Matthieu Cc: CMake Mailinglist Subject: Re: [CMake] Making variables visible in ccmake Le ven. 28 sept. 2018 ? 11:59, Dorier, Matthieu > a ?crit : Hi, How do I make a variable visible in the ccmake tool? For example I would like the user to be able to edit BOOST_ROOT when calling ccmake, how can I do that? Right now all I see when first running ccmake is "EMPTY_CACHE", and when typing "c" to configure (which fails because some variables aren't properly set) then "e" to exit, I see the variables I have defined with "option", and I can toggle those, but I don't see other variables. I have tried the following: if(NOT DEFINED BOOST_ROOT) set(BOOST_ROOT "/usr" CACHE PATH "Root of the Boost installation") endif(NOT DEFINED BOOST_ROOT) But I still don't see it in the list of variables. CACHE variables are "Advanced Variables" which are not displayed unless you toggle display advanced var in either ccmake or cmake-gui. In ccmake you have to hit 't' in order to see advanced variables. Additionally, is there a way to have set of variables (namely the options, as well as things like BOOST_ROOT, CMAKE_CXX_COMPILER, CMAKE_C_COMPILER) show up when first calling ccmake, instead of EMPTY_CACHE? I don't know, CMAKE__COMPILER is not meant to be set with cmake UI, they ought to be set in a toolchain or outside. As noted in CMakeForceCompiler module you should not force them, use toolchain or env var before calling cmake* tool. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Fri Sep 28 08:12:34 2018 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 28 Sep 2018 14:12:34 +0200 Subject: [CMake] Making variables visible in ccmake In-Reply-To: References: Message-ID: Le ven. 28 sept. 2018 ? 13:03, Dorier, Matthieu a ?crit : > Ah then maybe I don't understand correctly what is supposed to be > displayed by ccmake. > My usage workflow, not sure it is the expected one but other CMake users/developers may correct me if my usage is wrong. 1) Launch ccmake in an empty buiddir : ccmake -G Ninja /path/to/source 2) Hit 'c' once to populate the cache 3) hand edit needed var 4) Hit 'c' again and check result 5) Hit 'g'. Then I may have forgotten to toggle an option so I : 1) Launch ccmake in the populated build dir: ccmake . 2) hand edit the forgotten vars 3) Hit 'c' then 'g'. > In general, how can I have in the ccmake screen some variables displayed > to configure some paths to some libraries? > You have to hit 'c' once to populate the cache and make ccmake/cmake-gui aware of the defined (may be void) variables/ There was a "wizard" mode for cmake some time ago that was asking questions for setting var values but it's gone: $ cmake -i The "cmake -i" wizard mode is no longer supported. Use the -D option to set cache values on the command line. Use cmake-gui or ccmake for an interactive dialog. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Sep 28 08:49:17 2018 From: brad.king at kitware.com (Brad King) Date: Fri, 28 Sep 2018 08:49:17 -0400 Subject: [CMake] Relative RPATH for installation (was: LOCATION target property, generator expressions) In-Reply-To: References: <16167c00-884a-4513-0024-3d9a07ff79f4@kitware.com> Message-ID: On 09/27/2018 08:03 PM, Hendrik Greving wrote: > Thanks. Ok one step back. What we want is to have the same relative path > from binary/executable to linked library in build and install tree > (which we assume is the same for us). Looks like by default, > e.g. cmake 3.9, puts in an absolute path. CMake puts in absolute RPATH values in the build tree to make things run there. There is a separate INSTALL_RPATH target property that can be set to the RPATH to be used in the install tree. Since your install rules control the relative layout in the install tree independent of the build tree layout, then your project code can set INSTALL_RPATH to $ORIGIN/... as needed for wherever it installs things. -Brad From jan at swi-prolog.org Sat Sep 29 11:59:41 2018 From: jan at swi-prolog.org (Jan Wielemaker) Date: Sat, 29 Sep 2018 17:59:41 +0200 Subject: [CMake] Call function from name and list, including empty elements? Message-ID: Hi I'm converting a big project (SWI-Prolog) to cmake. Still a newbie wrt. cmake, but quite happy. There is one thing that I can't get done: install the system using symbolic links to the source tree. This is in this case really handy for developers. I've come as far as understanding: - The generator creates cmake_install.cmake - make/ninja/... install calls cmake -P cmake_install.cmake - This calls file(INSTALL ....) So, I thought I can - Add a file cmake_ln_install.cmake that - redefines file() - includes cmake_install.cmake To redefine file(), I tried this to see whether this works: function(file) message("Calling file(${ARGN})") _file(${ARGN}) endfunction() But ... some of the file() calls contain empty strings ("") in the argument vector. All the rest works fine. On stack overflow [1], the suggestion was to use "${ARGN}", which indeed keeps the empty lists and works fine if the receiver is a function iterating over its argument vector. After downloading the cmake source it turns out file() is builtin (C++) and complains to require at least 2 arguments. I tried passing the first two as file(${arg1} ${arg2} "${ARGN}"), which would (I think) work for a user function, but doesn't for a builtin. So, my question is - Is there a way to redefine a builtin function that passes empty strings correctly to the original? - If not, should this be considered a bug ... Thanks --- Jan P.s. I'd also like to see the possibility to create symlinks in cmake, other than calling cmake -E ... [1] https://stackoverflow.com/questions/52480737/pass-empty-strings-in-cmake From craig.scott at crascit.com Sat Sep 29 19:00:34 2018 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 30 Sep 2018 09:00:34 +1000 Subject: [CMake] Call function from name and list, including empty elements? In-Reply-To: References: Message-ID: On Sun, Sep 30, 2018 at 2:28 AM Jan Wielemaker wrote: > Hi > > I'm converting a big project (SWI-Prolog) to cmake. Still a newbie wrt. > cmake, but quite happy. There is one thing that I can't get done: > install the system using symbolic links to the source tree. This is in > this case really handy for developers. > This would be very unusual. An installed project should not generally require that the sources it was built from remain around. > > I've come as far as understanding: > > - The generator creates cmake_install.cmake > - make/ninja/... install calls cmake -P cmake_install.cmake > - This calls file(INSTALL ....) > > So, I thought I can > > - Add a file cmake_ln_install.cmake that > - redefines file() > - includes cmake_install.cmake > You will likely find it more convenient to use install(CODE) or install(SCRIPT) to define commands to add to the install process rather than trying to work with cmake_install.cmake directly. Those two forms of the install() command are the recommended way to get your own code into the cmake_install.cmake file that CMake generates. At the moment, you would need to use execute_process() to invoke cmake -E create_symlink to create the actual link within that code or script (see further below for state of the file() command for this). > > To redefine file(), I tried this to see whether this works: > > function(file) > message("Calling file(${ARGN})") > _file(${ARGN}) > endfunction() > Overriding built-in functions is strongly discouraged. Apart from relying on undocumented CMake behavior, the above has the potential to result in infinite recursion. I recently wrote a blog article about this which explains in more detail: https://crascit.com/2018/09/14/do-not-redefine-cmake-commands/ > > But ... some of the file() calls contain empty strings ("") in the > argument vector. All the rest works fine. > > On stack overflow [1], the suggestion was to use "${ARGN}", which > indeed keeps the empty lists and works fine if the receiver is a > function iterating over its argument vector. After downloading > the cmake source it turns out file() is builtin (C++) and complains > to require at least 2 arguments. I tried passing the first two > as file(${arg1} ${arg2} "${ARGN}"), which would (I think) work for > a user function, but doesn't for a builtin. > > [1] > https://stackoverflow.com/questions/52480737/pass-empty-strings-in-cmake > So, my question is > > - Is there a way to redefine a builtin function that passes > empty strings correctly to the original? > - If not, should this be considered a bug ... > Builtin functions should not be redefined, so no, it is not considered a bug. ;) I have a follow-up "part 2" article to the above one I linked, but it is still in preparation. It discusses other problems with trying to forward arguments using ARGN or ARGV, but some of the observations you've made here and in the linked stackoverflow article may also be relevant. If I get time, I'll try to see if I can incorporate some of the observations and behaviors you've raised. > P.s. I'd also like to see the possibility to create symlinks > in cmake, other than calling cmake -E ... > There is already a feature request with discussion for that here: https://gitlab.kitware.com/cmake/cmake/issues/16926 -- Craig Scott Melbourne, Australia https://crascit.com New book released: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan at swi-prolog.org Sun Sep 30 04:06:45 2018 From: jan at swi-prolog.org (Jan Wielemaker) Date: Sun, 30 Sep 2018 10:06:45 +0200 Subject: [CMake] Call function from name and list, including empty elements? In-Reply-To: References: Message-ID: <35acd2ad-1075-ef27-3697-79e30d6ac5ab@swi-prolog.org> Hi Craig, Thanks for the quick response. On 30/09/18 01:00, Craig Scott wrote: > > > On Sun, Sep 30, 2018 at 2:28 AM Jan Wielemaker > wrote: > > Hi > > I'm converting a big project (SWI-Prolog) to cmake. Still a newbie wrt. > cmake, but quite happy. There is one thing that I can't get done: > install the system using symbolic links to the source tree. This is in > this case really handy for developers. > > > This would be very unusual. An installed project should not generally > require that the sources it was built from remain around. I'm not proposing this as a standard feature :) SWI-Prolog is a pretty reflexive system with a lot of development features in it though. This makes it very practical to edit/develop installed Prolog libraries. This cannot be done from the source tree because it is the installation step that assembles the full environment from mostly independent packages. Right now (when using cmake) I need to go to the installed tree and copy the modified file(s) back to the sources. That is both inconvenient and error prone. Of course, this is only for developers! > I've come as far as understanding: > > - The generator creates cmake_install.cmake > - make/ninja/... install calls cmake -P cmake_install.cmake > - This calls file(INSTALL ....) > > So, I thought I can > > - Add a file cmake_ln_install.cmake that > - redefines file() > - includes cmake_install.cmake > > > You will likely find it more convenient to use install(CODE) > or > install(SCRIPT) > to > define commands to add to the install process rather than trying to work > with cmake_install.cmake directly. Those two forms of the install() > command are the recommended way to get your own code into the > cmake_install.cmake file that CMake generates. At the moment, you would > need to use execute_process() to invoke cmake -E create_symlink to > create the actual link within that code or script (see further below for > state of the file() command for this). Ok. I'm already using some install(CODE) for post-copy installation steps. I find the interface rather clumsy as you typically need to call external processes and need to get the quotes right :( Good news is that cmake allows you to hide all this stuff behind a function. So, I guess your proposal would be to define a function that abstracts away over installing the Prolog (data) files and uses one of the above if some option is selected and the usual install(FILES ...) otherwise? > To redefine file(), I tried this to see whether this works: > > function(file) > message("Calling file(${ARGN})") > _file(${ARGN}) > endfunction() > > Overriding built-in functions is strongly discouraged. Apart from > relying on undocumented CMake behavior, the above has the potential to > result in infinite recursion. I recently wrote a blog article about this > which explains in more detail: > > https://crascit.com/2018/09/14/do-not-redefine-cmake-commands/ Thanks. In this case I'm not that concerned about future robustness as it is `developers only' and when it breaks we'll find plan B ... It doesn't need to work everywhere anytime, just using a current recent version of cmake on Unix-like systems. > But ... some of the file() calls contain empty strings ("") in the > argument vector. All the rest works fine. > > On stack overflow [1], the suggestion was to use "${ARGN}", which > indeed keeps the empty lists and works fine if the receiver is a > function iterating over its argument vector. After downloading > the cmake source it turns out file() is builtin (C++) and complains > to require at least 2 arguments. I tried passing the first two > as file(${arg1} ${arg2} "${ARGN}"), which would (I think) work for > a user function, but doesn't for a builtin. > > [1] > https://stackoverflow.com/questions/52480737/pass-empty-strings-in-cmake > > So, my question is > > - Is there a way to redefine a builtin function that passes > empty strings correctly to the original? > - If not, should this be considered a bug ... > > > Builtin functions should not be redefined, so no, it is not considered a > bug. ;) :( > I have a follow-up "part 2" article to the above one I linked, but it is > still in preparation. It discusses other problems with trying to forward > arguments using ARGN or ARGV, but some of the observations you've made > here and in the linked stackoverflow article may also be relevant. If I > get time, I'll try to see if I can incorporate some of the observations > and behaviors you've raised. Is it a plan to have something that reliably does forward arguments? I needed that in some of my internal abstractions (between my own functions) and I've seen quite a few questions on how to do that. For example, call_function(name a1 a2 ... list) where list is a variable name rather than an expanded variable, i.e., the last argument is always a variable _name_? > P.s. I'd also like to see the possibility to create symlinks > in cmake, other than calling cmake -E ... > > There is already a feature request with discussion for that here: > > https://gitlab.kitware.com/cmake/cmake/issues/16926 Great! Cheers --- Jan P.s. Examining the source a bit further, it seems that installing a file that is in fact a symlink will create a symlink. Would a simple way around be to create a secondary tree next to the source tree that copies the directory structure and symlinks all the files work? P.s. Migrating from autoconf/make to cmake was a lot of work (about 2 weeks for converting 45 Makefile.in and 37 configure.ac files), but make the build specification a lot easier to follow and much shorter. Especially using the ninja backend, building is quite a bit faster as well. From kim.walisch at gmail.com Sun Sep 30 06:12:27 2018 From: kim.walisch at gmail.com (Kim Walisch) Date: Sun, 30 Sep 2018 12:12:27 +0200 Subject: [CMake] Warning when building static & shared library (DLL) on Windows Message-ID: Hi, I have recently found out about CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS which allows to easily build a shared library i.e. DLL on Windows. It works great and it is an awesome feature however I have run into a warning on Windows (using cmake, ninja, MSVC) because my CMakeLists.txt builds both a static and shared library. Here is what my CMakeLists.txt does: if(WIN32) set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON) endif() add_library(mylib SHARED ${LIB_SRC}) ... add_library(mylib STATIC ${LIB_SRC}) ... This works without any issues on all Unix-like OSes. However on Windows with MSVC I found out that building the shared library creates both mylib.dll and mylib.lib. And building the static library also creates mylib.lib which causes ninja to issue the following warning: ninja: warning: multiple rules generate mylib.lib. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn] So my question is how to best deal with this warning: 1) Should I ignore it? 2) Should I use add_library(... MODULE ...) instead of SHARED on Windows? The ninja maintainer's have suggested this when another user reported the issue here: https://github.com/ninja-build/ninja/issues/1128#issuecomment-207058115 One issue I see with this approach is that apparently when building a shared library using add_library(... MODULE ...) one should avoid using target_link_libraries(binary mylib) as mentioned in this stackoverflow answer: https://stackoverflow.com/a/4968940/363778 However the author of the stackoverflow answer also mentions that on Windows you could probably still use target_link_libraries(binary mylib)!? 3) Or is there another known workaround for this issue. Thanks, Kim -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Sun Sep 30 06:41:24 2018 From: d3ck0r at gmail.com (J Decker) Date: Sun, 30 Sep 2018 03:41:24 -0700 Subject: [CMake] Warning when building static & shared library (DLL) on Windows In-Reply-To: References: Message-ID: On Sun, Sep 30, 2018 at 3:12 AM Kim Walisch wrote: > Hi, > > I have recently found out about CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS which > allows > to easily build a shared library i.e. DLL on Windows. It works great and > it is an awesome > feature however I have run into a warning on Windows (using cmake, ninja, > MSVC) because > my CMakeLists.txt builds both a static and shared library. > > Here is what my CMakeLists.txt does: > > if(WIN32) > set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON) > endif() > > add_library(mylib SHARED ${LIB_SRC}) > make this 'mylib-sh' > ... > add_library(mylib STATIC ${LIB_SRC}) > make this 'mylib-st' > ... > > This works without any issues on all Unix-like OSes. However on Windows > with MSVC I found > out that building the shared library creates both mylib.dll and mylib.lib. > And building the static > library also creates mylib.lib which causes ninja to issue the following > warning: > > ninja: warning: multiple rules generate mylib.lib. builds involving this > target will not be correct; continuing anyway [-w dupbuild=warn] > > So my question is how to best deal with this warning: > > 1) Should I ignore it? > you need the .lib to later link to the .dll so no... > > 2) Should I use add_library(... MODULE ...) instead of SHARED on Windows? > The ninja > maintainer's have suggested this when another user reported the issue here: > https://github.com/ninja-build/ninja/issues/1128#issuecomment-207058115 > > One issue I see with this approach is that apparently when building a > shared library using > add_library(... MODULE ...) one should avoid > using target_link_libraries(binary mylib) > as mentioned in this stackoverflow answer: > https://stackoverflow.com/a/4968940/363778 > However the author of the stackoverflow answer also mentions that on > Windows you > could probably still use target_link_libraries(binary mylib)!? > > 3) Or is there another known workaround for this issue. > Could just use unique names. There's little use in practice in linking against both... if you really want to do both and have it be either just use add_library and let the user of the library deside if static or shared should be enabled. > > Thanks, > Kim > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.walisch at gmail.com Sun Sep 30 12:39:29 2018 From: kim.walisch at gmail.com (Kim Walisch) Date: Sun, 30 Sep 2018 18:39:29 +0200 Subject: [CMake] Warning when building static & shared library (DLL) on Windows In-Reply-To: References: Message-ID: Thanks! On Sun, Sep 30, 2018 at 12:41 PM J Decker wrote: > > > On Sun, Sep 30, 2018 at 3:12 AM Kim Walisch wrote: > >> Hi, >> >> I have recently found out about CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS which >> allows >> to easily build a shared library i.e. DLL on Windows. It works great and >> it is an awesome >> feature however I have run into a warning on Windows (using cmake, ninja, >> MSVC) because >> my CMakeLists.txt builds both a static and shared library. >> >> Here is what my CMakeLists.txt does: >> >> if(WIN32) >> set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON) >> endif() >> >> add_library(mylib SHARED ${LIB_SRC}) >> > make this 'mylib-sh' > >> ... >> add_library(mylib STATIC ${LIB_SRC}) >> > make this 'mylib-st' > >> ... >> >> This works without any issues on all Unix-like OSes. However on Windows >> with MSVC I found >> out that building the shared library creates both mylib.dll and >> mylib.lib. And building the static >> library also creates mylib.lib which causes ninja to issue the following >> warning: >> >> ninja: warning: multiple rules generate mylib.lib. builds involving this >> target will not be correct; continuing anyway [-w dupbuild=warn] >> >> So my question is how to best deal with this warning: >> >> 1) Should I ignore it? >> > you need the .lib to later link to the .dll so no... > >> >> 2) Should I use add_library(... MODULE ...) instead of SHARED on Windows? >> The ninja >> maintainer's have suggested this when another user reported the issue >> here: >> https://github.com/ninja-build/ninja/issues/1128#issuecomment-207058115 >> >> One issue I see with this approach is that apparently when building a >> shared library using >> add_library(... MODULE ...) one should avoid >> using target_link_libraries(binary mylib) >> as mentioned in this stackoverflow answer: >> https://stackoverflow.com/a/4968940/363778 >> However the author of the stackoverflow answer also mentions that on >> Windows you >> could probably still use target_link_libraries(binary mylib)!? >> >> 3) Or is there another known workaround for this issue. >> > Could just use unique names. > There's little use in practice in linking against both... if you really > want to do both and have it be either > just use add_library and let the user of the library deside if static or > shared should be enabled. > >> >> Thanks, >> Kim >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> https://cmake.org/mailman/listinfo/cmake >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: