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-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-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-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
[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-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-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-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-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-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
[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-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-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
[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-developers] CMP0022 documentation is outdated
On 2017-12-24 00:01+0100 Domen Vrankar wrote: 2017-12-23 13:25 GMT+01:00 Alan W. Irwin <ir...@beluga.phys.uvic.ca>: [...] So I guess the conclusion is it's a very low priority to update the documentation of ancient policies like this one. I guess that's fine if the plan is these ancient policies will finally be retired as of CMake-4 AND that new major version of CMake (which presumably will be allowed to break backwards compatibility) is coming reasonably soon. I don't know what the plans regarding bumping CMake major version or deprecating old policies are but I remember talks about deprecating some of them on the mailing list - couldn't find the mails though... but found this merger request that was already merged: https://gitlab.kitware.com/cmake/cmake/merge_requests/743 Hi Domen, Thanks for your response, but just to clarify, I said "retired" above when the term "removed" would have been a bit better. If policies have been removed, it means you can drop the support of the OLD policy version (so CMake always follows the NEW policy from then on) and completely remove all the policy infrastructure cruft for all those removed policies. So that is obviously a different case from "deprecated" where you still have to maintain the OLD policy and its documentation. 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-developers] CMP0022 documentation is outdated
On 2017-12-19 14:18-0800 Alan W. Irwin wrote: I have a software project with a dated CMake-based build system that specifically set CMP0022 to OLD. So while updating that build system I naturally consulted the latest CMP0022 documentation, e.g., <https://cmake.org/cmake/help/git-stage/policy/CMP0022.html>, and discovered that documentation was outdated, e.g., lots of historical references to CMake-2.8 which are likely no longer needed, and the following recommendation Warning-free future-compatible code which works with CMake 2.8.7 onwards can be written by using the LINK_PRIVATE and LINK_PUBLIC keywords of target_link_libraries(). (The obvious problem with that advice is that LINK_PRIVATE and LINK_PUBLIC are now deprecated themselves!) IF cmake-4 is coming soon and presuming that CMP0022 OLD behaviour will no longer be supported by that version of cmake, then you may not want to do anything about this outdated documentation since it will be removed with cmake-4. But otherwise for current needs like mine (updating an old build system that specifically set CMP0022 to OLD) a complete rewrite would be a good idea with the emphasis on simplifying down to one or two sentences such as Support for CMP0022 OLD behaviour is scheduled for removal with cmake-4 [if that decision has indeed already been made] so do not set this policy to OLD for new build systems. But if you need to know details about CMP0022 OLD behaviour in order to upgrade an old build system that currently requires the OLD version of this policy, see the target_link_libraries() documentation. Hmm. I got no responses to the above. So I guess the conclusion is it's a very low priority to update the documentation of ancient policies like this one. I guess that's fine if the plan is these ancient policies will finally be retired as of CMake-4 AND that new major version of CMake (which presumably will be allowed to break backwards compatibility) is coming reasonably soon. 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] CMP0022 documentation is outdated
I have a software project with a dated CMake-based build system that specifically set CMP0022 to OLD. So while updating that build system I naturally consulted the latest CMP0022 documentation, e.g., <https://cmake.org/cmake/help/git-stage/policy/CMP0022.html>, and discovered that documentation was outdated, e.g., lots of historical references to CMake-2.8 which are likely no longer needed, and the following recommendation Warning-free future-compatible code which works with CMake 2.8.7 onwards can be written by using the LINK_PRIVATE and LINK_PUBLIC keywords of target_link_libraries(). (The obvious problem with that advice is that LINK_PRIVATE and LINK_PUBLIC are now deprecated themselves!) IF cmake-4 is coming soon and presuming that CMP0022 OLD behaviour will no longer be supported by that version of cmake, then you may not want to do anything about this outdated documentation since it will be removed with cmake-4. But otherwise for current needs like mine (updating an old build system that specifically set CMP0022 to OLD) a complete rewrite would be a good idea with the emphasis on simplifying down to one or two sentences such as Support for CMP0022 OLD behaviour is scheduled for removal with cmake-4 [if that decision has indeed already been made] so do not set this policy to OLD for new build systems. But if you need to know details about CMP0022 OLD behaviour in order to upgrade an old build system that currently requires the OLD version of this policy, see the target_link_libraries() documentation. 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] For add_custom_command and add_custom_target does each COMMAND completely finish before the next COMMAND starts?
ation would be worthwhile to clarify this point. I would also appreciate corrections (if needed) to the above hypothesis to explain the peculiar modification times I demonstrated above. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] PLplot contract test
On 2017-11-08 18:00-0800 Alan W. Irwin wrote: [...] Changing topics back to the Nightly case where the job is started in a crontab environment rather than on the normal desktop command line as above, further research indicates it is possible to set DISPLAY for such environments (assuming that DISPLAY exists at the time the crontab job fires as is typical for my case). So I am going to try that to see if that change plus the above setting of XAUTHORITY solves the Nightly issue as well. Thanks to that crontab change to define the DISPLAY environment variable, all is now well with the Nightly case, see <https://open.cdash.org/testDetails.php?test=598968882=5135648>. So that appears to be the end of the configuration issues with the Contracts.PLplot test, and my thanks to Brad for implementing this test in the first place, and both Brad and Ben for some key help with my configuration of this test. So for others here that might be interested, Contracts.PLplot tests a build of the stage/master/nightly/latest branch of CMake by using ExternalProject_Add to git checkout a specified version of PLplot and to configure, build, and install that version with user control of the PLplot version selected for the test and the CMake options used to build PLplot. So this test is good from the PLplot perspective because it makes it more difficult for some new CMake development to cause PLplot developers problems without us knowing it long in advance of CMake releases. And it is also good from the CMake testing perspective since it is a test that exercises a lot of different CMake functionality in a realistic way (i.e., as used in a rather complex build system, warts and all). Additional notes are (1) because of the relatively small size of the PLplot project (despite its build-system complexity) this test adds less than ~30 per cent to the overall cost of building and testing CMake, and (2) this test should work on essentially all platforms (the build of PLplot is known to work on at least Linux, Mac OS X, Cygwin, MinGW-w64/MSYS2, and MSVC). So if anyone else is interested in trying this test on their favorite platform(s), feel free to contact me for help with configuring it and overcoming any PLplot build failures in the unlikely event of you encountering those. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] PLplot contract test
On 2017-11-08 16:14-0500 Ben Boeckel wrote:
On Wed, Nov 08, 2017 at 12:39:15 -0800, Alan W. Irwin wrote:
software@raven> time (nice -19 ctest -S
~/cmake/Dashboards/Scripts/CMakeScripts/my_dashboard.cmake -VV >& ctest.out16)
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
The only thing I can find in ctest.out16 corresponding to these
warnings is
264: application-specific initialization failed: couldn't connect to display
"localhost:10.0"
264: Error in startup script: couldn't connect to display "localhost:10.0"
The Xauthority file is not available to the nightly build job.
Hi Ben:
Note the above issue is for an Experimental test and not for a Nightly
one, i.e., the above errors occurred for a command-line environment
where X authentication normally just works (i.e., I can fire up
another konsole or xterm, run "xauth list", etc. without issues). The
corresponding X authority file is located at
/home/software/.Xauthority.
Following up on another comment you made concerning the
XAUTHORITY environment variable I decided to try setting
that environment variable using
macro(dashboard_hook_build)
set(ENV{XAUTHORITY} /home/software/.Xauthority)
endmacro()
within my Scripts/CMakeScripts/my_dashboard.cmake
file following how I set other environment variables
for this contract test.
That change completely solved the above Experimental X authority
issues and the Tk-related components of PLplot built for that
particular test.
So thanks very much for that XAUTHORITY idea!
Changing topics back to the Nightly case where the job is started in a
crontab environment rather than on the normal desktop command line as
above, further research indicates it is possible to set DISPLAY for
such environments (assuming that DISPLAY exists at the time the
crontab job fires as is typical for my case). So I am going to try
that to see if that change plus the above setting of XAUTHORITY solves
the Nightly issue as well.
@Brad:
I still have no idea why setting XAUTHORITY to the file that is used
in any case should be needed, and I am therefore pretty sure doing
that as above merely works around an issue with contract tests (or
deeper) where it is possible not enough care is being used to
propagate X authority.
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:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] PLplot contract test
On 2017-11-08 06:54-0500 Brad King wrote: [...] I've updated the test. Change the name from _ARGS to _FLAGS: ``` CMake_TEST_CONTRACT_PLplot_CMAKE_FLAGS:STRING=-DBUILD_TEST=ON -DBUILD_DOC=ON -DBUILD_DOX_DOC=ON ``` [...] I've added an option: ``` CMake_TEST_CONTRACT_PLplot_GIT_TAG:STRING=plplot-5.12.0 ``` The value can be anything that `git checkout` understands (tag, branch, commit sha1, etc.). Hi Brad: Thanks for these changes which all work well (see <https://open.cdash.org/viewTest.php?onlypassed=5134501> for details). The Contracts.PLplot test (for the current PLplot master branch HEAD) passed in < 10 minutes (even with all the extra documentation building I have configured) which is acceptable when compared to the total length of this test. As far as I can tell there is only one issue left which is I get the following X11 authentication warnings when running this test in Experimental mode. # Check DISPLAY environment variable software@raven> printenv |grep DISPLAY DISPLAY=localhost:10.0 software@raven> time (nice -19 ctest -S ~/cmake/Dashboards/Scripts/CMakeScripts/my_dashboard.cmake -VV >& ctest.out16) X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. X11 connection rejected because of wrong authentication. The only thing I can find in ctest.out16 corresponding to these warnings is 264: application-specific initialization failed: couldn't connect to display "localhost:10.0" 264: Error in startup script: couldn't connect to display "localhost:10.0" As a result of that error, the PLplot build system concludes Tk does not work for the given platform and as a result it disables building all Tk-related components of PLplot for this contract test. Which makes this contract test not quite as powerful as it should be. What is going on behind the scenes is the PLplot build system executes the Tk "wish" command to simply confirm version consistency. So it is used in a noninteractive way even though by default wish momentarily displays a blank GUI before wish exits with the required version information. That works fine when I run cmake by hand to configure PLplot since for those cases I never get the above X11 authentication errors. And I can launch any X application I like (such as wish or xterm) without such authentication errors as well. In other words, my X11 authentication environment is just fine. As a result for my interactive desktop environment, running wish with execute_process and configuring PLplot always "just works". But in Nightly mode, a crontab environment obviously does not include a DISPLAY variable so any attempt to configure PLplot in that environment would encounter this same error. So I plan to drop the wish version consistency check that is currently implemented whenever the DISPLAY environment variable is not set, and I am virtually positive that will fix this issue for the Nightly case. However, it appears this planned change will NOT fix the issue for the above Experimental case because I am pretty sure DISPLAY was defined internally when the above ctest command was being executed (because the error message referred to "localhost:10.0" which is the same as the DISPLAY environment variable set before the above ctest command was executed). So if that proves to be the case, I also plan to drop the wish-based version consistency checks when a particular PLplot build-system option is set, and also set that option for the Experimental case. Of course, if that additional fix (beyond the DISPLAY check) is necessary it smacks of a workaround for some X11 authentication issue for the CMake contract testing environment for the Experimental case so I thought I should bring that issue to your attention just in case there is an easy solution you could implement for that issue. 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
Re: [cmake-developers] PLplot contract test
On 2017-11-06 11:01-0500 Brad King wrote: On 10/30/2017 11:38 AM, Brad King wrote: FYI I'm refactoring the way the existing contract tests work to make it easier to add and maintain one for PLplot. Once that is done I'll look at actually adding PLplot and report back here. I've opened a MR to add the PLplot contract test here: * https://gitlab.kitware.com/cmake/cmake/merge_requests/1452 Please revise your dashboard script to add the following line to the `dashboard_cache` setting: ``` CMake_TEST_CONTRACT_PLplot:BOOL=ON ``` The MR is already staged so this should activate the contract test on the next build after you update the script. Hi Brad: I followed the above directions in Experimental mode (and also they will be followed later in Nightly mode as well). But I can see nothing related to a PLplot git checkout, configuration or build in the Experimental mode results, see <https://open.cdash.org/viewTest.php?onlypassed=5131552>. Is there something I have missed in those results or something wrong? 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] PLplot contract test
Hi Brad: If you look at <https://open.cdash.org/viewTest.php?onlypassed=5122233> it superficially appears that some of the tests (e.g., BootstrapTest) are timing out. But if you look deeper, the output from the test is being truncated because it is over the rather small 1024 default limit. I have checked the aaargh.kitware.com dashboard, and the BootstrapTest results for that case do not show this issue, i.e., they are quite large and clearly beyond the 1024 default limit so I suspect what has occurred for aaargh.kitware.com is this problem has been corrected on an individual basis. Could I do that for the raven results by, e.g., set(CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE 10240) set(CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE 10240) in my my_dashboard.cmake file or is the fix for this truncation issue more complex than that? In any case I suggest it would be better for you to implement the fix for this issue in cmake_common.cmake so those who submit CMake dashboards don't have to fix this issue individually. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] PLplot contract test
On 2017-10-27 07:02-0400 Brad King wrote:
On 10/26/2017 09:58 PM, Alan W. Irwin wrote:
However, one of the deficiencies of this third method is the
bootstrap script only pays attention to CXXFLAGS and CFLAGS when
setting compile flags for building the preliminary version of CMake
[...]
You could do this to apply flags to bootstrap and configuration
steps but not to the tests:
```
set(ENV{CXXFLAGS} "-O3 -DNDEBUG")
set(ENV{CFLAGS} "-O3 -DNDEBUG")
set(CTEST_BUILD_CONFIGURATION "")
macro(dashboard_hook_build)
unset(ENV{CXXFLAGS})
unset(ENV{CFLAGS})
endmacro()
```
Thanks for that idea which I have adopted (using
set(CTEST_BUILD_CONFIGURATION "Release")). It generates perfect
dashboards (see the Experimental raven result for today).
Should at least some of these considerations concerning CXXFLAGS and
CFLAGS (e.g., they normally should be unset to assure a standard build
configuration corresponding to CTEST_BUILD_CONFIGURATION) be
documented in comments in cmake_common.cmake?
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__
Linux-powered Science
__
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Need more information concerning the Trilinos test of CMake
On 2017-10-25 07:03-0400 Brad King wrote: On 10/24/2017 05:47 PM, Alan W. Irwin wrote: Since I essentially never get CMake build errors when building CMake by hand using the bootstrap method, I assume these build errors are due to some issue with how I set up my_dashboard.cmake. The difference is that the script is testing the nightly stage of in-flight topics that have not yet landed in `master`. You just happened to run this for the first time on one of the occasional nights that compiler errors were introduced. Hi Brad: Yes, I sure picked the exact moment of the day where my dashboard was the first to show the build error for g++ versions of 4.9 or less, but, of course, a number of other old compiler sites followed at the times when they completed their nightly tests. I notice in <https://gitlab.kitware.com/cmake/cmake/merge_requests/1402> there is an unstage comment from you. Just out of curiosity, does that mean that commit was effectively immediately removed from stage/master/head? In any case, my dashboard submission is working now using ctest -S ~/cmake/Dashboards/Scripts/CMakeScripts/my_dashboard.cmake -VV See the raven-without-fixed-IP Experimental results at <https://open.cdash.org/index.php?project=CMake> and <https://open.cdash.org/index.php?project=KWSys>. These results are perfect other than one CMake configure warning due to a minor system issue (misspelled COPYONLY as COPY_ONLY) with Debian Jessie Qt5 which I encounter for all my builds of cmake by hand and which has long since been fixed for more modern versions of Qt5. So what is the next step toward the goal of adding a test consisting of a build of PLplot? Alan ______ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Need more information concerning the Trilinos test of CMake
On 2017-10-24 17:24-0700 Alan W. Irwin wrote: Note the rest of the results at <https://open.cdash.org/index.php?project=CMake> appear to have no build errors like the ones demonstrated on my (Debian Jessie) system which is why I mentioned my g++ version above. Oops. I forgot to include that information so for the record that is g++ (Debian 4.9.2-10). Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Need more information concerning the Trilinos test of CMake
@Matthias:
I am directly addressing you in this post because git bisect says your
recent commit is the first one that shows this issue. More details below.
On 2017-10-24 14:47-0700 Alan W. Irwin wrote:
Hi Brad:
While waiting for your reply to my question concerning how to specify
bootstrap script options, I decided to not specify those additional
options for my initial try. I submitted that (Experimental) test by hand
using
ctest -S -V >& ctest.out1.
The result (which was a build error) is given at
<https://open.cdash.org/viewBuildError.php?buildid=5114481>.
Since I essentially never get CMake build errors when building
CMake by hand using the bootstrap method, I assume these build
errors are due to some issue with how I set up my_dashboard.cmake.
Here is the full text of that file:
# Client maintainer: air...@users.sourceforge.net
set(CTEST_SITE "raven home computer")
set(CTEST_BUILD_NAME "Linux-gcc")
#set(CTEST_BUILD_CONFIGURATION Debug)
set(CTEST_CMAKE_GENERATOR "Unix Makefiles")
# Additional variables to set before include:
set(dashboard_model Experimental)
set(CTEST_BUILD_FLAGS -j4)
include(${CTEST_SCRIPT_DIRECTORY}/cmake_common.cmake)
The above -V results from ctest had very little detail about the
build error. If you don't see anything obvious I should change in
my_dashboard.cmake, would you like me to run ctest -S again with
-VV?
For what it is worth, another difference with how I normally build
cmake is I specified (by accident) the environment variables
CXXFLAGS=-O3 -fvisibility=hidden -Wuninitialized
CFLAGS=-O3 -fvisibility=hidden -Wuninitialized
for this build while for my normal builds I just use -O3 for both flags.
Also, as you can see above I did not specify
CTEST_BUILD_CONFIGURATION, but unlike normal builds it appears for
this script that the Debug configuration is the default. How do I
turn that off?
Here is some critical information concerning this build issue that I
have gained since the above post:
The version of cmake source that generated the build error for me was
commit 8c5050835 from the (current) HEAD of stage/master/head
Running the bootstrap script for that version by hand
lead to exactly the same "array used as initializer" errors as
in my dashboard submission. Doing the same thing for v3.10.0-rc3 did not show
that build error.
git bisecting between those two commits found
commit 49287eed2bf9860919a155af848e7cf49d45f504
Author: Matthias Maennich <matth...@maennich.net>
Date: Mon Oct 9 16:25:52 2017 +0200
CommandArgumentParser: avoid strcpy usage
as the first commit that had the bootstrap issue.
Note the rest of the results at
<https://open.cdash.org/index.php?project=CMake> appear to have no
build errors like the ones demonstrated on my (Debian Jessie) system
which is why I mentioned my g++ version above.
@Brad and Matthias:
If there is any further test you would like me to run concerning this
build issue, please let me know.
Returning to the original topic, I assume once this CMake build issue
is addressed, that my dashboard submission will start working but I
am still interested in the answers to my questions concerning how
to specify boostrap options, and how to turn off Debug builds
via my_dashboard.cmake.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__
Linux-powered Science
__
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Need more information concerning the Trilinos test of CMake
Hi Brad:
While waiting for your reply to my question concerning how to specify
bootstrap script options, I decided to not specify those additional
options for my initial try. I submitted that (Experimental) test by hand using
ctest -S -V >& ctest.out1.
The result (which was a build error) is given at
<https://open.cdash.org/viewBuildError.php?buildid=5114481>.
Since I essentially never get CMake build errors when building
CMake by hand using the bootstrap method, I assume these build
errors are due to some issue with how I set up my_dashboard.cmake.
Here is the full text of that file:
# Client maintainer: air...@users.sourceforge.net
set(CTEST_SITE "raven home computer")
set(CTEST_BUILD_NAME "Linux-gcc")
#set(CTEST_BUILD_CONFIGURATION Debug)
set(CTEST_CMAKE_GENERATOR "Unix Makefiles")
# Additional variables to set before include:
set(dashboard_model Experimental)
set(CTEST_BUILD_FLAGS -j4)
include(${CTEST_SCRIPT_DIRECTORY}/cmake_common.cmake)
The above -V results from ctest had very little detail about the
build error. If you don't see anything obvious I should change in
my_dashboard.cmake, would you like me to run ctest -S again with
-VV?
For what it is worth, another difference with how I normally build
cmake is I specified (by accident) the environment variables
CXXFLAGS=-O3 -fvisibility=hidden -Wuninitialized
CFLAGS=-O3 -fvisibility=hidden -Wuninitialized
for this build while for my normal builds I just use -O3 for both flags.
Also, as you can see above I did not specify
CTEST_BUILD_CONFIGURATION, but unlike normal builds it appears for
this script that the Debug configuration is the default. How do I
turn that off?
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__
Linux-powered Science
__
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Need more information concerning the Trilinos test of CMake
On 2017-10-13 14:58-0400 Brad King wrote: On 10/13/2017 12:08 AM, Alan W. Irwin wrote: Accordingly Bill Hoffman suggested to me off-list some time ago that I configure a CMake dashboard submission that builds the master HEAD CMake version and tests it with a build and test of PLplot similarly to what is done for Trilinos. Could someone here please confirm that code is a good model for what I should set up in the PLplot case? Yes, that makes sense. It will help catch regressions in PLplot early. The first step is to get a normal CMake nightly build working. See instructions here: https://gitlab.kitware.com/cmake/cmake/blob/master/Help/dev/testing.rst Hi Brad: Thanks for your reply to my question. I have just now started looking at the above instructions. It appears cmake_common.cmake only provides the capability of changing the --parallel option for the bootstrap script. Must I change that script in order to specify additional bootstrap options I normally use such as --qt-gui --system-curl or is there a less brute-force way to specify bootstrap options? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Need more information concerning the Trilinos test of CMake
A PLplot configure, build, and test is an excellent indirect test of modern CMake because PLplot currently uses cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR) and has a relatively small and fast build but with a rather complex build system for its size that has been developed over the course of the last decade. Accordingly Bill Hoffman suggested to me off-list some time ago that I configure a CMake dashboard submission that builds the master HEAD CMake version and tests it with a build and test of PLplot similarly to what is done for Trilinos. But I am only getting around to this now, and all I can find in the CMake source code with regard to Trilinos is Tests/Contracts/Trilinos. Could someone here please confirm that code is a good model for what I should set up in the PLplot case? Assuming that is the case, and I modify my local CMake git repository to add the required files in Tests/Contracts/PLplot and build that modified CMake, how would I submit an Experimental CMake dashboard to test my work? Or more directly, how would I submit an Experimental CMake dashboard to test the existing Trilinos case? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] CMake-3.10.0-rc2 yields good comprehensive test results for PLplot
I just completed a comprehensive test of PLplot on Linux (Debian Jessie) using a cmake version that I built myself from the CMake-3.10.0-rc2 source code using the bootstrap method. The result was a complete success for the three different PLplot build systems (CMake-based build systems for the core build and installed examples, and a CMake-configured traditional [Makefile + pkg-config] build system for the installed examples) and the 3 major PLplot build configurations (shared libraries/dynamic devices, shared libaries/nondynamic devices, and static libraries/nondynamic devices). So from the PLplot perspective, CMake-3.10.x is looking quite promising. For further details of this comprehensive test, see the "Tested by" stanza of the git log for PLplot commit 6906798 <https://sourceforge.net/p/plplot/plplot/ci/69067983c65013058cfbe4cf047f0817f1933d37/>). 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Future of ccmake and cmake-gui and internationalization
On 2017-08-17 08:55-0700 Eric Wing wrote: On 8/17/17, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: On 2017-08-17 04:15-0700 Eric Wing wrote: I hope I'm doing this right...but the resulting program I think looks correct testing on my Mac. Attached are two pictures. The first is a simple label in a window. The second is from your MessageBox line. Yes, I confirm those two PNG images have that Arabic Peace word rendered in the correct right-to-left order. So that settles the question for what I assume is your Mac OS X native graphics back end. Can you (or some other IUP developer) do that same simple test for Linux native graphics (probably GTK+) backend and native Windows graphics backend? Alan ___ I think it works. Attached are screenshots from Ubuntu 12.04LTS with the GTK2 backend, and Windows. I confirm that (rho-like character rendered on the left, omega-like character rendered on the right) which should put this CTL concern to rest. Thanks for your help answering this critical question (from my perspective) for the three separate platforms. By the way, could you let me know if/when your CMake-based build system is completed to your satisfaction and ideally accepted into official IUP? I am prejudiced toward using CMake-based build system alternatives whenever possible so official acceptance by IUP developers of your build-system work will likely be the occasion when I first give an IUP build a try. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Future of ccmake and cmake-gui and internationalization
On 2017-08-17 04:15-0700 Eric Wing wrote: I hope I'm doing this right...but the resulting program I think looks correct testing on my Mac. Attached are two pictures. The first is a simple label in a window. The second is from your MessageBox line. Yes, I confirm those two PNG images have that Arabic Peace word rendered in the correct right-to-left order. So that settles the question for what I assume is your Mac OS X native graphics back end. Can you (or some other IUP developer) do that same simple test for Linux native graphics (probably GTK+) backend and native Windows graphics backend? 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Future of ccmake and cmake-gui
On 2017-08-17 19:29+0930 Simon Lees wrote: On 17/08/17 19:01, Jean-Michaël Celerier wrote: And Mac doesn't have configure/autotools by defaul. but... "configure" has nothing to do with autotools. It's just a shell script (which is sometimes generated *from* autotools; this is not the case with Qt AFAIK). Yes Qt's configure is a stand alone script unrelated to autotools. Qt uses its own build system thats shipped with it. I can confirm that. Also, I have built Qt5 a couple of times, and I was not particularly happy with the regidity of their build system when attempting to drop components I was not using. And I was also not happy with how the options for that configuration script changed so drastically from one Qt5 version to the next. So it is always a big disappointment to me that Qt5 does not have a flexible, user-friendly CMake-based build system following what the KDE developers have done for years. So this is another "minor" project for Alex. :-) 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Future of ccmake and cmake-gui and internationalization
On 2017-08-16 23:27-0700 Eric Wing wrote:
Thanks to your post the possibility now exists that I or one of my
PLplot colleagues will develop an IUP-based device driver in the
intermediate future. So if that occurs I would plan to download and
build IUP for myself on Linux. And that would put me in a position to
do the above simple test myself. But that is in the speculative
future and only for the GTK+ backend case. So your test results now
on this unicode and CTL question for as many of the IUP backends as
possible would be much appreciated.
I'll be honest, string encodings are not my strong suit. What I can
say is that IUP is developed in Brazil where they speak Portuguese. So
I know being able to at least support their language is important to
them, so I hope that means they got a lot of the string encoding stuff
right. For the Cocoa implementation, IUP has a mode called UTF8 mode
and I am basically enforcing that it is on for Mac. For every C string
I have to bridge, I hand it to the native Cocoa UTF8 APIs that convert
back and forth between C strings and NSStrings (native Cocoa string
type). I did have some fellow Cocoa devs review my code and run a few
tests, and they believed it was correct. Though it was not exhaustive.
If the implementation is wrong, I would like to correct it.
Hi Eric:
I knew nothing about UTF-8 and unicode ~10 years ago, but it is
essential developer knowledge that is well worth having (even if you
only have knowledge of one human language, which is my case).
Furthermore, it is actually quite simple to pick up this unicode and
CTL knowledge these days (compared to a decade ago). The reason for
that simplicity is for any decent editor such as emacs or vi you can
cut and paste any UTF-8 string right from any website directly into
your source code, and it normally "just works".
So my advice to test your Mac OS backend for CTL capability is instead of the
simple test case
given at
<http://webserver2.tecgraf.puc-rio.br/iup/en/tutorial/tutorial2.html>
use instead
#include
#include
int main(int argc, char **argv)
{
IupOpen(, );
IupMessage("Hello World 1 ﺳﻼم", "Hello world from IUP ﺳﻼم.");
IupClose();
return EXIT_SUCCESS;
}
where the only change I have made to the original is I have appended the utf-8 encoded
"ﺳﻼم" to each of those
IupMessage string arguments.
If your mailer is not unicode or CTL aware so you cannot see that
utf-8 encoded Arabic Peace word in this e-mail, cut and paste that
word from the third word in the line that starts with "Pace" in
<http://www.columbia.edu/~fdc/pace/> into the two IupMessage string
arguments.
Then build that modified app and see whether the GUI renders that word
in the same character order that word is rendered by your browser for
<http://www.columbia.edu/~fdc/pace/>. (Browsers such as firefox and
konqueror are typically the gold standard for being CTL-aware.)
If that rendering is in the correct order (right-to-left) as given by
firefox you have passed this simple CTL support test for
whichever backend you are using.
Also, you can test the CTL capability of cmake-gui (as well as the
cmake application) by using
option("ﺳﻼم" "ﺳﻼم" ON)
in a simple test project where those two utf-8 strings are cut and
pasted from the above "pace" website. The result of that test here is
the letters in those words are rendered in the same order as in the
above "pace" website both in the GUI (for the cmake-gui case) and in
CMakeCache.txt (for both the cmake and cmake-gui cases). And, of
course, if/when an IUP-based cmake-gui is developed, the same CTL test
should be applied to that result as well.
Note also, you don't have to limit your tests just to the word
for Peace in Arabic. For example, there are some good test
words in <https://en.wikipedia.org/wiki/Complex_text_layout> that
can be cut and pasted.
Finally, in my last post I stated that it would be bad news for IUP if
any of its backends failed the CTL test, but in retrospect that is too
strong a statement. For example, if the CTL capabilities of IUP are
fine for GTK+, Windows, and Mac OS X backends, but the Motif backend
(used on commercial Unices) is not capable of CTL, then that only
affects the internationalization capabilities of cmake-gui for a
minority platform (Commercial Unices). And given that the only bad
result if CTL fails is the characters are rendered in the wrong order
in the cmake-gui GUI display (with the CMakeCache.txt result
completely unaffected), I think that rendering failure in that Motif
corner case would be completely acceptable. Of course, CTL rendering
failure is a more serious problem if it occurs for any of the majority
platforms (i.e., Linux GTK+, Windows, or Mac OS X). However, I am
pretty sure that CTL should be well supported by IUP on each of those
3 platforms, and if you can confirm that it should be suffi
Re: [cmake-developers] Future of ccmake and cmake-gui and internationalization
cgraf.puc-rio.br/iup/ and it appears from those 10 hits that IUP completely supports the utf-8 encoding of unicode and since CTL capability is completely in the domain of the backend libraries, I am virtually positive that IUP supports both unicode and CTL for at least its GTK+ backend and likely its Windows backend. However, since those capabilities are so important (at least in my opinion) to cmake-gui can you please confirm this positive speculation concerning IUP for these two backends for me (and also your new Mac OS X backend). That test simply requires you to modify the first IUP tutorial example to use "ﺳﻼم" to see whether that Arabic word is rendered in the correct right-to-left order in the IUP GUI. Also, if the other IUP backends such as Motif and Haiku don't deal with the CTL issue properly, then I think that would be a fairly important justification for sticking with Qt instead for cmake-gui. Thanks to your post the possibility now exists that I or one of my PLplot colleagues will develop an IUP-based device driver in the intermediate future. So if that occurs I would plan to download and build IUP for myself on Linux. And that would put me in a position to do the above simple test myself. But that is in the speculative future and only for the GTK+ backend case. So your test results now on this unicode and CTL question for as many of the IUP backends as possible would be much appreciated. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] UseSWIG and enable_language(Java)
On 2017-08-01 16:29-0400 Brad King wrote:
On 07/26/2017 06:02 AM, Alan W. Irwin wrote:
[...]
62c4cb4b6f0cdb2be2729362133f850d6fe96c20 is the first bad commit
UseSWIG: Record generated java files as custom command outputs
Hmm. That causes swig_add_library's call to add_library to include
the generated .java source file as a source (since it is the
output of a custom command we want to run).
However, with `enable_language(Java)` CMake thinks it is supposed
to compile the .java file as part of the (module) library. That's
why it looks for CMAKE_Java_CREATE_SHARED_MODULE.
Please try the patch below.
diff --git a/Modules/UseSWIG.cmake b/Modules/UseSWIG.cmake
index 456a6bd63d..48d6a5b4af 100644
--- a/Modules/UseSWIG.cmake
+++ b/Modules/UseSWIG.cmake
@@ -121,8 +121,9 @@ macro(SWIG_GET_EXTRA_OUTPUT_FILES language outfiles
generatedpath infile)
endif()
foreach(it ${SWIG_${language}_EXTRA_FILE_EXTENSIONS})
-set(${outfiles} ${${outfiles}}
- "${generatedpath}/${SWIG_GET_EXTRA_OUTPUT_FILES_module_basename}${it}")
+set(extra_file
"${generatedpath}/${SWIG_GET_EXTRA_OUTPUT_FILES_module_basename}${it}")
+list(APPEND ${outfiles} ${extra_file})
+set_property(SOURCE "${extra_file}" PROPERTY LANGUAGE "")
endforeach()
endmacro()
Hi Brad:
Thanks for your response.
Yes, that patch works for PLplot. In particular, our multiple sets of
~30 standard examples written in Python, Java, and ~10 other languages
produce the same PostScript plot files as the corresponding set of
standard examples written in C. So that is a pretty good test.
Furthermore, if I am understanding its logic correctly this patch
empties the LANGUAGE property for these extra Java and Python files to
force these files NOT to be compiled (which would make no sense in any
case because swig-generated bindings are implemented as C or C++
modules). That forcing is actually not needed in the Python case
because Python is a scripting language, but that forcing is needed for
Java precisely because that language can be compiled. So my
understanding of the purpose of this patch is consistent with my
experience (our Python binding works regardless of whether this patch
is applied or not and our Java binding only works when the patch is
applied). However, if I got something wrong in this explanation of
the patch, please correct!
Assuming you are going to commit this patch is it something that
needs further extensive testing or will it go into one of the
CMake-3.9.x releases?
Second related topic:
[out of order]
enable_language(Java)
FWIW this language support is quite limited, is not well tested,
and has long been superseded by `UseJava.cmake`. I suggest porting
away from it in PLplot.
Let me give you some additional PLplot use case background information
before commenting on your suggestion.
I haven't been paying much attention to the java-related part of our
build system since it was almost entirely implemented a decade ago and
normally it has "just worked" during that time. But a quick review of
it now indicates it is quite primitive (probably because of the
limited CMake Java support a decade ago). It uses
${CMAKE_Java_COMPILER} (which is set to /usr/bin/javac for my current
system) in a custom command to compile *.java files into *.class files
for both our Java binding and Java examples. Collecting all those
binding and examples *.class results into a jar file using
${CMAKE_Java_ARCHIVE} (which is set to /usr/bin/jar for my current
system) is an afterthought.
Apparently, both CMAKE_Java_COMPILER and CMAKE_Java_ARCHIVE are determined
when our build system executes "enable_language(Java)". So that
command is required at the moment. But I think we are only using its
find capabilities so we could simply drop using it and
substitute instead the appropriate find commands to find the needed
javac and jar directly or call find_package(Java) to do the same.
So that is likely what I will implement in the short term to
avoid any other issues with the poorly supported
"enable_language(Java)" command.
It also appears from the UseJava.cmake documentation, that that module
allows us to build our jar file directly, thus allowing replacement of
all those primitive custom commands. But making that change appears
to be quite a bit of work, and there is no urgency for switching since
we have the above alternative. But if the required CMake code is truly
at lot higher level and therefore more compact, then we should
consider trying this suggestion in the long term, although see below.
Different, but related third topic:
PLplot developers might want to implement an option to use gcj
directly without the -C option (rather than its javac wrapper which
always uses the gcj -C option) to compile our *.java files into
ordinary machine object code that is stored in an ordinary library. Of
course, modifying our present primitive approach to do that
Re: [cmake-developers] Java language support regression (compared with 3.7.x and 3.8.x) for 3.9.0
Here is a spin-off topic from this thread which I believe may be of general interest. Bill Hoffman contacted me off list about the possibility of testing cmake with a build of a rapidly changing CMake corresponding to the tip of your release branch or possibly one of your development branches AND a corresponding build of a slowly changing PLplot (say change it once per release of PLplot) for each such CMake version. That is a good idea because the PLplot build is fast. For example, the build of the "all" target (including all our standard examples for our supported compiled languages) was completed in only 1 minute 40 seconds (with the aid of ccache) in a recent "make all" test. Even more importantly despite this quick build, the CMake-based build system for PLplot (which we have been developing for the last decade) is quite complex. That is, that build system has to find many soft dependencies of PLplot (almost entirely generated by our various optional device drivers), configure the build of our ~5 libraries, configure the build of the PLplot bindings for our ~10 supported computer languages, configure the build of ~30 standard examples written in each of our supported computer languages for the subset of those languages which are compiled, configure the build for ~15 PLplot device drivers (typically configured as shared objects or DLL's that are dynamically loaded by the core PLplot library if/when needed but another configuration is also possible where the device code is compiled directly into our core library), and configure many separate test targets as well as ctest examples. Because of these excellent PLplot project characteristics for CMake testing purposes, Alex Neundorf set up a combined CMake build and PLplot build test nearly a decade ago, but I assume that no longer exists (although I have asked Bill to search for it, and maybe Alex can comment as well on that CMake history back near the time when the earth was still cooling. :-) ). In any case, the ctest and dashboard server facilities we have now are much better than they were a decade ago, and I am consulting with Bill about the best way to use those facilities properly to set up a new version of Alex's test. And when that nightly test (currently in the very early planning stages) consisting of a CMake build + PLplot build goes live, I think it will be a noticeable improvement in the CMake testing process that will benefit not only the CMake project, but also the PLplot project. Anyhow, Bill and I both hope this test will very much reduce or eliminate instances like the present one where a CMake issue first introduced in 3.8.0 RC's somehow slipped through the cracks of all the normal continuous automatic testing of CMake (see new test suggestion for UseSWIG.cmake in my previous post in this thread). Of course, I am partially responsible for this situation as well because my near-constant testing of PLplot typically occurs for a fixed version of CMake that I rarely have time to change since such change does require a time-consuming build of CMake. Fortunately, the rarety of my CMake version changes used for my PLplot testing will no longer be a problem when the planned continuous integration test goes live so I am really looking forward to that. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Java language support regression (compared with 3.7.x and 3.8.x) for 3.9.0
On 2017-07-25 17:48-0700 Alan W. Irwin wrote:
More later on those git bisect results when that process is completed.
As per usual, git bisect (along with ccache to speed up the process by
a noticable amount especially in the last 5 steps or so) is awesome.
Here is what it found:
62c4cb4b6f0cdb2be2729362133f850d6fe96c20 is the first bad commit
commit 62c4cb4b6f0cdb2be2729362133f850d6fe96c20
Author: caryoscelus <caryosce...@gmx.com>
Date: Mon Nov 28 21:46:41 2016 +0300
UseSWIG: Record generated java files as custom command outputs
When another target depends on the generated files CMake must know which
custom command generates them in order to hook up the dependency
properly. We already do this for Python. Add the Java files too.
:04 04 0ba5ac99776eb3c196dfe7639dcf6c47711cd204
135152a2f7229d2a2f63cded6617c5b30f40e9d8 M Modules
software@raven> git describe
v3.7.0-651-g62c4cb4
The file differences introduced by that change were quite small:
software@raven> git diff 62c4cb4b6f0^ 62c4cb4b6f0
diff --git a/Modules/UseSWIG.cmake b/Modules/UseSWIG.cmake
index c5912f8..651f9f1 100644
--- a/Modules/UseSWIG.cmake
+++ b/Modules/UseSWIG.cmake
@@ -57,7 +57,8 @@
set(SWIG_CXX_EXTENSION "cxx")
set(SWIG_EXTRA_LIBRARIES "")
-set(SWIG_PYTHON_EXTRA_FILE_EXTENSION "py")
+set(SWIG_PYTHON_EXTRA_FILE_EXTENSIONS ".py")
+set(SWIG_JAVA_EXTRA_FILE_EXTENSIONS ".java" "JNI.java")
#
# For given swig module initialize variables associated with it
@@ -123,9 +124,9 @@ macro(SWIG_GET_EXTRA_OUTPUT_FILES language outfiles
generatedpath infile)
endif ()
endif()
- foreach(it ${SWIG_${language}_EXTRA_FILE_EXTENSION})
+ foreach(it ${SWIG_${language}_EXTRA_FILE_EXTENSIONS})
set(${outfiles} ${${outfiles}}
- "${generatedpath}/${SWIG_GET_EXTRA_OUTPUT_FILES_module_basename}.${it}")
+ "${generatedpath}/${SWIG_GET_EXTRA_OUTPUT_FILES_module_basename}${it}")
endforeach()
endmacro()
UseSWIG.cmake is a complex beast, and I frankly don't understand it.
However, for CMake-3.9.0 I tried simply commenting out
set(SWIG_JAVA_EXTRA_FILE_EXTENSIONS ".java" "JNI.java")
in the installed version of UseSWIG.cmake
and that workaround completely solved the CMake-time issue for PLplot!
Furthermore, when I built our test_diff_psc target (which exercises
our ~30 standard examples written in ~10 different computer languages
and compares the generated PostScript plot results for corresponding
examples in each language, the Java part of that test was perfect,
i.e., each of its standard examples written in Java produced the exact
same result as the corresponding standard example written in C.
To help with finding a real fix for this issue rather than the above
workaround, I have finally came up with a simple test project
that demonstrates the issue.
cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR)
project(test_java C)
find_package(SWIG)
include(UseSWIG)
enable_language(Java)
# As a simple test of missing Java language support variables try and
# configure a build of a Java module or library from an empty *.i file
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/test_java.i "")
swig_add_library(test_java TYPE MODULE LANGUAGE java SOURCES
${CMAKE_CURRENT_BINARY_DIR}/test_java.i)
I suggest this test project should be used as a template (possibly
with several other languages substituted for Java, NONE substituted
for C, and TYPE SHARED substituted for MODULE). Anyhow, here is the
cmake command output for this project with unpatched 3.9.0
-- The C compiler identification is GNU 4.9.2
-- Check for working C compiler: /usr/lib/ccache/cc
-- Check for working C compiler: /usr/lib/ccache/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Found SWIG: /usr/bin/swig2.0 (found version "2.0.12")
-- Configuring done
CMake Error: Error required internal CMake variable not set, cmake may not be
built correctly.
Missing variable is:
CMAKE_Java_CREATE_SHARED_MODULE
-- Generating done
-- Build files have been written to: /home/software/plplot/HEAD/build_dir
If the CMake-3.9.0 installed UseSWIG.cmake file is patched (by
commenting out the line in that file,
set(SWIG_JAVA_EXTRA_FILE_EXTENSIONS ".java" "JNI.java")
), then the initial cmake output is the same, but the final few lines are
-- Found SWIG: /usr/bin/swig2.0 (found version "2.0.12")
-- Configuring done
-- Generating done
-- Build files have been written to: /home/software/plplot/HEAD/build_dir
So from these two different results, the conclusion is the above simple project
file
recreates the bad PLplot results for unpatched CMake-3.9.0 and the good
PLplot results for patch
Re: [cmake-developers] Java language support regression (compared with 3.7.x and 3.8.x) for 3.9.0
On 2017-07-25 15:00-0700 Alan W. Irwin wrote: I was hoping some CMake developer here could remember a fairly recent language support infrastructure change in the run-up to 3.9.0 that is likely causing this issue, and better yet could immediately think of the Java language support changes that would need to be made to be consistent with that hypothesized language support infrastructure change. But if nobody gets back to me on that question soon, then I will go ahead and do a git bisect to help find the commit where the Java language support issue first showed up. Oops. I discovered during the initial stages of that git bisect process that 3.8.0-rc4 is bad while 3.7.2 is good when using the latest git master branch version of PLplot. That result surprised me (since I do recall testing 3.8.0-rc4/ without issues), So my testing of 3.8.0-rc4 may not have included java or some PLplot change between that test and now may be affecting this good/bad result (although I think that is fairly unlikely because I don't recall any specific java-related PLplot changes during that period), Anyhow, I am now bisecting between CMake 3.7.2 and 3.8.0-rc4 using a consistent PLplot version (the tip of our master branch) that is quite well tested for CMake-3.7.2. And if anyone here is attempting to remember relevant language support changes, you should be thinking about the period between 3.7.2 and 3.8.0-rc4. More later on those git bisect results when that process is completed. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Java language support regression (compared with 3.7.x and 3.8.x) for 3.9.0
n, then I will go ahead and do a git bisect to help find the commit where the Java language support issue first showed up. (I have been reluctant to spend the fairly substantial time to do that git bisect up to now because I was fairly confident someone would respond on that particular hypothesis, and most of my time right now is consumed with dealing with some late release-cycle issues with PLplot.) Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Java language support regression (compared with 3.7.x and 3.8.x) for 3.9.0
I have built CMake-3.9.0 on my Linux (Debian Jessie) platform using
the bootstrap method I have always successfully used for other CMake
versions (including 3.7.2).
For a complex project (PLplot) which uses swig_add_module and
swig_link_libraries to implement our Java binding, I get the following
error message at the end of that CMake-3.9.0 output.
-- Configuring done
CMake Error: Error required internal CMake variable not set, cmake may
not be built correctly.
Missing variable is:
CMAKE_Java_CREATE_SHARED_MODULE
-- Generating done
-- Build files have been written to:
/home/software/plplot/HEAD/build_dir
I don't get this error message for CMake-3.7.2.
Using find and xargs -0 grep I have looked in both 3.7.2 and 3.9.0
source code for any mention of CMAKE_Java_CREATE_SHARED_MODULE, and it
just does not exist.
By the way, I have tried the following simple project.
cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR)
project(test_java NONE)
enable_language(Java)
message(STATUS "CMAKE_Java_CREATE_SHARED_MODULE =
${CMAKE_Java_CREATE_SHARED_MODULE}")
(I used 3.6.2 for the minimum version because that is what PLplot uses).
That project does confirm that both 3.7.2 and 3.9.0 do not define
CMAKE_Java_CREATE_SHARED_MODULE. However, both versions failed to
generate the above error so a more complex project such as PLplot
that, e.g., swig-generates a Java binding for a C library is needed to
show the issue.
By the way, inserting the following lines in the PLplot top-level
CMakeLists.txt file
# Temporary workaround for Java language support issue for
# CMake-3.9.0
set(CMAKE_Java_CREATE_SHARED_MODULE "this_command_should_never_be_used")
has no bad consequences for cmake-3.7.2, i.e., I can build our Java
binding and run all our standard Java examples. However, for the
3.9.0 case, the above change avoids the cmake issue, but there are
many JNI-related build errors for our Java binding (although none
of them mention "this_command_should_never_be_used").
The only cmake-3.8.0 version I have built previously is one of the
release candidates. But that passed all tests at the time including
building our Java binding and running our Java examples with success
so this appears to be a newly introduced issue for 3.9.0.
From these symptoms, I am pretty sure that language support infrastructure
has been upgraded for 3.9.0, but your Java
language support has not been consistently upgraded at the same time.
If so, the solution is either downgrade your language support
infrastructure to be consistent with CMake-3.8.x or to upgrade your
Java language support to be consistent with your updated language
support for 3.9.0.
Once someone has a patch for this issue I would be happy to test it by
rebuilding a patched version of CMake-3.9.0 and trying out a build of
PLplot with that patched version.
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:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Advantages and disadvantages in blowing away CMAKE_MODULE_PATH
On 2017-05-25 15:01-0400 Chuck Atkins wrote: The typical use case is when your package is being used as a third party library by somebody else. There are many different ways that could be done but for small dependencies, a typical approach is to just place the code in a subdirectory and add it to an existing build with add_subdirectory. Hi Chuck: Thanks for describing the use case you had in mind as a background to your remarks concerning why you thought blowing away CMAKE_MODULE_PATH was not ideal. However, although the CMake software project itself does integrate software from other projects into the CMake project, and I assume there are also other well-known examples, I suspect that use case is uncommon in general (at least on Unix systems where the culture positively encourages keeping every software package as independent as possible from every other software package.) Furthermore, projects blowing away CMAKE_MODULE_PATH by setting that variable in their top-level CMakeLists.txt file do have the one advantage I alluded to which is this approach precludes users of such projects from using that variable to point to an inappropriate set of find modules. And, as you mentioned, blowing away the variable simply means that projects which integrate your software have one additional one-line change to make. So it appears there is a relatively small advantage to blowing away CMAKE_MODULE_PATH and a relatively small disadvantage as well. On balance I think I will continue with our present "blow-away" approach, but this is a decision developers of each project need to make for 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Problems with external language support when there is a blank in CMAKE_MODULE_PATH
So my guess is the measures that have been used so that a blank in the fullpath name works fine for CMake language support files that are installed by CMake have not been extended to the case where CMAKE_MODULE_PATH must be used to find the language support files. I forgot to mention that the PLplot project also uses CMAKE_MODULE_PATH to find the find modules we have implemented. That use case works without issues when CMAKE_MODULE_PATH has a blank in the full pathname. So such a blank only appears to be an issue when CMAKE_MODULE_PATH is used to find language support files. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Problems with external language support when there is a blank in CMAKE_MODULE_PATH
I have been systematically testing PLplot builds for any issues with blanks in the prefix of the source, build, and install trees, and generally all is well under these test conditions. However, we do have two remaining issues which are that our (external) language support for both Ada and D fails if there is a blank in the source tree prefix. Our Ada language support comes with a simple "Hello, world" test project to test for language support issues for that language, and I have attached a tarball of that simple project so you can easily replicate this "blank in source tree" issue for yourself for at least that language. This test project works fine if the tarball is unpacked in a location without blanks in the full pathname, but fails when there is a blank in that unpacked pathname. The initial error message in that latter case is CMake Error: Could not find cmake module file: CMakeAdaInformation.cmake Such external language support (e.g., in this Ada case) must necessarily set CMAKE_MODULE_PATH to help CMake find the external language support files such as CMakeAdaInformation.cmake, and that full pathname necessarily contains a blank when the tarball is unpacked in a location with a blank in the full pathname. I thought the trouble might be that CMake just did not accept blanks in the full pathname of _any_ language support files, but I tested that case (by moving a previous CMake install location to one with a blank in its full pathname), but a simple project consisting of # Test C language support cmake_minimum_required(VERSION 3.8.1 FATAL_ERROR) project(test_c C) had no issues under those conditions, i.e., with the C language support files in the /share/share/cmake-3.8/Modules/ directory tree. So my guess is the measures that have been used so that a blank in the fullpath name works fine for CMake language support files that are installed by CMake have not been extended to the case where CMAKE_MODULE_PATH must be used to find the language support files. If that is the issue, a fix would be appreciated. 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 __ test_ada.tar.gz Description: Simple test case for Ada language support -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Making your regular expression engine more reliable
I have just discovered a long-standing regular expression bug (see <https://gitlab.kitware.com/cmake/cmake/issues/16899>) that has been around since at least 3.0.2. So your unit tests for regular expressions obviously missed at least this issue. I have no idea what those unit tests are (or even if they exist), but one possibility for attempting to wring most of the bugs out of your regular expression processor is to adapt some other project's regexp test suite. See <http://stackoverflow.com/questions/15819919/where-can-i-find-unit-tests-for-regular-expressions-in-multiple-languages> for a rather large list of such test suites. Another possibility is simply to forget supporting your own regexp engine and adopt someone else's very well regarded regexp engine (such as libprng). I vaguely recall that has been suggested before, but since that hasn't happened I presume inertia or NIH syndrome won or else there was some strong reason why you didn't go that route. From my perspective as a strongly interested CMake user (but not a CMake developer or regexp guru) that wants a completely reliable regular expression engine for CMake, I don't care which of these two approaches you use to achieve that goal. But I hope my starting this topic here will facilitate reaching that 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Issues with overriding Python version, possible bug?
On 2017-05-01 08:54-0400 Brad King wrote: On 04/29/2017 04:47 PM, Alan W. Irwin wrote: looks for Python 3, but if that does not exist it looks for Python 2. find_package(PythonInterp 3) find_package(PythonInterp 2) So far so good, but I am sure there will be some of our users that prefer Python 2 even when Python 3 is installed on their system. You should use your own variable for that. The version-named executables are searched based on PythonInterp_FIND_VERSION which comes from the version number passed to find_package. The order of find_package calls and the version numbers passed to them is controlled by your project, so if you want a switch for this it should be in your project. Or, you can tell the users to pass `-DPYTHON_EXECUTABLE=/path/to/python2` to specify the desired python executable. Thanks, Brad, for that guidance. I have decided to go with our own FORCE_PYTHON2 option for this purpose. way (e.g., by setting Python_ADDITIONAL_VERSIONS) to specify the Python version they prefer. That variable is only for aiding the search for future python versions not released as of the running version of CMake, e.g. 3.12. Actually, for the find_package(PythonInterp) case, i.e., when no version specified to find_package, it does allow the user to pick Python2, for example. This is exactly consistent with the current documentation of Python_ADDITIONAL_VERSIONS which states: The Python_ADDITIONAL_VERSIONS variable can be used to specify a list of version numbers that should be taken into account when searching for Python. You need to set this variable before calling find_package(PythonInterp). Which is why I thought I might have found a bug when it failed to work when find_package specified the version. On the other hand, the name of the variable does support your interpretation. So perhaps a change to the real documentation is all that is needed here. I suggest adding this sentence to the above: Python_ADDITIONAL_VERSIONS is ignored if find_package specifies a version. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Issues with overriding Python version, possible bug?
My use case (which I am pretty sure is a common one) is that for PLplot I want the default behaviour of our build system to be that it looks for Python 3, but if that does not exist it looks for Python 2. It appears the following logic implements that desired default behaviour. find_package(PythonInterp 3) find_package(PythonInterp 2) So far so good, but I am sure there will be some of our users that prefer Python 2 even when Python 3 is installed on their system. I could implement that user choice with a special FORCE_PYTHON2 option option to allow the user to skip the first find_package command above, but if possible I would far prefer that our users used a more standard way (e.g., by setting Python_ADDITIONAL_VERSIONS) to specify the Python version they prefer. However, when I tried (for both CMake-3.6.2 and CMake-3.8.0-rc4) -DPython_ADDITIONAL_VERSIONS:STRING=2, the result was that setting was ignored, i.e., the result of the above two find_package commands was -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.4.2", minimum required is "3") -- Found PythonInterp: /usr/bin/python3 (found suitable version "3.4.2", minimum required is "2") Is this ignoring of Python_ADDITIONAL_VERSIONS for the above find_package logic due to a bug in Modules/FindPythonInterp.cmake? Is there some other standard way that the Python version can overridden by the user for the above find_package logic? (I am sorry I cannot answer either of these questions myself, but I am having real trouble following the PythonInterp module logic for the case when the default behaviour is specified via the above find_package logic.) 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] On-going UseSWIG troubles with the official versions --SOLVED
On 2017-04-25 08:54-0400 Brad King wrote:
On 04/25/2017 04:08 AM, Alan W. Irwin wrote:
set PREFIX to "" for all languages not specifically covered by the if
and elseif blocks.
Do you mean
```
diff --git a/Modules/UseSWIG.cmake b/Modules/UseSWIG.cmake
index 277f4ca28a..bfe1a6f754 100644
--- a/Modules/UseSWIG.cmake
+++ b/Modules/UseSWIG.cmake
@@ -326,6 +326,9 @@ macro(SWIG_ADD_LIBRARY name)
if (APPLE)
set_target_properties (${SWIG_MODULE_${name}_REAL_NAME} PROPERTIES SUFFIX
".bundle")
endif ()
+ else()
+# assume empty prefix because we expect the module to be dynamically loaded
+set_target_properties (${SWIG_MODULE_${name}_REAL_NAME} PROPERTIES PREFIX
"")
endif ()
endmacro()
```
?
Yes, exactly.
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:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] On-going UseSWIG troubles with the official versions --SOLVED
On 2017-04-23 14:26-0700 Alan W. Irwin wrote: [... My] further testing showed the versions of FindSWIG.cmake and UseSWIG.cmake from CMake-3.0.2 has build failures for Java and Lua, and the versions from CMake-3.6.2 and 3.8.0-rc4 have build failures for Java even though none of these "official" versions exhibited the rule contamination. I have bumped the minimum CMake version from 3.0.2 to 3.6.2 for PLplot so I am not going to worry about the Lua issue for 3.0.2. And it turned out the Java issue was simply a change in naming convention for the resulting module between my special UseSWIG.cmake and the official ones that I needed to adjust for. So that concludes this topic from the PLplot perspective. However, while researching this, I did notice one issue with the CMake git master version of Modules/UseSWIG.cmake that the CMake maintainers of that file might want to address which is the if...elseif...elseif clauses establishing the PREFIX and SUFFIX properties for each specific language language covered currently has no else clause to set PREFIX to "" for all languages not specifically covered by the if and elseif blocks. I suggest you do implement such an else cause to be consistent with older versions of UseSWIG.cmake (such as my special version) which simply set PREFIX to "" for all languages, and also consistent with the specificially covered languages where PREFIX is set to "" as well (except for the Java 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: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] On-going UseSWIG troubles with the official versions
On 2017-04-23 17:10+0200 Rolf Eike Beer wrote: The somewhat longer story is just at the start (fortunately for me) of that simplification process, I double checked the source of both FindSWIG.cmake and UseSWIG.cmake as used by PLplot, and those turned out to be special cutting-edge versions recommended by one user of the cmake bug tracking system from a decade (!) ago. Oops! Those versions did continue to work for a very long time for our simple swig needs, but those are obviously well past their "best buy" date, and complete removal of those "special" versions from PLplot (so PLplot is now using the official version of those modules that is distributed by whatever CMake version a user chooses) works without the warning messages for both CMake-3.0.2 AND CMake-3.8.0-rc4. So something in that range of versions has broken those old modules. It would be interesting to find out if that was breaking a never-really-supported case or something else. Hi Rolf: It turns out I will be following up on that question because (sigh) my further testing showed the versions of FindSWIG.cmake and UseSWIG.cmake from CMake-3.0.2 has build failures for Java and Lua, and the versions from CMake-3.6.2 and 3.8.0-rc4 have build failures for Java even though none of these "official" versions exhibited the rule contamination. And, of course, our special versions of FindSWIG.cmake and UseSWIG.cmake built our Python, Java, Lua, and Octave bindings without any issues (except for the peculiar rule contamination between Python and _Pltk_init). So the current status is the official versions partly fail, and the special versions partly fail in a completely different way (ugh). For the official versions, the consistently good results for Python and Octave and the lack of rule contamination that is obtained argue that my overall goal should be to figure out how to make PLplot use the official versions without any errors for Lua and Java. So more later once I get this mess untangled using many different diff results between the various versions of FindSWIG.cmake and UseSWIG.cmake and comparing how our CMake code uses the UseSWIG facilities for Lua and Java compared to the rest of our swig-generated bindings. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [UseSWIG] regression in results from CMake-3.0.2 to recent versions --SOLVED
On 2017-04-22 21:46-0700 Alan W. Irwin wrote: So my next steps are gross simplification (to prove this cross-contamination of build rules for UseSWIG-generated modules in the same CMakeLists.txt file really is due to a regression in CMake somewhere between CMake-3.0.2 and 3.7.2. Note that both CMake-3.7.2 and CMake-3.8.0-rc4 show the warning problem.) Well, the short story is there was no such regression. Note the "--SOLVED" in the revised subject line. Also, sorry for the noise! The somewhat longer story is just at the start (fortunately for me) of that simplification process, I double checked the source of both FindSWIG.cmake and UseSWIG.cmake as used by PLplot, and those turned out to be special cutting-edge versions recommended by one user of the cmake bug tracking system from a decade (!) ago. Oops! Those versions did continue to work for a very long time for our simple swig needs, but those are obviously well past their "best buy" date, and complete removal of those "special" versions from PLplot (so PLplot is now using the official version of those modules that is distributed by whatever CMake version a user chooses) works without the warning messages for both CMake-3.0.2 AND CMake-3.8.0-rc4. In fact (as I expected since I am an optimist) but unlike the extremely peculiar result I had before, inspection of bindings/python/CMakeFiles/_Pltk_init.dir/build.make showed no contamination from plplotc rules at all. So problem solved completely! Thus, thanks to swig, and official versions of FindSWIG.cmake and UseSWIG.cmake that vary with CMake version but which are good enough for our needs despite that variation, I now have my test of our Tcl/Tk "plframe" plotting GUI working well for both Python 2 and Python 3 for a very large range of CMake versions. I hasten to add we will not support that large a range of CMake versions too much longer although that supported range actually helped to figure out the current problem. Indeed, I soon plan to bump our minimum CMake version from 3.0.2 to 3.6.2 which will allow me to greatly simplify our build system by stripping out a whole lot of cruft that was necessary to work around issues that existed for quite a few versions after CMake-3.0.2 was released. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Where execute_process INPUT_CONTENT or INPUT_VARIABLE?
On 2017-04-23 10:24+0300 Konstantin Podsvirov wrote: Hi Alan! 23.04.2017, 10:01, "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>: On 2017-04-23 08:30+0300 Konstantin Podsvirov wrote: Where execute_process INPUT_CONTENT or INPUT_VARIABLE? This would be very convenient for a small input. Why should I always write a file for input? Hi Konstantin: I assume that last sentence refers to using the CMake FILE command directly to write the required file at cmake time in the build tree (as opposed to having to create an actual permanent file in the source tree to be used directly or as a prototype for a configured file in the build tree)? If so, I use that approach quite a bit in various build systems I have helped to develop to help drastically reduce the number of small CMake-related files in the source tree. And I far prefer that approach to what you seem to be asking for above which is some added syntax variation to EXECUTE_PROCESS to provide the same ability that the FILE command currently has. Note, I had to make some assumptions when answering you, and my apologies in advance if I have misinterpreted anything you said above. You have correctly understood and assumed. Thanks for your reply. But imagine that we need to perform a simple process and process its standard output. But this process unfortunately awaits user input to complete. Interesting use case! Of course, if it is really simple user input to the process involving just a few values, then for that use case the user could enter those values via environment variables or CMake variables while the designed build system writes those via FILE to a temporary file in the right order that is then read by the process that is being executed by execute_process. But that idea becomes clumsy as the number of values increases. So I agree it would be useful to deal with the case where user input of a substantial number of values via stdin (presumably interactively prompted by the process to help guide that user input) is the best and most flexible way to control the process. One possibility to address that use case is whenever an appropriate optional argument was specified to execute_process, i.e., that execute_process command had the correct optional signature, then, for example, you could connect cmake stdin with the stdin for the process that is being executed by execute_process. Of course, one concern with this solution for the use case might be this makes the user build process difficult for a project's developers to debug in case the whole thing is failing because the user typed in the wrong stdin data for the process. But I would argue against that concern because this capability does give CMake-based build-system designers more power and freedom which I fundamentally like as such a build-system designer. And with each such additional increase in power and freedom of CMake, build-system designers have a documentation responsibility (i.e., in this case documenting exactly the stdin user choices for the process they have forced users to run at cmake time with execute_process), and the process design responsibility (sanitizing user input, prompting user input, etc.). Also build-system users have the responsibility of reading that process input documentation! :-) I must stop there because I have test project simplification and very likely git bisect work to do on a completely different issue I have raised here today. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Feature Request] Fortran standards compliance for various compilers
On 2017-04-19 13:12-0700 Alan W. Irwin wrote: It appears we are in consensus so it is time to put this idea into the bug tracker as a feature request. OK. It was a bit of a struggle, but with list help from Brad with a different subject line I finally got registered and generated the desired feature request (CMake issue #16819). Good luck to the CMake developers in dealing with this issue. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Feature Request] Fortran standards compliance for various compilers
On 2017-04-19 07:27+0200 Rolf Eike Beer wrote: What would really be useful is a list containing what Fortran features from the Fortran 2003 and 2008 standards that the given Fortran compiler supports. That information is already To name the kid: this is about adding CMAKE_Fortran_KNOWN_FEATURES and friends, no? I wasn't aware of CMAKE_C_KNOWN_FEATURES and CMAKE_CXX_KNOWN_FEATURES, but now that I have looked them up, I agree adding CMAKE_Fortran_KNOWN_FEATURES is the right way to go rather than the generic list I proposed above. This exactly sounds like the whole compile_features things already done for C and C++, so yet another language shouldn't be too hard I guess. Especially since that Fortran information is already collected in well-organized form in on one place, namely <http://www.fortranplus.co.uk/app/download/23704631/fortran_2003_2008_compiler_support.pdf>. It appears we are in consensus so it is time to put this idea into the bug tracker as a feature request. However, when I attempted to do that following your FAQ, I could not get access to <https://gitlab.kitware.com/users/sign_in> with the login identity ir...@beluga.phys.uvic.ca. I have never used that bug tracker before, but I thought at least that login identity would have be copied from the old Mantis bugtracker. But using my old Mantis bugtracker password failed and clicking on "forgot password" or "Request a new one" (which presumably should work even if gitlab does not have ir...@beluga.phys.uvic.ca registered as a login identity) did not send any e-mail response at all to the above address. And, yes, all mail gets through to me except that spam_bayes sorts it into the INBOX, sb_unsure, and sb_spam folders based solely on word counts, and mail from your gitlab bug tracker showed up at none of those places after a ~half hour wait. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Tag signature with expired key
Speculation: the key was renewed locally, but those things have not been uploaded to the keyservers. Hi Eike: The explanation was similar to your above speculation but not quite. :-) I had not refreshed my local keyring from the keyservers recently. When I did that refresh (inspired by your speculation), the expired key "problem" was solved. So sorry for the noise, but nevertheless there is a useful gpg lesson to be learned here. After keys expire they can be renewed (which I didn't realize before) rather than having to generate a whole new key. So that means I (or anybody else) should always execute "gpg --refresh-keys" before complaining about expired keys! 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: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Tag signature with expired key
Hi Brad: I attempted to verify a recent tag on the release branch with the following results: software@raven> git tag --verify v3.7.1 object db3499df5d06ab2cacc61e9f7720a33456aeafe4 type commit tag v3.7.1 tagger Brad King <brad.k...@kitware.com> 1480522722 -0500 CMake 3.7.1 gpg: Signature made Wed 30 Nov 2016 08:18:42 AM PST using RSA key ID 34921684 gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: Good signature from "Brad King" gpg: aka "Brad King <brad.k...@kitware.com>" gpg: aka "[jpeg image of size 4005]" gpg: Note: This key has expired! Primary key fingerprint: CBA2 3971 357C 2E65 90D9 EFD3 EC8F EF3A 7BFB 4EDA Subkey fingerprint: C6C2 6532 4BBE BDC3 50B5 13D0 2D2C EF10 3492 1684 error: could not verify the tag 'v3.7.1' software@raven> echo $? 1 I assume that error in an otherwise good tag signature is due to the fact your key has expired, but I thought it was impossible to sign with an expired key? Anyhow, I thought I should bring this signing by an expired key to your attention in case there is something going on here that you are not aware of. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Thanks for the nice way that CMP0054 was implemented
Hi Nils:
According to "git log" you were the author of the first commit that
referred to CMP0054 so I wanted to publicly thank you and others that
helped you with CMP0054 for the very nice way that is implemented in
practice for developers of CMake-based build systems like me.
Note the PLplot CMake minimum version and corresponding uniform policy
is 3.0.2. We adopt that version to make it easier to build PLplot on
virtually all modern Linux distributions including Debian stable
(which currently only packages 3.0.2). I do have plans in 5 months or
so (likely coinciding fairly closely with when a new Debian stable is
released that will package at least CMake-3.7.0) to bump our minimum
CMake version and uniform policy to at least 3.7.x. But for now we
will be sticking with a policy that conforms to 3.0.2 because of this
modern Linux packaging constraint limiting what versions of cmake are
readily available to Linux users who do not want to have to build
CMake in order to build PLplot.
I now want to move to the issue where the design of CMP0054 saved the
day for me.
The PLplot build system had the following "innocuous" if statement in
one of its heavily used functions:
if(BINDING STREQUAL "c")
That CMake logic has worked well for years in the obvious way
(treating "c" as a simple string) because there was no CMake variable
named c in our build system that would nameclash with that string.
But apparently 4.7.0 does define such a variable and that nameclash
with the "c" string (with CMP0054 OLD behaviour allowing that c
variable to be dereferenced) caused a major issue for that version of
CMake. But because of the nice way that CMP0054 is implemented, CMake
immediately warned about this nameclash when running CMake-3.7.0, and
I was able to temporarily workaround the issue by replacing the above
if statement by
if("X${BINDING}X" STREQUAL "XcX")
(since there is evidentally no variable named XcX to nameclash with
that string). Of course, once we are able to bump our minimum version
to a modern version of CMake like 3.7.0 that allows us to use the much
more logical NEW form of CMP0054 that eliminates the possibility of
such nameclashes, and that vastly preferred policy will allow me to
revert the above workaround necessary for CMP0054 OLD.
In sum, I wanted to acknowledge the forward thinking of everybody that
worked on CMP0054 since that nice implementation saved my ass today
when one of our users who had good success with the PLplot build for
3.6.x reported major PLplot build-system trouble with CMake-3.7.0.
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:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Current deficiencies of automoc
On 2016-11-14 09:06+0100 Sebastian Holtermann wrote:
What probably could be done is to add
${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir
to the INCLUDE_DIRECTORIES of the target and then generate all
#included moc file there, accepting the risk of intra target name
collisions.
Hi Sebastian:
Your compromise idea above sounds good to me!
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:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Current deficiencies of automoc
On 2016-10-22 19:49+0200 Sebastian Holtermann wrote:
[...]
Actually I made an implementation in 3.6.0 that generated the moc files
in the a build tree subdirectory correspoding to the header path.
But that blew up on some projects because the generated paths got too long
for some compiĺers. That implementation was theefore reverted.
In 3.7 there is a new approatch that generates the moc files in
${CMAKE_BINARY_DIR}/
${TARGETNAME}_automoc.dir/
${HEADERNAME}_${HEADERPATHCHECKSUM}.cpp
This ensures that the paths don't get too long and that there won't be any
name collisions.
Hi Sebastian:
After a substantial break to finish off a different project, I have
now had a chance to return to the present topic using my attached
test_automoc project. (Also available in the cmake/test_automoc
subdirectory of the PLplot git master branch that can be accessed at
<https://sourceforge.net/p/plplot/plplot/ci/master/tree/>.) The
project builds 6 separate simple Qt5 applications that #include a
header that needs moc processing. The only differences between the
source code files for the various executables is the name and
directory location of that #include'd file and the various instructions
given to automoc (and in one case qt5_wrap_cpp) to process that file.
With that test project, I now confirm (sorry about the noise to the
contrary before) that automoc does use the approach you mentioned
above for CMake-3.7.0 to reduce the name collisions that occur for
that same project for earlier versions of CMake.
Concerning the collisions still expected for 3.7.0, the automoc
documentation (see
<https://cmake.org/cmake/help/v3.7/prop_tgt/AUTOMOC.html>) states the
following:
"However, if multiple source files in different directories do this
[i.e., contain an "#include "moc_.cpp" when the header
name is .h] then their generated moc files would
collide. In this case a diagnostic will be issued."
For the life of me, I cannot find a way to generate that diagnostic.
Instead, three different targets (two targets concerning the same
implementation code and header in the same directory and a third
target for a copy of that same implementation code and header in a
different directory) generate at build time a file named
moc_test_q_object.cpp in the same build directory at different times.
This is a clear example of a three-way name collision, but CMake does
not issue a diagnostic for any of these targets concerning that
collision contrary to the above documentation.
Could you please take a look at the three last executables configured
for this test case (helloworld_automoc_same_include,
helloworld_automoc_same_include1, and
helloworld_automoc_same_include2) to see why that collision diagnostic
is not being issued with cmake-3.7.0? Better yet, of course, would be
to solve these remaining name collisions completely by using a
modification of your idea above, i.e., for this special case where
users implementation code contained
#include "moc_.cpp"
then moc should generate the file
${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir/${HEADERPATHCHECKSUM}/moc_${HEADERNAME}.cpp
Note, the generated moc file has the name expected by the #include so
I believe this idea would work so long as automoc automatically
appended
${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir/${HEADERPATHCHECKSUM} to
the target INCLUDE_DIRECTORIES property.
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
__
test_automoc.tar.gz
Description: Simple project to test automoc for various header file locations and names
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Current deficiencies of automoc
On 2016-10-22 19:49+0200 Sebastian Holtermann wrote:
Actually I made an implementation in 3.6.0 that generated the moc files
in the a build tree subdirectory correspoding to the header path.
But that blew up on some projects because the generated paths got too long
for some compiĺers. That implementation was theefore reverted.
In 3.7 there is a new approatch that generates the moc files in
${CMAKE_BINARY_DIR}/
${TARGETNAME}_automoc.dir/
${HEADERNAME}_${HEADERPATHCHECKSUM}.cpp
This ensures that the paths don't get too long and that there won't be any
name collisions.
Hi Sebastian:
Now that I have thought a bit more about this, you do need to
distinguish by target since those can have different automoc options,
and even if that is the same for the two targets, you would not want
multiple moc commands on the same header to generate the same output
file at the same time. So this looks like an excellent naming scheme
that will avoid all such collisions.
However, I see no sign of this new approach in my recent compilation
of 3.7.0-rc2, nor in the automoc documentation for the master branch
tip (or next branch tip). So is it really going to get into 3.7.0
(including the automoc documentation of this new approach)?
Also, I tested the simple test case modified to add an additional
target using the same source code and CMake-3.7.0-rc2. That currently
does generate the same filename for the two different moc output
results, and I was also surprised (considering the 3.7.0-rc2 automoc
documentation that states there would be a diagnostic warning of moc
output collisions) there was no collision diagnostic for this
particular case of two targets in the same directory. But your above
approach (once it gets into 3.7) should avoid all such collisions (and
thus make collision diagnostics moot).
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:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Current deficiencies of automoc
is a very low level dependency for
them). The moc outputs that are #include’ed don’t need to be added to the
target.
The problem here is, that once a target is created in CMake, you can’t add any
files to it. So this has to be done that way.
Since the TAM target is build before T’s “scan for dependencies”, automoc can’t
know what files _exactly_ are included in the project (unless given through
add_executable/add_library). This makes an informed automatic decision in the
above cases 3 and 4 practically impossible. And for case 1, this means: We’d
actually have to consider _all_ files in _all_ -I directories, possibly
including /usr/include and /usr/local/include.
So, what we’re left with is the actual command lines to the compiler, the
include paths as defined in CMakeLists.txts. This _could_ be used to solve the
case 2. But such a solution would be very error prone and still leaves case 1
to be sorted out somehow.
Hi Sascha:
I accept what you have said, and I very much appreciate your attempt
to educate me (and others here) in these C++/Qt/moc technical
considerations. Therefore, subject to some minor corrections such as
the subsequent one by Craig Scott I strongly urge you to put this
essential background information into the CMake FAQ so it is not lost
in the large traffic on this list.
I’ve read the cmake-qt(7) section about automoc several times now. I can’t
actually figure out anything inside it that is plain _wrong_. However, I would
suggest to change the documentation to:
The AUTOMOC target property controls whether cmake(1) inspects the C++
header and implementation
files in the target to determine if they require moc to be run, and to
create rules to execute moc at the
appropriate time.
Note that it is recommended to explicitly list header files when
declaring a target with add_executable
or add_library - even though this is only required when header and
corresponding implementation file
are in different directories. {1}
That statement is not true in complete generality so I would suggest
the addition of the following qualifier
"Note that it is recommended" ==>
"Note that to assure consideration for moc processing it is recommended"
Also, it sounds from your footnote 1 that you would prefer not to have
all the details here about the exact rules for identifying the header
files to be scanned so I would suggest the following addition to the
above paragraph.
When the header is in the same directory as the C++ implementation
file there are additional possibilities for identifying it for
consideration for moc processing, see the automoc documentation.
And then the automoc documentation should be updated with those
same-directory possibilities clearly stated.
moc needs to be run, if:
- A Q_OBJECT or Q_GADGET macro is found in a header file. In this case,
the result will be put into
into a file named according to moc_.cpp. Multiple moc outputs
generated that way will
be added to the target as one translation unit.
- The macro is found in a C++ implementation file. Following the Qt
conventions, moc output will be
put into a file named according to .moc.
The implementation file may optionally use a preprocessor #include to
include the .moc file (This is
typically done at the end of the file). If such an include is omitted,
the .moc file will also be added to
the aforementioned translation unit.
Generated moc_*.cpp and *.moc files are placed in the build directory
so it is convenient to set the
CMAKE_INCLUDE_CURRENT_DIR variable. {2}
The moc command line will consume the COMPILE_DEFINITIONS and
INCLUDE_DIRECTORIES
target properties from the target it is being invoked for, and for the
appropriate build configuration.
The AUTOMOC target property may be pre-set for all following targets by
setting the
CMAKE_AUTOMOC variable. The AUTOMOC_MOC_OPTIONS target property may be
populated
to set options to pass to moc. The CMAKE_AUTOMOC_MOC_OPTIONS variable
may be populated
to pre-set the options for all following targets.
{1} I’d consider this too generic for _that_ part of the
documentation, but it could be added: "Header files that are in the same
directory as their implementation file will be automatically added to
the target”.
{2} Maybe this should actually be changed to “so it might be required
to set”
Assuming you have no strong objections to the above further changes,
then I plan to wrap up our joint cmake-qt documentation changes into git
format-patch form for the convenience of the CMake developers here.
And I also plan to work on the automoc documentation using similar
language to what you have used above in the cmake-qt case with some
additions about the same-directory possibilities for identifying
headers that should moc'ed.
Alan
________
Re: [cmake-developers] Current deficiencies of automoc
On 2016-10-22 03:35+0100 Sascha Cunz wrote: But automoc must know where to look for. It can only do that if something tells it where to look - If your header files are in the same directory as the source files, they’re getting added and scanned automatically. If, like in your example, the files are in different directories, you have to add them to add_executable / add_library in order to let automoc know that it shall scan them. That is a good summary of what I have discovered through experimentation. However, I view these results for the separate header file directory as an unexpected constraint of automoc at best. Compilers know exactly where the header files are through include_directories or the equivalent target PROPERTY so why can't automoc find those same header files using similar logic? Of course, I am in the odd position (as I explained before) of not being able to help out with implementing such logic so if it turns out nobody wants to clean up this issue at the moment, I will put it on the bugtracker for future reference. [...] However, I see that the take away from the thread should probably be that the wording in the documentation could be improved. To be fair, it is in general very hard for someone who knows a tool and it’s complete history to write documentation that someone who doesn’t have that prior knowledge is able to understand. So, improving things here usually relies on input like yours to figure out what actually has to be improved. I agree. I have already suggested some possible changes to the documentation on the initial thread on the CMake mailing list and this additional thread here on the CMake developer list. But if nobody is inspired to take immediate action on fixing the problem summarized above (which would largely make the current documentation correct), I will write up these documentation issues for the current automoc behaviour for the bugtracker as well. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Current deficiencies of automoc
On 2016-10-21 23:54+0200 el.bar...@gmx.de wrote:
1. The automoc documentation at
<https://cmake.org/cmake/help/v3.6/prop_tgt/AUTOMOC.html> only
documents the #include method (which doesn't work for the current test
case nor for PLplot), and the above working fullpath method is not
documented at all there.
At least in cmake-qt(7) [1] this is documented:
If a |Q_OBJECT| or |Q_GADGET| macro is found in a header file, |moc| will be
run on the file. The result will be put into a file named according to
|moc_.cpp|. If the macro is found in a C++ implementation file, the
moc output will be put into a file named according to |.moc|,
following the Qt conventions. The |moc file| may be included by the user in
the C++ implementation file with a preprocessor |#include|. If it is not so
included, it will be added to a separate file which is compiled into the
target.
Hi Marc:
I have put my response to your comment back on the list where I think it
belongs.
I don't agree with your above conclusion. The above remarks immediately refer
to
header files and imply automoc scans them to find the ones that contain
the Q_OBJECT macro and certainly does not imply the user must list
the files to be scanned directly as fullpaths in the add_executable
(or add_library) command. And the last sentence implies that
if the so-called #include method is not used, then automoc will figure
everything out for itself, i.e., the fullpath method allowing the
user to specify which headers are scanned by moc is not documented
here at all.
If the first sentence in the above paragraph had referred to header
files appearing in the list of source files for add_executable or
add_library and/or if the last sentence in the above paragraph had
been replaced by
"If it is not so included, the user must put the fullpaths of the
headers that need moc processing in the source list for add_executable
or add_library." then I would agree with your conclusion, but that
type of specific documentation of the fullpath method is just not
currently in the cmake-qt documentation.
By the way, I have been able to show that the "leaving it completely
to automoc" method documented above does not work with the second
(fixed) version of my simple example, and I urge you to try that
experiment also by making the following additional change (from
"fullpath" to "leave it to automoc")
- add_executable(helloworld main.cpp
${CMAKE_SOURCE_DIR}/include/test_q_object.h)
+ add_executable(helloworld main.cpp)
For this case nm shows everything in test_q_object.h is completely ignored
by automoc despite the '#include "test_q_object.h"' in main.cpp.
N.B. the above documentation is likely correct and the "leave it to
automoc" method should work but it doesn't for this simple example, and that is
likely
due to the same bug that keeps the "#include" method from working for
this simple example of an include file in a separate directory.
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:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Current deficiencies of automoc
On 2016-10-21 09:42+0200 Sebastian Holtermann wrote:
[...]
Hi!
I tried your example.
It isn't complete, test_q_object.h needs an
#include
and a constructor/destructor definition, e.g.:
MyClass(QObject *parent = 0) {;}
~MyClass(){;}
Hi Sebastian:
Thanks for that fix which indeed solves the linking issue.
With regards to automoc the
#include "moc_test_q_object.cpp"
in the end should not be neccessary since
#include "test_q_object.h"
already references to the header.
The problem is that this reference is not a direct path from the
source file but relies on include_directories.
CMake does not seem to populate automoc's scan list with files
from include_directories.
I tried to figure out why but this is quite complex.
I hope you are able to fix this along the lines I have mentioned
(which includes putting all generated results in the build tree
corresponding to the header) since using #include
"moc_test_q_object.cpp" in main.cpp is currently the only documented
way to use automoc (see, e.g.,
<https://cmake.org/cmake/help/v3.6/prop_tgt/AUTOMOC.html>).
A quick fix for the example would be to explicitly add the
headers-to-moc to the sources list.
- add_executable(helloworld main.cpp)
+ add_executable(helloworld main.cpp
+ ${CMAKE_SOURCE_DIR}/include/test_q_object.h)
The #include "moc_test_q_object.cpp" in main.cpp can be removed then.
That idea (specifying the fullpath of the original header as part of the source
code)
does indeed make automoc work properly. "ldd -r helloworld" shows
no linking issues, I can run the executable without issues,
and "nm --defined-only --demangle helloworld |less" shows lots
of references to MyClass. I attach a revised tarball
example with the test_q_object.h fix and this
change.
However, there are still two problems with this method which
I will call the fullpath method to distinguish it from the documented
#include method.
1. The automoc documentation at
<https://cmake.org/cmake/help/v3.6/prop_tgt/AUTOMOC.html> only
documents the #include method (which doesn't work for the current test
case nor for PLplot), and the above working fullpath method is not
documented at all there.
2. With that fullpath method, The automoc-generated
helloworld_automoc.cpp and moc_test_q_object.cpp are located in
${CMAKE_CURRENT_BINARY_DIR} (the build directory where the helloworld
executable is located), and that is not ideal. For example, I have no
idea how the compile process found that directory to include those
files since that directory is specifically not mentioned in
include_directories for this project. It also means that for
executables and libraries in a variety of directories that include
${CMAKE_SOURCE_DIR}/include/test_q_object.h in their source list will
be generating duplicate moc_test_q_object.cpp in a variety of
different directories.
Thus, it seems to me the more logical location for these two
automoc-generated files would be ${CMAKE_BINARY_DIR}/include. Note
that ${CMAKE_BINARY_DIR}/include/helloworld_automoc.cpp is unique
(because the target name helloworld must be unique), and
${CMAKE_BINARY_DIR}/include/moc_test_q_object.cpp is also unique
because it corresponds to the unique filename
${CMAKE_SOURCE_DIR}/include/test_q_object.h. So this means there is
no chance of nameclashes with this location (although to be fair that
is also true of the current location for these two generated files).
This suggested location is also the one I suggest for the #include
method, and that consistency of location between the two methods
(and also the qt5_wrap_cpp method) is important.
Of course, if ${CMAKE_SOURCE_DIR}/include/test_q_object.h appears in
source lists for lots of different executables and libraries, automoc
has to test whether ${CMAKE_BINARY_DIR}/include/moc_test_q_object.cpp
has already been generated so that generation is only done once. I
presume such a check would be easy to implement if automoc doesn't do
that already.
In sum, I hope you are willing to fix the currently documented automoc
"#include" method so it puts all generated results in the build tree
corresponding to the header, update the automoc documentation so you
also mention the "fullpath" alternative, and also similarly fix that
method so the location of the two generated files is in the build
directory corresponding to the header rather than the build directory
corresponding to the source file.
My apologies for making suggestions for improvement without being able
to help you with the implementation (except testing of results), but
my C++ skills and CMake developer skills are just not up to it (as you
could probably tell from the required test_q_object.h fix you had to
suggest.)
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliat
Re: [cmake-developers] Current deficiencies of automoc
On 2016-10-20 15:08-0400 Brad King wrote:
Please construct a minimal/complete example source tree/tarball
that demonstrate the layout you'd like to have work. That will
be helpful in constructing such a bug report.
OK. I have attached the requested minimal example to serve as the
basis for further discussion. The files in the tarball are
test_qt5/
test_qt5/include/
test_qt5/include/test_q_object.h
test_qt5/main.cpp
test_qt5/CMakeLists.txt
include/test_q_object.h is a header that contains a minimal use of
Q_OBJECT. (Likely too minimal so I will need help with that see below.)
main.cpp is a "hello-world" example that #includes that header. It also
#includes
the moc-generated moc_test_q_object.cpp.
The USE_AUTOMOC option for this test project defaults to OFF. In that
default case this test project is set up so that the qt5_wrap_cpp is called
instead of using automoc, and the
result is the compilation works fine (all headers and files generated
by moc are found with no issues) but there is a link error
CMakeFiles/helloworld.dir/main.cpp.o:(.data.rel.ro._ZTV7MyClass[_ZTV7MyClass]+0x28):
undefined reference to MyClass::~MyClass()'
which likely has to do with include/test_q_object.h being too minimal.
I would appreciate help with that issue to complete this example, but
that is a side issue and the principal result is the compile (as
opposed to the link) was a success with the default -DUSE_AUTOMOC=OFF.
However, if you try -DUSE_AUTOMOC=ON with this project the compile
step (before it even gets to the link step) fails as follows:
Automatic moc for target helloworld
/home/software/cmake/install-3.5.2/bin/cmake -E cmake_autogen
/home/software/plplot/HEAD/test_qt5/build_dir/CMakeFiles/helloworld_automoc.dir/
""
AUTOGEN: Checking /home/software/plplot/HEAD/test_qt5/main.cpp
AUTOGEN: error: /home/software/plplot/HEAD/test_qt5/main.cpp The file includes the moc file
"moc_test_q_object.cpp", but could not find header
"test_q_object{.h,.hh,.h++,.hm,.hpp,.hxx,.in,.txx}" in
/home/software/plplot/HEAD/test_qt5/
I hope a simple solution to this deficiency of the current automoc can
be found using the following ideas (copied from my previous post to
keep this self-contained).
If
#include "moc_.cpp"
is found in a source file under automoc
control, then if moc_.cpp could not be found in any of the
include directories for the target, then search those include
directories (including source-tree equivalents of build-tree include
directories) for .h, run moc on that file and place the result
moc_.cpp in the build directory corresponding to .
So the result is moc would be run just once on the correct header file
with the moc_.cpp result stored in one logical location no
matter how many different source files in different directories have
code with the above #include.
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
__
test_qt5.tar.gz
Description: compressed tarball containing a minimal example of automoc compile failure
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Current deficiencies of automoc
On 2016-10-20 15:08-0400 Brad King wrote: Please construct a minimal/complete example source tree/tarball that demonstrate the layout you'd like to have work. That will be helpful in constructing such a bug report. A minimal example illustrating the issue is a great idea. However, the problem is I am not much of an expert on C++ or Qt5 so reducing the PLplot Qt5 example source code to such a minimal example is going to be somewhat time consuming for me. So unless someone here lends me a hand by implementing the needed simple Qt5 source code, I first plan to look through the many Qt5 demos accessible on the web to see if any of them qualify in terms of no Q_OBJECT in source, but Q_OBJECT in #included header, and as a last resort I will attempt to simplify the PLplot Qt5 example source code. Then follow up with implementing the CMake aspects of that simple example which should be trivial for me. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Current deficiencies of automoc
Disclaimer: I am no expert on any of this stuff so the conclusions I have drawn are based on the particular experiments I have done and are probably limited because of that. On 2016-10-20 21:17+0200 Tobias Hunger wrote: Hi! Am 20.10.2016 21:08 schrieb "Brad King" <brad.k...@kitware.com>: On 10/20/2016 02:30 PM, Alan W. Irwin wrote: To be specific here is the way I believe automoc should work. If #include "moc_.cpp" is found in a source file under automoc control, then if moc_.cpp could not be found in any of the include directories for the target, then search those include directories (including source-tree equivalents of build-tree include directories) for .h, run moc on that file and place the result moc_.cpp in the build directory corresponding to . [snip] this is a plea to the CMake developers to fix the above deficiency If you include moc_name.cpp, then you need to run moc on this *source* file. That is what allows you to have private classes in your source file that derive from QObject. That is not the case I am concerned with which is the source file has no direct reference to the Q_OBJECT macro. Instead it #includes a header that uses that macro. My experiments (see disclaimer above) with that case show moc needs to be run directly on the header, and the resulting generated file needs to be #included in the source file. The headers should be covered by automoc automatically: Any header containing a Q_OBJECT macro should be moc-ed. So there should not be any need to include moc_*.cpp files in source files for any header. Actually my experiments show the headers using the Q_OBJECT macro are completely ignored by automoc unless you specifically put #include moc_.cpp in the source file, and that works only if .h is in the current directory. And I want to see that severe current directory limitation removed as above. At least that is how I always use this with qmake, but I am hardly an expert on how moc should work:-) That lack of expertise goes double for me. :-) See disclaimer above. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Current deficiencies of automoc
This is a follow up to the CMake mailing list thread with the subject line "Cannot get automoc to work properly with recommended Qt5 support method". The deficiency I found with automoc is (as far as I can tell) it does not properly handle the case where the header that should be processed by moc is located in a different source-tree directory than the source file that includes that header. For PLplot I have worked around this deficiency by abandoning use of automoc altogether and instead used custom targets that invoked qt5_wrap_cpp. But the whole concept of automoc is far superior to a custom target approach so this is a plea to the CMake developers to fix the above deficiency in automoc. To be specific here is the way I believe automoc should work. If #include "moc_.cpp" is found in a source file under automoc control, then if moc_.cpp could not be found in any of the include directories for the target, then search those include directories (including source-tree equivalents of build-tree include directories) for .h, run moc on that file and place the result moc_.cpp in the build directory corresponding to . So the result is moc would be run just once on the correct header file with the moc_.cpp result stored in one logical location no matter how many different source files in different directories have code with the above #include. My experiments showed that automoc currently falls short of this behaviour and only works if .h is in the current source directory and I consider this deficiency to be a serious bug in automoc. Furthermore, the documentation of automoc needs improving to explicitly name the header file being processed by moc when encountering the above #include. Furthermore, the directories searched for that header file should be stated. For the current buggy state of automoc that would just be the current source tree, but once the bug was fixed it would be everything mentioned in include_directories and their source-tree equivalents. I hate to lose issues that can be trivially fixed on bug trackers, but if the above automoc fix and automoc documentation fix are not trivial, then I would be willing to incorporate the above and any further discussion here into an official CMake bug report. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Export files in the build tree have a total path length which is unnecessarily long
On 2016-08-09 10:11-0400 Brad King wrote: On 08/08/2016 02:54 PM, Alan W. Irwin wrote: For all such staging areas, would it be straightforward to hash the paths for the cmake-generated EXPORT files in the build tree to substantially reduce their pathlengths for the absolute install location case while still avoiding name collisions? Actually it looks like we already do this, but the logic forgot to account for the length of the file name. Please try this fix: install(EXPORT): Fix support for mid-length install destinations on Windows https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c7a319ab Hi Brad: I don't have access to Windows, but I tried this fix on Linux with a very long CMAKE_INSTALL_PREFIX (to trigger the hashing), and all seems to be well. software@raven> ~/cmake/install-c7a319a/bin/cmake -DCMAKE_INSTALL_PREFIX=$(pwd)/42397430947234398793874973983732987249739347293472938729487239472439782394723492374294847234927423497971498749237349723958749473934873497235987549023475/92752349572349053475945729729527234957349735209573999725497834957249524752904573975295742957349857934539709925294754973957493720274903485230252239/42397430947234398793874973983732987249739347293472938729487239472439782394723492374294847234927423497971498749237349723958749473934873497235987549023475/92752349572349053475945729729527234957349735209573999725497834957249524752904573975295742957349857934539709925294754973957493720274903485230252239/42397430947234398793874973983732987249739347293472938729487239472439782394723492374294847234927423497971498749237349723958749473934873497235987549023475/92752349572349053475945729729527234957349735209573999725497834957249524752904573975295742957349857934539709925294754973957493720274903485230252239/423974309472343987 93874973983732987249739347293472938729487239472439782394723492374294847234927423497971498749237349723958749473934873497235987549023475/92752349572349053475945729729527234957349735209573999725497834957249524752904573975295742957349857934539709925294754973957493720274903485230252239/42397430947234398793874973983732987249739347293472938729487239472439782394723492374294847234927423497971498749237349723958749473934873497235987549023475/92752349572349053475945729729527234957349735209573999725497834957249524752904573975295742957349857934539709925294754973957493720274903485230252239/42397430947234398793874973983732987249739347293472938729487239472439782394723492374294847234927423497971498749237349723958749473934873497235987549023475/92752349572349053475945729729527234957349735209573999725497834957249524752904573975295742957349857934539709925294754973957493720274903485230252239/4239743094723439879387497398373298724973934729347293872948723947243978239472349237429484723492742349797149874923734 9723958749473934873497235987549023475/92752349572349053475945729729527234957349735209573999725497834957249524752904573975295742957349857934539709925294754973957493720274903485230252239/42397430947234398793874973983732987249739347293472938729487239472439782394723492374294847234927423497971498749237349723958749473934873497235987549023475/92752349572349053475945729729527234957349735209573999725497834957249524752904573975295742957349857934539709925294754973957493720274903485230252239/install_tree -DBUILD_TEST=ON .. -- The Fortran compiler identification is GNU 4.9.2 -- Check for working Fortran compiler: /usr/bin/f95 -- Check for working Fortran compiler: /usr/bin/f95 -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether /usr/bin/f95 supports Fortran 90 -- Checking whether /usr/bin/f95 supports Fortran 90 -- yes -- Configuring done -- Generating done -- Build files have been written to: /home/software/plplot/HEAD/plplot.git/cmake/test_fortran/build_dir Despite that long install prefix (note the numbers have "/" embedded periodically to avoid going over the individual filename length limit on Linux), the exported files in the build-tree staging area appeared in hashed form, e.g., software@raven> pwd /home/software/plplot/HEAD/plplot.git/cmake/test_fortran/build_dir software@raven> find $(pwd) -type f |grep -i export /home/software/plplot/HEAD/plplot.git/cmake/test_fortran/build_dir/src_lib/CMakeFiles/Export/57a65d04a859ba876e044822264a11fe/export_test_fortran.cmake /home/software/plplot/HEAD/plplot.git/cmake/test_fortran/build_dir/src_lib/CMakeFiles/Export/57a65d04a859ba876e044822264a11fe/export_test_fortran-noconfig.cmake and after "make install" were installed in unhashed form (pathname length as large as 2471 for this particular test case) without issues. By the way, an install prefix of roughly 500 in length did not trigger the hashing. But I assume that lack of hashing for smaller-sized prefixes on Linux is due to some knowledge CMake has about pathname length limits on that platform, and hashing will be triggered for much smaller install prefixes on MinGW-w64/MSYS2 because of the known much
Re: [cmake-developers] Export files in the build tree have a total path length which is unnecessarily long
On 2016-08-08 13:40-0400 Brad King wrote: On 08/07/2016 01:39 AM, Alan W. Irwin wrote: why is the install location of these export files included in the pathname for both export files? That significantly increases the pathlength of these files to no purpose since the install location of these files is already known to CMake by other means. These files are generated by the install(EXPORT) command. Their location is a staging area for "make install" to copy to the actual install destination. The install destination is used in their staging location to make sure there are no collisions. Normally the install(EXPORT) command is given a relative DESTINATION so the path is not very long. Are you giving it an absolute destination? Why? PLplot (including the test_fortran subproject to be consistent with the principal plplot project) has always used absolute install locations. It sounds like I could work around the issue by moving PLplot over to relative install locations, but that is a fairly intrusive change to our build system so I am a bit reluctant to make that change. Furthermore, I doubt this problem is unique to the PLplot build system since presumably there are other projects that use absolute install locations as well because such install locations are typically well supported by CMake. The only exception to that support that I am aware of at this time is this particular install(EXPORT) case where the (encoded) absolute staging area potentially adds so much to the total length of the pathname. Is this the only case where you have a staging area in the build tree that corresponds to an install pathname? For all such staging areas, would it be straightforward to hash the paths for the cmake-generated EXPORT files in the build tree to substantially reduce their pathlengths for the absolute install location case while still avoiding name collisions? 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: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Export files in the build tree have a total path length which is unnecessarily long
I have a simple project called test_fortran which somone else is testing for me on MinGW-w64/MSYS2, and it failed because the following file D:/plplot-svn/comprehensive_test_fortran_disposeable/shared/noninteractive/build_tree/src_lib/CMakeFiles/Export/D_/plplot-svn/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/cmake/test_fortran/export_test_fortran-noconfig.cmake configured (or generated) by cmake had too long a pathname for that platform. The complete cmake output for this test_fortran project was -- The Fortran compiler identification is GNU 4.9.2 -- Check for working Fortran compiler: C:/msys64/usr/bin/f95.exe -- Check for working Fortran compiler: C:/msys64/usr/bin/f95.exe -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether C:/msys64/usr/bin/f95.exe supports Fortran 90 -- Checking whether C:/msys64/usr/bin/f95.exe supports Fortran 90 -- yes -- Configuring done CMake Error: cannot write to file "D:/plplot-svn/comprehensive_test_fortran_disposeable/shared/noninteractive/build_tree/src_lib/CMakeFiles/Export/D_/plplot-svn/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/cmake/test_fortran/export_test_fortran-noconfig.cmake": No such file or directory -- Generating done -- Build files have been written to: D:/plplot-svn/comprehensive_test_fortran_disposeable/shared/noninteractive/build_tree (Another such file called D:/plplot-svn/comprehensive_test_fortran_disposeable/shared/noninteractive/build_tree/src_lib/CMakeFiles/Export/D_/plplot-svn/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/cmake/test_fortran/export_test_fortran.cmake just squeaked under the limit for that platform so was generated in the build tree OK. (Note for my test of that same project on Linux these exported files in the build tree had similar long total path lengths, but it is OK in that case because of the very long total path length on Linux.) Note that in all cases the total path length of those export files in the build tree are significantly longer than they need to be. For example, for this particular user's test of this project the build tree prefix was D:/plplot-svn/comprehensive_test_fortran_disposeable/shared/noninteractive/build_tree so we are stuck with that part of the path length, but why is the install location of these export files (in this case D:/plplot-svn/comprehensive_test_fortran_disposeable/shared/noninteractive/install_tree/lib/cmake/test_fortran ) included (in encoded form with D: replaced by D_) in the pathname for both export files (export_test_fortran-noconfig.cmake and export_test_fortran.cmake)? That significantly increases the pathlength of these files to no purpose since the install location of these files is already known to CMake by other means. This issue is critical on platforms like MinGW-w64/MSYS2 with limited total path length so it would be good to get it addressed. If cmake developers feel the fix for this issue will require sufficient time to warrant bug triage, let me know, and I would be willing to start that process by copying the above discussion to the bugtracker. But ideally it would require only a quick fix that does not require bug triage. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMP0065 warning not supressed when --trace used
On 2016-07-14 13:49-0400 Brad King wrote: On 07/14/2016 01:32 PM, Alan W. Irwin wrote: I am addressing this mostly to you because you are the author of CMP0065 which has the special property that by default it does not warn when the policy is not set. However, I find it does warn when --trace is set which I am fairly sure is a (minor) bug. This is documented behavior: https://cmake.org/cmake/help/v3.6/variable/CMAKE_POLICY_WARNING_CMP.html "running cmake(1) with the --debug-output, --trace, or --trace-expand option will also enable the warning." I should have followed the obvious link in <https://cmake.org/cmake/help/v3.5/policy/CMP0065.html#policy:CMP0065> to the above URL. Sorry for that noise. should change "thier" (in the third last line) to "their". Recently fixed: Fix typos. https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=56608618 Glad that Felix Geyer spotted this and fixed it last weekend. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] CMP0065 warning not supressed when --trace used
Hi Chuck:
I am addressing this mostly to you because you are the author of
CMP0065 which has the special property that by default it does not
warn when the policy is not set. However, I find it does warn when
--trace is set which I am fairly sure is a (minor) bug.
Please take a look at the attached CMakeLists.txt file
which is a self-contained simple test project that demonstrates
the described issue with CMP0065 and --trace. For this project the policy is
not
set because of
cmake_minimum_required(VERSION 3.3.2 FATAL_ERROR)
And indeed normal use of cmake (version 3.5.2) gives no warning for
CMP0065 as advertised by the CMP0065 documentation.
However, on my Linux platform (Debian Jessie with cmake-3.5.2 which I
built with the bootstrap method) if you use the cmake --trace option you do get
the following
warning message (after a whole bunch of other messages from the
--trace option).
-- Configuring done
CMake Warning (dev) in CMakeLists.txt:
Policy CMP0065 is not set: Do not add flags to export symbols from
executables without the ENABLE_EXPORTS target property. Run "cmake
--help-policy CMP0065" for policy details. Use the cmake_policy command to
set the policy and suppress this warning.
For compatibility with older versions of CMake, additional flags may be
added to export symbols on all executables regardless of thier
ENABLE_EXPORTS property.
This warning is for project developers. Use -Wno-dev to suppress it.
First there is an extremely minor but still irritating message content
bug here where you should change "thier" (in the third last line) to
"their".
More seriously, I am pretty sure that the --trace option should not
change warnings policy this way, i.e., this is a bug in --trace or a
bug in the way that CMP0065 implements the supression of the warning
by default. If you have any difficulty confirming this issue with the
attached CMakeLists.txt and CMake-3.5.2 (or presumably later) please
get back to me.
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
__cmake_minimum_required(VERSION 3.3.2 FATAL_ERROR)
project(test_CMP0065 C)
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/hello.c
"#include
void main(void)
{
printf(\"hello, world\\n\");
}
"
)
add_executable(hello ${CMAKE_CURRENT_BINARY_DIR}/hello.c)
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Don't enclose CMake version to generated files
On 2016-07-11 17:17+0200 Christoph Grüninger wrote: Hi Ben, this comes from the open build system, which is the system used by openSuse to generate the packages. If the CMake version is updated, which happens quite often, the generated files are altered and the packages are rebuild, repackaged and republished. Without the version number in the generated files, it wouldn't happen. Hi Christoph: For the use case you describe, shouldn't that rebuild happen to maintain consistency between the openSuse version of CMake and all the openSuse packages that are built with CMake? CMake does have a large degree of backwards compatibility, but it is not perfect so I think the version does matter. Another way of saying this is you might want to consider CMake to be part of the tool chain (like gcc is) where any version difference is presumably considered to be quite significant and therefore worth a rebuild of binary packages. I don't know what openSuse policy is for gcc version changes, but presumably such changes are heavily controlled to reduce rebuilds, and openSuse has the option of following that heavy control of version change policy for CMake instead of doing what I consider to be a workaround which is patching CMake to remove version information from the generated 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Parallel ctest issues on the MinGW-w64/MSYS2 platform
On 2016-03-29 22:46+0200 Nils Gladitz wrote: On 29.03.2016 21:39, Alan W. Irwin wrote: One of the PLplot developers, Arjen Markus, has just reported to me that ctest -j4 for PLplot hangs on his MinGW-w64/MSYS2 platform while ctest works fine. This issue occurred for the mingw64/mingw-w64-x86_64-cmake 3.4.1-1 package version of ctest.exe, and the PLplot build was done with the "MSYS Makefiles" generator. In contrast to the MinGW-w64/MSYS2 platform case, ctest -j4 works fine for the Linux case. Has anyone else here had similar difficulties OR success with the parallel ctest option on the MinGW-w64/MSYS2 platform? Afair there are sporadic issues with the cygwin runtime (on which msys/msys2 is based) in the process handling code of kwsys (used by cmake). The code is used by e.g. execute_process() and also ctest for test execution. I think the issue is due to how pipes are implemented by the runtime. From what I remember rsync also suffers from this. Also having Kaspersky installed (even when paused) seems to make these hangs more likely. Thanks, Nils, for that information. Could this issue be related to the Cygwin unreliability mentioned in <http://cygwin.com/cygwin-ug-net/highlights.html> where they say "In summary, current Windows implementations make it impossible to implement a perfectly reliable fork, and occasional fork failures are inevitable."? In any case, whatever the issue is, Arjen appears (so far) to have found a reliable reproducer with the -j option for ctest. So I hope others here try the -j option for ctest on MinGW-w64/MSYS2 platforms for their favorite projects to get a better idea of how widespread this issue is. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Parallel ctest issues on the MinGW-w64/MSYS2 platform
One of the PLplot developers, Arjen Markus, has just reported to me that ctest -j4 for PLplot hangs on his MinGW-w64/MSYS2 platform while ctest works fine. This issue occurred for the mingw64/mingw-w64-x86_64-cmake 3.4.1-1 package version of ctest.exe, and the PLplot build was done with the "MSYS Makefiles" generator. In contrast to the MinGW-w64/MSYS2 platform case, ctest -j4 works fine for the Linux case. Has anyone else here had similar difficulties OR success with the parallel ctest option on the MinGW-w64/MSYS2 platform? Previously, Arjen had discovered that the parallel build -j4 option for make.exe (from the msys/make 4.1-4 package) was not reliable on this platform. I have forgotten all the details for that issue, but we didn't pursue it further at that time because Cygwin also had the same parallel make trouble so we wrote it off to some make.exe bug for Cygwin that had been copied to MinGW-w64/MSYS2 platform (since the two platforms are so closely related). Of course, it always possible on both platforms that some make race condition caused by a badly implemented CMake-based build system for PLplot could be the source of these parallel make issues. However, make -j4 works fine for the Linux case so if there is such a make race issue it is a subtle one. To eliminate this possibility does there exist a definitive way to search for make race conditions for CMake-based builds? (I am thinking along the lines of looking for duplicate "Building ..." lines in the output from "make all", but there may be some better method that someone here would like to suggest.) Assuming make race conditions can be eliminated as the cause of the issue with the make parallel build option, is there any obvious connection between that issue and the parallel ctest issue on this platform? For example, is the ctest parallel build option implemented using generator facilities (e.g., the parallel build option for make.exe) or do both the ctest and make implementations of their respective parallel options use some common library that could be screwing up on the MinGW-w64/MSYS2 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Changes for v3.5.0
On 2016-02-10 09:16-0500 Brad King wrote: On 02/10/2016 05:34 AM, Bartosz Kosiorek wrote: I have great news. With Nighly Build 3.5.20160208 the regression was gone Great, thanks for testing this! I got curious about how this affected the timing of configuration of the PLplot build so here are my results for that where in all cases I am taking timing numbers from the second run of cmake (starting with an empty build tree each time cmake is invoked) to account for all speed gains from ccache and memory caching. All CMake versions used below were built by me on Linux (Debian jessie) with the bootstrap method using export CFLAGS='-O3' export CXXFLAGS='-O3'. So this speed test between the various CMake versions should be a reasonably level playing field. Time required to configure PLplot with various versions of cmake: 3.3.2: real0m15.678s user0m11.472s sys 0m2.432s 3.4.3: real0m16.351s user0m11.988s sys 0m2.468s 3.5.0-rc2 (that tagged version from the git release branch this morning) real0m16.167s user0m11.812s sys 0m2.568s The 0.7 second increase in real time between 3.3.2 and 3.4.3 likely indicates a small (~4 per cent) but acceptable systematic regression in efficiency between those two versions. However, the 0.2 second decrease in real time between 3.4.3 and 3.5.0-rc2 is likely close to the measurement errors. Nevertheless, that result is consistent with Bartosz's result that the original large regression in efficiency he found for 3.5.0-rc1 compared to prior versions has now been completely solved for 3.5.0-rc2. My thanks to Bartosz for finding this efficiency regression for 3.5.0-rc1, and my thanks to Brad for fixing it for 3.5.0-rc2. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Changes for v3.5.0
On 2016-02-09 13:50-0500 Brad King wrote: On 02/09/2016 01:00 PM, James Bigler wrote: Will changes integrated into master automatically be slated for either v3.5.0 RC2 or v.3.5.0 final? No, the development window for 3.5 closed on Feb 1: https://cmake.org/pipermail/cmake-developers/2016-February/027637.html Hi Brad: So what branch should we follow if we want to test the on-going 3.5.x effort? I assumed it would be "release", but one of the key fixes to 3.5.0-rc1 is the efficiency one from my perspective, but I cannot find either "Fix internal target lookup performance regression" or "Improve internal generator target structure lookup" at <https://cmake.org/gitweb?p=cmake.git;a=shortlog;h=refs/heads/release>. Are those changes being "cooked" a bit longer or are they already in the release branch under some different title? 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Namespaces
On 2016-01-28 19:58+0100 Pau Garcia i Quiles wrote: Unfortunately ExternalProject does not work well with find_package, e. g. this fill fail: CMakeLists.txt | \--- 3rdparty/CMakeLists.txt \--- server/CMakeLists.txt Where: 3rdparty/CMakeLists.txt contains ExternalProject_Add(QtZeroConf ...) and server/CMakeLists.txt contains find_package(QtZeroConf) Hi Pau: Your experience is contrary to mine. For example, in my epa_build project (where I build all the many prerequisites of PLplot) I build a lot of different libraries (such as Qt5 and the GTK+ stack of libraries) using ExternalProject_Add, and I don't experience any difficulties using find_package to find the installed results. I assume find_package should work well with ExternalProject_Add for you as well so long as (a) all your ExternalProject(s) are configured to do both a build and install (not just a build), and (b) you are being careful in server/CMakeLists.txt to set PATH, CMAKE_LIBRARY_PATH, CMAKE_INCLUDE_PATH, and PKG_CONFIG_PATH consistently with the install prefix used for the ExternalProject(s). By the way, some versions of CMake-3.x.y have been plagued by substantial find issues, and your bad experience with find_package might be related to those issues. However, I haven't experienced any major find issues with CMake-3.3.2 so you might want to shift to that version if you aren't using it already. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Namespaces
On 2016-01-28 23:25+0100 Pau Garcia i Quiles wrote: On Thu, Jan 28, 2016 at 9:58 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: Your experience is contrary to mine. For example, in my epa_build project (where I build all the many prerequisites of PLplot) I build a lot of different libraries (such as Qt5 and the GTK+ stack of libraries) using ExternalProject_Add, and I don't experience any difficulties using find_package to find the installed results. I assume find_package should work well with ExternalProject_Add for you as well so long as (a) all your ExternalProject(s) are configured to do both a build and install (not just a build), and (b) you are being careful in server/CMakeLists.txt to set PATH, CMAKE_LIBRARY_PATH, CMAKE_INCLUDE_PATH, and PKG_CONFIG_PATH consistently with the install prefix used for the ExternalProject(s). It works well for you because you actually have two things there: - PlPlot - A superbuild that builds the dependencies required to build PlPlot, and then, PlPlot itself by way of ExternalProject_Add (using download_command = copy the source code from some directory to another) Hi Pau: Yes, that is a good summary, although I would add that all the dependencies are handled properly. So the result is you can epa_build any library (such as PLplot) within the epa_build project and the subset of the epa_builds corresponding to its dependencies automatically occur first, but only once (unless some change is made in one of the dependent epa_builds). The dependency handling for a given project is a bit complex, but, as you might expect, the dependency logic is essentially identical for each project so I could implement it using a CMake function. So the net result is the CMakeLists.txt file for each epa_build project is quite short consisting of establishing the list of dependencies, calling the dependency-handling function, setting up ExternalProject_Add for a given project, and then calling that routine. But what I would like to do with ExternalProject_Add (and please note this is a different topic than what I started the thread for) is to avoid that superbuild: You do have to build and install the external software once in any case so I suspect your motivation to avoid the "superbuild" is it keeps getting unnecessarily repeated in your case. But that should not be an issue if you deal with the dependencies correctly, see remarks above. I do take your point this is a different topic than your original one so if you want to continue this discussion, we should probably do it off list. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Namespaces
On 2016-01-28 18:47+0100 Pau Garcia i Quiles wrote: [...] In the root CMakeLists.txt, I have: add_subdirectory(3rdparty) And in 3rdparty/CMakeLists.txt: add_subdirectory(pugixml/scripts) add_subdirectory(QtZeroConf) add_subdirectory(QtDropBox) add_subdirectory(websocketpp) This is an easy way to work with third-party dependences. My problem comes from the fact several of these third-party libraries use common variable names, e. g. BUILD_SHARED, BUILD_TESTS, etc). Has some kind of namespacing been considered for add_subdirectory? I cannot answer that question, but I suggest instead that the proper way to deal with third-party libraries with no name contamination from the parent project is simply to build and install them using the ExternalProject approach. 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: http://public.kitware.com/mailman/listinfo/cmake-developers
