Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries
On 2019-12-29 12:15+1100 Craig Scott wrote: This one has sat in my inbox for a long time - sorry I'm only getting to it now! No problem, and big thanks for replying late rather than taking the easier course of replying never. I haven't yet absorbed all of what you said, but I am sure your answers will be a big help to my project to modernize the CMake-base build system for PLplot which was originally "designed" in 2006 by a team of CMake newbies (including me). 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.org); 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 kitware.com/cmake Kitware offers various services to support the CMake community. For more information on each offering, please visit https://cmake.org/services Visit other Kitware open-source projects at https://www.kitware.com/platforms Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake This mailing list is deprecated in favor of https://discourse.cmake.org
Re: [cmake-developers] These two generator expressions should be equivalent, but one working while the other not working. Bug?
On 2019-10-24 12:41-0700 Alan W. Irwin wrote: [ W]ould you entertain a feature request to remove that hard-coded language limitation on the above 4 classes of genex so both internally and externally supported languages would work for all of them? Well, since you did not respond I assume you are at least not horrified by that idea so I have written this up as <https://gitlab.kitware.com/cmake/cmake/issues/19893> and further discussion should appear there. 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.org); 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
Re: [cmake-developers] These two generator expressions should be equivalent, but one working while the other not working. Bug?
On 2019-10-24 08:08-0400 Brad King wrote: On 10/24/19 12:18 AM, Alan W. Irwin wrote: $ Expression did not evaluate to a known generator expression The `*_COMPILER_ID` generator expressions are a hard-coded set corresponding to the languages supported by upstream CMake: * C_COMPILER_ID * CXX_COMPILER_ID * CUDA_COMPILER_ID * Fortran_COMPILER_ID * OBJC_COMPILER_ID (new in 3.16) * OBJCXX_COMPILER_ID (new in 3.16) This is because the language name is part of the expression name. In the `$` case, the language name is one of the parameters. Thanks for that clear explanation of this current CMake hard-coded limitation. To work around it, I will stick with the $ genex, but only bother with that -pthread mapping for cmake 3.15.0 and above (since that is the first version of CMake to support $). So that takes care of PLplot's needs. However, on the general question of the above CMake hard-coded language limitation I searched through <https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html> for "CXX" and found these genex's $<"language"_COMPILER_ID:compiler_ids> $<"language"_COMPILER_VERSION:version> $<"language"_COMPILER_ID> $<"language"_COMPILER_VERSION> where I have substituted "language" for CXX to indicate these actually represent 4 different classes of genex's where "language" is currently on a hard-coded list for the first, and it appears from Source/cmGeneratorExpressionNode.cxx that is true of the rest as well. My C++ skills are limited and as a result I don't understand the CMake code that well, and I don't have any idea how difficult this would be to implement. So I should ask would you entertain a feature request to remove that hard-coded language limitation on the above 4 classes of genex so both internally and externally supported languages would work for all of them? For example, you currently have $<"language"_COMPILER_ID:compiler_ids> where compiler_ids is a comma-separated list. 1 if the CMake’s compiler id of the "language" compiler matches any one of the entries in compiler_ids, otherwise 0. See also the CMAKE__COMPILER_ID variable where "language" is restricted to the above hard-coded list. Would it be straightforward to change the implementation of this whole class of genexes so that "language" was simply determined from the first part of the genex name with that "language" then checked against the available language support? If so, that approach would solve the above issue (i.e., drop this artificial distinction between languages with internal and external support) and also have the additional advantages that it would replace what I presume are currently 6 different genex implementations and the documentation of each of those with just one implementation and corresponding piece of documentation with no introduced backwards incompatibilities due to this change. And similarly for $<"language"_COMPILER_VERSION:version> $<"language"_COMPILER_ID> $<"language"_COMPILER_VERSION> 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.org); 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
[cmake-developers] These two generator expressions should be equivalent, but one working while the other not working. Bug?
Hi Brad: The two generator expressions $<$:-pthread> and $<$,$>:-pthread> are supposed to be equivalent according to the cmake-generator-expressions manual. Up to now I have always used the first form when setting the INTERFACE_LINK_OPTIONS property of an interface library which my D examples link with. All my tests of that form for both the test_d and plplot cases work fine. So I was about to declare that my D language support (a fork of the cmake-d project which I hope to merge back with that project) was perfect for our needs (at least on Linux) until I ran into a problem with the above second generator expression which I will now describe. Some old versions (e.g., 3.13.2) of CMake that PLplot still needs to support do not implement the $ generator expression so after the first form passed all tests, I tried switching to the second generator expression for the plplot case. However, that generated errors at CMake time which are typically (for each of our D examples) CMake Error at examples/d/CMakeLists.txt:119 (target_link_libraries): Error evaluating generator expression: $ Expression did not evaluate to a known generator expression [...] -- Generating done CMake Generate step failed. Build files cannot be regenerated correctly. These errors were obtained with cmake version 3.15.20190829-g3ec986c (the version I have recently been using for testing). This is a really peculiar result since both forms provide the same information (language and compiler id) and are supposed to be equivalent, i.e., both forms should either work or not work. And the second form works for the Fortran case (where I am having to deal with a similar -pthread issue). So my guess is there is some internal implementation issue with the second form that makes it not quite equivalent to the first form, and some minor issue with my D language support (that otherwise works perfectly for PLplot needs on Linux) has exposed this implementation difference. If you confirm that guess, then ideally the CMake implementation should be changed so the second form is equivalent to the first form in all circumstances. And I would be happy to test that change with my present CMake D language support. I also need the second form of generator expression to work with older unfixed CMake versions so once you spot the implementation difference between the two forms I would also appreciate a hint about how to change my CMake D language support so the present CMake code does not generate the above type of errors for the second form of the generator expression. In case you need details about my present CMake D language support, those can be found at either cmake/test_d/cmake/Modules or cmake/modules/language_support/cmake-d_fork/ within the plplot source tree. That source tree can be cloned using git clone https://git.code.sf.net/p/plplot/plplot plplot.git 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.org); 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
Re: [CMake] error executing script with cmake -P
On 2019-10-14 12:00+0100 Edoardo Pasca wrote:
Dear all,
I am using external project. I would like to patch a source file. I came
out with a cmake script that does the string replacement I'm interested in.
I tested in a standalone project, with the following CMakeLists.txt
cmake_minimum_required(VERSION 3.4)
project(patching_string)
file (STRINGS TestData.py testdata NEWLINE_CONSUME)
string(REPLACE "sys.prefix" "os.environ[\'SIRF_INSTALL_PATH\']" patched
${testdata})
file( WRITE ${CMAKE_CURRENT_SOURCE_DIR}/TestData.py ${patched} )
and as a matter of facts this does the string replacement I'm interested in.
Good, now I would like to use this to the project I'm really interested in
which uses the ExternalProject_Add machinery. I added the patch step:
file (WRITE ${CMAKE_BINARY_DIR}/patch_script.cmake "
file (STRINGS
${${proj}_SOURCE_DIR}/Wrappers/Python/ccpi/framework/TestData.py testdata
NEWLINE_CONSUME)
string(REPLACE \"sys.prefix\" \"os.environ[\\\'SIRF_INSTALL_PATH\\\']\"
patched \${testdata})
file( WRITE
${${proj}_SOURCE_DIR}/Wrappers/Python/ccpi/framework/TestData.py
\${patched} ) ")
ExternalProject_Add(
...
PATCH_COMMAND ${CMAKE_COMMAND} -P ${CMAKE_BINARY_DIR}/patch_script.cmake
... )
Notice that I write the patch_script.cmake before the ExternalProject_Add
Now, all of this WORKS. Or at least I get the patch_script.cmake file in
the proper directoty, with the content I want. However, execution with
cmake -P patch_script.cmake doesn't work as expected.
I get
CMake Error at build/patch_script.cmake:3 (string):
string sub-command REPLACE requires at least four arguments.
Given that the patch_script.cmake has the same content of the standalone
CMakeLists.txt above (without the first 2 lines), I don't know where things
don't go well, except that I execute the script with cmake -P
cmake version 3.15.2
Thanks for any help.
Hi Edo:
This help likely belongs to the "any" category. :-) That is, it is just a
informed suggestion
that might help you but nothing definite.
It sounds to me from the research you reported above that you have an
absolutely clear case where
standalone cmake operating on CMake logic contained in a file (with
cmake_minimum_required(VERSION 3.4)
project(patching_string)
prepended so standalone CMake works fine, but cmake -P operating on *that same
file* does
not work. I suggest you prepare a test tarball containing a file which contains
the CMake logic executed by cmake -P (i.e., all but the first two lines of the
above
CMakeLists.txt file),
and the original TestData.py file that logic is supposed to work on. That
simple test
case should help others here (likely not me) replicate the issue you have found
and
explain why it occurs for cmake -P but not for the standalone cmake case (with
the two
lines prepended, separate build tree, etc., so standalone works).
N.B. Also note that even before that difference is confirmed and
explained, you have the option of either fixing the logic in the cmake
-P case (where the cmake options --debug-output and --trace-expand
might help you figure out exactly what the problem is) or else
adopting the current (prepended) logic for the standalone case and
executing that (rather clumsy, of course) standalone method in your
super-project.
Good luck, and I hope this overview of how I would deal with the
issue you have described is a help to you.
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.org); 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
Re: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)
On 2019-10-13 17:15-0400 Paul Smith wrote: A unity source file can lump together N real source files from the same target (library/executable) as long as those files don't have extra source-specific flags, because all other files in a given target have the same flags. I agree that it is not at all clear whether this is the cause of the issue. So I will stop speculating about that cause even though that is a fun activity. :-) Nevertheless, it does sound like your complex test case does expose some issue with EITHER how you have implemented the build system for your complex case OR how CMake currently rejects certain builds from being included in Unity builds. So to figure out which it is, I think your next step should be to attempt to implement the simplest possible self-contained test case that illustrates the Unity exclusion issue you have found. I believe that course has already been suggested in this thread so I am seconding that motion. My own experiences with such implementations is I often cannot demonstrate the issue in a simple way, i.e., the "CMake bug" often tends to be due to an issue with my implementation of the build system for the complex case. However, when I have demonstrated with such a simple test case there really is a CMake bug, that test case normally helps CMake developers in a big way to find and fix the issue. 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.org); 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
Re: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)
On 2019-10-12 15:40-0400 Paul Smith wrote: On Fri, 2019-10-11 at 10:17 -0400, Kyle Edwards wrote: On Fri, Oct 11, 2019 at 1:36 AM Alan W. Irwin < alan.w.irwin1...@gmail.com wrote: The source files that have COMPILE_OPTIONS, COMPILE_DEFINITIONS, COMPILE_FLAGS, or INCLUDE_DIRECTORIES will also be skipped." This is by far the most likely reason. We added this restriction because we don't want files that have different COMPILE_FLAGS etc. to be lumped together in a unity file. We decided that this was good enough as a first past, but the way forward is to intelligently group together files that have the same COMPILE_OPTIONS, COMPILE_DEFINITIONS, COMPILE_FLAGS, and INCLUDE_DIRECTORIES. I saw this in the manual, and I interpreted it to mean that if we used something like set_source_files_properties() or set_property(SOURCE) to set these properties on specific source files, then those files which are impacted by this won't be part of unity builds. That seems quite sensible to me. However, I don't do that hardly anywhere at all; maybe one or two files have an extra INCLUDE_DIRECTORIES setting or similar. Virtually all my properties are set on a per-target basis, so I assumed they wouldn't be an issue here. Am I misunderstanding that? I think the current documentation is ambiguous about this. But certain target and directory properties can affect the flags used to compile the source code just as much as source code properties. So I am virtually positive the implementation has to pay attention to all these sources of properties to decide what can/cannot be lumped into a Unity source file. If Kyle confirms this guess, then the documentation should be changed accordingly to remove the ambiguity about this. 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.org); 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
Re: [CMake] Unity builds (was: Re: [ANNOUNCE] CMake 3.16.0-rc1 is ready for testing)
On 2019-10-10 18:21-0400 Paul Smith wrote: On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote: * The "UNITY_BUILD" target property was added to tell generators to batch include source files for faster compilation times. Are there any instructions on how to make this work? I tried this: cmake -G 'Unix Makefiles' -DCMAKE_UNITY_BUILD=ON . Then ran "make". The output showed I had just as many output .o files as input .cpp files and that make ran one compile command per .cpp file. Is there something else I need to do to enable unity builds in my cmake files, than just give the above option? The docs imply that the above is all that's needed. Hi Paul: I have never tried unity builds, but your question did inspire me to look at [the unity build documentation](https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html) which if you follow the links to other related documentation does imply what you have done above is correct and should by default group 8 source-code files into a lump to be compiled together. Since you are not getting that behaviour, I am wondering if one or more of the documented reasons for skipping unity builds is making a difference in your case. Those reasons are the following: "The source files marked by GENERATED will be skipped from unity build. This applies also for the source files marked with SKIP_UNITY_BUILD_INCLUSION. The source files that have COMPILE_OPTIONS, COMPILE_DEFINITIONS, COMPILE_FLAGS, or INCLUDE_DIRECTORIES will also be skipped." Good luck, and I hope you will keep the list informed of any further progress you make with your unity build experiments. 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.org); 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
Re: [cmake-developers] FindThreads module documentation needs some work
I have [opened an issue on the bugtracker](https://gitlab.kitware.com/cmake/cmake/issues/19823) concerning this documentation bug. 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.org); 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
[cmake-developers] FindThreads module documentation needs some work
In my opinion [the latest documentation of the FindThreads module](https://cmake.org/cmake/help/latest/module/FindThreads.html) needs some work. Specifically please deal with the following documentation issues. * Threads_FOUND needs documentation. And that needs to be done at the top of the documentation as typically happens with other modules where a _FOUND variable is being set on a successful find. * CMAKE_HAVE_THREADS_LIBRARY needs documentation. I suspect the value of this variable (set in the module but otherwise not used there) has been historically useful for those module users who have figured out its purpose, but it would be good to have that purpose documented. * The CMAKE_THREAD_LIBS_INIT variable and corresponding Threads::Threads INTERFACE_LINK_LIBRARIES target property is the empty string for the case when the (Posix) threads functions are provided by the C library. According to a second-hand report I received this case happens on Mac OS X (at least for MacPorts). Therefore, please document this expected result for that important use case. * Finally, for that same important use case THREADS_PREFER_PTHREAD_FLAG is completely ignored, and that should be documented as well. Because of these documentation issues, learning to use this module properly on both Linux and Mac OS X for PLplot and another project I have been working on has been much more work than I expected (i.e., instead of relying on documentation I had to analyze the CMake code in this module to figure out what was going on). I would be willing to repeat all the above in a bug report, but instead of doing that I hope someone here is willing to step forward with fixups for the above simple documentation issues in a timely manner so there is no bug triage burden for these fixups. 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.org); 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
Re: [cmake-developers] Possible feature request concerning conditional linking support by generator expressions
On 2019-09-24 14:02-0700 Alan W. Irwin wrote: [...] I. Possible feature request After reading through the generator-expression documentation at <https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html> it appears for my use case (see below) I need generator expressions of the form $<$>:-pthread> $<$:-pthread> $<$:-Xcc-pthread> $<$:libbasename> (where libbasename is likely pthread) To follow up, I have just been informed on one of the dmd mailing lists that the dmd developers have implemented an option in a pre-release version of dmd 2.088.0 that will change the semantics of -L so that dmd with that option (-preview=noXlinker) will interpret -L-pthread as a request to pass that -pthread option on to the C compiler used internally by dmd for linking. So when I implement this fixed -preview=noXlinker option in PLplot's fork of the cmake-d dmd D language support it appears the above dmd example of my possible feature request above would change to $<$:-L-pthread> And similarly I would use -L-pthread for dmd in my proposed workaround for the lack of such generator-expressions right now. In sum, some substantial uncertainty about how to handle the -pthread option for the dmd case is now gone, but the question still persists about whether I will always have to use the proposed messy workaround (which requires building an extra variant of the PLplot library) or whether I can look forward to someone implementing the above generator expressions which would provide a neat solution to the -pthread linking issue I have described. 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.org); 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
[cmake-developers] Possible feature request concerning conditional linking support by generator expressions
n since apparently on some platforms the -pthread
compiler option for linking is essential according to the gcc
documentation and lots of web pages that parrot that information.
But since using a library rather than -pthread is working for me on
my platform, I don't know whether that general consensus is really
true anymore or just a remnant of bad threading solutions to be
avoided in the past. Therefore, if others here have good or bad
experience with NOT setting the THREADS_PREFER_PTHREAD_FLAG I would
like to hear about it since this is an easy solution to implement if
it is actually known to be reliable on all platforms/compilers that
understand the -pthread linking option for compilers.
* Always use some other linking language than D for linking the D examples
As an experiment I was able to set the LINKER_LANGUAGE
x${STRING_INDEX}d target property to C, and that did force using gcc
(which understands the -pthread compiler option for linking) for
linking the D examples. But that lead to another issue which is I
had to specify which libphobos was to be used with each different D
compiler, and they are all different! So this option is possible,
but quite messy with regard to finding the correct libphobos for
each different D compiler on every platform!
* Use generator expressions like above. This should work perfectly I
think, but does require agreement on your part this change should be
made to CMake, and that very likely depends on how complicated that
implementation would be.
* What I tentatively plan to do now as a workaround for the issue
For the combination of static libraries, D enabled, D compiler one
of ldc2 or dmd, and Threads::Threads INTERFACE_LINK_LIBRARIES set to
-pthread, make an additional version of the PLplot library called
PLPLOT::plplot_nothread. This library would be absolutely identical
to PLPLOT::plplot except that Threads::Threads would be removed from
its INTERFACE_LINK_LIBRARIES property. (I am assuming here that the
INTERFACE_LINK_LIBRARIES only affects what happens at generation
time so it is impossible to "temporarily" remove Threads::Threads
from the INTERFACE_LINK_LIBRARIES for PLPLOT:plplot just for linking
the D examples which is why a second library needs to be built for
this situation).
Then if that target exists use PLPLOT::plplot_nothread and an extra
link option consisting of either -Xcc-pthread for the ldc2 case or
basename for the dmd case where needed to build the D binding
library PLPLOT::plplotdmd and the D examples.
In sum, I think I have found a way to work around the -pthread D issue
for my use case although I haven't yet implemented or tested that
workaround. However, it is obvious that making a build of a second
version of the core plplot C library is not an ideal solution so I
would far prefer to use conditional linking that depended on generator
expressions. However, that requires work by you guys which you might
not prefer to do if this turns out to be the only use case ever that
requires such conditional linking. :-)
Again, sorry for the length of this, but I look forward to replies
from those who have had the patience to read through this about the
feasibility and general usefulness of implementing the possible
feature request or additional discussion or suggestions concerning the
other proposed solutions above to the -pthread D issue for my use
case.
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.org); 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
Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries
Hi Craig: It appears you pretty much made the definitive statement about target_link_libraries (TLL) options at <https://cmake.org/pipermail/cmake/2016-May/063400.html>. However, I have some further questions about this key section of your statement: "[...] when A links in B as PRIVATE, the include directories of B never propagate to something linking to A, but if A is a static library, then the *linking* of B behaves as though the relationship was PUBLIC. This PRIVATE-becomes-PUBLIC behaviour for static libraries only applies to the *linking*, not to the other dependencies (compiler options/flags and include search paths). The upshot of all this is that if you select PRIVATE, PUBLIC or INTERFACE based on the explanations in the dot points above, then CMake will ensure dependencies propagate through to where they are required, regardless of whether libraries are static or shared. This does, of course, rely on you the developer not missing any dependencies or specifying the wrong PRIVATE/PUBLIC/INTERFACE relationship." The issues I am concerned with are the following: * The target_include_directories, target_compile_definitions, and target_compile_options (TID, TCD, and TCO) commands all have options. I am pretty sure those options must take precedence over the TLL options, but can you confirm that? * It appears to me that if a CMake-based build system is configured properly there is very little need for the PUBLIC option for TLL because PRIVATE works well for shared libraries and the PRIVATE-becomes-PUBLIC behaviour for static libraries you mentioned above. Can you confirm this statement is generally true both for Unix and Windows? I am concerned with the above issues because the PLplot build system currently does the following: * For shared libraries uses the PRIVATE TLL option for the Unix case and PUBLIC TLL option for the Windows case. * For static libraries always uses the PUBLIC TLL option. These decisions were based on my own understanding of transitive linking needs for static Unix libraries and shared and static Windows libraries many years ago, but now it appears that understanding is out of date or else was wrong in the first place. For example, in the static Linux case there is a nasty leakage of compile and link flags between static libraries that I have just tripped over when dealing with the D ldc2 compiler which cannot understand those flags which are generated for the gcc compiler for a C library which our D library depends on. So to stop that leakage, and in light of what you said three years ago, it appears to be a no-brainer to use PRIVATE TLL for the PLplot static libraries at least in the Unix case. So assuming that for the PLplot build system I follow up and prove that PRIVATE TLL works for both the shared and static library cases on Unix, would you also recommend PLplot move to PRIVATE TLL for both the shared and static library cases on Windows? Thanks in advance for your further comments on these matters. 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.org); 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
Re: [CMake] Plan to deal with remaining D language support issues for PLplot
On 2019-08-21 19:17-0700 Alan W. Irwin wrote: Please let me know if there are any technical issues with this pull request because it has been a long time since I have made such a request to CMake developers. I have now made this pull request available on the bug tracker, see <https://gitlab.kitware.com/cmake/cmake/issues/19631>. 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.org); 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
Re: [cmake-developers] For a certain use case, CMake configures linking to the *same* library in both -L... -l... form and raw file form
I have now written [a bug report](https://gitlab.kitware.com/cmake/cmake/issues/19630) that describes this issue. 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.org); 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
Re: [CMake] Plan to deal with remaining D language support issues for PLplot
On 2019-08-21 13:37-0700 Alan W. Irwin wrote: I took a look at [another D support project that you recommended to me off list](https://github.com/trentforkert/cmake/) that project contained the following commit: Author: Ben Boeckel Date: Tue Apr 15 00:21:15 2014 -0400 [...] [My] planned next step is to rebase that commit on the upstream cmake master branch, and test that patched upstream result to see if those limited internal CMake changes allow fixing (with minor patching of cmake-d files) all remaining cmake-d issues for the PLplot use case. Indeed, all issues in (patched) cmake-d have now been solved by this commit (now rebased to the cmake upstream cmake master branch which required some conflict resolution). The results for this patched upstream cmake for all of gdc, ldc, and dmd pass our stringent tests of our D examples (where we compare SVG plot file results for our ~30 D examples with corresponding results for the equivalent C examples) for our three major PLplot configurations (shared libraries + dynamic devices, shared libraries + nondynamic devices, and static libraries + nondynamic devices). In order for PLplot users other than me to be able to take advantage of these additional internal CMake capabilities for some future release of upstream CMake, I request you pull the attached commit (which is non-intrusive and rebased from your single commit above for the trentforkert version) into the appropriate branch of upstream cmake development. Please let me know if there are any technical issues with this pull request because it has been a long time since I have made such a request to CMake developers. 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.org); 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 __ 0001-linking-Support-language-specific-link-flags.patch.gz Description: Upstream CMake pull request (in compressed git format-patch form) -- 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
[CMake] Plan to deal with remaining D language support issues for PLplot
Hi Ben: You know this already from our off-list discussion, but for other's here, the PLplot's ancient fork of the cmaked project works well for gdc, but is completely broken (doesn't even compile a test example) with dmd on my Linux (Debian Buster) platform. So I have been trying the [cmake-d](https://github.com/dcarp/cmake-d) project (suitably patched for PLplot needs) instead for our D language support. That support currently works well for gdc, and also *almost* works well for dmd (and probably ldc as well although I am concentrating on the dmd case at the moment). The remaining issues for cmake-d appear to be 1. # "D" version: set(CMAKE_LIBRARY_PATH_FLAG "-L-L") set(CMAKE_LINK_LIBRARY_FLAG "-L-l") for the dmd and also the ldc cases. This conflicts with support for our other languages on Linux which sets # "C" version set(CMAKE_LIBRARY_PATH_FLAG "-L") set(CMAKE_LINK_LIBRARY_FLAG "-l") 2. Libraries linked by full pathname cannot be linked properly by dmd and lcd (since they both need an "-L" prefix to such pathnames to pass those to the linker). I took a look at [another D support project that you recommended to me off list](https://github.com/trentforkert/cmake/) that project contained the following commit: Author: Ben Boeckel Date: Tue Apr 15 00:21:15 2014 -0400 linking: Support language-specific link flags Adds support for the following variables: * CMAKE__LINK_LIBRARY_FLAG * CMAKE__LINK_LIBRARY_FILE_FLAG * CMAKE__LINK_LIBRARY_SUFFIX * CMAKE__LINK_PATH_FLAG * CMAKE__LINK_PATH_TERMINATOR so that compilers with different flags can be used in the same build. M Help/manual/cmake-variables.7.rst A Help/variable/CMAKE_LANG_LIBRARY_PATH_FLAG.rst A Help/variable/CMAKE_LANG_LINK_LIBRARY_FILE_FLAG.rst A Help/variable/CMAKE_LANG_LINK_LIBRARY_FLAG.rst A Help/variable/CMAKE_LANG_LINK_LIBRARY_SUFFIX.rst M Source/cmComputeLinkInformation.cxx M Source/cmLocalGenerator.cxx It appears from those documentation files that this commit would help to solve both issues 1. and 2. above. Therefore, my planned next step is to rebase that commit on the upstream cmake master branch, and test that patched upstream result to see if those limited internal CMake changes allow fixing (with minor patching of cmake-d files) all remaining cmake-d issues for the PLplot use case. More later as the above plan unfolds 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.org); 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
Re: [cmake-developers] For a certain use case, CMake configures linking to the *same* library in both -L... -l... form and raw file form
On 2019-08-17 13:00-0700 Alan W. Irwin wrote:
To temporarily work around some bugs in cmake-d support for the D
language case, I modified our normal use case for PLplot linking
between our D examples and D binding. And that lead to the peculiar
result mentioned on the subject line which I have now also confirmed
for the Fortran language. (So I presume this result holds both for
externally supported languages such as D and languages officially
supported by CMake such as Fortran.)
The PLplot Fortran examples link to the PLplot Fortran binding library
whose target name is PLPLOT::plplotfortran. And PLplot uses
non-transitive linking on my (Linux, Debian Buster) platform.
So in the shared library build case, if I link the Fortran examples
using my normal method:
target_link_libraries(x${STRING_INDEX}f PLPLOT::plfortrandemolib
PLPLOT::plplotfortran)
the resulting link command for our x00f example (and similarly for all
the rest) is
[100%] Linking Fortran executable x00f
cd /home/software/plplot/HEAD/build_dir/examples/fortran &&
/home/software/cmake/install-3.13.2/bin/cmake -E cmake_link_script
CMakeFiles/x00f.dir/link.txt --verbose=1
/usr/bin/gfortran -O3 -Wuninitialized -Wunused
CMakeFiles/x00f.dir/x00f.f90.o -o x00f
-Wl,-rpath,/home/software/plplot/HEAD/build_dir/bindings/fortran
../libplfortrandemolib.a ../../bindings/fortran/libplplotfortran.so.0.2.0
make[3]: Leaving directory '/home/software/plplot/HEAD/build_dir'
[100%] Built target x00f
which is the expected result (which mentions the link to the
plplotfortran library only in raw file format). (N.B. I set the
environment variable FFLAGS="-O3 -Wuninitialized -Wunused" which
explains those special gfortran options.)
However, if I link the Fortran examples with
target_link_libraries(x${STRING_INDEX}f PLPLOT::plfortrandemolib
$)
add_dependencies(x${STRING_INDEX}f PLPLOT::plplotfortran)
the resulting link command for our x00f example (and similarly for all
the rest) is
[100%] Linking Fortran executable x00f
cd /home/software/plplot/HEAD/build_dir/examples/fortran &&
/home/software/cmake/install-3.13.2/bin/cmake -E cmake_link_script
CMakeFiles/x00f.dir/link.txt --verbose=1
/usr/bin/gfortran -O3 -Wuninitialized -Wunused
CMakeFiles/x00f.dir/x00f.f90.o -o x00f
-L/home/software/plplot/HEAD/build_dir/bindings/fortran
-Wl,-rpath,/home/software/plplot/HEAD/build_dir/bindings/fortran
../libplfortrandemolib.a -lplplotfortran
../../bindings/fortran/libplplotfortran.so.0.2.0 make[3]: Leaving directory
'/home/software/plplot/HEAD/build_dir'
[100%] Built target x00f
I expected that the result would simply link to the plplotfortran
library in "-L/home/software/plplot/HEAD/build_dir/bindings/fortran
-lplplotfortran" form so that redundant mention of the *same* library
in raw file form (../../bindings/fortran/libplplotfortran.so.0.2.0)
was a surprise to me.
Hi Ben:
Thanks for contacting me off list concerning this issue.
I have now done some more experiments and it appears the issue does
not exist unless the following specific conditions are met:
1. There must be at least two library items (i.e., the target links to
at least two libraries) mentioned in the target_link_libraries
command. For example, I was unable to replicate the issue with our C
and C++ examples (where only one library item is mentioned in the
target_link_libraries command), and similarly if I (incorrectly)
dropped plfortrandemolib from the items mentioned for the
target_link_libraries command for our Fortran examples the issue
disappeared (although that incomplete linking generated other issues,
as expected).
2. The two item libraries must be built in different ways. For
example, plfortrandemolib is normally built as a static library and
plplotfortran is built as a shared library, but the issue disappeared
if both libraries were built as shared libraries.
3. The example must link to the two item libraries in two different
ways. For example, the issue disappeared if I used
target_link_libraries(x${STRING_INDEX}f
$
$)
add_dependencies(x${STRING_INDEX}f PLPLOT::plfortrandemolib
PLPLOT::plplotfortran)
where as a result of that logic, the Fortran examples link to both
plfortrandemolib and plplotfortran using the same -L... -l... link
method.
It does appear this issue is independent of language. For example, I
can replicate it for our D examples where the above 3 conditions were
met, but that issue disappeared if, for example, I link the D examples
to both of the two item libraries using the -L... -l... link method.
I would appreciate it if you took a quick look to see if there is an
easy fix for this extremely specific issue, and if not then I would be
willing to put it on the bug tracker to reduce the chances it will get
lost.
Alan
__
Alan W. Irwin
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemeride
[cmake-developers] For a certain use case, CMake configures linking to the *same* library in both -L... -l... form and raw file form
To temporarily work around some bugs in cmake-d support for the D
language case, I modified our normal use case for PLplot linking
between our D examples and D binding. And that lead to the peculiar
result mentioned on the subject line which I have now also confirmed
for the Fortran language. (So I presume this result holds both for
externally supported languages such as D and languages officially
supported by CMake such as Fortran.)
The PLplot Fortran examples link to the PLplot Fortran binding library
whose target name is PLPLOT::plplotfortran. And PLplot uses
non-transitive linking on my (Linux, Debian Buster) platform.
So in the shared library build case, if I link the Fortran examples
using my normal method:
target_link_libraries(x${STRING_INDEX}f PLPLOT::plfortrandemolib
PLPLOT::plplotfortran)
the resulting link command for our x00f example (and similarly for all
the rest) is
[100%] Linking Fortran executable x00f
cd /home/software/plplot/HEAD/build_dir/examples/fortran &&
/home/software/cmake/install-3.13.2/bin/cmake -E cmake_link_script
CMakeFiles/x00f.dir/link.txt --verbose=1
/usr/bin/gfortran -O3 -Wuninitialized -Wunused CMakeFiles/x00f.dir/x00f.f90.o -o x00f -Wl,-rpath,/home/software/plplot/HEAD/build_dir/bindings/fortran ../libplfortrandemolib.a ../../bindings/fortran/libplplotfortran.so.0.2.0
make[3]: Leaving directory '/home/software/plplot/HEAD/build_dir'
[100%] Built target x00f
which is the expected result (which mentions the link to the
plplotfortran library only in raw file format). (N.B. I set the
environment variable FFLAGS="-O3 -Wuninitialized -Wunused" which
explains those special gfortran options.)
However, if I link the Fortran examples with
target_link_libraries(x${STRING_INDEX}f PLPLOT::plfortrandemolib
$)
add_dependencies(x${STRING_INDEX}f PLPLOT::plplotfortran)
the resulting link command for our x00f example (and similarly for all
the rest) is
[100%] Linking Fortran executable x00f
cd /home/software/plplot/HEAD/build_dir/examples/fortran &&
/home/software/cmake/install-3.13.2/bin/cmake -E cmake_link_script
CMakeFiles/x00f.dir/link.txt --verbose=1
/usr/bin/gfortran -O3 -Wuninitialized -Wunused CMakeFiles/x00f.dir/x00f.f90.o -o x00f -L/home/software/plplot/HEAD/build_dir/bindings/fortran -Wl,-rpath,/home/software/plplot/HEAD/build_dir/bindings/fortran ../libplfortrandemolib.a -lplplotfortran ../../bindings/fortran/libplplotfortran.so.0.2.0
make[3]: Leaving directory '/home/software/plplot/HEAD/build_dir'
[100%] Built target x00f
I expected that the result would simply link to the plplotfortran
library in "-L/home/software/plplot/HEAD/build_dir/bindings/fortran
-lplplotfortran" form so that redundant mention of the *same* library
in raw file form (../../bindings/fortran/libplplotfortran.so.0.2.0)
was a surprise to me.
My guess is this is actually an expected (albeit peculiar) result for
the above use case due to the existing general design of CMake
language support, but I thought I had better mention this result here
in case it is due to a bug in that support.
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.org); 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
Re: [CMake] cmake + ninja how to use several CPU cores?
On 2019-07-29 15:32-0400 Brad King wrote: [...]We don't know what `main.cpp` includes until after compiling it, by which point it is too late. It could have `#include "anything.txt"` for example. CMake must add these pessimistic dependencies to ensure a correct build. Is this the real reason why even the simplest no_custom_add_internal_library project (with nothing custom at all) still demonstrates the issue? 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.org); 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
Re: [CMake] cmake + ninja how to use several CPU cores?
On 2019-07-29 13:24-0400 Brad King wrote: On 7/29/19 11:50 AM, Dave Milter wrote: Only source code are generated, so main.cpp -> main.cpp.o doesn't depend on anything. But generated by cmake build.ninja still require link of extern_lib before starting main.cpp -> main.cpp.o If there are any custom commands in any targets on which main.cpp's target depends then CMake must pessimistically assume that the custom commands may generate a header needed to compile `main.cpp`. Hi Brad: Thanks for that clarification. Clearly David's test case for an external library and my own recently corrected test case for an internal library are not consistent with that assumption which explains the bad results we get for them. However, I think there is still a problem when a project is consistent with that assumption. See the attached no_custom_add_internal_library.tar.gz which contains an extremely simple test project with no custom commands at all (i.e., no wait and headers and source are pre-existing in all cases). Yet for this project I get the following results with ninja. irwin@merlin> ninja -j16 -v app [1/7] /usr/bin/c++ -Dinternal_lib_EXPORTS -I../lib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib4.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib4.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib4.cpp.o -c ../lib/lib4.cpp [2/7] /usr/bin/c++ -Dinternal_lib_EXPORTS -I../lib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib1.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib1.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib1.cpp.o -c ../lib/lib1.cpp [3/7] /usr/bin/c++ -Dinternal_lib_EXPORTS -I../lib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib2.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib2.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib2.cpp.o -c ../lib/lib2.cpp [4/7] /usr/bin/c++ -Dinternal_lib_EXPORTS -I../lib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib3.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib3.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib3.cpp.o -c ../lib/lib3.cpp [5/7] : && /usr/bin/c++ -fPIC-shared -Wl,-soname,libinternal_lib.so -o libinternal_lib.so CMakeFiles/internal_lib.dir/lib/lib1.cpp.o CMakeFiles/internal_lib.dir/lib/lib2.cpp.o CMakeFiles/internal_lib.dir/lib/lib3.cpp.o CMakeFiles/internal_lib.dir/lib/lib4.cpp.o && : [6/7] /usr/bin/c++ -I../lib -MD -MT CMakeFiles/app.dir/main.cpp.o -MF CMakeFiles/app.dir/main.cpp.o.d -o CMakeFiles/app.dir/main.cpp.o -c ../main.cpp [7/7] : && /usr/bin/c++ CMakeFiles/app.dir/main.cpp.o -o app -Wl,-rpath,/home/irwin/David.Milter/20190728/test_ninja/no_gen_add_internal_library/build_dir libinternal_lib.so && : irwin@merlin> grep cmake_object_order_depends_target_app build.ninja build cmake_object_order_depends_target_app: phony || cmake_object_order_depends_target_internal_lib build CMakeFiles/app.dir/main.cpp.o: CXX_COMPILER__app ../main.cpp || cmake_object_order_depends_target_app 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.org); 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
Re: [CMake] cmake + ninja how to use several CPU cores?
On 2019-07-29 18:50+0300 Dave Milter wrote: On Mon, Jul 29, 2019 at 1:48 PM Bruce Stephens wrote: I think it's reasonable for CMake/Ninja to require the headers be generated, especially since main.cpp does include one of them (though CMake/Ninja doesn't know that until later). lib/lib1.cpp is more arguable, but I imagine there's no real distinction made: main.cpp.o depends on all the dependencies of the libraries. In my initial example headers files are not generated in cmake scripts. Only source code are generated, so main.cpp -> main.cpp.o doesn't depend on anything. But generated by cmake build.ninja still require link of extern_lib before starting main.cpp -> main.cpp.o Thanks, Bruce, for spotting that issue with the first version of my simple example which I oversimplified. I have now corrected it (see attached tarball) to follow the use case of pre-existing headers and an app that links to a library (internal for my corrected test case, and external for David's test case). The issue (compilation of main.cpp is unreasonably delayed for parallel builds until after the library (internal or external) is built) still shows up in my corrected test case for both -G"Ninja" and -G"Unix Makefiles" just like happens for David's test case for an external library. So the question remains why does CMake constrain parallel builds this way (to the point that it is a bottlneck for David's real project with external libraries) for this general use case? 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.org); 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 __ corrected_add_internal_library.tar.gz Description: tarball containing corrected test case of app with pre-existing headers and internal library -- 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
Re: [CMake] cmake + ninja how to use several CPU cores?
On 2019-07-28 23:39-0700 Alan W. Irwin wrote: @Both: I also plan to look at whether this issue exists for the internal library case so more later when I get that corresponding simple test project implemented. @Brad and David: I have now implemented a simple test project for the internal library case. See the attached tarball (and please let me know if your input mail software chain allows you to receive that tarball). In general I think this test case improves somewhat on Dave's test project by making the sleep more explicit at the CMake level, generating the headers explicitly rather than including them in the tarball, generating all header and source code files and the library (internal in this case) within the build tree rather than source tree (which considerably simplifies making a clean start), and by allowing the user to specify the -DBUILD_SHARED_LIBS=ON (or OFF) cmake option to choose whether the library is built shared on static. (Of course, none of these improvements should affect the delayed compilation issue.) For this new simple test project, here are the results for the -G"Ninja" case (when -DBUILD_SHARED_LIBS=ON is specified): irwin@merlin> ninja -j16 -v app [1/10] cd /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir/lib && sh /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/lib/include_generator.sh [2/10] cd /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir/lib && sh /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/lib/lib_generator.sh [3/10] cd /home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir && sleep 5 [4/10] /usr/bin/c++ -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib1.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib1.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib1.cpp.o -c lib/lib1.cpp [5/10] /usr/bin/c++ -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib3.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib3.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib3.cpp.o -c lib/lib3.cpp [6/10] /usr/bin/c++ -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib4.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib4.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib4.cpp.o -c lib/lib4.cpp [7/10] /usr/bin/c++ -Dinternal_lib_EXPORTS -Ilib -fPIC -MD -MT CMakeFiles/internal_lib.dir/lib/lib2.cpp.o -MF CMakeFiles/internal_lib.dir/lib/lib2.cpp.o.d -o CMakeFiles/internal_lib.dir/lib/lib2.cpp.o -c lib/lib2.cpp [8/10] : && /usr/bin/c++ -fPIC-shared -Wl,-soname,libinternal_lib.so -o libinternal_lib.so CMakeFiles/internal_lib.dir/lib/lib1.cpp.o CMakeFiles/internal_lib.dir/lib/lib2.cpp.o CMakeFiles/internal_lib.dir/lib/lib3.cpp.o CMakeFiles/internal_lib.dir/lib/lib4.cpp.o && : [9/10] /usr/bin/c++ -Ilib -MD -MT CMakeFiles/app.dir/main.cpp.o -MF CMakeFiles/app.dir/main.cpp.o.d -o CMakeFiles/app.dir/main.cpp.o -c ../main.cpp [10/10] : && /usr/bin/c++ CMakeFiles/app.dir/main.cpp.o -o app -Wl,-rpath,/home/irwin/David.Milter/20190728/test_ninja/add_internal_library/build_dir libinternal_lib.so && : Note that the build of main.cpp.o is (unreasonably in my opinion) delayed to step 9. And that build is similarly delayed in the -G"Unix Makefiles" case. That is this newly implemented test case for the internal library build shows exactly the same unexplained compilation delays for main.cpp for both -G"Ninja" and -G"Unix Makefiles" as David's test case for the external library build. @Brad and other CMake developers who might be lurking here: Can anybody explain why CMake has this delayed compilation "feature" for apps that depend on internal or external libraries, and if there is no compelling reason for it would it be straightforward to remove it? 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.org); 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 __ add_internal_library.tar.gz Description: tarball for newly implemented simple test case for internal library + app -- 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 Kitw
Re: [CMake] cmake + ninja how to use several CPU cores?
Hi to Dave and Brad: @Dave: As you are probably already aware Brad is one of the primary CMake developers so I think he should be in on this discussion. @Brad: Using Dave's simple test project I confirmed the compilation delay issue below in detail for both the -G"Ninja" case AND the -G"Unix Makefiles" case on Debian Buster. Would you please take a look at this simple test case to see if you can find the explanation for this issue? After years of ignoring CMake + Ninja because of the Fortran issues for that combination, I have just realized you have a fork of Ninja (not yet merged upstream) which apparently works well with CMake for the Fortran case. So I am in the process of trying that Ninja fork out for all components of PLplot (including our Fortran binding and examples), and I plan to report to you those results in a separate thread. Which explains my renewed interest in Ninja (in this case not your fork since no Fortran is involved) for this current thread. @Both: I also plan to look at whether this issue exists for the internal library case so more later when I get that corresponding simple test project implemented. More details below concerning the external library case On 2019-07-29 03:36+0300 Dave Milter wrote: Hi, On Mon, Jul 29, 2019 at 12:01 AM Alan W. Irwin wrote: On 2019-07-28 19:03+0300 Dave Milter wrote: To help answer your question, I see no fundamental issues with your code above. If the latter is really true, that appears to me to be a CMake bug (although I cannot make the final judgement call on that since I am an experienced CMake user rather than a CMake developer). And if so, does that same problem (unnecessary delay in compilation rather than linking) occur for the following simplified case? In fact my code in previous email is demo code. It already contains "sleep" inside lib_generator.sh to emulate real project. @Dave: Great minds think alike concerning clearly demonstrating this issue with the help of the sleep command. :-) I am just not sure is this good idea to send attachment into this mailing list. Actually, for obvious reasons of convenience, gzipped tarball attachments should never be an issue on mailing lists (like the CMake ones) which are relevant to discussion of software. (There are typically mailing-list limits with regard to size, but they are normally quite generous so I have never run into this issue on the CMake mailing lists. Therefore, as expected, your attachment got through to me without issues. Also, I double-checked your description of that attachment which is critical for the input mail chains of some users. In your case that description (which you can configure with your mail software) was "application/GZIP" which is obviously fine for my input mail chain case and presumably most others on this list who want to look at that attachment. @Brad: have you had any trouble seeing that attachment without your input mail chain stripping it out? See attachment, it is possible only to build on Linux/Mac, because of usage bash/gcc for lib_geneator.sh And I am pretty sure that problem in cmake (or my usage of cmake), because of build.ninja generated by cmake contains such rules: ``` build cmake_object_order_depends_target_app: phony || extern_lib_target build CMakeFiles/app.dir/main.cpp.o: CXX_COMPILER__app ../main.cpp || cmake_object_order_depends_target_app ``` "||" is "order-only dependencies" according to https://ninja-build.org/manual.html#_syntax_example . So cmake instruct ninja do not build main.cpp.o untill extern_lib_target build. @Dave: Thanks very much for that simple test project. @Both: I configured and built it using the Debian Buster = Stable system versions of cmake (version 3.13.4) and ninja (version 1.8.2) using the following commands I. The -G"Ninja" case # Fresh start: # IMPORTANT: first cd to the top-level directory of the source tree. Then # Get rid of the previously generated external library (if any) to # insure the 5 second pause associated with that generation always # occurs. rm -f extern_lib/libextern.so # Start with an empty build tree rm -rf build_dir mkdir build_dir cd build_dir # Configure time cmake -G"Ninja" .. >& cmake.out ==> real0m1.084s user0m0.845s sys 0m0.232s # Just to be specific (although ninja normally figures this out for itself for parallel builds) # build with -j16 since I have 16-thread hardware. Also use -v option to create (slightly more) # verbose output. time ninja -j16 -v all ==> [1/3] cd /home/irwin/David.Milter/20190728/test_ninja/add_library_imported/extern_lib && sh ./lib_generator.sh Generating... Generating...DONE [2/3] /usr/bin/c++ -isystem ../extern_lib/gen -MD -MT CMakeFiles/app.dir/main.cpp.o -MF CMakeFiles/app.dir/main.cpp.o.d -o CMakeFiles/app.dir/main.cpp.o -c ../main.cpp [3/3] : && /usr/bin/c++ CMakeFi
Re: [CMake] cmake + ninja how to use several CPU cores?
On 2019-07-28 19:03+0300 Dave Milter wrote:
Hi,
I heard that ninja has great feature it allows build continue without
wainting full link.
So if you have library Lib and executable App,
source code of App may build in parallel with source code of Lib,
and sync only link stage. While other build systems force build of Lib,
and only then start build of any object files of App.
But is it possible to use this feature with cmake?
Here my cmake code to emulate bottleneck of our build:
```
cmake_minimum_required(VERSION 3.12 FATAL_ERROR)
project(imported)
set(EXTERN_LIB_FILE ${CMAKE_CURRENT_SOURCE_DIR}/extern_lib/libextern.so)
set(EXTERN_LIB_INCLUDES ${CMAKE_CURRENT_SOURCE_DIR}/extern_lib/gen)
add_custom_command(OUTPUT ${EXTERN_LIB_FILE}
COMMAND sh ./lib_generator.sh
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/extern_lib)
add_custom_target(extern_lib_target DEPENDS ${EXTERN_LIB_FILE})
add_library(extern_lib SHARED IMPORTED GLOBAL)
add_dependencies(extern_lib extern_lib_target)
set_target_properties(extern_lib
PROPERTIES
IMPORTED_LOCATION ${EXTERN_LIB_FILE}
INTERFACE_INCLUDE_DIRECTORIES ${EXTERN_LIB_INCLUDES})
add_executable(app main.cpp)
target_link_libraries(app extern_lib)
```
we use not C/C++ library as part of our source tree,
and it builds some time,
so I expect that ninja can run "main.cpp" -> main.o compilation during
"extern_lib" build,
but this is not happens.
Is cmake has problem with add_custom_command and ninja,
or the whole idea is wrong, and cmake + ninja can not work in this way,
and I should use some other project generator instead of cmake for this?
Hi Dave:
To help answer your question, I see no fundamental issues with your code above.
The
add_dependencies(extern_lib extern_lib_target)
command in your above code means that the external project that is
created by building the extern_lib_target target must be *entirely*
completed before the extern_lib target
is built. Furthermore, the
target_link_libraries(app extern_lib)
command means extern_lib must be built before the app is linked which, of
course, is a complete necessity.
However, I don't see anything in your CMake code that demands that the
compilation of main.cpp must be delayed until extern_lib is built. So
can you double-check that the bottleneck is not actually the
(necessary until external_lib is built) delay of linking of app rather
than some unneccessary delay in the compilation of main.cpp?
If the latter is really true, that appears to me to be a CMake bug
(although I cannot make the final judgement call on that since I am an
experienced CMake user rather than a CMake developer). And if so, does that
same problem (unnecessary delay in compilation rather than linking)
occur for the following simplified case?
cmake_minimum_required(VERSION 3.12 FATAL_ERROR)
project(test_internal_library)
# Delay 10 seconds so that it is obvious if main.cpp compilation is
# being unnecessarily delayed.
# You should introduce boolean CMake logic here to
# use the equivalent (see
#
<https://stackoverflow.com/questions/1672338/how-to-sleep-for-five-seconds-in-a-batch-file-cmd>)
# "timeout 10" command for the Windows case.
add_custom_target(delay
COMMAND sleep 10
)
add_library(intern_lib SHARED ${)
# Add a 10 second delay until intern_lib is built
add_dependency(intern_lib delay)
add_executable(app main.cpp)
target_link_libraries(app intern_lib)
Also, please organize both test cases as tarballs containing simple
examples (including a simplified lib_generator.sh for the first case,
a 10 second delay inserted in that case as well, and simplified source
code for library (e.g., containing one function to return the "hello,
world" string and a simplified app (a main routine to print out that
string) for both cases). Such self-contained test projects make it
much more convenient for others to confirm the issue you have
discovered on the platforms they have access to. For example, if you
supply such self-contained test cases, I would be happy to run both
test cases here on my Linux platform for both ninja and make. (I have
had a lot of success with parallel builds for the make case on Linux
which is why I would like to also test make just in case it turns out
you have found a ninja-only CMake bug.)
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.org); 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
Re: [CMake] cmake on MinGW64; which generator
On 2019-06-24 07:39-0600 Christopher Webster wrote: Thank you Benjamin, that [install and use mingw-w64-x86_64-cmake in the mingw64 shell] fixed it. I was happy to hear that Benjamin solved this first issue for you. Just to follow up on what he said, I confirm the good PLplot results for the MSYS2 platform that I referred to in my previous post also used the "mingw-w64-x86_64-cmake" native package rather than the non-native (linked to msys2.dll) "cmake" package. You (and others reading this thread) should consult the patches at <https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-cmake> to see the various ways that the "mingw-w64-x86_64-cmake" package differs from vanilla cmake for Windows from Kitware. I agree with another poster's comments that if indeed some or all of those fixes are really necessary for the MSYS2 platform that ideally they should be adopted by the upstream CMake developers. So I hope those developers are (i) reading this thread and (ii) willing to follow up by looking at those patches. 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.org); 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
Re: [CMake] cmake on MinGW64; which generator
On 2019-06-23 07:49-0600 Christopher Webster wrote: Greetings, I am trying to figure out which generator to use on MinGW64 on Windows10, the 2-3 I have tried fail. cmake version is 3.14.5 If I try "Unix Makefiles" I get: $ cmake -S coin -B coin_build -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=C:\Tools\Packages\Coin3D -- The C compiler identification is GNU 9.1.0 -- The CXX compiler identification is GNU 9.1.0 System is unknown to cmake, create: Platform/MINGW64_NT-10.0-17763 to use this system, please send your config file to cm...@www.cmake.org so it can be added to cmake If I try "MinGW Makefiles" I get: $ cmake -S coin -B coin_build -G "MinGW Makefiles" -DCMAKE_INSTALL_PREFIX=C:\Tools\Packages\Coin3D CMake Error: Could not create named generator MinGW Makefiles There are a lot of different platforms that use the MinGW-w64 compiler so you should probably describe the platform where you are attempting to use that compiler in more detail. For example, it sounds like you are simply taking a normal Window platform and downloading the MinGW-w64 compiler for that platform, but what is the exact URL for that download? I don't have any recent direct experience myself (I have no access to Microsoft Windows and Wine Windows bugs are currently blocking access to MSYS2), but PLplot developers I am aquainted with have recently had a lot of success with the [MSYS2 platform](https://github.com/msys2/msys2/wiki) which is another exaple of a platform that uses the MinGW-w64 compiler. For that platform they have found that "Unix Makefiles" and "MSYS Makefiles" generally give good results. They haven't yet tried "MinGW Makefiles" but from my ancient (MSYS/Wine where MSYS is the predecessor of MSYS2) experience for that generator you have to be sure that sh.exe is not on your PATH (e.g., by renaming it) before it will work. (I have never quite been sure why that was a requirement, but my guess was the "mingw" make version acts differently if it detects sh.exe.) But again from my ancient experience the rest of the Unix tools provided by MSYS2 including bash.exe will likely work well with the "MinGW Makefiles" generator. I hope this (ancient direct and recent indirect) practical experience with "Unix Makefiles", "MSYS Makefiles", "MinGW Makefiles", and MinGW-w64 will be of some help to you. 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.org); 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
[cmake-developers] target_link_libraries links mathlib as -lm rather than /libm.so, why?
On Linux (Debian Testing) with CMake 3.13.2 (which I built myself) I have a case where apparently target_link_libraries( /usr/lib/x86_64-linux-gnu/libm.so) results in an actual link option "-lm". Is this an exception to the rule documented at <https://cmake.org/cmake/help/v3.13/policy/CMP0060.html#policy:CMP0060> that if the full path is specified to target_link_libraries (as above) that full path is used for the actual linking? If so, I am curious about why this "CMake -lm exception" occurs and are there other instances of such exceptions? And shouldn't at least the fact that there are still some exceptions be documented as part of the CMP0060 documentation? Note I discovered the above issue from a fairly short chain of inference for the libLASi CMake-based build system, but if necessary, I would be willing to attempt making a simple case demonstrating this issue if it turns out that nobody here can verify it. By the way, my use case is that some day I would likely to have the option of building libLASi as static with *all* external libraries static as well. Of course, for that use case I could not use a generic linking flag such as -lm which is why I am wondering why "-lm" is being used for the actual link option above. 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.org); 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
Re: [cmake-developers] Is email notification of a failed CMake dashboard possible?
On 2019-05-26 11:07+1000 Craig Scott wrote: Notifications for builds are controlled through CDash. You can adjust your CDash notifications to suit your preferences. Go to CDash, click on "My CDash". You should see a list of "My Projects" and "Public Projects". Subscribe to a project and it will appear under your "My Projects" area if it isn't there already. For each subscribed project, you should see an icon next to it under the Actions column which allows you to edit your subscription and from there you can control what you receive email notifications for. I'm not sure if there is a way to limit your notifications to just certain sites though. You may need to ask on the CDash mailing list for help with that. Hi Craig: Thanks for trying to help me, but I can find no mention of "My CDash" at either <https://open.cdash.org/viewProjects.php> or <https://open.cdash.org/index.php?project=CMake>. So can you be more specific about what URL I need to consult to control my notification preferences at **? Alan On Sun, May 26, 2019 at 7:54 AM Alan W. Irwin wrote: With a lot of initial configuration help from Brad King, I have been automatically submitting a Nightly dashboard for CMake (including the PLplot contract test) for some time now (see the "merlin" results at <https://open.cdash.org/index.php?project=CMake> and <https://open.cdash.org/index.php?project=KWSys>). On extremely rare occasions there is a failure in either of my CMake or KWSYS dashboards. Is it possible for me to set up e-mail notification of such failures (and successes at first to make sure notification works), and if so, how? 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.org); 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 -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-cmake/> __ 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.org); 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
[cmake-developers] Is email notification of a failed CMake dashboard possible?
With a lot of initial configuration help from Brad King, I have been automatically submitting a Nightly dashboard for CMake (including the PLplot contract test) for some time now (see the "merlin" results at <https://open.cdash.org/index.php?project=CMake> and <https://open.cdash.org/index.php?project=KWSys>). On extremely rare occasions there is a failure in either of my CMake or KWSYS dashboards. Is it possible for me to set up e-mail notification of such failures (and successes at first to make sure notification works), and if so, how? 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.org); 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
Re: [CMake] Manually-specified variables were not used by the project
On 2019-05-24 19:38+0200 Haio Maio wrote: Manually-specified variables were not used by the project MY_VAR when I call cmake -DMY_VAR= ... The goal is if(NOT DEFINED MY_VAR) ... else() ... if() in order to tell cmake over the command line what to do. How to achieve this ? This functionality just works for me (using cmake version 3.13.4). For example, here is a simple test case: irwin@merlin> cat /tmp/CMakeLists.txt if(NOT DEFINED MY_VAR) message(STATUS "MY_VAR is not DEFINED") else() message(STATUS "MY_VAR is DEFINED") endif() irwin@merlin> cmake -P /tmp/CMakeLists.txt -- MY_VAR is not DEFINED irwin@merlin> cmake -DMY_VAR=OFF -P /tmp/CMakeLists.txt -- MY_VAR is DEFINED irwin@merlin> cmake -DMY_VAR=ON -P /tmp/CMakeLists.txt -- MY_VAR is DEFINED So just like the documentation says at <https://cmake.org/cmake/help/latest/command/if.html> what is tested is whether *any* true or false value has been set. What is more problematic is how to make sure the variable is not set with the -D option, and the only way I know how to do that is the first test above (i.e., do not use -DMY_VAR=??? at all). I hope this simple example helps you to figure out what is going on with your more complex example. 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.org); 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
Re: [CMake] Forcing finding FreeGLUT instead of the system GLUT on MacOS
On 2019-05-02 15:10+0200 ardi wrote: Hi, I built and installed FreeGLUT in a custom location in my home directory (Note: it's a custom location, but I also have pkg-config installed on my PATH, and I did set it up so that when I do 'pkg-config --list-all' it successfully detects FreeGLUT in the location where I installed it). Now I'm trying to build a project that has find_package(GLUT REQUIRED) and, as I would expect, it detects the system GLUT that comes standard with MacOS. But for this particular build, I want it to find FreeGLUT instead of the system GLUT. How can I force finding FreeGLUT? Thanks a lot in advance, Hi ardi: In your cmake installation take a look at $PREFIX/share/cmake-3.14/Modules/FindGLUT.cmake where you will find no mention of PkgConfig, i.e., CMake does not use pkg-config to find GLUT. Instead, it uses native CMake find methods which are documented at e.g., <https://cmake.org/cmake/help/latest/command/find_path.html>. And if you look into that documentation you can find a number of environment variables that control which GLUT installation location is found such as CMAKE_PREFIX_PATH. Hope that helps. 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 __ -- 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
Re: [CMake] Install without building unittests
On 2019-03-28 02:24- Scott Bloom wrote: Note, Im running from inside visual studio... I do realize for a makefile based system, I can run make install from inside the executable's build directory From: CMake On Behalf Of Scott Bloom Sent: Wednesday, March 27, 2019 7:23 PM To: cmake@cmake.org Subject: [CMake] Install without building unittests I asked this a couple of years ago, and the answer was "no"... If you run tests, it doesn't automatically build tests... So why does an install? I would never release something into the wild with out running the tests... But, for developer builds, were we need to install all the packages in order to run the applications, sometimes I just want to test the GUI which requires an install of the core application into the correct location, without building the 1500+ (yes 1500) unittests, which can take 15-20 minutes to build on their own... Is there anyway to break the dependency?? The "install" target depends on the "all" target, and the "all" target depends on everything built with "add_executable". And I and presumably many other users of CMake would not be happy if the CMake developers decided to change these fundamental characteristics of CMake. However, I think you can straightforwardly achieve exactly what you want to do as follows: option(BUILD_UNIT_TESTS "Build unit tests?" OFF) if(BUILD_UNIT_TESTS) loop over add_executable for your various unit tests endif(BUILD_UNIT_TESTS) Of course, it is not as simple as that, and likely your builds of unit tests are scattered all over your build system, but the point is to protect all use of "add_executable" for those tests with an if block as above. Then you specify -DBUILD_UNIT_TESTS=ON cmake option if you actually do want to build your unit tests, but otherwise the default is not to build them (just like you apparently want). We have used a similar option over the years with the CMake-based build system for PLplot (in our case whether to build our standard examples in the build tree so we can test there in addition to our normal build and test of those examples in the installed examples tree). That method has worked well for us, and I think it would work well for your needs also. 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 __ -- 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
Re: [CMake] PIE-pie_off and CMP0083-cmp0083_new fail for openSuse Leap 15.0
On 2019-03-20 00:01+0100 Christoph Grüninger wrote: Dear CMake, while trying to update the RPMs for openSuse with the Open Build service, I stumbled upon a strange problem. Following the same spec file for all target plattforms, CMake is first built and then the tests are executed. The tests pass for different types of openSuse versions (Factory, Tumbleweed, Leap 42.3, SLE 12 SP3) but fail for a single version, openSuse Leap 15.0. I attached the output of the failing tests. The failure is related to CMP0083 and PIE. But I cannot spot any difference causing different test results. Could someone advice how to track down the reason for my issue? Hi Christoph: Just in case the trouble is simply due to a real CMake bug for some old version of CMake, what exact versions of CMake are you testing on each of your various "good" platforms compared to your "bad" platform, openSuse Leap 15.0? 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 __ -- 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
Re: [cmake-developers] different behavior of cmake_minimum_required(3.0) and 3.1
On 2019-03-15 23:10+0100 Rolf Eike Beer wrote:
Out of boredom I'm hacking a bit around in the build system of Subsurface
(https://github.com/Subsurface-divelog/subsurface). One of the things I'm
looking to is requiring a newer CMake version. And now something strange
happens:
The original code:
cmake_minimum_required(VERSION 2.8.11)
This still works:
cmake_minimum_required(VERSION 3.0)
like this:
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
-- Checking for module 'libxml-2.0'
-- Found libxml-2.0, version 2.9.4
-- Checking for module 'sqlite3'
-- Found sqlite3, version 3.20.1
-- Checking for module 'libxslt'
-- Found libxslt, version 1.1.29
-- Checking for module 'libzip'
-- Found libzip, version 1.1.3
And this breaks:
cmake_minimum_required(VERSION 3.1)
like this:
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
-- Checking for module 'libxml-2.0'
-- Found libxml-2.0, version 2.9.1
-- Checking for module 'sqlite3'
-- Found sqlite3, version 3.8.2
-- Checking for module 'libxslt'
-- Found libxslt, version 1.1.28
-- Checking for module 'libzip'
-- No package 'libzip' found
I suspected it was a policy thing, so I tried this:
foreach(_p RANGE 21 54)
cmake_policy(SET CMP00${_p} OLD)
endforeach()
Does not change anything.
Build logs can be found here for 3.0:
https://api.travis-ci.org/v3/job/506938155/log.txt
And for 3.1:
https://api.travis-ci.org/v3/job/506849909/log.txt
It's a CMake 3.8.2 actually, which can be found in the mxe tarballs (look in
the logs, IIRC it's the first one).
Has anyone an idea what's happening there? And even more important: how to get
it fixed? The maximum version the requirement can be raised to is 3.5.1 for
the moment because of the supported Ubuntu versions (16.04+).
Hi Eike:
Since you appear to be running 3.8.2 in both cases, then the default
policy change difference between cmake_minimum_required(VERSION 3.0)
and cmake_minimum_required(VERSION 3.1) should be the only difference
between the two results. So you appear to be left with (i)
cmake_minimum_required is not implemented as documented (i.e., there
is more going on then just a policy change for CMake 3.8.2), (ii)
there is some typo in how you changed policies for
cmake_minimum_required(VERSION 3.1) to be effectively the same as the
default policies for cmake_minimum_required(VERSION 3.0), or (iii)
there is absolutely no explanation for what you have found. :-)
However, if it were me I would simply forget about getting to the
bottom of this mystery for cmake_minimum_required(VERSION 3.1) since
that is a really an old set of policies. Instead, I suggest you move
on to the more modern set of policies associated with
cmake_minimum_required(VERSION 3.5.1) to see whether you have the same
trouble in that case for a range of CMake versions (including 3.8.2,
just in case there is a specific bug in that version) from 3.5.1 to
the latest version.
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
__
--
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
Re: [CMake] Automatically updating Doxygen documentation and making it readily available to users with CMake
On 2019-02-20 17:52-0500 Timothy Wrona wrote: I have worked on multiple C++ libraries that are built with CMake and run Doxygen to generate HTML documentation. In every one of these libraries, the documentation get's built into an "html" folder in the CMake "build" directory and never gets looked at by anyone. *Because let's be honest, most people don't like to read documentation at all - let alone search for it.* This leads to a few questions: 1. Is there a standard location to put the documentation once it is built where it makes it very clear to the users of a library that documentation is available for a library? 2. How can I ensure that every time my library is built, the documentation will be *automatically *updated and placed in this standard location? 3. Is there any standard way to keep past versions of documentation for reference in case someone is using an earlier version of the library? I have also posted this question on stack overflow. If you would like, you can answer there instead because it may help a wider audience: https://stackoverflow.com/questions/54796513/automatically-updating-doxygen-documentation-and-making-it-readily-available-to I am not aware of any standard responses to your 3 questions above. What I do for a couple of my projects that have doxygen-generated documentation is I have a special custom command/target that copies the doxygen-generated documentation from the build tree back to a special directory in the source tree, and I only invoke that target if I am creating a source tarball. And similarly for DocBook-generated documentation. Furthermore, I configure my VCS in each case to ignore those generated directories in the source tree so there are no VCS complications, yet tarball users get a chance to access the generated documentation. Of course, if someone here has a better or more standardized scheme, I would like to hear it. 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 __ -- 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
Re: [cmake-developers] How does CMake know when to use the rpath option in the build tree with a combination of static internal and shared external libraries?
On 2019-02-08 15:19-0800 Alan W. Irwin wrote: So all is well with that C example, but I would like to know *how* CMake knew (for the build tree case) that the rpath option was needed. Having thought some more about this, I now assume the CMake build-tree algorithm is if the library is specified with a full path, and that location is non-standard use rpath/runpath (regardless of whether the the library referred to sets rpath/runpath or not). And I have also confirmed from several different web sources that the internal property rpath is transitive while the internal propery runpath is non-transitive. So I assume for linkers (such as the one for Debian Testing) that transform external -rpath options to runpath internally, it is no longer possible to be quite so sloppy, i.e., it is best to specify the rpath option following the normal transitive (e.g., for static internal libraries) and non-transitive (e.g., for shared external libraries) rules that are used for linking. But could someone here please confirm (or correct) these assumptions? Once I have the requested confirmation of my assumptions (or else a set of corrected assumptions) from someone here, then I think it should be straightforward for me to deal with the peculiar static OCaml case where I have discovered that internal runpath (for Debian Testing) versus internal rpath (for Debian Jessie) appears to make a crucial difference. 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 __ -- 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
[cmake-developers] How does CMake know when to use the rpath option in the build tree with a combination of static internal and shared external libraries?
1.0.so.0] 0x0001 (NEEDED) Shared library: [libgobject-2.0.so.0] 0x0001 (NEEDED) Shared library: [libglib-2.0.so.0] 0x0001 (NEEDED) Shared library: [libfontconfig.so.1] 0x0001 (NEEDED) Shared library: [libfreetype.so.6] 0x0001 (NEEDED) Shared library: [libm.so.6] 0x0001 (NEEDED) Shared library: [libshp.so.2] 0x0001 (NEEDED) Shared library: [libqhull.so.7] 0x0001 (NEEDED) Shared library: [libstdc++.so.6] 0x0001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0001 (NEEDED) Shared library: [libc.so.6] 0x0001 (NEEDED) Shared library: [libQt5Core.so.5] 0x0001 (NEEDED) Shared library: [libQt5Gui.so.5] 0x0001 (NEEDED) Shared library: [libQt5PrintSupport.so.5] 0x0001 (NEEDED) Shared library: [libQt5Widgets.so.5] 0x0001 (NEEDED) Shared library: [libQt5Svg.so.5] 0x0001 (NEEDED) Shared library: [libdl.so.2] Note that those extra Qt libraries should not be there since this particular test was without the Qt components of PLplot so that is an overlinking issue for our OCaml support I need to address. But the fundamental OCaml issue is RUNPATH is missing, and I hope to address that issue once I know more about how CMake (apparently if my above analysis of the PLplot build system is correct) automatically knows in the build tree when to use the appropriate rpath option for the C language case. 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 __ -- 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
Re: [CMake] find_package config and install
Hi Lars: On 2019-01-22 12:05- Lars wrote: Alan, Thank you very much for the response. You are welcome. Our 'foo' package does not use CMake. That means there is no build-system to produce the foo-config.cmake file, the file is manually created. The file does allow different projects to import the target from 'foo' package that has been installed. However, we need to include the library and config file in CPack installer and who is responsible for that task? We are using Qt5 config mode to import targets like you describe in development context and it works. However, to setup packaging system (CPack) we need to perform the Install(..) command so that the necessary Qt5 targets are included in the installer (MSI and RPM). We cannot require the customer to install a 2GB Qt5 installer for a few libraries. In that context it is unclear who\when\how should perform the installation. As you are probably already aware, the Qt5 software produces their "*-config.cmake" in a non-CMake way. And it appears you are attempting to follow that method for your own "foo" package case. I applaud that attempt since that end result should make life much easier for users of your foo package that do use CMake. However, now I hear you are using CPack for foo as well. So maybe it is time to bite the bullet and move foo to a cmake build (which should make your life much simpler for creating both a working "foo-config.cmake" file and a working CPack configuration.) I specifically used the term "bite the bullet" because changing build systems for any large software project with many different executables and libraries is obviously not a trivial task. But I assure you the end goal of having a complete CMake-based build, test, and CPack system is worth the pain of the transition. But I would also advise you it is possible to get from your present state to that goal in small manageable steps that are not painful at all because partially implemented CMake-based build systems normally happily coexist with other build systems. To take an example of such a soft (and completely unplanned) transition to CMake (from more than a decade ago now) in the PLplot case we had a mature autotools-based build system that was mostly good enough "except for a few nagging problems" So out of curiosity more than anything else I started a hobby project of implementing the build of just one of our smaller libraries with CMake. And that proved to be trivial (it only took a half an hour or so to learn what I needed about CMake starting from zero knowledge), and the resulting library built much faster. Following up on that initial promising result I quickly (with some substantial help from other PLplot developers at the time who were interested in learning about CMake) extended that hobby build system to more and more of our libraries and executables. Until within a month or so of me starting this "hobby" this self-organized group of developers for our CMake-based build system was producing the same libraries, shared-objects, and executables as our "standard" autotools-based build system. But that configuration was much easier to understand than for our standard build system, and both the configuration and build was much faster than for the autotools case. As a result we "got serious" and for the next month or so extended the work to support both PLplot testing and the installed version of PLplot to essentially complete the project. For a year after that we maintained both the CMake-based and autotools-based build systems, but interest in the latter dropped so fast that at the end of that year we completely removed all traces of our autotools-based build system from our source tree, and we never regretted that decision. Note, this transition to a CMake-based build system would likely not have ever happened if we attempted to plan it from the start. Instead, treating it like a learning hobby motivated me and the rest of our development group a lot, and we achieved a very fast and non-painful transition as a result. Of course, you may reply that the "foo" case is completely different and you are completely happy with your present build system for that software. If so, that is fine. However, if you have some nagging doubts about that build system (for example, some inconveniences when implementing the "foo-config.cmake" file, configuring CPack, or ultimately (if you are interested in testing "foo" configuring CTest) then perhaps it is time for you to start a possible soft transition to a CMake-based build system for "foo" as a hobby style of project without the type of "planning" that often kills such potentially useful projects dead. Alan __ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.
Re: [CMake] find_package config and install
On 2019-01-21 11:09- Lars wrote: Hello, We are creating a foo-config.cmake file for a package. The 'foo' package contain a dynamic library that provides two interfaces and a number of configuration files. There is a mapping between an interface and required configuration files. What is the recommended approach for installing targets and necessary configuration files in this context? Should this be performed by foo-config.cmake or system that performed find_package? If foo-config.cmake should perform the install, how should it be informed of which interface is required? Can the "components" tag be used for this task? Qt 5.11 support config mode but does not perform any install. Does anyone know why? We are using CMake 3.13.2 Hi Lars: Here is an overview of packaging which I believe will be useful to you. foo-config.cmake does no installation itself. Instead, the build system for project "foo" installs that file to help keep track of all the installed targets for foo that get exported by foo. That file (and the many files it includes) allows different projects to import foo targets with ease from a foo package that has already been installed. So, for example, Qt5 config mode allows your project to import Qt5 targets that have been exported by that project, but in order to access that functionality, Qt5 has to already be installed by some means completely independent of CMake. Some references that explain all this (and a lot more) are <https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html>, the install(EXPORT...) variant of the install commmand documented in <https://cmake.org/cmake/help/latest/command/install.html>, and <https://cmake.org/cmake/help/latest/command/export.html>. In sum, cmake makes it trivially easy to import targets (e.g., from an already installed Qt5 package). It is substantially more work to export targets from your own "foo" project using the foo-config.cmake approach because there are a fair number of details you have to keep track of to provide a useful result that other projects can import successfully. But exporting is pretty straightforward once you have read the above documentation, and it sure makes life convenient for other projects which wish to import targets from an already installed foo package. 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 __ -- 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
Re: [CMake] Issue with qt5_add_resources with unit tests
On 2019-01-19 00:09- Scott Bloom wrote:
I use qt + google test to run tests in my build environment.
The problem I have, is in some (most) of my unit test directories, there will
be multiple test executables created, all dependent on the same output file
from the add_resources step.
Typically its something like
qt_add_resource( resourceVar resource.qrc )
add_executable( test1 test1main.cpp ${resourceVar} )
add_executable( test2 test2main.cpp ${resourceVar} )
On windows (running the build from cmake through visual studio with parallel
building turned on) this sometimes (1 out of 20 or 30 builds or so) causes a
race condition, where the dependency on the qrc_resource.cpp is attempted to be
generated by both executable dependencies at once.
Not sure what is going on, but wondering if there was any advice out there for
this problem
Hi Scott:
I could find no google hits for qt_add_resource (except for your
question). But that search did ask is "qt5_add_resources" what
you meant?
If so there is a rather old but still useful
discussion at
<https://stackoverflow.com/questions/23041356/corrupted-resource-cpp-file-when-using-qt5-add-resources-and-multithread-compil>
for what appears to be exactly the problem you describe. See
especially the CMake code associated with this comment:
"The workaround is to add a custom target and add explicit depends on that".
Actually, regardless of causes and whether you were refererring to
qt5_add_resources or not I think that workaround will work to solve
your issue since in a parallel build environment a custom target and
relevant dependencies on that target always assures just one build
(rather than multiple builds which race with each other) of whatever
it refers to.
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
__
--
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
Re: [CMake] Help with non-standard use of CMake
On 2018-12-31 16:38-0500 Kyle Edwards via CMake wrote: On Mon, 2018-12-31 at 16:16 -0500, Donald MacQueen [|] via CMake wrote: First, CMake is quite impressive. Nice job. I am using it in a non-standard way where I set a bunch of variables and then go straight to CTest thatI installs our software and then runs several hundred tests on it. The batch file looks like this: rmdir /s/q build mkdir build cd build cmake -Dx64=%x64% -Doption:STRING="%opt%" .. ctest -D Experimental -S I do not make or build or compile. I recently hooked this up to a CDash server which is very handy. I want to get the results that are sent to CDash, currently from Windows only, to be all green. Under Build I have one error: Build log line 2. The system cannot find the file specified. CMake Error: Generator: execution of make failed. Make command was: "nmake" "/nologo" "-i" You could try one of several things: 1) Running with a different generator, such as one of the Visual Studio generators or the Ninja generator, or 2) Installing NMake. However, I am a little curious about what you're doing in your use case. You say you're not building anything. Does your sofware exist in the form of scripts (Python, Perl, etc.), or are you downloading pre- built binaries from somewhere? I am curious as well about that issue. It is possible the error he is getting is because one or more of his tests are not working because he doesn't use a build step to build something in his project that is needed by those tests. So to ask the question directly to the OP, do you have any CMake logic anywhere in this project that builds software, e.g., the add_library or add_executable commands? If so, you do have to build all such software first (by building the "all" target) before you run ctest if any of your ctest tests depend on those built libraries or executables. 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 __ -- 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
Re: [CMake] Modern cmake advise for transitive library dependencies
On 2018-12-17 21:35+0100 Mario Emmenlauer wrote: Dear cmake team and user community, I'd kindly like to ask for advice on how to handle transitive dependencies cleanly with "modern" cmake. I'm often plagued by this problem: I have a library X that optionally depends on library A. When I build library Y that depends on X, how do I (cleanly) handle the optional dependency A? Assume "A" would be "Qt5Core". I can link X publicly against Qt5::Core. But when I import X into Y, then Y will complain about unknown target Qt5::Core, unless I do find_package(Qt5 COMPONENTS Core) in Y. But since Qt is optional in X, I would need to track somehow if Qt was enabled before. But what good is the public transitive dependency when I manually need to track it, to find the libraries again? Am I missing something? Can the dependency be automatically resolved, or can I query some variable if X was linking A? How to do this cleanly? Hi Mario: One way to cleanly automate this is to configure the XConfig.cmake file (depending on whether X is linked with Qt5 or not) to optionally execute find_package(Qt5 ...) As a result, when the logic in XConfig.cmake is executed as a result of find_package(X ...) from Y, Qt5 should be found automatically when needed. 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 __ -- 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
Re: [cmake-developers] A dashboard that reveals a ctest issue on Windows when there are no tests
On 2018-12-05 12:37-0800 Alan W. Irwin wrote: On 2018-12-05 09:22-0500 Brad King via cmake-developers wrote: On 12/4/18 4:08 PM, Alan W. Irwin wrote: Build Warnings (1) *** WARNING non-zero return value in ctest from: C:\cmake-3.13.1-win64-x64\bin\cmake.exe That's in the "Build" section and indicates that the build command exited with non-zero status. If you want to try to reproduce that by hand, run the `cmake --build . --config Debug` command rather than `ctest`. `cmake --build`'s exit code just forwards from the native build tool. It may be that MSBuild has chosen to exist with non-zero for some reason. Hi Brad: Did you mean "ctest --build-and-test ..." rather than "cmake --build ..."? I assume if the build part of "ctest --build-and-test ..." returned with some non-zero return code, then you would get a message like the above that mentions ctest in a way that implies it is running the show. But I cannot see any way you could get such a WARNING message from "cmake --build ...". I hasten to add that I have been completely content over the years to use cmake, make, and ctest separately, and I have no experience using them in an integrated way (e.g., "cmake --build ..." or "ctest --build-and-test ..."). So my comment is based on my quick reading the appropriate sections of the man pages for cmake and ctest this morning, and I may have missed some way that a cmake command could generate what appears to be a message from ctest. Never mind, I got it wrong. I was too focussed on the "ctest" in the above message, and it pretty clearly was issued "from: C:\cmake-3.13.1-win64-x64\bin\cmake.exe" But I still don't understand exactly how ctest is run from cmake. Assuming the "test" target (which I have never tried) runs the "all" target and then ctest, I guess cmake --build . --config Debug --target test would run ctest indirectly after the "all" target was built, although I haven't yet figured out how in this case that user specified the -D option to submit a dashboard for that indirect ctest command. But even if that puzzle can be solved, the above message does mention ctest so I am pretty sure the above message is not coming from that "all" target. Which means ctest itself is sending a non-zero return code. And for the "--target test" case I don't see how that indirect ctest command could actually build anything. Anyhow, if you still feel the above rather opaque message was really from a PLplot build error on this guy's platform, then it appears to me (since both cmake and ctest are mentioned in the message) that it must be from cmake calling ctest which calls the build tool, but I don't see how that is possible. 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 __ -- 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
Re: [cmake-developers] A dashboard that reveals a ctest issue on Windows when there are no tests
On 2018-12-05 09:22-0500 Brad King via cmake-developers wrote: On 12/4/18 4:08 PM, Alan W. Irwin wrote: Build Warnings (1) *** WARNING non-zero return value in ctest from: C:\cmake-3.13.1-win64-x64\bin\cmake.exe That's in the "Build" section and indicates that the build command exited with non-zero status. If you want to try to reproduce that by hand, run the `cmake --build . --config Debug` command rather than `ctest`. `cmake --build`'s exit code just forwards from the native build tool. It may be that MSBuild has chosen to exist with non-zero for some reason. Hi Brad: Did you mean "ctest --build-and-test ..." rather than "cmake --build ..."? I assume if the build part of "ctest --build-and-test ..." returned with some non-zero return code, then you would get a message like the above that mentions ctest in a way that implies it is running the show. But I cannot see any way you could get such a WARNING message from "cmake --build ...". I hasten to add that I have been completely content over the years to use cmake, make, and ctest separately, and I have no experience using them in an integrated way (e.g., "cmake --build ..." or "ctest --build-and-test ..."). So my comment is based on my quick reading the appropriate sections of the man pages for cmake and ctest this morning, and I may have missed some way that a cmake command could generate what appears to be a message from ctest. 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 __ -- 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
[cmake-developers] A dashboard that reveals a ctest issue on Windows when there are no tests
Three dashboards for PLplot submitted today at <https://my.cdash.org/index.php?project=PLplot_git> had a build warning concerning ctest. For example, <https://my.cdash.org/buildSummary.php?buildid=1574104> contained Build Warnings (1) *** WARNING non-zero return value in ctest from: C:\cmake-3.13.1-win64-x64\bin\cmake.exe which I have never seen before, and the test summary section contained (just) the following message 0 passed, 0 failed, 0 failed for timing, 0 not run. (which I have also never seen before). A PLplot peculiarity is that all tests depend on bash scripts so if bash.exe is not available (as in this user's case) then there will be no ctest tests configured. In an attempt to replicate this issue, I forced bash not to be found on my own Linux box which guaranteed no add_test logic was executed. However, instead of the above results here was the reasonable PLplot "no-test" result from ctest (version 3.13.1): software@merlin> ctest Test project /home/software/plplot/HEAD/build_dir No tests were found!!! software@merlin> echo $? 0 So I would have expected the same reasonable "no-test" result on this user's Windows machine (where he was also using ctest-3.13.1), but instead he is generating the above peculiar results. Can someone here shed some light on this issue? For example, could this be a ctest bug for the "no-test" case that this user's platform exposes? Or could this be a cdash issue when a dashboard is submitted with the above reasonable "no-test" results I got on Linux? Note, there cannot be much wrong with the normal PLplot configuration of ctest when most of our ~30 tests are configured since I have recently submitted (see, e.g., <https://my.cdash.org/index.php?project=PLplot_git=2018-12-02>) successful dashboards for a fully loaded Linux systems, and Arjen Markus has done the same thing previously for his fully loaded Cygwin and MinGW-w64/MSYS2 platforms. 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 __ -- 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
Re: [CMake] custom commands, targets and parallel builds
On 2018-11-25 00:23- Kris Thielemans wrote:
Hi all
I'm trying to add doxygen-generated comments to my Python module build via
SWIG using https://github.com/m7thon/doxy2swig. This means I need to run
doxygen first, then run doxy2swig, and only then run swig. However, I'm
getting reports that parallel builds are failing (sometimes).
My strategy is based on CMake advice and some blogs (e.g. at
https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-ta
rgets-and-files-and-custom-commands/ ) and relies on creating custom
commands to generate the files and custom targets to be able to specify
dependencies on those generated files. Somewhat simplified code is below
(original is at https://github.com/UCL/STIR/pull/280)
# command that runs doxygen
add_custom_command(
OUTPUT doxygen.stamp
DEPENDS ${doxyfile}
COMMAND ${DOXYGEN_EXECUTABLE} ${doxyfile}
COMMAND cmake -E touch doxygen.stamp
.)
# corresponding target
add_custom_target( doc ALL DEPENDS doxygen.stamp)
# command that runs doxy2swig
add_custom_command(
OUTPUT STIR_DOXY2SWIG.i
DEPENDS doc
COMMAND ${PYTHON_EXECUTABLE} doxy2swig.py -c index.xml STIR_DOXY2SWIG.i
)
# corresponding target
add_custom_target(doxy2swig DEPENDS STIR_DOXY2SWIG.i)
# now add that target to the SIWG module
add_dependencies(${SWIG_MODULE_stir_REAL_NAME} doxy2swig)
Any suggestions on what I'm doing wrong?
Many thanks!
Kris
PS: I note that FindDoxygen's doxygen_add_docs merges the add_custom_command
and target into one add_custom_target, see
https://github.com/Kitware/CMake/blob/a44191abc489373d295ecaeb5c2eb1573c876a
1a/Modules/FindDoxygen.cmake#L1104
I thought that couldn't be done but I guess I was wrong.
PS: I also note that doxygen_add_docs doesn't create a doxygen.stamp file to
prevent re-runs though, is that not needed then?
Hi Kris:
To answer your last set of questions first, you can execute all
desired commands with add_custom_target, but the issue is that COMMAND
always reruns. So your way of doing it above (with paired
add_custom_command/add_custom_target) is the recommended procedure
which should only re-run if the OUTPUT file is non-existent or older
than a dependent file.
Anyhow, I think what you have outlined above is generally correct.
For example, your "DEPENDS doc" argument to add_custom_command where
doc is a custom target argument is correct according to the
documentation at
<https://cmake.org/cmake/help/latest/command/add_custom_command.html>.
However, your simplified code above has several deviations from the
pattern I always use. I know my pattern generally works, and I think
at least your first two deviations from it are important.
1. I always like to specify the full pathname for all files (e.g.,
${CMAKE_CURRENT_BINARY_DIR}/doxygen.stamp and
${CMAKE_CURRENT_BINARY_DIR}/STIR_DOXY2SWIG.i. This is true not only
for OUTPUT files and the corresponding DEPENDS but also for input
(which typically start with ${CMAKE_CURRENT_SOURCE_DIR} and output
files for COMMANDs.
2. At the same time I make sure I run all commands in
${CMAKE_CURRENT_BINARY_DIR} by specifying that as the working
directory. So that all unmentioned files on the command line are
generated in the build tree to keep the source tree as clean as
possible.
3. I don't think it matters above but I always use the VERBATIM
attribute for COMMANDS.
I have found one of my most difficult CMake tasks is to avoid build
race conditions that can occur for parallel builds. So your real code
is most important in that regard rather than a simplified example of
your CMake logic. Perhaps others here would like to comment on the
most reliable way to find such race conditions. But what I do is
process "make -j " output results to remove the
progress percentage marks, sort those results, and look for anything
that is repeated that shouldn't be. But even such care is not
sufficient, and I recently got help on this list from someone who
found a race condition (several different commands using the same
temporary filename to store intermediate results) in the build system
for PLplot. That issue had been around for years!
Finally, although I have found parallel builds to be reliable on
Linux, Arjen Markus, one of the PLplot developers, has discovered that
parallel builds are currently unreliable for all Unix-like Windows
platforms, e.g., classical MinGW/MSYS, its modern replacement
MinGW-w64/MSYS2, and Cygwin. So if some of your users are reporting
parallel build troubles on any of those platforms it is likely an
issue with the make command on those platforms rather than your build
system.
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
Re: [CMake] add_library ALIAS
On 2018-11-19 14:20- rmawatson rmawatson wrote:
I am trying to figure out exactly what this line is for in the cmake file of the
github json project here ->
https://github.com/nlohmann/json/blob/develop/CMakeLists.txt#L48
add_library(${PROJECT_NAME}::${NLOHMANN_JSON_TARGET_NAME} ALIAS
${NLOHMANN_JSON_TARGET_NAME})
Specifically with this example, what does this allow in this cmake file that
otherwise would not be possible?
The commit message where this line was added says,
"Enable target namespaces and build dir project config
CMake convention is to use a project namespace, i.e. Foo::, for imported
targets. When multiple targets are imported from a project, this looks
like Foo::Bar1 Foo::Bar2, etc. This adds the nlohmann_json:: namespace to
the exported target names.
This also allows the generated project config files to be used from the
build directory instead of just the install directory."
Removing this line appears to make no difference to any off the generated cmake
files. I can still use find_package with the build directory in
CMAKE_PREFIX-PATH with our without this line. Has something changed in cmake
since this was added?
I am using cmake 3.10.2.
No, ALIASed targets continue to be supported by the latest CMake because
they are an important component of CMake best practices for name-spaced
targets. Thus, unless you can prove it has no effect you should leave
that ALIAS logic alone.
For example, a common use case for ALIASed targets is to allow
build-tree CMake logic to use the same name-spaced name for a
project's build-tree targets as foreign projects use to import targets
from that project. So to take one example, the PLplot standard
examples are all linked against the target PLPLOT:plplot (our
principal library). That target name refers to an ALIASed target in
our build tree but is a simple imported namespaced target in our
installed examples tree (which is set up as a foreign project that
imports namespaced targets such as PLPLOT:plplot from the PLplot
installation). Therefore this ALIASing allows us to use and maintain
the identical CMake logic (where we literally install copies of some
of our build-tree CMakeLists.txt files in our installed examples tree)
for the two separate cases. If we removed our ALIASed targets in the
build tree, that would not affect anything in our installed examples
tree, but it sure would mess up our build-tree testing (which depends
on our examples getting built in that case), and you may find similar
build-tree test failures would occur for the project you are
investigating if you removed the ALIASing logic.
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
__
--
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
Re: [CMake] CMAKE_*_IMPLICIT_INCLUDE_DIRECTORIES with MinGW
On 2018-11-08 07:36+0100 Olivier Croquette wrote: Hi everyone, any feedback on this? As a summary, it's about adding the default include paths of GCC to the variables "CMAKE_*_IMPLICIT_INCLUDE_DIRECTORIES" to avoid CMake modules or scripts to mess up with them, more specifically with their order. Hi Olivier: I am afraid I cannot help you directly with your specific question because I have no access to the Microsoft version of Windows, and it has been a while since I worked with the Wine version of Windows. However, for the sake of those who might be able to help you, I suggest you clarify exactly what you mean by "MinGW". For example, some possibilities are 1. MinGW, the traditional gcc variant for Windows. This platform uses the CMake generator "MinGW Makefiles" and the MinGW version of GNU make. 2. MinGW-w64, a successor (with different developers, see <https://sourceforge.net/p/mingw-w64/wiki2>) to MinGW. This platform uses the CMake generator "MinGW Makefiles" and the MinGW-w64 version of GNU make (see <https://sourceforge.net/p/mingw-w64/wiki2/Make/>) 3. MinGW/MSYS which combines the traditional gcc variant for Windows and a traditional Unix-like variant for Windows where MSYS is developed by the same group of developers as MinGW. This platform uses the CMake generator "MSYS Makefiles" and the MSYS version of GNU make. 4. MinGW-w64/MSYS2 a successor to MinGW/MSYS where the MSYS2 developers are a different group (See <https://github.com/msys2/msys2/wiki>) than the MinGW-w64 developers and the MSYS developers. This platform uses the CMake generator "MSYS Makefiles" and the MSYS2 version of GNU make. 5. A slight variant of 4. which uses the "Unix Makefiles" generator. The reasons these platform distinctions are important for your question is the issue you have found might not be an issue for some/most of them. For example, years ago I did do comprehensive (including static linking) tests of PLplot on platform 3 for the Wine version of Windows, and I do not recall encountering the issue you have described. And my friend and PLplot colleague Arjen Markus who comprehensively tests PLplot on platform 5 on a regular basis has also never run into this issue according to the comprehensive test reports he has sent to me over the years including one such report just last week. Of course, PLplot comprehensive tests might not expose the issue you have discovered so I suggest you provide a self-contained minimal CMake-based project (minimal C source code + CMake build system to build it) which demonstrates the issue you have found on at least one of the above platforms. Once you supply that, others here can conveniently use that test project to verify (or not) the issue on any of the above 4 platforms. Good luck with your further investigations into this issue! 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 __ -- 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
Re: [CMake] Uninstalling CMake from Linux?
On 2018-11-07 22:48- Osman Zakir wrote: I want to remove CMake from my Docker image in order to reduce the image size (I'm also going to remove g++, make and build-essential -- it's after the executable program has been built). How do I do this? My opinion is this question is off-topic for this list. Instead consult with some appropriate Docker list. 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 __ -- 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
Re: [CMake] Finding out how "cmake" was run
On 2018-10-31 14:17- Ian Cullen wrote: Looks like someone had a similar idea to you a few days ago - https://gitlab.kitware.com/cmake/cmake/issues/18505 Also discussed previously: https://gitlab.kitware.com/cmake/cmake/issues/14756 https://gitlab.kitware.com/cmake/cmake/issues/16833 In addition I requested something like this roughly a decade ago although it has likely not propagated all the way from the bug tracker back then to this latest generation of the bug tracker. I think simply reporting back most cmake arguments specified on the command line is completely straightforward, i.e., what is reported back would simply be a list of all cmake arguments that were specified by the user. But the -D subset of the arguments are a special case because there are cache complications. For that subset what is useful to me is what was requested in 14756, i.e., give the user a minimal set of cmake arguments that allow them to reproduce the build starting from an empty build tree. (For example, if the user specified a -D value which happened to be the default presented by the option command, this unnecessary -D value would be dropped from this minimal list.) I guess 16833 (which asked just for whatever the last set of cmake options were regardless of cache state) might have a use case as well, but in the discussion there the requester finally decided that 14756 would satisfy his needs. In sum, it would be great from my perspective if the "reproduce the build from empty build-tree case" use case presented in 14756 (and also very long ago by me) was finally addressed. 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 __ -- 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
Re: [cmake-developers] KWSys build warnings on the "merlin" platform
On 2018-10-24 09:05-0400 Brad King wrote: On 10/23/2018 06:37 PM, Alan W. Irwin wrote: look at those build warnings which repeatedly show up on the "merlin" report for the the KWSys dashboard The warnings come from code generated by CMake. You're driving the builds with CMake 3.7 which still generated code on which gcc 8 warns. CMake 3.11 has the fix. If you drive with that or higher instead then the warnings should go away. OK. The issue was I keep ctest-3.7.2 (and cmake-3.7.2) first on my PATH because I want to make sure to test those versions for the PLplot case (since that is the PLplot minimum version of CMake for now although I plan within a year or so to bump that to 3.12.3 or higher once most Linux distributions provide that version). To fix this issue, I left my PATH the same but I now use the explicit system version of ctest (3.12.3 on Debian Buster) to launch the script, and the script automatically figures out inside to use the compatible version of cmake to launch other parts of the test rather than cmake-3.7.2 from my PATH). And as you predicted the warnings go away (see the most recent merlin results on the dashboard). So thanks very much for your key help in getting this issue figured out. I seem to have been the only one currently who has tried to use a ctest version less than 3.11 to drive testing, but nevertheless, you may still want to document that the minimum ctest version to drive testing should be 3.11 to avoid others running into this issue in the future. 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 __ -- 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
Re: [cmake-developers] KWSys build warnings on the "merlin" platform
The promised attachment concerning how my CMake test is configured. __ 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 __ my_dashboard.cmake.gz Description: application/gtar-compressed -- 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
Re: [cmake-developers] KWSys build warnings on the "merlin" platform
On 2018-10-23 21:20+0200 Rolf Eike Beer wrote: [...] [These segfaults are] intentional, there are test binaries that segfault to test if that is properly detected by the signal handler/debug/ctest/whatever code. OK, and thanks for that info. I have therefore changed the subject line appropriately. I don't notice any other platform on KWSys dashboard that also has the 8 build warnings, but it is likely my fairly recent gcc compiler (Debian Buster ccache and gcc/g++ 8.2.0) is more sensitive to problematic code in KWSys than prior versions of the gcc compiler suite. I run gcc 8.2 on castor, but I don't know why this does not trigger these warnings. It's possible it is the gcc/g++ flags I am using, but in any case someone knowledgeable should look at those build warnings which repeatedly show up on the "merlin" report for the the KWSys dashboard to see if there is anything obvious that can be done to deal with the source code issues that gcc/g++ has discovered for my Debian Buster platform. 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 __ -- 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
[cmake-developers] kernel log segfault warning messages when building/testing CMake
em to appear just for my platform. 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 __ -- 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
Re: [CMake] CMake Cookbook is out!!
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.) 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 __ -- 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
Re: [cmake-developers] FindLua.cmake module does not find a locally built lua library
On 2018-09-24 11:07-0400 Brad King wrote:
On 09/22/2018 07:09 PM, Alan W. Irwin wrote:
2. Use the NAMES_PER_DIR option in the find_library command.
This is the correct fix.
The versioned names need to go first to try to match the headers.
I agree. I have additional code in PLplot to find the Lua executable,
and the versioned name (e.g., lua3.2 or Lua3.3 on Debian Buster) needs to go
first to be
consistent with with whatever header and library are found. So I
solved the issue of finding the local build of lua in that case using
the NAMES_PER_DIR option on find_program.
Here is my code for doing this.
string(SUBSTRING ${LUA_VERSION_STRING} 0 3 SHORT_LUA_VERSION_STRING)
# Look for consistently versioned LUA_EXECUTABLE and only use the
# "lua" name for that executable as a last resort because the
# generic system version may not correspond to the library that is
# found. But in order to find a locally built version (if higher
# than the system version on the search PATHs) must also use
# NAMES_PER_DIR.
find_program(LUA_EXECUTABLE NAMES lua${SHORT_LUA_VERSION_STRING} lua
NAMES_PER_DIR)
The current FindLua.cmake does not determine the location for a
a consistent lua executable so I suggest similar code to the
above is adopted in that module to add that functionality.
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
__
--
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
[cmake-developers] FindLua.cmake module does not find a locally built lua library
This issue is due to the following NAMES logic (that is in all
versions from CMake 3.7.2 to the latest git version) of the
find_library command within FindLua.cmake.
find_library(LUA_LIBRARY
NAMES ${_lua_library_names} lua
HINTS
ENV LUA_DIR
PATH_SUFFIXES lib
)
_lua_library_names contains a bunch of different versioned names such
as lua5.3. As a result the system version of the lua libraries (which
for Debian Buster lua5.3.3 contains a nasty bug that is fixed in
upstream lua5.3.5 which I have built locally) is always found no
matter how I set CMAKE_PREFIX_PATH (or LUA_DIR) because the local
build installs the lua library with the generic name liblua.a. I can
work around that by installing an extra symlink liblua5.3.a ->
liblua.a in my locally built version of lua-5.3.5, but that
workaround should not be necessary.
There are at least two possible fixes for this issue in FindLua.cmake.
1. Use
NAMES lua ${_lua_library_names}
which follows the advice at
<https://cmake.org/cmake/help/latest/command/find_library.html>
to place the generic name first for exactly this reason (finding a local
version).
2. Use the NAMES_PER_DIR option in the find_library command.
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
__
--
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
Re: [CMake] Finding a pkg-config file
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
__
--
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
[cmake-developers] Today's PLplot contract has failed with missing Linux default .so suffix on modules
Just in case this has been fixed already where should I check for obvious CMake fix activity before reporting such issues? 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 __ -- 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
[cmake-developers] Documentation of version comparisons needs updating
The current (3.12.2) "if" documentation says, e.g., if( VERSION_LESS_EQUAL ) Component-wise integer version number comparison (version format is major[.minor[.patch[.tweak]]]). But what happens if any component of the version string is not an integer, e.g., cmake version 3.12.20180915-g6f04e for the latest git version used for the cmake dashboard. It appears from the CMAKE_CACHE_PATCH_VERSION:INTERNAL=20180915 CMakeCache.txt entry that the string "20180915-g6f04e" is reliably converted in that case to the integer 20180915, but does that reliable conversion also occur for the "if" VERSION comparisons? And if so, shouldn't the "if" documentation say something about truncation of trailing non-integer parts of the version components? What has lead me to these two questions is I am trying to distinguish between the above version and 3.12.2, and since the documentation did not acknowledge what would be done when non-integer strings were appended to any of the integer components of the version string, I am concerned the component integers might be determined in an unreliable way for trailing non-integer string cases. 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 __ -- 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
[cmake-developers] Build warnings for CMake 3.12.2
For g++ version 8.0.2 from Debian Buster, I recently noticed the following (bootstrap) build warnings for CMake-3.12.2: /home/software/cmake/cmake.git/Source/CursesDialog/cmCursesLongMessageForm.cxx:50:10: warning: ‘char* strncpy(char*, const char*, size_t)’ specified bound depends on the length of the source argument [-Wstringop-overflow=] [...] /home/software/cmake/cmake.git/Source/CursesDialog/cmCursesLongMessageForm.cxx:50:10: warning: ‘char* strncpy(char*, const char*, size_t)’ specified bound depends on the length of the source argument [-Wstringop-overflow=] I have no clue whether these build warnings signal a CMake issue that should be addressed or ignored. 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 __ -- 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
Re: [CMake] Happy Birthday CMake!
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 <https://en.wikipedia.org/wiki/Cmake>, 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 __ -- 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
Re: [cmake-developers] [CMake] Happy Birthday CMake!
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 <https://en.wikipedia.org/wiki/Cmake>, 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 __ -- 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
Re: [CMake] groups of ascii nul ('\0) characters inserted into make output but this just occurs for parallel builds (SOLVED)
On 2018-07-09 09:10+0200 Nils Gladitz wrote:
On Sun, Jul 8, 2018 at 11:00 PM Alan W. Irwin
wrote:
My parallel builds on my Linux OS (currently Debian Buster, but this
also happened for Debian Jessie so this is a long-standing problem)
have ascii null ('\0) characters inserted in the output while the
corresponding non-parallel build does not have those extra characters.
I narrowed it down with Ninja which buffers command outputs in parallel
builds which makes it easier to match output to specific commands.
Alternatively I think CTest launchers might have helped with this too.
CMake uses them to redirect build command outputs to distinct files for
CTest submissions.
I see null bytes coming from the "cat test.error" in the script file
generated from
https://sourceforge.net/p/plplot/plplot/ci/master/tree/plplot_test/test_c.sh.in
If this only shows up in parallel builds perhaps multiple processes are
reading/writing the same test.error file in parallel?
Haven't looked closer than that. You probably know better where to look
from there.
Hi Nils:
Many thanks for going "above and beyond" with this issue. Indeed,
many of the language test scripts in plplot_test write to "test.error"
and then output it after the command has been run with "cat
test.error". Many of those test.error files are in the same directory
so this constitutes a many-way name clash and therefore a set of clear race
condition for parallel builds that has existed for at least the last
decade in PLplot. UGH!
I fixed those nameclashes with PLplot commit a4bada004 (see that log
message for additional commentary), and the extra '\0' characters in
parallel output are now gone. I have no idea why the symptom of the
race is the extra '\0' characters, but I am just happy to have these
symptoms as well as the race conditions fixed!
Thanks for your key help in leading me to the solution of
this long-standing PLplot build-system issue.
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
__
--
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
Re: [CMake] specifying path for license file for commercial compiler?
On 2018-07-09 12:48- Clune, Thomas L. (GSFC-6101) wrote: [...] Based upon conversations with colleagues in other institutions, the most frustrating compiler is always the one you don’t do your development with. Because of my clients, I mostly start with Intel and then get frustrated when a design discovers defects in gfortran. But others that primarily work with gfortran say the same about Intel. My conclusion as that we subconsciously develop a coding style this is (mostly) robust within our native environment. I agree with your overall conclusion (and many other interesting points you made which I didn't quote). When the situation permits, I mostly develop with the NAG fortran compiler. The generated code is not particularly fast, but the compiler is very strict and very robust. I have no experience with that compiler myself, but a colleague has taken advantage of its well-known strictness to make sure the Fortran binding of the PLplot C library (which is implemented using the iso_c_binding module) is fully compliant with the Fortran 2003 standard with run-time results that pass our Fortran tests (which demand that our standard set of 33 plot examples written in Fortran 2003 give identical results to the corresponding C examples). He has also achieved similar testing success with ifort, and I have done the same with gfortran. So with PLplot, those three Fortran compilers give perfect test results and although we haven't yet had the time to look at other Fortran compilers presumably most of them will also produce perfect test results (since most Fortran vendors report they have correctly implemented all parts of the iso_c_binding module). 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 __ -- 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
Re: [CMake] specifying path for license file for commercial compiler?
On 2018-07-06 20:34- Clune, Thomas L. (GSFC-6101) wrote:
To use the Intel compiler, one must use an environment variable that specifies
the path to the license file. E.g.,
export INTEL_LICENSE_FILE=/usr/local/intel/license
Other commercial compilers use a very similar mechanism.I had hoped to
capture such information in a cache file so that I could avoid polluting the
shell where I am invoking cmake:
% cmake -C my-cache
Such a cache file could look like:
set(CMAKE_Fortran_COMPILER
"/usr/local/intel/2018/compilers_and_libraries_2018.3.222/linux/bin/intel64/ifort" CACHE
path "Fortran compiler")
set(ENV{INTEL_LICENSE_FILE} "/usr/local/intel/license" CACHE path "Intel
license")
Unfortunately, the compiler is not “seeing” the env variable and complains that
there is no license. Is there a solution to this, or am I forced to set the
env variable each time I try to build?
Hi Thomas:
I only skimmed responses so someone else may have said this as well,
but you will need a valid license both at cmake time (since cmake
typically tests the compiler to see if it works) and also at build
time when you obviously also have to use the compiler. In both cases
to answer your concern about polluting your normal environment
variable setup, I would advocate simply setting the environment
variable *just* for the command, e.g.,
env INTEL_LICENSE_FILE=/usr/local/intel/license cmake
env INTEL_LICENSE_FILE=/usr/local/intel/license make ...
rather than doing anything more complex.
I also have to ask is ifort really a necessity for you? There are
two reasons I have asked this question.
* Licensing infrastructure you need with proprietary compilers was
just plain annoying to me in the past. In the old days in a shared
environment I often had to wait to get work done until a compiler
license became available from someone else who was using it. So our
institution kept buying more licenses, but it was never enough. And
also in the old days when Sourceforge had a compile farm including
licensed compilers from Sun, that licensing software was semi-broken
and would often make it impossible to use the Sun part of the compile
farm. Maybe licensing infrastructure is much better implemented now,
but those bad old days completely radicalized me about licensing
infrastructure annoyances, and as a result I have been content for
years to compile fortran code with gfortran which has no licensing
infrastructure annoyances and virtually always produces reliable
results for me.
* ifort reliability was not impressive the one time I had some
(indirect) experience with it. For that case, I had a colleague who
wasted a month of both his time and my time trying to use ifort to
compile lapack as well as one of my software projects that required
lapack to solve some linear equations. ifort didn't complain at all,
but simply produced bad results at run time (i.e., the linear
equations were not being solved correctly.) After a lot of hair
pulling we discovered that this guy's habit (he was a strict fortran
traditionalist who would have no truck with new-fangled ideas such as
cmake!) of concatanating all fortran code into one giant file before
compiling it was the cause of the issue; ifort quietly produced bad
code whenever it had to process too many source lines! I hope ifort
is much more reliable now, but it sure gave me a bad first impression
in that regard.
Hope you don't mind these old war stories.... :-)
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
__
--
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
[CMake] groups of ascii nul ('\0) characters inserted into make output but this just occurs for parallel builds
My parallel builds on my Linux OS (currently Debian Buster, but this
also happened for Debian Jessie so this is a long-standing problem)
have ascii null ('\0) characters inserted in the output while the
corresponding non-parallel build does not have those extra characters.
For example, for the PLplot case and proceeding from a clean start
by configuring PLplot in an initially empty build tree:
software@merlin> make -j16 test_noninteractive >& test_noninteractive.out
software@merlin> od -c test_noninteractive.out |grep '\\0'
0713660 g r a d i e n t . \n \n \0 \0 \0 \0 \0
0713700 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0717000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0717540 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 O u t
0722160 1 4 f . f 9 0 . o \n \0 \0 \0 \0 \0 \0
0722200 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0722740 \0 \0 \0 \0 \0 \0 \0 O u t p u t f i
Note the test_noninteractive target has been configured by the PLplot
build system to build all non-interactive test command prerequisties
and then runs those test commands. (Note, these test commands are
just executables that I build and are not formal CMake test commands
that, for example, are run by ctest.) Also note those '\0' characters
occur in groups, and there are three such groups in the output, but
because parallel builds mix target outputs together it is impossible
to tell which target is generating the '\0' characters. And if I drop
the parallel build (-j16) option, the issue goes away.
Note, there is a chance this is an operating system problem rather
than a CMake problem. For example, my shell (bash) might not properly
handle the case where many different applications are simultaneously
outputting to stdout. But if so, it is a difficult issue to
replicate. For example, I implemented a simple Makefile where the all
target had 10 different prerequisites, and each of those prerequisites
used the the cat command to output the UTF-8 contents of the same file
where the file was long enough (in this case ~1 characters) so the
different outputs were mixed together for the parallel build case.
But that test failed to replicate the issue because the parallel and
non-parallel builds produced output with the same number of characters
(which was 10 times the number of characters in the file), and further
evaluation using "od -c" showed no instances of "\0" in either the
parallel or non-parallel output.
So two questions for those who are lurking here:
1. Have you ever experienced this problem when building a target with
large numbers of prerequisites in parallel with CMake, and if so, what
was the fix?
2. It is possible (although I cannot imagine how the symptoms would
just be limited to emission of extra '\0' characters) this issue could
be the symptom of a parallel build race condition for the PLplot build
system. To help eliminate or confirm this possibility what is the most
fool-proof method to diagnose whether such a race exists?
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
__
--
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
Re: [CMake] [ANNOUNCE] CMake 3.12.0-rc2 is ready for testing
On 2018-06-29 14:46-0400 Robert Maynard wrote: [...] * The "cmake_minimum_required()" and "cmake_policy(VERSION)" commands now accept a version range using the form "[...]". The "" version is required but policies are set based on the "" version. This allows projects to specify a range of versions for which they have been updated and avoid explicit policy settings. [...] I suggest the following change to the above description: but policies are set based on the "" version. ==> but policies are set based on the minimum of the running CMake and "" versions. I prefer the latter because it immediately answers the question implied by the former, i.e., what happens if the running version is less than max? 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 __ -- 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
Re: [CMake] advice for resolving errors with CMake 3.8
On 2018-05-02 09:45-0700 Michael Ellery wrote: I generally develop on a latest cmake (provided by homebrew) and that works well for me. Unfortunately, I also need to support Visual Studio builds and it looks like the cmake that is bundled with VS is 3.8. I’m apparently using bleeding-edge features related to IMPORTED libraries, judging by these errors: || Cannot specify include directories for imported target “some_lib”. || add_library cannot create ALIAS target “NIH::some_lib" because target || “some_lib" is IMPORTED. || Cannot specify compile options for imported target “some_lib". || What is the recommended way to deal with include dirs and compile settings for IMPORTED targets with pre-3.11? Hi Michael: Just in case nobody comes up with a simple solution for your question about taking the backward step (in my opinion) of making your build system compatible with CMake-3.8, have you tried to download and install CMake version 3.11 from KitWare for Windows to see if that works well for your VS platform? (My guess is you would merely need to change the PATH so that CMake version 3.11 rather than CMake version 3.8 was used, but I don't have any VS experience so it might be more complicated than that.) Anyhow, I thought this idea was worth a shot since it allows you to stick with CMake-3.11 compatibility for your build system. 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
Re: [CMake] Multiple "projects" one directory
On 2018-04-27 22:06- Scott Bloom wrote: I have a rather complicated Qt based project. We are looking at rolling out a subset tool, and it will be significantly smaller in functionality. For that mode, I would like to set a CMake variable LITEVERSION that builds the tool with -DLITEVERSION defined. however, one (or two) folders, the main executable (and possibly the main window folder), and I would like include into the tool with this turned on, and with it turned off Is that possible? Other times I have done this, I just have two build areas.. But 90% of this code base is the same, and will be built independent of the flag. So Id rather not build it twice Hi Scott: My opinion is two build areas is actually the way to go. Also, have you considered using ccache? With that software (see <http://ccache.samba.org/>, rebuild costs tend to be negligible so that two build areas which build largely the same code will not cost that much more to build than one build area. 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
[CMake] Is it possible for CMake to generate unescaped quotes on the (bash) command line as a result of add_custom_command?
Hi Nils:
I am asking this question directly of you because in the past (at
<https://cmake.org/Bug/view.php?id=15898>) you stated
"To pass quotes directly to the command either [["foo"]] or \"foo\"
should work."
But that doesn't work for me (using make and the bash command-line on
Linux), and instead with either of those two methods I get escaped
quotes on the command-line.
My use case (for add_custom_command with
VERBATIM and cmake 3.6.2 or higher) is as follows:
COMMAND test-drv-info
${LIBRARY_TARGET_PREFIX} ${SOURCE_ROOT_NAME}
${CMAKE_CURRENT_BINARY_DIR}/test_dyndrivers_dir/${SOURCE_ROOT_NAME}.driver_info
that translates to
./test-drv-info temporary_target_ ps >
/home/software/plplot/HEAD/build_dir/drivers/test_dyndrivers_dir/ps.driver_info
on the command line which is correct for the case when
LIBRARY_TARGET_PREFIX has been set to "temporary_target_". But when
LIBRARY_TARGET_PREFIX is set to the empty string the result is
./test-drv-info ps >
/home/software/plplot/HEAD/build_dir/drivers/test_dyndrivers_dir/ps.driver_info
However, that is wrong since that command currently needs two arguments even if
one of them is empty. So instead I need the generated command to be
./test-drv-info "temporary_target_" ps >
/home/software/plplot/HEAD/build_dir/drivers/test_dyndrivers_dir/ps.driver_info
or
./test-drv-info "" ps >
/home/software/plplot/HEAD/build_dir/drivers/test_dyndrivers_dir/ps.driver_info
depending on how LIBRARY_TARGET_PREFIX is set.
Is it possible to implement that? If I try your (historical)
suggestion above, I get instead
./test-drv-info \"temporary_target_\" ps >
/home/software/plplot/HEAD/build_dir/drivers/test_dyndrivers_dir/ps.driver_info
or
./test-drv-info \"\" ps >
/home/software/plplot/HEAD/build_dir/drivers/test_dyndrivers_dir/ps.driver_info
which isn't correct since unescaped quotes are needed on the generated command
line rather than escaped ones.
If the answer is unescaped quotes are not possible on the generated
command line, that is fine since there are multiple ways to work
around that CMake limitation (e.g., by changing the test-drv-info
executable to check the number of arguments and act differently if one
of them is missing). But in light of your quote above, I just want to
make sure I am not missing some obvious way that CMake can generate
unescaped quotes on the command-line.
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
Re: [cmake-developers] Is the "cmake_policy (VERSION 3.11)" statement in the latest UseSWIG.cmake correct?
On 2018-04-05 07:34- 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 __ -- 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
[cmake-developers] Is the "cmake_policy (VERSION 3.11)" statement in the latest UseSWIG.cmake correct?
According to <https://cmake.org/cmake/help/git-stage/command/cmake_policy.html>, 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
Re: [CMake] looking for 2 features to help pkg-config pc files
On 2018-03-27 21:25+0300 Nikos Chantziaras wrote: Note that one downside to that is that people not using CMake cannot make use of that. They still need a pkgconfig file. So in a sense, pkgconfig is the common denominator everybody can use, regardless of build system. It is not an either-or proposition. Both kinds of packages are useful. The pkg-config package is useful for the (lowest) common-denominator reason you state, but for those already using CMake, a native CMake package is considerably more powerful (e.g., the ability to use generator expressions based on packages imported from a native CMake package). For these reasons in the PLplot case I generate both pkg-config and native packages. The current implementation uses independent logic for each kind of package, but to absolutely guarantee consistent information for the two kinds of packages, it would be desireable to move to an implementation that uses generator expressions to extract the required compiler and linker data from a generated native package and configure the pkg-config result directly from those data. So if somebody here has already tried that approach or the alternative approach of converting pkg-config packages to native packages, I would like to hear about it. 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
Re: [CMake] looking for 2 features to help pkg-config pc files
On 2018-03-27 21:19+0900 suzuki toshiya wrote: Hi all, I'm looking for 2 features to generate pkg-config pc files. Hi Suzuki: CMake has its own native way of generating package information describing software (see, <https://cmake.org/cmake/help/git-stage/manual/cmake-packages.7.html>). So it would be worthwhile in its own right for you to generate a native CMake package for your software to benefit those of your users who want to use find_package in Config mode to obtain all the information they need about your software. In fact, it has been argued (see <https://cmake.org/cmake/help/git-stage/manual/cmake-packages.7.html>) that native CMake packages are so useful that it is worthwhile generating those for external projects that don't produce them for themselves. Now moving to your question, once a native CMake package describing software has been implemented, then it should be possible, in principle, to translate the information in that native package into pkg-config form (for the benefit of those who prefer pkg-config to find_package in Config mode to obtain information about a software package). So this is an indirect way of fulfilling your need to generate information about your software in pkg-config form, but the very large side benefit is you also provide that information in native CMake package form. 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
[cmake-developers] set_target_properties documentation needs to be updated
I just noticed (at <https://cmake.org/cmake/help/git-stage/command/set_target_properties.html>) the following inconsistent documentation of set_target_properties: "Targets can have properties that affect how they are built. set_target_properties(target1 target2 ... PROPERTIES prop1 value1 prop2 value2 ...) Set properties on a target. The syntax for the command is to list all the files you want to change, and then provide the values you want to set next. You can use any prop value pair you want and extract it later with the get_property() or get_target_property() command. See Properties on Targets for the list of properties known to CMake." I believe this documentation needs to be updated. The principal issue is whether there is just a single target for this command (as indicated by the command name) or multiple targets. In the former case "target2 ..." should be removed and list all the files you want to change ==> specify the target you want to change In the latter case Set properties on a target ==> Set properties on targets and list all the files you want to change ==> list all the targets you want to change If somone here knows which case is correct, then I would be willing to make one or the other of the above sets of changes available as a git format-patch result, but I doubt that complication should be necessary since presumably anybody who knows that answer will be in a good position to do this simple documentation fix commit themselves. 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
Re: [CMake] What are the actual benefits of namespaced targets?
On 2018-03-11 10:15+0100 Nils Gladitz wrote: On 10.03.2018 23:01, Alan W. Irwin wrote: Anyhow, your thoughts would be appreciated for reasonable best practice limits on how far (if any) beyond the common code case you would go to convert an old project to use ALIAS libraries and modules in the build tree that have to be implemented in any case for CMake code that is common to both the build tree and install tree. Hello Alan, I agree with your assessments. Assuming a project that is highly structured through directory scopes I might consider the following. Any target is defined in exactly one directory scope. Any command that extends the definition of a target has to use the original target name and should be in the same directory scope. In all other directory scopes I'd consider consistent use of a target's alias. Hi Nils: I think your suggestions prior to the last one above make perfect sense, and as far as I know my three projects already conform to them. But I have now considered your last suggestion (replacing read-only library and module targets in the build tree with the relevant namespaced target alias), but I have decided the cost/benefit ratio is too high in the PLplot case. The cost issue is PLplot has some 330 different build system files (those named "CMakeLists.txt", "*.cmake", or "*in") and something like 30 different library and module targets. An additional complication is all libraries include "plplot" in the target name (including our principal library whose target name is "plplot") but "plplot" also occurs in all sorts of other contexts in those 330 files. So making this change in the PLplot case would require a massive mentally concentrated editing exercise for what I think is a rather small and mostly stylistic benefit. So for PLplot I plan to limit use of namespaced targets to just the target_link_libraries and add_dependencies commands that are common to the build-tree and install-tree build systems. In contrast to the PLplot case, the costs of your last suggestion are much lower for the ephcom and te_gen cases (many fewer build-system files, libraries, and modules) so in those cases I might go all the way with converting the present read-only library and module targets with namespaced targets. And similarly when implementing new projects since the costs are even lower in those cases. 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
Re: [CMake] What are the actual benefits of namespaced targets?
On 2018-03-08 12:49-0800 Alan W. Irwin wrote:
On 2018-03-08 20:05+0100 Nils Gladitz wrote:
On 08.03.2018 19:50, Alan W. Irwin wrote:
So what are the actual benefits of namespacing the exported targets
associated with libraries?
On the consumer side it makes linking to targets less error prone.
When you link to a library target without a namespace and e.g. get the name
or scope wrong CMake will silently assume that you want to link a library
by name (e.g. in context of gcc "foo" becomes "-lfoo").
When the library and its headers happens to be in the compiler's standard
search directories this might not even get caught at build time right away.
When the library target has a namespace CMake will require the given name
to be a target and will fail during generation if the target is not
actually available.
Hi Nils:
Thanks for that explanation which convinced me this particular "best
practice" is worth implementing along with the rest mentioned in
<https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/>.
Hi Nils:
Here are some further questions about best practice with regard to
namespaced targets. The three different build systems I am updating
in this regard have some common CMake code between the build-tree and
install-tree cases (to build examples and run various commands for the
two cases) so for that common code I need to use a namespaced ALIAS
library for the rather large number of libraries and modules (e.g.,
PLplot device driver dll's) that are built by those three projects in
order for the namespaced targets to also be available in the
build-tree case.
But since I am already going to the trouble of creating those ALIAS
libraries for each of my real libraries and modules, what is best
practice for use of those ALIAS libraries and modules in the build
tree?
For example, should I just confine their use to common
target_link_libraries and add_dependencies commands for the build-tree
and install-tree cases?
Or would you recommend I expand their use further for the build tree
case alone? For example, would you recommend the following change:
OLD method:
add_library(a ...)
add_executable(b ...)
target_link_libraries(b a)
NEW method (where would be one of PLPLOT::, EPHCOM::, or
TE_GEN:: depending on project):
add_library(a ...)
add_library(a ALIAS a)
add_executable(b ...)
target_link_libraries(b a)
?
This *could* be considered best practice since similar motivations
apply ("a" could be the name of a system library so using a
as a target_link_libraries item *could* find a build system bug (where
some naive build system developer was happily referring to what he
thought was an internal library when in fact the system version was
being used because of some misspelling issue when creating the
library.) But I think such misspelling issues would be quickly found
for build systems in any case so my feeling is you will say this is
"one step too far" since there is lots of editing involved (for all
code, not just the common code) for very little added benefit.
Anyhow, your thoughts would be appreciated for reasonable best
practice limits on how far (if any) beyond the common code case you
would go to convert an old project to use
ALIAS libraries and modules in the build tree that have to be
implemented in any case for CMake code that is common to
both the build tree and install tree.
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
Re: [CMake] What are the actual benefits of namespaced targets?
On 2018-03-08 20:05+0100 Nils Gladitz wrote: On 08.03.2018 19:50, Alan W. Irwin wrote: So what are the actual benefits of namespacing the exported targets associated with libraries? On the consumer side it makes linking to targets less error prone. When you link to a library target without a namespace and e.g. get the name or scope wrong CMake will silently assume that you want to link a library by name (e.g. in context of gcc "foo" becomes "-lfoo"). When the library and its headers happens to be in the compiler's standard search directories this might not even get caught at build time right away. When the library target has a namespace CMake will require the given name to be a target and will fail during generation if the target is not actually available. Hi Nils: Thanks for that explanation which convinced me this particular "best practice" is worth implementing along with the rest mentioned in <https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/>. 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
[CMake] What are the actual benefits of namespaced targets?
I am currently trying to update three CMake-based build systems (for PLplot, ephcom, and te_gen) to use best practices following the really useful example of best practice given at <https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/>. That example uses the NAMESPACE signature for the install(EXPORT ... ) command to export its targets. I realize that is a quite common practice, but I don't understand the motivation for this practice. After all, the library names (and therefore the un-namespaced associated targets) already are virtually guaranteed to be unique (since two projects with two different libraries with a common library name would be an invitation to nameclash disaster). So what are the actual benefits of namespacing the exported targets associated with libraries? The reason why I ask is namespaced targets would add some (small) complexity to my build systems. For example, I would need to define a namespaced ALIAS target for each library in my build tree to use common CMake logic to refer to that library in the build systems for both my build tree and install tree. (I use that common-code practice for all three of the above projects.) Defining such ALIAS targets should be absolutely straightforward, but I want to make sure the actual namespaced target benefits outweigh this small added complexity. 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
Re: [CMake] Return an Error Code (or something) from a CMake Script.
On 2018-02-26 14:19-0500 Michael Jackson wrote:
In our CMake based project I generate a *.cmake file which I call with the
following bit of code:
add_custom_target(DREAM3D_MKDOCS_GENERATION ALL
COMMAND "${CMAKE_COMMAND}" -P "${docsCmakeFile}"
COMMENT "using mkdocs to generate the documentation"
)
Inside the generated file is the following cmake command:
message(STATUS "Starting mkdocs execution. This can take a while.")
execute_process(COMMAND "/path/to/mkdocs" build
OUTPUT_VARIABLE mkdocs_gen_output
RESULT_VARIABLE mkdocs_gen_result
ERROR_VARIABLE mkdocs_gen_error
WORKING_DIRECTORY
"/Users/mjackson/DREAM3D-Dev/DREAM3D-Build/Debug/Documentation/mkdocs"
)
message(STATUS "mkdocs_gen_result: ${mkdocs_gen_result}")
message(STATUS "mkdocs_gen_error: ${mkdocs_gen_error}")
message(STATUS
"**")
message(STATUS "mkdocs_gen_output: ${mkdocs_gen_output}")
message(STATUS
"**")
The issue that I am having is that if the mkdocs command fails, the build does NOT show
the failure. Is there a way to have the "cmake -P" command pick up the fact
that the cmake script failed so that the build fails or throws a warning/error?
Hi Mike:
I think you already have a good specific answer to your question, but
just out of curiosity could this CMake script approach be replaced by
executing "/path/to/mkdocs" as the COMMAND in a custom command where
your DREAM3D_MKDOCS_GENERATION custom target DEPENDS on the OUTPUT of
that custom command? Or are there reasons not to implement this more
usual custom command/custom target approach in this case?
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__
Linux-powered Science
__
--
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
Re: [CMake] Help with find module for package w/ components
On 2018-02-23 22:27- Zaak Beekman wrote: Is there a way to define a single target that can be passed to target_link_libraries() that will cause the *multiple* (imported) library archives of the base package to linked in? Hi Zaak: Imported library targets are handled similarly to ordinary library targets. So suppose you have a core library with the name core_fortran and a c interface library with the name c_interface, then C code should be linked to c_interface (which draws in core_fortran if you are transitively linking but otherwise not) and fortran code should be linked to core_fortran. Can I define it in such a way that it is namespaced like Foo::Foo? I have never tried that myself, but from my (very recent) reading of <https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/> namespacing is done using the NAMESPACE option for the install(EXPORT...) command. N.B. that article is extremely useful so I would recommend reading and re-reading it with care. For an optional component, then do I specify an additional target for that component? CMake users can organize the export of CMake packages in essentially any way they like. For example, the PLplot build system I am helping to maintain uses a deprecated paradigm where there is just one exported package containing a very large number of different targets. But this approach is deprecated since it makes life too difficult for software distribution maintainers who typically like to split up the various libraries and dll's installed by a project into several different interdependent binary packages. So it is very much on my agenda to reorganize our single export of a CMake package into a number of different exports with each of those CMake packages containing a disjoint subset of our targets with appropriate find_package commands in Config mode to import all CMake packages that a given CMake package depends on. So in your case, this new approach we intend to take would boil down to you exporting a CMake package corresponding to your C interface library and a CMake package corresponding to your core Fortran library. And the C interface library CMake package should use find_package to find the fortran core library package your C interface library depends on. So if user code depends on your C interface, they should use find_package in Config mode to find your C interface library package which in turn automatically finds your core Fortran library. But if user code is Fortran only they should just import your core Fortran library CMake package. N.B. in both cases, the net effect is all targets are imported that are needed. But once those targets are imported then the use of those targets in target_link_library commands is completely orthogonal to exactly how the targets are organized into separate packages. Anyhow, I hope this discussion (especially the above URL reference to best CMake practices) is a help to you. 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
Re: [CMake] Generator expressions: Identifying when they're used in a custom command?
On 2018-02-19 13:03-0700 Sam Edwards wrote:
Alan,
I'm kicking myself for leaving off the DEPENDS in add_custom_target as that
is the most essential part of what you suggested. Bah!
I tried copying in your changes verbatim and I'm still left with an output
that produces IS_INTERROGATE=0. This is on both 3.9.6 (my development
machine) and 2.8.12 (my testing VM). Does your version of CMake produce
IS_INTERROGATE=1 with your changes?
I don't want to get involved in too much further testing since the
overview of what you are attempting to do with generator expressions
is beyond my expertise. However, I did build the following simple
project (with CMake-3.6.2)
cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR)
project(test NONE)
add_custom_target(depending_target)
set_target_properties(depending_target PROPERTIES
IS_INTERROGATE 1)
get_target_property(target_interrogate depending_target IS_INTERROGATE)
message(STATUS "target_interrogate = ${target_interrogate}")
The results were
-- target_interrogate = 1
-- Configuring done
-- Generating done
-- Build files have been written to:
/home/software/plplot/HEAD/build_dir/test_build
That result confirms that if you set that property on a custom target,
then that value is accessible via get_target_property (as expected).
So I don't know why that value is not currently accessible to you with
generator expressions, but for what it is worth (since this is beyond
my CMake expertise) I think it should be. Anyhow, to debug this
further I suggest you simplify your test case even further (similar to
above) and compare generator expression results with
get_target_property results to try and understand what is going
on with the generator expression version.
The rationale behind 2.8.12 is this is the version that ships with Ubuntu
Trusty and will probably be what's present if a user is simply told to
"install CMake" - although 3.5.1 is also available on that platform under
the cmake3 package, so I might be able to justify a minimum version of
either that or 3.0.1 (which is what's on backports-less Debian Jessie). I'd
have to bring it up with the project maintainer to see, but in any case
we're trying to follow a "stick with the same minimum version until we
encounter a bug we can't work around, then bump the minimum to the version
that fixes that bug" approach.
I would take the opposite approach, i.e., develop for the latest CMake, and
then once that completely works, push the minimum version to smaller
values to see how far you can get before you run into any difficulties.
In any case, I would definitely avoid early CMake 3 versions such as
3.0.1 for the reasons I mentioned. I hauled that around on my back
for a while by working around its bugs with the PLplot build system,
but it was quite a lot of effort, and that build system became
somewhat simpler once I bumped the minimum cmake version to 3.6.2.
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
Re: [CMake] Generator expressions: Identifying when they're used in a custom command?
On 2018-02-18 19:47-0700 Sam Edwards wrote:
Alan,
Thanks for your help! I tried to implement that paradigm myself in a small
example CMakeLists.txt which I've attached, but the addition of a depending
custom target doesn't seem to change the context of the 'this' target. In
other words, the IS_INTERROGATE property is still read from fake_target and
not depending_target.
Could you take a look and clarify what I'm not doing quite right?
Hi Sam:
I just looked at the custom command part of it which was
add_custom_command(OUTPUT source.c
COMMAND "${PYTHON_EXECUTABLE}" "${script_path}"
"$<TARGET_PROPERTY:fake_target,INTERFACE_INCLUDE_DIRECTORIES>" >
source.c)
# Add a custom target to depend on source.c, as suggested
add_custom_target(depending_target)
set_target_properties(depending_target PROPERTIES
IS_INTERROGATE 1)
# Compile the output
add_executable(output source.c)
# Make sure we depend on the custom target
add_dependencies(output depending_target)
I would change the above to the following:
add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/source.c
COMMAND "${PYTHON_EXECUTABLE}" "${script_path}"
"$<TARGET_PROPERTY:fake_target,INTERFACE_INCLUDE_DIRECTORIES>" >
source.c)
# Add a custom target to depend on source.c, as suggested
add_custom_target(depending_target
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/source.c)
set_target_properties(depending_target PROPERTIES
IS_INTERROGATE 1)
# Compile the output
add_executable(output ${CMAKE_CURRENT_BINARY_DIR}/source.c)
Here are my reasons for the suggested changes.
* Absolute path when referring to source.c. I am not sure whether
this is stylistic or required, but this style works for me.
* Use DEPENDS to make the custom target depend on the custom command.
This change is essential.
* Drop add_dependency. The typical way you let CMake know that source
code is generated is with the GENERATED property which should take
care of all dependencies. However,
<https://cmake.org/cmake/help/v3.11/prop_sf/GENERATED.html> implies to
me you do not even need to specify the GENERATED property for
${CMAKE_CURRENT_BINARY_DIR}/source.c. So try the above and see, and
if it does not work try using the GENERATED property.
* Set a much higher minimum CMake version. You mentioned CMake
2.8.12+ in your original post, but there are some fundamental
differences between CMake-2 and CMake-3, and in my opinion you are
just making a rod for your back if you try to make your build system
work for both. For example, I have no idea whether the above approach
will work for 2.8.12. Another constraint is early versions of CMake-3 were
frankly buggy. So I use a minimum version of CMake-3.6.2 for all my
build systems, and that works well for me. Note all modern
Linux distributions, Cygwin, MinGW-w64/MSYS2, HomeBrew, MacPorts, and
Fink all provide that version of CMake or higher, and Kitware provides
CMake for that version and higher for MSVC as well so that choice of minimum
CMake version should inconvenience very few of your potential users.
I hope these suggested changes help you toward your broader goal.
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
Re: [CMake] Generator expressions: Identifying when they're used in a custom command?
On 2018-02-18 03:49-0700 Sam Edwards wrote: However, when it came time to actually set this IS_INTERROGATE property, I could find no way to apply it to a custom command. I guess this makes sense - custom commands aren't targets, after all. But I couldn't convert my custom command to a custom target, because it produces a C++ source file and I need to use OUTPUT to let CMake know where that source file comes from, and you can't use OUTPUT and TARGET together in add_custom_command. Hi Sam: It's quite common for each custom command to have a corresponding custom target that DEPENDS on the OUTPUT of the custom command. So building the target part of that pair means the custom command is executed *only if* the OUTPUT from it is out of date. If you used that paradigm for the custom commands you refer to above (where each such custom command is paired with a unique target via the DEPENDS of the latter) could you not set the IS_INTERROGATE property for the custom target part of of each pair whenever that property is relevant? 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
Re: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to combine?
On 2018-02-13 14:56-0500 Brad King wrote: On 2/13/2018 2:50 PM, Alan W. Irwin wrote: While waiting for Arjen to respond from his European time zone to that question, which cmake package for MinGW-w64/MSYS2 do you usually recommend? The cmake package from the mingw64 repository or the cmake package from the msys2 repository? I'm not familiar with either of those. What does each report as CMAKE_HOST_SYSTEM_NAME? In general, you get native packages from the mingw64 repository and POSIX-aware packages from the msys2 repository for this dual-natured platform, and cmake is one of those rare beasts that has a package in each repo. @Arjen: to answer Brad's questions you should modify our top-level CMakeLists.txt to also report CMAKE_HOST_SYSTEM_NAME (just in case that is not the same as CMAKE_SYSTEM_NAME which we already report there). I assume from the CMakeCache.txt file you included in your August comprehensive test report for this platform that you are still running $PREFIX/mingw64/bin/cmake.exe, i.e., the version of cmake from the mingw64 repository. So just configuring PLplot on that platform should give you the mingw64 answer to Brad's questions. And to get the msys2 answer you will need to temporarily move $PREFIX/mingw64/bin/cmake.exe out of the way, install the POSIX version of cmake from the msys2 repo, and configure PLplot from scratch again using the msys2 version of cmake. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
Re: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to combine?
On 2018-02-13 12:32-0500 Brad King wrote: On 2/9/2018 2:36 AM, Arjen Markus wrote: From: Alan W. Irwin I suggest you try the names CYGWIN-NAG-Fortran.cmake and Windows-NAG-Fortran.cmake for the two separate Platform files you are trying to create for the Cygwin and MinGW-w64/MSYS2 platforms. I think those names are correct. However, the status of CMake for MSYS2-native builds is unclear. See below. I have a Platform file “Windows-NAG-Fortran.cmake” and that is used correctly if I start the NAG Fortran environment (using the MinGW Makefiles generator) Good. but if I try the same with MinGWw-w64/MSYS2, this file is clearly ignored What is the value of CMAKE_SYSTEM_NAME that is detected? Typically this should be "Windows" for a Windows-native CMake and "CYGWIN" for a cygwin-built CMake that is linked against the cygwin runtime library. For MSYS2 what CMake are you running? A Windows CMake or one that came packaged by MSYS2? Does the latter link against the msys2 runtime library? While waiting for Arjen to respond from his European time zone to that question, which cmake package for MinGW-w64/MSYS2 do you usually recommend? The cmake package from the mingw64 repository or the cmake package from the msys2 repository? 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
Re: [CMake] MSYS2 broken CMAKE_PREFIX_PATH
On 2018-02-13 15:22+0100 Mario Emmenlauer wrote: I'm 99% certain that this variable [the CMAKE_PREFIX_PATH environment variable] is not defined, because I build from a standard Cygwin shell started from a gitlab runner. But there might be another piece of evidence that can help us further. When I build as outlined above (here for reference): /mingw64/bin/cmake /d/tmp/sources \ -DCMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries" && \ make && make install then the find_xxx() commands will work, but the cmake package configurations fail. To get them also to work, I can switch to Windows path styles: /mingw64/bin/cmake /d/tmp/sources \ -DCMAKE_PREFIX_PATH="D:\\dest\\thirdparty;D:\\dest\\binaries" && \ make && make install then *everything* will work. So this should clarify that my POSIX path was not automatically translated before, otherwise both invocations would be identical, and the cmake package configurations should still fail. PS: Note that the source directory is *still* in POSIX path notation :-) Hi Mario: My understanding is that POSIX-style CMAKE PATH variables must be colon-delimited. So what does your CMakeCache.txt file say about CMAKE_PREFIX_PATH with the semicolon delimiter you used above in your first (POSIX) variant, and just as an experiment what happens with that cache file and also your results with that first version if you change the semicolon to a colon, i.e., /mingw64/bin/cmake /d/tmp/sources \ -DCMAKE_PREFIX_PATH="/d/dest/thirdparty:/d/dest/binaries" && \ make && make install ? 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
Re: [CMake] MSYS2 broken CMAKE_PREFIX_PATH
On 2018-02-12 23:06+0100 Mario Emmenlauer wrote: On 12.02.2018 22:09, Alan W. Irwin wrote: [...] I am virtually positive from reading <https://github.com/msys2/msys2/wiki/MSYS2-introduction> and other MinGW-w64/MSYS2 documentation that the conversion from POSIX to native PATHs is done by the MSYS2 dll. Also, MinGW-w64/MSYS2 applications from the msys2 repository are linked against that dll while the applications from the mingw64 repository are pure native, i.e., not linked against that dll. Thus, if that mental model is correct, here are some predictions that flow from it. * The cmake version from the msys2 repository will understand cache variables expressed as POSIX PATHs, but the cmake version from the mingw64 repository wont have that capability. I am not sure if I follow until here, but very likely I just misunderstand what you are saying. Please help shed some light! I will try. :-) In my observation, I have cmake installed from mingw64 repository, and I can successfully use this cmake with a CMAKE_PREFIX_PATH in POSIX PATH notation find all my dependencies with find_xxx() commands (i.e. find_library() or find_file() or the like). I also use this same cmake with a path to the source directory specified as POSIX PATH. So to be 150% sure we mean the same, the following works for me, where /d/ corresponds to the D: drive of Windows: /mingw64/bin/cmake /d/tmp/sources \ -DCMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries" && \ make && make install Is that contradictory to your point above? It certainly contradicts one of my predictions. Just to clarify, the environment variable form of the above command would have been (assuming your command-line environment is bash.exe from the msys2 repository of MinGW-w64/MSYS2) export CMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries" /mingw64/bin/cmake /d/tmp/sources && make && make install But instead, of using that environment variable form of the command you used the -DCMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries" cmake option which sets CMAKE_PREFIX_PATH as a cache variable. And for that cache variable approach, my prediction was the mingw64 version of cmake would not work with the above POSIX form of CMAKE_PREFIX_PATH, but your experience is it does work! So that contradiction to the prediction is indeed an interesting result. Just to cover off one possibility, could you try the bash printenv command to print out all your bash environment variables to make sure you have not inadvertently set the environment variable form of CMAKE_PREFIX_PATH? Of course, if you confirm this way that CMAKE_PREFIX_PATH is not set as an environment variable, then it is pretty clear something is incorrect/incomplete about the above mental model. 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
Re: [CMake] MSYS2 broken CMAKE_PREFIX_PATH
On 2018-02-12 13:06+0100 Mario Emmenlauer wrote: Hi, ok I agree it might be cleaner to use Windows-style paths for all cmake parameters on MSYS2. I changed my CI and everything works! :-) But just as a side comment: It would be super cool if cmake would support both styles for all parameters. The typical use on MSYS2 for many commands is with Unix paths, and its great that cmake already supports this so nicely. It really made things easier for me! If its not a huge effort it would be great to have the same behaviour also for the package configs. I am glad you have found a satisfactory solution for your needs, but I would like to respond to your further side comment about the broader picture. I am virtually positive from reading <https://github.com/msys2/msys2/wiki/MSYS2-introduction> and other MinGW-w64/MSYS2 documentation that the conversion from POSIX to native PATHs is done by the MSYS2 dll. Also, MinGW-w64/MSYS2 applications from the msys2 repository are linked against that dll while the applications from the mingw64 repository are pure native, i.e., not linked against that dll. Thus, if that mental model is correct, here are some predictions that flow from it. * The cmake version from the msys2 repository will understand cache variables expressed as POSIX PATHs, but the cmake version from the mingw64 repository wont have that capability. * bash.exe (only available on MinGW-w64/MSYS2 from the msys2 repository for obvious reasons) will understand the POSIX version of environment variables that represent PATHs. * The combination of mingw64 cmake and bash will work for your POSIX PATH needs if you are careful to use the bash environment variable form of CMAKE_PREFIX_PATH rather than the cache variable form of CMAKE_PREFIX_PATH. I invite you to read the MinGW-w64/MSYS2 documentation to satisfy yourself concerning that mental model. And I also hope you do some experiments to see whether the above predictions are correct. By the way, I don't have access to Microsoft Windows myself but since the MinGW-w64/MSYS2 platform is so important for PLplot I have tried to get access to it via Wine-staging version of Windows just to help my fellow PLplot developers with testing of MinGW-w64/MSYS2. Unfortunately, the combination of MinGW-w64/MSYS2 and Wine-staging that apparently worked a while ago no longer works at all, see <https://github.com/TeaCI/tea-ci/wiki/Msys2-on-Wine>. If you follow the link there, apparently there is a lot of continuing interest in getting this wine-staging bug fixed. But while waiting for that, I am in the frustrating position of only being able to make theoretical predictions based on mental models as above rather than trying MinGW-w64/MSYS2 for myself! Anyhow, if you get a chance to test out some of the above predictions, I would be most interested in your results. 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
Re: [CMake] MSYS2 broken CMAKE_PREFIX_PATH
On 2018-02-12 09:32+0100 Mario Emmenlauer wrote: [...] Hi Mario: From <https://github.com/msys2/msys2/wiki/MSYS2-introduction>, and what you said above it appears you are using the "native Windows" cmake version from the mingw64 repository rather than the POSIX-style cmake package you can install from the msys2 repository. I am pretty Hmm, I don't think I have a native Windows cmake installed. As Marc said in his post, be aware of the dual nature of this platform. One side (the mingw64 repository) supplies native Windows packages while the other (the msys2 repository) supplies a much smaller number of Unix-like packages. CMake packages happen to be in both repositories! 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
Re: [CMake] MSYS2 broken CMAKE_PREFIX_PATH
On 2018-02-11 15:13+0100 Mario Emmenlauer wrote: I use mingw-w64-x86_64-cmake 3.10.2 on MSYS2. Generally it works well, but just recently I started to have problems with CMAKE_PREFIX_PATH. Its possible that the problems have been there forever, but I now just found them due to a better use of CI systems. The problem is that cmake is not finding package configuration files correctly. I have such files in DESTDIR/lib/cmake, i.e. for a library XXX there are typically files XXXConfig.cmake, XXXConfigVersion.cmake and XXXTargets.cmake (i.e. for Qt, VTK and others). But they are not found when I specify CMAKE_PREFIX_PATH=DESTDIR/lib/cmake in Unix path style. It does work when I specify the package configuration directory in Windows style! This makes things quite confusing, because many find_xxx() commands for headers and libraries work with Unix paths. So now I need to use CMAKE_PREFIX_PATH=UNIXDESTDIR for the normal find_xxx(), but add WINDESTDIR\lib\cmake for the package configuration files (*). Is this an MSYS2 issue or a standard cmake issue? I reported it with MSYS2 here https://github.com/Alexpux/MINGW-packages/issues/3337 in case someone can comment? Hi Mario: From <https://github.com/msys2/msys2/wiki/MSYS2-introduction>, and what you said above it appears you are using the "native Windows" cmake version from the mingw64 repository rather than the POSIX-style cmake package you can install from the msys2 repository. I am pretty sure the native version would not do well with non-native POSIX-style paths so I am not surprised by your results. Anyhow, I suggest you experiment with native versus POSIX cmake packages in both CMD and bash (from msys2) environments to establish what the different results are in those four cases for native Windows and POSIX paths. Note I have no access to MinGW-w64/MSYS2 myself, but I do pay close attention to this platform because it is the best Windows platform for PLplot according to a fellow PLplot developer who does have a lot of practical experience with this platform. 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
Re: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to combine?
On 2018-02-10 08:04+0100 Mojca Miklavec wrote: On 9 February 2018 at 18:24, Alan W. Irwin wrote: On 2018-02-09 10:44- Arjen Markus wrote: Hi Alan, The result is the same or very much the same. OK. Time for more knowledgable people to weigh in here about what Platform filenames to use for the combination of nagfor and MinGW-w64/MSYS2 for the "Unix Makefiles" and "MSYS Makefiles" generators. Meanwhile, can you test whether the Platform filename I suggested for the nagfor Cygwin case with "Unix Makefiles" generator is correct? Alan I wonder if this is in any way related to https://cmake.org/Bug/view.php?id=14252 Hi Mojca: Just to clarify there has been a change in the CMake bugtracker. You reference the old bug tracker entry where all issues there were automatically closed and moved to the new bug tracker <https://gitlab.kitware.com/cmake/cmake/issues/14252>. However, that is an almost completely vacuous entry (except for title) in the new bug tracker although it does declare the issue is still open. As far as I can tell from that old discussion, Brad King found the hard-coded source of your problem in the CMake code with -arch, but there is no reference to a fix either in the old tracker or new one so I assume that fix has not been implemented yet. Furthermore, although there is a superficial resemblance I am pretty sure from the description this hard-coded issue is quite specific to certain compiler options, and does not refer to ignoring all nagfor compiler options as Arjen has apparently observed. So I think the source of Arjen's problem likely is that he is using the incorrect Platform filenames for the various nagfor Windows cases that have been discussed, and we need advice from a CMake language support expert to help us figure out what those Platform filenames should be. 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
Re: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to combine?
On 2018-02-09 10:44- Arjen Markus wrote: Hi Alan, The result is the same or very much the same. OK. Time for more knowledgable people to weigh in here about what Platform filenames to use for the combination of nagfor and MinGW-w64/MSYS2 for the "Unix Makefiles" and "MSYS Makefiles" generators. Meanwhile, can you test whether the Platform filename I suggested for the nagfor Cygwin case with "Unix Makefiles" generator is correct? 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
Re: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to combine?
On 2018-02-09 07:36- Arjen Markus wrote: Hi Alan, -Original Message- From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] Sent: Thursday, February 08, 2018 10:59 PM To: Arjen Markus Cc: cmake@cmake.org Subject: Re: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to combine? On 2018-02-08 19:33- Arjen Markus wrote: So: Is it possible to instruct CMake to use the NAG-Fortran specific settings [for the Cygwin and MinGW-w64/MSYS2 platforms] and if so, how do I do that? Hi Arjen: I think you should be guided by what goes on for gfortran. For that compiler, the relevant Platform files are called CYGWIN-GNU-Fortran.cmake and Windows- GNU-Fortran.cmake Platform files for the Cygwin, and MinGW-w64/MSYS2 platforms. Furthermore, in all the existing nagfor cases (Linux and Darwin), you derive the nagfor-related name from the gfortran related name by replacing GNU- Fortran by NAG-Fortran. Therefore, I suggest you try the names CYGWIN-NAG- Fortran.cmake and Windows-NAG-Fortran.cmake for the two separate Platform files you are trying to create for the Cygwin and MinGW-w64/MSYS2 platforms. I have a Platform file "Windows-NAG-Fortran.cmake" and that is used correctly if I start the NAG Fortran environment (using the MinGW Makefiles generator), but if I try the same with MinGWw-w64/MSYS2, this file is clearly ignored - I see the compiler fail on a typical GCC flag for creating shared libraries (the Platform file I added takes care of that in the NAG Fortran environment and therefore the build succeeds). Hi Arjen: Is the issue that you used the "Unix Makefiles" generator rather than the "MSYS Makefiles" generator for the MinGW-w64/MSYS2 test? I believe you have found both generators work pretty well for this platform, but in order to use your "Windows-NAG-Fortran.cmake" platform file, you may find that the "MSYS Makefiles" generator is the one you *must* use. If you report back that experiment doesn't work, then we need a knowledgable CMake developer to chime in here to let you know exactly what Platform filename is correct for the nagfor compiler on the MinGW-w64/MSYS2 platform for either/both the "Unix Makefiles" and "MSYS Makefiles" generators. 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
Re: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to combine?
On 2018-02-08 19:33- Arjen Markus wrote: So: Is it possible to instruct CMake to use the NAG-Fortran specific settings [for the Cygwin and MinGW-w64/MSYS2 platforms] and if so, how do I do that? Hi Arjen: I think you should be guided by what goes on for gfortran. For that compiler, the relevant Platform files are called CYGWIN-GNU-Fortran.cmake and Windows-GNU-Fortran.cmake Platform files for the Cygwin, and MinGW-w64/MSYS2 platforms. Furthermore, in all the existing nagfor cases (Linux and Darwin), you derive the nagfor-related name from the gfortran related name by replacing GNU-Fortran by NAG-Fortran. Therefore, I suggest you try the names CYGWIN-NAG-Fortran.cmake and Windows-NAG-Fortran.cmake for the two separate Platform files you are trying to create for the Cygwin and MinGW-w64/MSYS2 platforms. 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
Re: [CMake] announce: free VTK, ParaView and CMake training at Kitware New York next month
On 2018-02-01 15:16-0500 David E DeMarle wrote: Kitware is going to present three free, one day training courses next month at our Albany NY headquarters. The outline for each day follows. For those of who would prefer not to make such a long trip but who are extremely interested in those training courses, would you be willing to record a video of those training sessions and make that video freely accessible on the web? I (and presumably many others here since this is the CMake mailing list after all) would be particularly interested in watching the last-day session March 15'th "CMake and Friends" all day: w/ Bill Hoffman 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
Re: [CMake] Do any CMake back ends have support for parallel builds that efficiently use clusters?
On 2018-01-12 13:34+0300 Konstantin Tokarev wrote: 12.01.2018, 12:58, "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>: I am looking into the practicality of using clusters containing ~5 cheap ARM 8-core computers (such as the Banana Pi M3) to rapidly build and test software (since even with ccache I am currently spending a lot of my time waiting for tests to complete as I develop my software). Such clusters would give you ~40 cores which is a lot of computer power for ~$500 or so. But, of course, the issue with clusters is how to use them efficiently? 1. For compilation you often need good single-core performance more than parallelism, and I doubt that embedded-grade ARMv8 can provide it I guess exception is compiling projects written in C which don't have huge source files. Still, overhead of passing data between nodes may be substanital. 2. You should probably use icecc or distcc, unless you have MPI as a requirement. Most of the work is run-time tests (configured with add_custom_command/target) rather than compilations. It have just discovered that it looks like "distmake" or equivalent is what I need (see the post I just wrote). 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
Re: [CMake] Do any CMake back ends have support for parallel builds that efficiently use clusters?
On 2018-01-12 11:14+0100 Eric Noulard wrote: 2018-01-12 10:58 GMT+01:00 Alan W. Irwin <ir...@beluga.phys.uvic.ca>: I am looking into the practicality of using clusters containing ~5 cheap ARM 8-core computers (such as the Banana Pi M3) to rapidly build and test software (since even with ccache I am currently spending a lot of my time waiting for tests to complete as I develop my software). Such clusters would give you ~40 cores which is a lot of computer power for ~$500 or so. But, of course, the issue with clusters is how to use them efficiently? For one 8-core M3 you would expect make -j target to scale linearly with NNN up to the saturation limit of roughly NNN=8 (where target depends on ~hundreds of different and mostly independent tests). But my understanding from recent Google searching is that the -j option for GNU Make is not MPI-aware, i.e., only works for the cores for a single computer (node) in a cluster. So in a cluster you would have to assign the above task to just one node and simply accept that you cannot scale NNN up to the total number of cores in that cluster. AFAIU what you want is "distributed ctest" not really distributed build right? Not ctest, but actually distributed "build", but with "build" in quotes because instead of exclusively building software, most of the targets that are built are configured with add_custom_command/add_custom_target and actually run tests with proper dependencies on other test targets as well as targets that actually build software. So this testing paradigm makes initial testing of one particular test much quicker because you don't have to build the "all" target before the test like is required with ctest. For distributed build you may have a look at distcc (http://distcc.org/) which seems already used by CMake-enabled project like ccache is ( https://stackoverflow.com/questions/32752446/using-compiler-prefix-commands-with-cmake-distcc-ccache/34317588 ) It looks like distcc could speed up compilations tremendously on a cluster, but only a minority of my targets are actually builds of software. So I need a "distmake". Just after writing that sentence I decided I liked that made-up name so on the off-chance someone else had liked it as well, I did a google search and found the SF distmake project that apparently does exactly what I need! Instead of using MPI (Message Passing Interface) standard to coordinate the targets that are built between the various nodes, it looks like it uses something a lot simpler. Now I'm not quite sure to understand why you speak of MPI-awareness ? I thought to coordinate target builds over a cluster, that the make programme itself would have to have MPI directives inserted into its source code so the whole build coordination could be handled by MPI. But it appears that complexity is not necessary (see distmake, above). Are your test including MPI which would mean that some executable are already eating up more than one core? No. Or do you have a big collection of mono-processor tests you want to run on the cluster? Yes, but with complete dependencies as explained above. In sum, it looks like this question now boils down to whether anyone here has used distmake (or something equivalent to it) on a cluster, and if so, are there any gotcha's? 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
