From gjasny at googlemail.com Mon Apr 2 15:12:52 2018 From: gjasny at googlemail.com (Gregor Jasny) Date: Mon, 2 Apr 2018 21:12:52 +0200 Subject: [cmake-developers] iOS friendly CMake In-Reply-To: <9e9d5a26-03bf-2bf7-11a1-4a960b083e38@googlemail.com> References: <9e9d5a26-03bf-2bf7-11a1-4a960b083e38@googlemail.com> Message-ID: Hi, On 1/16/18 11:19 AM, Gregor Jasny wrote: > I created a CMake branch where I attempt to provide an easy way to > configure CMake projects for iOS (and all other Xcode SDKs). I have a second revision of the patches. Issue: https://gitlab.kitware.com/cmake/cmake/issues/17870 Branch: https://gitlab.kitware.com/gjasny/cmake/commits/17870-iphone-friendly-cmake It would be nice if you could give the branch a try. But please note the list of open todos within the issue. Thanks, Gregor From mathieu.westphal at kitware.com Wed Apr 4 03:30:49 2018 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Wed, 4 Apr 2018 09:30:49 +0200 Subject: [cmake-developers] execute_process on windows uses CreateProcess Message-ID: Hello CMake developpers. We are using execute_process in some of our tests for a Qt based application (ParaView) However, on windows, the GUI does not show up and that caused some problems for rendering. We have investigated the problem, and it looks like execute_process on windows is based on CreateProcess [1], But CreateProcess cannot interact directly with the user desktop as a GUI would need. It has to do with permissions and system environnement, see the relevant discussions [2], [3] and [4]. So here is my question : Is there a way, using cmake, to start a gui command on windows and have the gui shows up ? If not, is this intended ? Could we have this feature ? Thanks for any hindsight ! Best, Mathieu Westphal [1] : https://github.com/Kitware/KWStyle/blob/c541ae8f81d7ca739b3c03138d430cb3f41ed1c6/Utilities/KWSys/ProcessWin32.c#L1844 [2] : https://social.msdn.microsoft.com/Forums/vstudio/en-US/24cd0f16-c5c7-4574-ac27-8e785bdf6bad/createprocess-creates-the-new-process-but-the-gui-is-not-displayed?forum=vcgeneral [3] : https://stackoverflow.com/questions/948417/how-to-launch-a-gui-program-in-a-windows-service?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa [4] : https://stackoverflow.com/questions/267838/how-can-a-windows-service-execute-a-gui-application -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Apr 4 09:28:05 2018 From: brad.king at kitware.com (Brad King) Date: Wed, 4 Apr 2018 09:28:05 -0400 Subject: [cmake-developers] execute_process on windows uses CreateProcess In-Reply-To: References: Message-ID: On 04/04/2018 03:30 AM, Mathieu Westphal wrote: > Is there a way, using cmake, to start a gui command on windows > and have the gui shows up ? ``` execute_process(COMMAND cmd /c notepad) ``` > If not, is this intended? Yes. Otherwise console windows appear for everything. CreateProcessW is *the* way to create a process on Windows. It has flags to control whether a window is shown, and we intentionally set them to not show the window. > Could we have this feature ? The `cmd /c` workaround should be sufficient, but it wouldn't be hard to add an option to the execute_process command to allow the window to be shown. -Brad From irwin at beluga.phys.uvic.ca Wed Apr 4 15:10:21 2018 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 4 Apr 2018 12:10:21 -0700 (PDT) Subject: [cmake-developers] Is the "cmake_policy (VERSION 3.11)" statement in the latest UseSWIG.cmake correct? Message-ID: According to , an important side effect of "cmake_policy (VERSION 3.11)" is that no user with cmake version less than 3.11.0 can use the latest version of UseSWIG.cmake. Was that change intended (i.e., does the latest version of UseSWIG.cmake use policies AND CMake logic that is only available for 3.11.0 and higher)? If so, fair enough. But if not (i.e., the latest version of UseSWIG.cmake would work fine for earlier versions of CMake) I suggest you adjust the above VERSION 3.11 to the actual minimum version of CMake that will work with this module to advertise what range of older versions of CMake can use it as a replacement for the buggy official UseSWIG.cmake that they would otherwise be using. This reason this issue has come up for me is that I had to copy the 3.9.1 UseSWIG.cmake module to PLplot to give our users that use older versions of CMake such as 3.6.2 access to an important bug fix in that version. And that copy has worked fine for us ever since for those using, e.g., cmake version 3.6.2. So as a result I became interested in the official further development of UseSWIG.cmake module after 3.9.1 in case there were any further bug fixes that would be important to our users. And that investigation left me wondering whether that "cmake_policy (VERSION 3.11)" statement actually states the correct minimum version of cmake that would work with this module. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From marc.chevrier at sap.com Thu Apr 5 03:34:52 2018 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Thu, 5 Apr 2018 07:34:52 +0000 Subject: [cmake-developers] Is the "cmake_policy (VERSION 3.11)" statement in the latest UseSWIG.cmake correct? In-Reply-To: References: Message-ID: <39771D8F-6ACF-4831-92A8-1B98EE721600@sap.com> Yes, the "cmake_policy" command is here on purpose because the "new" module rely on features (mainly source properties) introduced in CMake version 3.11. ?On 04/04/2018 21:18, "cmake-developers on behalf of Alan W. Irwin" wrote: According to , an important side effect of "cmake_policy (VERSION 3.11)" is that no user with cmake version less than 3.11.0 can use the latest version of UseSWIG.cmake. Was that change intended (i.e., does the latest version of UseSWIG.cmake use policies AND CMake logic that is only available for 3.11.0 and higher)? If so, fair enough. But if not (i.e., the latest version of UseSWIG.cmake would work fine for earlier versions of CMake) I suggest you adjust the above VERSION 3.11 to the actual minimum version of CMake that will work with this module to advertise what range of older versions of CMake can use it as a replacement for the buggy official UseSWIG.cmake that they would otherwise be using. This reason this issue has come up for me is that I had to copy the 3.9.1 UseSWIG.cmake module to PLplot to give our users that use older versions of CMake such as 3.6.2 access to an important bug fix in that version. And that copy has worked fine for us ever since for those using, e.g., cmake version 3.6.2. So as a result I became interested in the official further development of UseSWIG.cmake module after 3.9.1 in case there were any further bug fixes that would be important to our users. And that investigation left me wondering whether that "cmake_policy (VERSION 3.11)" statement actually states the correct minimum version of cmake that would work with this module. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake-developers From irwin at beluga.phys.uvic.ca Thu Apr 5 12:30:36 2018 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 5 Apr 2018 09:30:36 -0700 (PDT) Subject: [cmake-developers] Is the "cmake_policy (VERSION 3.11)" statement in the latest UseSWIG.cmake correct? In-Reply-To: <39771D8F-6ACF-4831-92A8-1B98EE721600@sap.com> References: <39771D8F-6ACF-4831-92A8-1B98EE721600@sap.com> Message-ID: On 2018-04-05 07:34-0000 CHEVRIER, Marc wrote: > Yes, the "cmake_policy" command is here on purpose because the "new" module rely on features (mainly source properties) introduced in CMake version 3.11. OK. Thanks for that clear answer and also for maintaining this important module. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From matthias.goesswein at eeas.at Wed Apr 11 10:48:56 2018 From: matthias.goesswein at eeas.at (=?UTF-8?Q?G=c3=b6=c3=9fwein_Matthias_/_eeas_gmbh?=) Date: Wed, 11 Apr 2018 16:48:56 +0200 Subject: [cmake-developers] Usage Requirements with Object Libraries Message-ID: <1d60abc2-57ee-11ab-0b30-cbf28cc32a68@eeas.at> Hello, Right now I'm using a nightly build (3.11.20180407-g268d0) to use and test the Usage Requirements with Object Libraries, which is planned for CMake 3.12.0 (https://gitlab.kitware.com/cmake/cmake/issues/14778) It's working great so far, but I if i have a construct of two object libraries, which depend in some way of each other I get an error message: CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle): ? "lib1" of type OBJECT_LIBRARY ??? depends on "lib2" (strong) ? "lib2" of type OBJECT_LIBRARY ??? depends on "lib1" (weak) At least one of these targets is not a STATIC_LIBRARY.? Cyclic dependencies are allowed only among static libraries. CMakeLists.txt: add_library(lib1 OBJECT lib1.c) target_link_libraries(lib1 PUBLIC lib2) add_library(lib2 OBJECT lib2.c) target_link_libraries(lib2 PUBLIC lib1) If i use Static libraries, then it works (in fact even if only one library is an object library it fails). Is it possible to implement the same thing for object libraries too, or are there some technical restrictions? In the past i had sometimes such cyclic dependencies with legacy code and i think it would be great if it is possible to support such dependencies with object libraries as well. Best regards, Matthias Goesswein. -- matthias.goesswein at eeas.at /mail www.eeas.at /web +43 660 1280 131 /phone ------------------------------ eeas gmbh Technologiepark 17 4320 Perg Austria ------------------------------ ATU67456549 /uid FN385458a /firmenbuchnummer landesgericht linz /firmenbuch From brad.king at kitware.com Wed Apr 11 11:45:59 2018 From: brad.king at kitware.com (Brad King) Date: Wed, 11 Apr 2018 11:45:59 -0400 Subject: [cmake-developers] Usage Requirements with Object Libraries In-Reply-To: <1d60abc2-57ee-11ab-0b30-cbf28cc32a68@eeas.at> References: <1d60abc2-57ee-11ab-0b30-cbf28cc32a68@eeas.at> Message-ID: On 04/11/2018 10:48 AM, G??wein Matthias / eeas gmbh wrote: > CMake Error: The inter-target dependency graph contains the following > strongly connected component (cycle): > ? "lib1" of type OBJECT_LIBRARY > ??? depends on "lib2" (strong) > ? "lib2" of type OBJECT_LIBRARY > ??? depends on "lib1" (weak) > At least one of these targets is not a STATIC_LIBRARY.? Cyclic > dependencies are allowed only among static libraries. > > add_library(lib1 OBJECT lib1.c) > target_link_libraries(lib1 PUBLIC lib2) > add_library(lib2 OBJECT lib2.c) > target_link_libraries(lib2 PUBLIC lib1) > > Is it possible to implement the same thing for object libraries too For reference, the documentation of tll behavior for object libraries is here: https://cmake.org/cmake/help/git-master/command/target_link_libraries.html#linking-object-libraries It states that "linking" object libraries to each other only propagates usage requirements and does nothing special with the object files. If there are dependencies like this then consumers would need to list both object libraries together. All object files would be listed once on the link line and no repetition would be needed since explicitly listing them guarantees they are linked. Likely this will be okay. However, I'd like to avoid supporting the case until we gain more experience with the current design. I've opened an issue to track it here: * OBJECT library circular target_link_libraries https://gitlab.kitware.com/cmake/cmake/issues/17905 Thanks, -Brad From Lenindarbi.Jayakumar at magna.com Wed Apr 11 12:25:26 2018 From: Lenindarbi.Jayakumar at magna.com (Jayakumar, Lenindarbi) Date: Wed, 11 Apr 2018 16:25:26 +0000 Subject: [cmake-developers] CMAKE :: mingw make files with response file for includes References: <869a0ca961ff4ba58ec22a3cf4c93493@FRAMSEX06.magna.global> Message-ID: Hi Brad, Is the below issue solved in latest release 3.11.0 ? Could you please confirm? Gr??e Lenin -----Original Message----- From: Jayakumar, Lenindarbi Sent: Freitag, 19. Januar 2018 15:26 To: 'Brad King' ; cmake-developers at cmake.org Subject: RE: [cmake-developers] CMAKE :: mingw make files with response file for includes Thanks for the reply. It is not compiler and linker. I have to use response file for both includes and objects. Tasking compiler expects -f as Response file link flag for both. But cmake produces command line for objects using -f and includes using @. I prefer to get it fixed in generator. Unfortunately I don't have enough time and experience. Perhaps an cmake expert could confirm and fix it. Possible cause: The @ symbol is hardcoded in "cmMakefileTargetGenerator::AddIncludeFlags" function in file ../Source/cmMakefileTargetGenerator.cxx if (useResponseFile) { std::string name = "includes_"; name += lang; name += ".rsp"; std::string arg = "@" + this->CreateResponseFile(name.c_str(), includeFlags, this->FlagFileDepends[lang]); this->LocalGenerator->AppendFlags(flags, arg); } However, the implementation should be like in "cmMakefileTargetGenerator::CreateObjectLists" function. // Lookup the response file reference flag. std::string responseFlagVar = "CMAKE_"; responseFlagVar += this->GeneratorTarget->GetLinkerLanguage(this->ConfigName); responseFlagVar += "_RESPONSE_FILE_LINK_FLAG"; const char* responseFlag = this->Makefile->GetDefinition(responseFlagVar); if (!responseFlag) { responseFlag = "@"; } Thanks, Lenin -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Freitag, 19. Januar 2018 15:01 To: Jayakumar, Lenindarbi >; cmake-developers at cmake.org Subject: Re: [cmake-developers] CMAKE :: mingw make files with response file for includes On 01/17/2018 03:52 AM, Jayakumar, Lenindarbi wrote: > Response file link flag "CMAKE_C_RESPONSE_FILE_LINK_FLAG" is not > customizable for include paths. > The @ symbol is hardcoded in "cmMakefileTargetGenerator::AddIncludeFlags" In case the compiler and link driver want different response file flags, one could add a separate "CMAKE__RESPONSE_FILE_COMPILE_FLAG" variable to use for include flags. See https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst for contribution instructions if you'd like to work on it. Thanks, -Brad -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: "Jayakumar, Lenindarbi" Subject: CMAKE :: mingw make files with response file for includes Date: Wed, 17 Jan 2018 08:52:54 +0000 Size: 15808 URL: From brad.king at kitware.com Wed Apr 11 13:02:15 2018 From: brad.king at kitware.com (Brad King) Date: Wed, 11 Apr 2018 13:02:15 -0400 Subject: [cmake-developers] CMAKE :: mingw make files with response file for includes In-Reply-To: References: <869a0ca961ff4ba58ec22a3cf4c93493@FRAMSEX06.magna.global> Message-ID: <24ea53df-6648-4045-8deb-e063b922d676@kitware.com> On 04/11/2018 12:25 PM, Jayakumar, Lenindarbi wrote: > Is the below issue solved in latest release 3.11.0 ? > Could you please confirm? The fix discussed elsewhere in the thread: https://gitlab.kitware.com/cmake/cmake/merge_requests/1691 is in 3.11.0. The `@` is no longer hard coded. I think it should work now. -Brad From Lenindarbi.Jayakumar at magna.com Thu Apr 12 04:35:17 2018 From: Lenindarbi.Jayakumar at magna.com (Jayakumar, Lenindarbi) Date: Thu, 12 Apr 2018 08:35:17 +0000 Subject: [cmake-developers] CMAKE :: mingw make files with response file for includes In-Reply-To: <24ea53df-6648-4045-8deb-e063b922d676@kitware.com> References: <869a0ca961ff4ba58ec22a3cf4c93493@FRAMSEX06.magna.global> <24ea53df-6648-4045-8deb-e063b922d676@kitware.com> Message-ID: <64d62182a00544f484dcfdf16171da88@FRAMSEX06.magna.global> Perfect. It works. Gr??e Lenin -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Mittwoch, 11. April 2018 19:02 To: Jayakumar, Lenindarbi ; cmake-developers at cmake.org Cc: 'lenindarbi at gmail.com' Subject: Re: [cmake-developers] CMAKE :: mingw make files with response file for includes On 04/11/2018 12:25 PM, Jayakumar, Lenindarbi wrote: > Is the below issue solved in latest release 3.11.0 ? > Could you please confirm? The fix discussed elsewhere in the thread: https://gitlab.kitware.com/cmake/cmake/merge_requests/1691 is in 3.11.0. The `@` is no longer hard coded. I think it should work now. -Brad From robert.maynard at kitware.com Tue Apr 17 11:35:44 2018 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 17 Apr 2018 11:35:44 -0400 Subject: [cmake-developers] [ANNOUNCE] CMake 3.11.1 available for download Message-ID: We are pleased to announce that CMake 3.11.1 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.11.1 since 3.11.0: Brad King (5): Revert "CheckIncludeFiles: Honor CMAKE_REQUIRED_LIBRARIES" CPack: Fix crash on invalid generator name Restore support for explicitly referenced CMakeLists.txt sources Exclude "libgcc_eh" library files from implicit link libraries CMake 3.11.1 Daniel Filipe (1): Features: Record for VS 2017 through 15.6 Kirill Erofeev (2): Explicitly require LibUV 1.10 or higher to build CMake bootstrap: Add option to enable/disable usage of system libuv R2RT (1): Fix crash with --trace-expand --warn-uninitialized together Roland Schulz (1): FindOpenMP: Fix support for Intel on Windows Sebastian Holtermann (7): Autogen: Protected calls to cmSystemTools::CollapseCombinedPath Autogen: Protected calls to cmSystemTools::Split/JoinPath Autogen: Protected calls to cmSystemTools::GetFilenameWithoutLastExtension Autogen: Protected calls to cmQtAutoGen::SubDirPrefix Autogen: Protected calls to cmFilePathChecksum Autogen: Use std::istreambuf_iterator for file so string reading Autogen: Print moc/uic/rcc output to stdout From neundorf at kde.org Tue Apr 17 16:15:31 2018 From: neundorf at kde.org (Alexander Neundorf) Date: Tue, 17 Apr 2018 22:15:31 +0200 Subject: [cmake-developers] Adding a non-make based generator In-Reply-To: <4019658.14JC1xEBJ6@linux-l7nd> References: <1804321e67e648f8ad6819459aba127e@SVR-IES-MBX-03.mgc.mentorg.com> <4019658.14JC1xEBJ6@linux-l7nd> Message-ID: <5065398.c1udZTuO0x@linux-l7nd> Hi, On 2018 M02 14, Wed 22:16:54 CEST Alexander Neundorf wrote: > On 2018 M02 14, Wed 18:46:52 CET Saeed, Khurram wrote: > > Thanks Alex. > > Yes it does support generating the project in the build dir. It also works > > while generating in a subdir of the source dir. Eclipse version control > > plugin also works (I am using git). > > Interesting. > How did you get that working ? > > Let's say the directories look like this: > > src/CMakeLists.txt > build/CMakeCache.txt > build/.project > build/.cproject > > I guess this is what you generate, right ? > How do you get the source tree into this project ? > The Eclipse-generator in cmake uses a "linked resource" to the source dir, > but the version control plugin is not activated for those files. > According to the Subversion-Plugin developers this is because the source > files are then outside the "project directory", i.e. no below the directory > where the .project file is located. > > So I'm really interested how you got that working. > Can you send the .project and .cproject files for a simple hello-world > project, built out-of-source ? any news here ? Alex From cristian.adam at gmail.com Tue Apr 24 01:03:22 2018 From: cristian.adam at gmail.com (Cristian Adam) Date: Tue, 24 Apr 2018 07:03:22 +0200 Subject: [cmake-developers] CMake Checks Cache Message-ID: Hi, If you use CMake in a CI you should probably have a look at how to speed up your CMake build: https://github.com/cristianadam/cmake-checks-cache In the case of LLVM + Clang on a Windows box the speed up was either 2.66x or 3.32x, depending on the CMake generator. Even if you don't use CMake Check macros you might want to cache the initial compiler detection, which could take a few seconds :) Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stotko at informatik.uni-bonn.de Wed Apr 25 14:22:10 2018 From: stotko at informatik.uni-bonn.de (Patrick Stotko) Date: Wed, 25 Apr 2018 20:22:10 +0200 Subject: [cmake-developers] target_link_libraries not callable from other directory scopes Message-ID: Hi, this nice post (https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/) mentions some modern usage of target_sources(), but also shows some discrepancy between target_link_libraries and the remaining target_* functions. In particlar, CMake does not allow linking to a target outside its creation scope whereas all the other ones do. There exists a workaround with include(), but it seems not the correct and clean way to handle this. So I think lifting this limitation would escepially help large-scale projects and improve modularization by handling third-party dependencies in the specific modules (as long as only this particular module needs it). So what is your experience regarding this linking restriction, especially in larger projects? I also opened an issue for this (see https://gitlab.kitware.com/cmake/cmake/issues/17943). Best regards, Patrick Stotko From craig.scott at crascit.com Thu Apr 26 19:18:40 2018 From: craig.scott at crascit.com (Craig Scott) Date: Fri, 27 Apr 2018 09:18:40 +1000 Subject: [cmake-developers] target_link_libraries not callable from other directory scopes In-Reply-To: References: Message-ID: On Thu, Apr 26, 2018 at 4:22 AM, Patrick Stotko < stotko at informatik.uni-bonn.de> wrote: > Hi, > > this nice post (https://crascit.com/2016/01/3 > 1/enhanced-source-file-handling-with-target_sources/) mentions some > modern usage of target_sources(), but also shows some discrepancy between > target_link_libraries and the remaining target_* functions. In particlar, > CMake does not allow linking to a target outside its creation scope whereas > all the other ones do. There exists a workaround with include(), but it > seems not the correct and clean way to handle this. > > So I think lifting this limitation would escepially help large-scale > projects and improve modularization by handling third-party dependencies in > the specific modules (as long as only this particular module needs it). > > So what is your experience regarding this linking restriction, especially > in larger projects? I also opened an issue for this (see > https://gitlab.kitware.com/cmake/cmake/issues/17943). > > And from Brad's comment on that gitlab issue: This limitation has been intentional since target_link_libraries was first created long before the others. It is the oldest of the target_ commands. The original justification is that we don't want to allow this because it makes it very easy for non-local commands to drastically change the way a target is built. That the newer target_ commands allow non-local targets was an oversight. Maybe the limitation could be lifted but I'd like to see a strong justification and example use case. Perhaps it was an oversight that newer target_... commands don't have the same restriction as target_link_libraries(), but it is a very useful oversight! As the linked blog article explains, it allows much better modularity of the project. Extracting part of one of my comments on the above-linked article: For a real world example, consider a library or executable that has many source files and where some functionality is optional and/or depends on the availability of some external toolkit. Code related to such an optional feature can be put in its own sub directory and conditionally included in the library or executable. That sub directory can hold all the logic related to that feature, including any external libraries that need to be linked in. This is good modularisation since it localised the logic instead of polluting the main CMakeLists.txt file. It isn?t always possible or desirable to split out such an optional feature to its own library (eg to ensure aspects of the implementation are not revealed by exported symbol names or similar concerns). Thus, being able to incorporate it directly into the main library or executable could be a requirement. Being able to still isolate everything related to that feature in its own sub directory can help keep things organised and easy to manage. Being able to use add_subdirectory() instead of include() allows the subdirectory to be more isolated, since any variables changed in the subdirectory's scope won't affect the current scope. For new users, add_subdirectory() also tends to feel more natural than include() and lead to fewer errors. When using include(), you have to be very careful to use CMAKE_CURRENT_LIST_DIR instead of CMAKE_CURRENT_SOURCE_DIR whenever you need to construct an absolute path to something in the same (source) directory, but new users often seem to not really know about CMAKE_CURRENT_LIST_DIR. There's also no corresponding binary directory if you use include(), unlike add_subdirectory() which nicely reproduces the source directory structure in the build directory. Basically you can do things with include() if you are careful, but add_subdirectory() is more intuitive and more forgiving. The current restriction on target_link_libraries() is the one hold-out for being able to make subdirectories fully self-contained as far as building things goes. Adding to the above quoted comment from the article, my experience on some large projects has been that I can modularise optional parts of libraries quite well using the various target_...() commands, but then I have to duplicate some of the logic just because I still have to put the target_link_libraries() call in the same directory as where the target is defined. That's been a thorn in my side, because the modularity made possible by target_sources() and the other target_...() commands have otherwise allowed me to make the CMakeLists.txt files in each subdirectory quite focused on just what that directory supplies. I found that using include() instead of add_subdirectory() was confusing for some of our users, so I tend to prefer to use add_subdirectory() and live with the target_link_libraries() calls being leaked to the main directory, but I would really love to avoid having to do that. -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Apr 27 09:13:03 2018 From: brad.king at kitware.com (Brad King) Date: Fri, 27 Apr 2018 09:13:03 -0400 Subject: [cmake-developers] target_link_libraries not callable from other directory scopes In-Reply-To: References: Message-ID: <19eee405-520f-98bd-12b2-3ea870d588e2@kitware.com> On 04/26/2018 07:18 PM, Craig Scott wrote: > Perhaps it was an oversight that newer target_... commands don't have the same > restriction as target_link_libraries(), but it is a very useful oversight! > As the linked blog article explains, it allows much better modularity of the > project. Yes, and usage requirements make non-local effects commonplace anyway. Those didn't exist when the `target_link_libraries` restriction was first put in place. Back then *everything* that affected a target's build was in its own `CMakeLists.txt` file. > Being able to use add_subdirectory() instead of include() allows the subdirectory > to be more isolated The original restriction was to prevent parent and sibling directories from affecting a target's build. We didn't think much about subdirectories as a way of incrementally accumulating build information for a target. I think it would be fine to lift the restriction if there is no technical hurdle. -Brad From stotko at informatik.uni-bonn.de Fri Apr 27 14:36:19 2018 From: stotko at informatik.uni-bonn.de (Patrick Stotko) Date: Fri, 27 Apr 2018 20:36:19 +0200 Subject: [cmake-developers] target_link_libraries not callable from other directory scopes In-Reply-To: <19eee405-520f-98bd-12b2-3ea870d588e2@kitware.com> References: <19eee405-520f-98bd-12b2-3ea870d588e2@kitware.com> Message-ID: Am 27.04.2018 um 15:13 schrieb Brad King: > On 04/26/2018 07:18 PM, Craig Scott wrote: >> Perhaps it was an oversight that newer target_... commands don't have the same >> restriction as target_link_libraries(), but it is a very useful oversight! >> As the linked blog article explains, it allows much better modularity of the >> project. > Yes, and usage requirements make non-local effects commonplace anyway. > Those didn't exist when the `target_link_libraries` restriction was > first put in place. Back then *everything* that affected a target's > build was in its own `CMakeLists.txt` file. > >> Being able to use add_subdirectory() instead of include() allows the subdirectory >> to be more isolated > The original restriction was to prevent parent and sibling directories from > affecting a target's build. We didn't think much about subdirectories as > a way of incrementally accumulating build information for a target. > > I think it would be fine to lift the restriction if there is no technical > hurdle. > > -Brad As far as I can see, the code that prevents linking from other directories starts here: https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmTargetLinkLibrariesCommand.cxx#L369 The check for imported targets should be definitly kept since users should still not be able to modify third party targets. Maybe FindLocalNonAliasTarget() can be replaced with something like FindNonAliasTarget() or FindGlobalNonAliasTarget() to catch aliases. I am not sure whether such a thing already exists or must be implemented. We can also continue the discussion at GitLab to avoid bothering the others with such technical details if you like. Best regards, Patrick Stotko From brad.king at kitware.com Fri Apr 27 14:39:19 2018 From: brad.king at kitware.com (Brad King) Date: Fri, 27 Apr 2018 14:39:19 -0400 Subject: [cmake-developers] target_link_libraries not callable from other directory scopes In-Reply-To: References: <19eee405-520f-98bd-12b2-3ea870d588e2@kitware.com> Message-ID: <16790261-ac28-bd61-63b8-298d7ba602cd@kitware.com> On 04/27/2018 02:36 PM, Patrick Stotko wrote: > We can also continue the discussion at GitLab to avoid bothering the > others with such technical details if you like. Fine with me. I mainly wanted it brought up here to gain more attention. Interested followers can now jump to the issue: https://gitlab.kitware.com/cmake/cmake/issues/17943 -Brad From eike at sf-mail.de Fri Apr 27 14:53:00 2018 From: eike at sf-mail.de (Rolf Eike Beer) Date: Fri, 27 Apr 2018 20:53 +0200 Subject: [cmake-developers] target_link_libraries not callable from other directory scopes In-Reply-To: References: Message-ID: <5087267.uq8KpsXYe4@daneel.sf-tec.de> Craig Scott wrote: > This limitation has been intentional since target_link_libraries was first > created long before the others. It is the oldest of the target_ commands. > The original justification is that we don't want to allow this because it > makes it very easy for non-local commands to drastically change the way a > target is built. That the newer target_ commands allow non-local targets > was an oversight. > > Maybe the limitation could be lifted but I'd like to see a strong > justification and example use case. [?] This sounds very much like what I'm doing for OSM2go by other means. This will become simpler once 3.12 is out and object libraries can drag in additional dependencies: https://github.com/osm2go/osm2go/blob/master/src/platforms/gtk/CMakeLists.txt Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: