From julius.caro at gmail.com Thu Jun 1 07:11:48 2017 From: julius.caro at gmail.com (Luis Caro Campos) Date: Thu, 1 Jun 2017 12:11:48 +0100 Subject: [CMake] Using target_link_libraries INTERFACE with static libraries Message-ID: I have the following scenario where I have 2 static libraries, where one uses symbols from the other, and the executable needs to link against both in order to build properly. Library 'Bar' uses symbols from library 'Foo' internally, but 'Foo' is not part of the "interface" of Bar, i.e., the calling library/application only needs to include headers from 'Bar', and use symbols from Bar. --- #static libraries, assuming BUILD_SHARED_LIBS is off add_library(Foo) add_library(Bar) target_include_directories(Foo PRIVATE ... ) target_include_directories(Foo INTERFACE ...) target_include_directories(Bar PRIVATE ...) target_include_directories(Bar INTERFACE ..) # this will expose Bar to Foo's interface include directories target_link_libraries(Bar PUBLIC|PRIVATE Foo) add_executable(MyApp) target_link_libraries(MyApp PRIVATE Bar) --- In order to for the executable "MyApp" to build successfully, which uses static library Bar, "Foo" also needs be in the link statement otherwise I'll get missing symbols. If 'Bar' doesn't include this information in the target link interface, I'll have to explicitly link against "Foo" for MyApp. My question is, in this case, which is the correct keyword for use when calling "target_link_libraries" between Bar and Foo? Technically, 'Foo' is not part of Bar's public interface, so it would be PRIVATE. However, this would force me to have to expressly link against Foo in MyApp. The other alternative is PUBLIC, as that would take care of the dependency. I think strictly speaking, it is an "interface link dependency", but not an "interface" dependency. I know that there are LINK_PUBLIC and LINK_PRIVATE keywords for target_link_libraries, however the documentation says they are for compatibility only and the other ones should be favoured. So in this scenario, I guess "PUBLIC" would be the best case, as that takes care of the linking of MyApp. Question (1): does this not have the downside of adding Foo's interface include directories to MyApp's include path? The second scenario would be if Foo was static and Bar was shared. In that case, it would be crystal clear, the target_link_libraries call between Foo and Bar should use the PRIVATE keyword. However, what about if BUILD_SHARED_LIBS was set to on? Both would be shared libraries, but MyApp doesn't need to link against "Foo" anymore, however it is needed at runtime. Question (2): toggling the BUILD_SHARED_LIBS flag then seems to require altering the semantics of calls to target_link_libraries? What about the "needed at runtime" but "no part of the interface case? My conclusion is that I should perhaps explicitly declare those libraries as static (foo and bar), and use the "PUBLIC" keyword when linking them. Although I see two downsides: 1) Foo's interface include path is added to MyApp's include path (and it is not needed) 2) Bar is now dependant on "Foo", so Foo needs to be built before. However, from a compiler point of view, the binaries of Foo are not needed to produce bar. Any help would be appreciated, in case there are better ways to express these dependencies that I'm ignoring. Thanks, Luis -------------- next part -------------- An HTML attachment was scrubbed... URL: From mario.werner at iaik.tugraz.at Thu Jun 1 07:53:29 2017 From: mario.werner at iaik.tugraz.at (Mario Werner) Date: Thu, 1 Jun 2017 13:53:29 +0200 Subject: [CMake] Using target_link_libraries INTERFACE with static libraries In-Reply-To: References: Message-ID: Hi Luis, as you correctly concluded, if 'Foo' is not part of the public interface of 'Bar', then the PRIVATE is the correct specifier. However, you don't have to add 'Foo' to the consumers of 'Bar' (e.g., 'MyApp'). If everything works as expected, CMake automatically tracks the link dependency from 'Bar' to 'Foo' and adds it to the link command of the consuming artifact when 'Bar' is a static library. I did a quick experiment based on the code layout you outlined and for me everything worked out of the box. If it does not for you, it would be great if you can provide an actual minimal working example which shows the issue. Maybe the very detailed explanation [1] provided by Craig Scott is also interesting in this context. HTH, Mario [1] https://cmake.org/pipermail/cmake/2016-May/063400.html On 2017-06-01 13:11, Luis Caro Campos wrote: > I have the following scenario where I have 2 static libraries, where one > uses symbols from the other, and the executable needs to link against both > in order to build properly. > > Library 'Bar' uses symbols from library 'Foo' internally, but 'Foo' is not > part of the "interface" of Bar, i.e., the calling library/application only > needs to include headers from 'Bar', and use symbols from Bar. > > --- > #static libraries, assuming BUILD_SHARED_LIBS is off > add_library(Foo) > add_library(Bar) > target_include_directories(Foo PRIVATE ... ) > target_include_directories(Foo INTERFACE ...) > target_include_directories(Bar PRIVATE ...) > target_include_directories(Bar INTERFACE ..) > > # this will expose Bar to Foo's interface include directories > target_link_libraries(Bar PUBLIC|PRIVATE Foo) > > > add_executable(MyApp) > target_link_libraries(MyApp PRIVATE Bar) > > --- > > In order to for the executable "MyApp" to build successfully, which uses > static library Bar, "Foo" also needs be in the link statement otherwise > I'll get missing symbols. If 'Bar' doesn't include this information in the > target link interface, I'll have to explicitly link against "Foo" for MyApp. > > My question is, in this case, which is the correct keyword for use when > calling "target_link_libraries" between Bar and Foo? > > Technically, 'Foo' is not part of Bar's public interface, so it would be > PRIVATE. However, this would force me to have to expressly link against Foo > in MyApp. > The other alternative is PUBLIC, as that would take care of the dependency. > I think strictly speaking, it is an "interface link dependency", but not an > "interface" dependency. I know that there are LINK_PUBLIC and LINK_PRIVATE > keywords for target_link_libraries, however the documentation says they are > for compatibility only and the other ones should be favoured. > > So in this scenario, I guess "PUBLIC" would be the best case, as that takes > care of the linking of MyApp. > > Question (1): does this not have the downside of adding Foo's interface > include directories to MyApp's include path? > > The second scenario would be if Foo was static and Bar was shared. In that > case, it would be crystal clear, the target_link_libraries call between Foo > and Bar should use the PRIVATE keyword. > However, what about if BUILD_SHARED_LIBS was set to on? > Both would be shared libraries, but MyApp doesn't need to link against > "Foo" anymore, however it is needed at runtime. > > Question (2): toggling the BUILD_SHARED_LIBS flag then seems to require > altering the semantics of calls to target_link_libraries? What about the > "needed at runtime" but "no part of the interface case? > > My conclusion is that I should perhaps explicitly declare those libraries > as static (foo and bar), and use the "PUBLIC" keyword when linking them. > Although I see two downsides: > 1) Foo's interface include path is added to MyApp's include path (and it is > not needed) > 2) Bar is now dependant on "Foo", so Foo needs to be built before. However, > from a compiler point of view, the binaries of Foo are not needed to > produce bar. > > Any help would be appreciated, in case there are better ways to express > these dependencies that I'm ignoring. > > > > Thanks, > Luis > > > From julius.caro at gmail.com Thu Jun 1 08:20:55 2017 From: julius.caro at gmail.com (Luis Caro Campos) Date: Thu, 1 Jun 2017 13:20:55 +0100 Subject: [CMake] Using target_link_libraries INTERFACE with static libraries Message-ID: Hi Mario, Eureka! I had glanced through that explanation in the past, however, I missed this key piece of information: "For this reason, when A links in B as PRIVATE and another target C links in A, CMake will still add B to the list of libraries to be linked for C because parts of B are needed by A, but A itself doesn't have that dependency encoded into it. So even though B is an internal implementation detail of A, C still needs B added to the linker command, which CMake conveniently handles for you." So, indeed, CMake takes care of this by adding the 'static' library dependency to the link dependency, even if it's private. Great feature! My confusion comes from reading the documentation. For target_link_libraries, it simply states: "Libraries and targets following PRIVATE are linked to, but are not made part of the link interface." Perhaps it should add another sentence "except when the library is a static library". And perhaps would also clarify how this "exception" indeed only applies to the link interface but nothing else (include path or compile flags), as stated in Craig Scott's explanation. Thanks a lot for the clarification! -- Luis On Thu, Jun 1, 2017 at 12:53 PM, Mario Werner wrote: > Hi Luis, > > as you correctly concluded, if 'Foo' is not part of the public interface > of 'Bar', then the PRIVATE is the correct specifier. > > However, you don't have to add 'Foo' to the consumers of 'Bar' (e.g., > 'MyApp'). If everything works as expected, CMake automatically tracks > the link dependency from 'Bar' to 'Foo' and adds it to the link command > of the consuming artifact when 'Bar' is a static library. > > I did a quick experiment based on the code layout you outlined and for > me everything worked out of the box. If it does not for you, it would be > great if you can provide an actual minimal working example which shows > the issue. > > Maybe the very detailed explanation [1] provided by Craig Scott is also > interesting in this context. > > HTH, > Mario > > [1] https://cmake.org/pipermail/cmake/2016-May/063400.html > > On 2017-06-01 13:11, Luis Caro Campos wrote: > > I have the following scenario where I have 2 static libraries, where one > > uses symbols from the other, and the executable needs to link against > both > > in order to build properly. > > > > Library 'Bar' uses symbols from library 'Foo' internally, but 'Foo' is > not > > part of the "interface" of Bar, i.e., the calling library/application > only > > needs to include headers from 'Bar', and use symbols from Bar. > > > > --- > > #static libraries, assuming BUILD_SHARED_LIBS is off > > add_library(Foo) > > add_library(Bar) > > target_include_directories(Foo PRIVATE ... ) > > target_include_directories(Foo INTERFACE ...) > > target_include_directories(Bar PRIVATE ...) > > target_include_directories(Bar INTERFACE ..) > > > > # this will expose Bar to Foo's interface include directories > > target_link_libraries(Bar PUBLIC|PRIVATE Foo) > > > > > > add_executable(MyApp) > > target_link_libraries(MyApp PRIVATE Bar) > > > > --- > > > > In order to for the executable "MyApp" to build successfully, which uses > > static library Bar, "Foo" also needs be in the link statement otherwise > > I'll get missing symbols. If 'Bar' doesn't include this information in > the > > target link interface, I'll have to explicitly link against "Foo" for > MyApp. > > > > My question is, in this case, which is the correct keyword for use when > > calling "target_link_libraries" between Bar and Foo? > > > > Technically, 'Foo' is not part of Bar's public interface, so it would be > > PRIVATE. However, this would force me to have to expressly link against > Foo > > in MyApp. > > The other alternative is PUBLIC, as that would take care of the > dependency. > > I think strictly speaking, it is an "interface link dependency", but not > an > > "interface" dependency. I know that there are LINK_PUBLIC and > LINK_PRIVATE > > keywords for target_link_libraries, however the documentation says they > are > > for compatibility only and the other ones should be favoured. > > > > So in this scenario, I guess "PUBLIC" would be the best case, as that > takes > > care of the linking of MyApp. > > > > Question (1): does this not have the downside of adding Foo's interface > > include directories to MyApp's include path? > > > > The second scenario would be if Foo was static and Bar was shared. In > that > > case, it would be crystal clear, the target_link_libraries call between > Foo > > and Bar should use the PRIVATE keyword. > > However, what about if BUILD_SHARED_LIBS was set to on? > > Both would be shared libraries, but MyApp doesn't need to link against > > "Foo" anymore, however it is needed at runtime. > > > > Question (2): toggling the BUILD_SHARED_LIBS flag then seems to require > > altering the semantics of calls to target_link_libraries? What about the > > "needed at runtime" but "no part of the interface case? > > > > My conclusion is that I should perhaps explicitly declare those libraries > > as static (foo and bar), and use the "PUBLIC" keyword when linking them. > > Although I see two downsides: > > 1) Foo's interface include path is added to MyApp's include path (and it > is > > not needed) > > 2) Bar is now dependant on "Foo", so Foo needs to be built before. > However, > > from a compiler point of view, the binaries of Foo are not needed to > > produce bar. > > > > Any help would be appreciated, in case there are better ways to express > > these dependencies that I'm ignoring. > > > > > > > > Thanks, > > Luis > > > > > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From theldoria at hotmail.com Fri Jun 2 01:57:13 2017 From: theldoria at hotmail.com (Frank Roland) Date: Fri, 2 Jun 2017 05:57:13 +0000 Subject: [CMake] Emacs cmake-mode indentation flaw Message-ID: There is probably a faulty indentation implemented in cmake-mode for emacs regarding closing parens. If you have the following source code: foo( bar ) I indents the closing parenwould expect it to be indented like this: foo( bar ) I would expect the single closing paren to be not indendet. Can anybody confirm that this is an issue worth reporting? I could also create a pull request for a fix if there is interest in doing so. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juliog at Knights.ucf.edu Fri Jun 2 02:21:03 2017 From: juliog at Knights.ucf.edu (Julio Gutierrez) Date: Fri, 2 Jun 2017 06:21:03 +0000 Subject: [CMake] A simple website to get started on new CMake projects Message-ID: Hello all, I've used CMake for a few years now in almost all of my projects. It's a great tool and it makes my life easy. However, every time I start a new project, I just can't remember CMake's syntax and all of the commands. I usually spend a lot of time rereading the CMake docs or referencing my old CMake scripts. So I decided to make an open-source website that will help developers get started on a new CMake-based project just a tiny bit faster. It's available here (requires JavaScript and a modern browser): https://jgcoded.github.io/CMakeStarter/ Instead of writing your CMake code from scratch, you instead fill out a few forms on this website. Once you've filled out everything to your liking, you can then download the skeleton files as a ZIP file. The website does have a few shortcomings, and the generated CMake files are in my own personal opinion of what I think is right. The way I've used CMake might be different from how others use it, so that's where I think I can get some help from the CMake community. if you think something isn't right or if something is missing, then please submit a new issue on project's issue page, found here: https://github.com/jgcoded/CMakeStarter/issues. Or even better, send a pull request! Regards, Julio -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjklaim at gmail.com Fri Jun 2 09:17:16 2017 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Fri, 2 Jun 2017 15:17:16 +0200 Subject: [CMake] A simple website to get started on new CMake projects In-Reply-To: References: Message-ID: Well it's interesting but clearly you are providing help in only one kind of organisation. For example: - if you are doing a library that have public and private headers, it helps A LOT to have the public headers in an "include" directory - you don;t support this option; - you do not support header-only libraries; - for the dependencies, you don't take into account potential other way dependencies can be setup (by necessity) like if you use a dependency manager that works with cmake, like conan. Hope that helps. Jo?l On 2 June 2017 at 08:21, Julio Gutierrez wrote: > Hello all, > > > > I?ve used CMake for a few years now in almost all of my projects. It?s a > great tool and it makes my life easy. However, every time I start a new > project, I just can?t remember CMake?s syntax and all of the commands. I > usually spend a lot of time rereading the CMake docs or referencing my old > CMake scripts. So I decided to make an open-source website that will help > developers get started on a new CMake-based project just a tiny bit faster. > > > > It?s available here (requires JavaScript and a modern browser): > https://jgcoded.github.io/CMakeStarter/ > > > > Instead of writing your CMake code from scratch, you instead fill out a > few forms on this website. Once you?ve filled out everything to your > liking, you can then download the skeleton files as a ZIP file. > > > > The website does have a few shortcomings, and the generated CMake files > are in my own personal opinion of what I think is right. The way I?ve used > CMake might be different from how others use it, so that?s where I think I > can get some help from the CMake community. if you think something isn?t > right or if something is missing, then please submit a new issue on > project?s issue page, found here: https://github.com/jgcoded/ > CMakeStarter/issues. Or even better, send a pull request! > > > > Regards, > > > > Julio > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From burlen.loring at gmail.com Fri Jun 2 14:53:45 2017 From: burlen.loring at gmail.com (Burlen Loring) Date: Fri, 2 Jun 2017 11:53:45 -0700 Subject: [CMake] No FortranCInterface mangling known for VerifyFortran -- OSX Sierra Message-ID: After upgrading to latest XCode and command line tools on OSX Sierra our project that uses CMake to mix C++ and Fortran fails to configure. Full output below. Any ideas? here are version cmake version 3.7.1 GNU Fortran (Homebrew GCC 7.1.0) 7.1.0 Apple LLVM version 8.1.0 (clang-802.0.42) and full cmake output -- Detecting Fortran/C Interface -- Detecting Fortran/C Interface - Failed to compile -- Verifying Fortran/C Compiler Compatibility CMake Warning (dev) at /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface.cmake:309 (message): No FortranCInterface mangling known for VerifyFortran Call Stack (most recent call first): /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface/Verify/CMakeLists.txt:16 (FortranCInterface_HEADER) This warning is for project developers. Use -Wno-dev to suppress it. -- Verifying Fortran/C Compiler Compatibility - Failed CMake Error at /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface.cmake:382 (message): The Fortran compiler: /usr/local/bin/gfortran and the C compiler: /usr/bin/clang failed to compile a simple test project using both languages. The output was: Change Dir: /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC Run Build Command:"/usr/bin/make" /usr/local/Cellar/cmake/3.7.1/bin/cmake -H/usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface/Verify -B/Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC --check-build-system CMakeFiles/Makefile.cmake 0 /usr/local/Cellar/cmake/3.7.1/bin/cmake -E cmake_progress_start /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC/CMakeFiles /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC/CMakeFiles/progress.marks /Library/Developer/CommandLineTools/usr/bin/make -f CMakeFiles/Makefile2 all /Library/Developer/CommandLineTools/usr/bin/make -f CMakeFiles/VerifyFortran.dir/build.make CMakeFiles/VerifyFortran.dir/depend cd /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC && /usr/local/Cellar/cmake/3.7.1/bin/cmake -E cmake_depends "Unix Makefiles" /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface/Verify /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface/Verify /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC/CMakeFiles/VerifyFortran.dir/DependInfo.cmake Scanning dependencies of target VerifyFortran /Library/Developer/CommandLineTools/usr/bin/make -f CMakeFiles/VerifyFortran.dir/build.make CMakeFiles/VerifyFortran.dir/requires make[2]: Nothing to be done for `CMakeFiles/VerifyFortran.dir/requires'. /Library/Developer/CommandLineTools/usr/bin/make -f CMakeFiles/VerifyFortran.dir/build.make CMakeFiles/VerifyFortran.dir/build [ 20%] Building Fortran object CMakeFiles/VerifyFortran.dir/VerifyFortran.f.o /usr/local/bin/gfortran -I/Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC -Wall -Wextra -Wno-conversion -O3 -DNDEBUG -O3 -c /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface/Verify/VerifyFortran.f -o CMakeFiles/VerifyFortran.dir/VerifyFortran.f.o [ 40%] Linking Fortran static library libVerifyFortran.a /usr/local/Cellar/cmake/3.7.1/bin/cmake -P CMakeFiles/VerifyFortran.dir/cmake_clean_target.cmake /usr/local/Cellar/cmake/3.7.1/bin/cmake -E cmake_link_script CMakeFiles/VerifyFortran.dir/link.txt --verbose=1 /usr/bin/ar qc libVerifyFortran.a CMakeFiles/VerifyFortran.dir/VerifyFortran.f.o /usr/bin/ranlib libVerifyFortran.a [ 40%] Built target VerifyFortran /Library/Developer/CommandLineTools/usr/bin/make -f CMakeFiles/VerifyFortranC.dir/build.make CMakeFiles/VerifyFortranC.dir/depend cd /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC && /usr/local/Cellar/cmake/3.7.1/bin/cmake -E cmake_depends "Unix Makefiles" /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface/Verify /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface/Verify /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC/CMakeFiles/VerifyFortranC.dir/DependInfo.cmake Scanning dependencies of target VerifyFortranC /Library/Developer/CommandLineTools/usr/bin/make -f CMakeFiles/VerifyFortranC.dir/build.make CMakeFiles/VerifyFortranC.dir/build [ 60%] Building C object CMakeFiles/VerifyFortranC.dir/main.c.o /usr/bin/clang -I/Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC -O3 -DNDEBUG -o CMakeFiles/VerifyFortranC.dir/main.c.o -c /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface/Verify/main.c [ 80%] Building C object CMakeFiles/VerifyFortranC.dir/VerifyC.c.o /usr/bin/clang -I/Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC -O3 -DNDEBUG -o CMakeFiles/VerifyFortranC.dir/VerifyC.c.o -c /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface/Verify/VerifyC.c [100%] Linking C executable VerifyFortranC /usr/local/Cellar/cmake/3.7.1/bin/cmake -E cmake_link_script CMakeFiles/VerifyFortranC.dir/link.txt --verbose=1 /usr/bin/clang -O3 -DNDEBUG -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/VerifyFortranC.dir/main.c.o CMakeFiles/VerifyFortranC.dir/VerifyC.c.o -o VerifyFortranC -L/usr/local/Cellar/gcc/7.1.0/lib/gcc/7/gcc/x86_64-apple-darwin16.5.0/7.1.0 -L/usr/local/Cellar/gcc/7.1.0/lib/gcc/7 libVerifyFortran.a -lgfortran -lquadmath -lm Undefined symbols for architecture x86_64: "_VerifyFortran", referenced from: _main in main.c.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [VerifyFortranC] Error 1 make[1]: *** [CMakeFiles/VerifyFortranC.dir/all] Error 2 make: *** [all] Error 2 Call Stack (most recent call first): alg/CMakeLists.txt:74 (FortranCInterface_VERIFY) -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Fri Jun 2 15:02:17 2017 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Fri, 2 Jun 2017 15:02:17 -0400 Subject: [CMake] Emacs cmake-mode indentation flaw In-Reply-To: References: Message-ID: Hi Frank, It's really a matter of personal style. There's a multitude of different ways that people format multi-line function calls so no one way is right or wrong. For instance: foo( bar1 bar2) foo( bar1 bar2 ) foo( bar1 bar2 ) foo(bar1 bar2) foo(bar1 bar2 ) foo(bar1 bar2 ) All of which have their justifications. ---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc. On Fri, Jun 2, 2017 at 1:57 AM, Frank Roland wrote: > There is probably a faulty indentation implemented in cmake-mode for emacs > regarding closing parens. > > If you have the following source code: > > foo( > bar > ) > > > I indents the closing parenwould expect it to be indented like this: > > foo( > bar > ) > > > I would expect the single closing paren to be not indendet. > > > Can anybody confirm that this is an issue worth reporting? > > > I could also create a pull request for a fix if there is interest in doing > so. > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From burlen.loring at gmail.com Fri Jun 2 17:20:21 2017 From: burlen.loring at gmail.com (Burlen Loring) Date: Fri, 2 Jun 2017 14:20:21 -0700 Subject: [CMake] No FortranCInterface mangling known for VerifyFortran -- OSX Sierra In-Reply-To: References: Message-ID: <5dee887c-3ff4-bde5-97de-d90d11ae6137@gmail.com> upgrading from cmake 3.7.1 to cmake version 3.8.2 resolved the issue. On 06/02/2017 11:53 AM, Burlen Loring wrote: > After upgrading to latest XCode and command line tools on OSX Sierra > our project that uses CMake to mix C++ and Fortran fails to configure. > Full output below. Any ideas? > > here are version > > cmake version 3.7.1 > GNU Fortran (Homebrew GCC 7.1.0) 7.1.0 > Apple LLVM version 8.1.0 (clang-802.0.42) > > and full cmake output > > -- Detecting Fortran/C Interface > -- Detecting Fortran/C Interface - Failed to compile > -- Verifying Fortran/C Compiler Compatibility > CMake Warning (dev) at > /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface.cmake:309 > (message): > No FortranCInterface mangling known for VerifyFortran > Call Stack (most recent call first): > /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface/Verify/CMakeLists.txt:16 > (FortranCInterface_HEADER) > This warning is for project developers. Use -Wno-dev to suppress it. > > -- Verifying Fortran/C Compiler Compatibility - Failed > CMake Error at > /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface.cmake:382 > (message): > The Fortran compiler: > > /usr/local/bin/gfortran > > and the C compiler: > > /usr/bin/clang > > failed to compile a simple test project using both languages. > The output > was: > > Change Dir: > /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC > > Run Build Command:"/usr/bin/make" > /usr/local/Cellar/cmake/3.7.1/bin/cmake > -H/usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface/Verify > -B/Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC > --check-build-system CMakeFiles/Makefile.cmake 0 > /usr/local/Cellar/cmake/3.7.1/bin/cmake -E > cmake_progress_start > /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC/CMakeFiles > /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC/CMakeFiles/progress.marks > /Library/Developer/CommandLineTools/usr/bin/make -f > CMakeFiles/Makefile2 all > /Library/Developer/CommandLineTools/usr/bin/make -f > CMakeFiles/VerifyFortran.dir/build.make > CMakeFiles/VerifyFortran.dir/depend > cd > /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC && > /usr/local/Cellar/cmake/3.7.1/bin/cmake -E cmake_depends "Unix > Makefiles" > /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface/Verify > /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface/Verify > /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC > /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC > /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC/CMakeFiles/VerifyFortran.dir/DependInfo.cmake > Scanning dependencies of target VerifyFortran > /Library/Developer/CommandLineTools/usr/bin/make -f > CMakeFiles/VerifyFortran.dir/build.make > CMakeFiles/VerifyFortran.dir/requires > make[2]: Nothing to be done for > `CMakeFiles/VerifyFortran.dir/requires'. > /Library/Developer/CommandLineTools/usr/bin/make -f > CMakeFiles/VerifyFortran.dir/build.make > CMakeFiles/VerifyFortran.dir/build > [ 20%] Building Fortran object > CMakeFiles/VerifyFortran.dir/VerifyFortran.f.o > /usr/local/bin/gfortran > -I/Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC > -Wall -Wextra -Wno-conversion -O3 -DNDEBUG -O3 -c > /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface/Verify/VerifyFortran.f > -o CMakeFiles/VerifyFortran.dir/VerifyFortran.f.o > [ 40%] Linking Fortran static library libVerifyFortran.a > /usr/local/Cellar/cmake/3.7.1/bin/cmake -P > CMakeFiles/VerifyFortran.dir/cmake_clean_target.cmake > /usr/local/Cellar/cmake/3.7.1/bin/cmake -E cmake_link_script > CMakeFiles/VerifyFortran.dir/link.txt --verbose=1 > /usr/bin/ar qc libVerifyFortran.a > CMakeFiles/VerifyFortran.dir/VerifyFortran.f.o > /usr/bin/ranlib libVerifyFortran.a > [ 40%] Built target VerifyFortran > /Library/Developer/CommandLineTools/usr/bin/make -f > CMakeFiles/VerifyFortranC.dir/build.make > CMakeFiles/VerifyFortranC.dir/depend > cd > /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC && > /usr/local/Cellar/cmake/3.7.1/bin/cmake -E cmake_depends "Unix > Makefiles" > /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface/Verify > /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface/Verify > /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC > /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC > /Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC/CMakeFiles/VerifyFortranC.dir/DependInfo.cmake > Scanning dependencies of target VerifyFortranC > /Library/Developer/CommandLineTools/usr/bin/make -f > CMakeFiles/VerifyFortranC.dir/build.make > CMakeFiles/VerifyFortranC.dir/build > [ 60%] Building C object CMakeFiles/VerifyFortranC.dir/main.c.o > /usr/bin/clang > -I/Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC > -O3 -DNDEBUG -o CMakeFiles/VerifyFortranC.dir/main.c.o -c > /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface/Verify/main.c > [ 80%] Building C object CMakeFiles/VerifyFortranC.dir/VerifyC.c.o > /usr/bin/clang > -I/Users/bloring/TECA/build/CMakeFiles/FortranCInterface/VerifyC > -O3 -DNDEBUG -o CMakeFiles/VerifyFortranC.dir/VerifyC.c.o -c > /usr/local/Cellar/cmake/3.7.1/share/cmake/Modules/FortranCInterface/Verify/VerifyC.c > [100%] Linking C executable VerifyFortranC > /usr/local/Cellar/cmake/3.7.1/bin/cmake -E cmake_link_script > CMakeFiles/VerifyFortranC.dir/link.txt --verbose=1 > /usr/bin/clang -O3 -DNDEBUG -Wl,-search_paths_first > -Wl,-headerpad_max_install_names > CMakeFiles/VerifyFortranC.dir/main.c.o > CMakeFiles/VerifyFortranC.dir/VerifyC.c.o -o VerifyFortranC > -L/usr/local/Cellar/gcc/7.1.0/lib/gcc/7/gcc/x86_64-apple-darwin16.5.0/7.1.0 > -L/usr/local/Cellar/gcc/7.1.0/lib/gcc/7 libVerifyFortran.a > -lgfortran -lquadmath -lm > Undefined symbols for architecture x86_64: > "_VerifyFortran", referenced from: > _main in main.c.o > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v > to see invocation) > make[2]: *** [VerifyFortranC] Error 1 > make[1]: *** [CMakeFiles/VerifyFortranC.dir/all] Error 2 > make: *** [all] Error 2 > > Call Stack (most recent call first): > alg/CMakeLists.txt:74 (FortranCInterface_VERIFY) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcosatti at gmail.com Fri Jun 2 23:03:13 2017 From: marcosatti at gmail.com (Marco Satti) Date: Sat, 3 Jun 2017 11:03:13 +0800 Subject: [CMake] Provide default compiler/link flags in cache before project command. Message-ID: <004c01d2dc15$f30bb3a0$d9231ae0$@gmail.com> Hi, I am trying to let the user pick their own compiler/linker flags through the cache, whilst providing sane defaults. The problem is, I rely on the CMAKE_CXX_COMPILER_ID variable to set these defaults which is only available after the project() command is used. This also causes the CMAKE_CXX_FLAGS_{target} and CMAKE_EXE_LINKER_FLAGS_{target} to be populated in the cache by CMake, with defaults that do not work. Trying to set these flags after the project() command doesn't work unless the FORCE flag is used. but then the user wouldn't be able to override them. The workaround I used involved introducing a set of "USER_*" variables that are available in the cache (populated initially with the sane defaults), which then overrides the CMAKE_* variables above with the FORCE flag. It works, but I kind of think there should be a better way, especially since people who have used CMake before might try to set -DCMAKE_* using the command line or other wise and find it doesn't work. Example from my CMakeLists.txt (working). I use INTERNAL instead of FORCE here so the user does not see this in the cmake-gui: project(myproject CXX) if(${CMAKE_CXX_COMPILER_ID} STREQUAL GNU) set(USER_CXX_FLAGS_DEBUG "-g -std=c++14" CACHE STRING "CMake CXX compiler flags (Debug)." ) set(USER_EXE_LINKER_FLAGS_DEBUG "" CACHE STRING "CMake CXX linker flags (Debug)." ) elseif(${CMAKE_CXX_COMPILER_ID} STREQUAL MSVC) set(USER_CXX_FLAGS_DEBUG "/MTd /Zi /Ob0 /Od /RTC1 /MP /std=c++14" CACHE STRING "CMake CXX compiler flags (Debug)." ) set(USER_EXE_LINKER_FLAGS_DEBUG "/machine:x64 /DEBUG" CACHE STRING "CMake CXX linker flags (Debug)." ) endif() . some lines below . set(CMAKE_CXX_FLAGS_DEBUG "${USER_CXX_FLAGS_DEBUG}" CACHE INTERNAL "") set(CMAKE_EXE_LINKER_FLAGS_DEBUG "${USER_EXE_LINKER_FLAGS_DEBUG}" CACHE INTERNAL "") Ideally, I would like to be able to do something like this (doesn't work): project(myproject CXX) if(${CMAKE_CXX_COMPILER_ID} STREQUAL GNU) set(CMAKE_CXX_FLAGS_DEBUG "-g -std=c++14" CACHE STRING "CMake CXX compiler flags (Debug)." ) set(CMAKE_EXE_LINKER_FLAGS_DEBUG "" CACHE STRING "CMake CXX linker flags (Debug)." ) elseif(${CMAKE_CXX_COMPILER_ID} STREQUAL MSVC) set(CMAKE_CXX_FLAGS_DEBUG "/MTd /Zi /Ob0 /Od /RTC1 /MP /std=c++14" CACHE STRING "CMake CXX compiler flags (Debug)." ) set(CMAKE_EXE_LINKER_FLAGS_DEBUG "/machine:x64 /DEBUG" CACHE STRING "CMake CXX linker flags (Debug)." ) endif() Thanks for your time! Marco. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mapron at yandex.ru Fri Jun 2 23:30:42 2017 From: mapron at yandex.ru (mapron) Date: Sat, 3 Jun 2017 10:30:42 +0700 Subject: [CMake] Object files list in project after 3.7 upgrade Message-ID: <300c63a8-2ce8-0619-5100-db1b2a877c4a@yandex.ru> Hello, I have noticed after upgrading to Cmake 3.7 (3.8.2 problem still exists): when using object libraries, generated object files now persist in project tree (just after configuration). You can see Qt Creator screenshot at https://bugreports.qt.io/browse/QTCREATORBUG-18308 Actually, when using generator CodeBlocks + Ninja, .cbp files are different, e.g: for 3.6, and