Re: [CMake] fortran compiler failed to compile simple test program
Very little. The whole point is to test that the compiler works the way CMake will invoke it in the generated build system. But the user does have tons of control over the generated build system so why can't he have same control have test program compilation? I think in this case someone forcing cmake/ld to link in /usr/lib would solve the issue. Or is it the case that user has pretty much same hooks for test program but only via command line since CMakeFiles.txt are not used (e.g. -DCMAKE_EXE_LINKER_FLAGS like you suggest below)? cmake . -DCMAKE_EXE_LINKER_FLAGS=-v to get more verbose output from the link step. The command below does not turn cf77 verbose on during test program compilation...any other suggestions for this? cmake . -DCMAKE_EXE_LINKER_FLAGS=-v -G Unix Makefiles It shouldn't matter if /usr/lib is in your PATH. The linker does not pay attention to PATH. Linkers normally look in /usr/lib by default. So the linker determines where to look for libs for test program and cmake plays no part in this? Seems surprising given that it works outside of cmake. So the question is: why does this work when invoked by hand but not when CMake invokes it? IDK this is bizarre. Then run that command line by hand. You can add -v to it too. Results are shown below. Looks identical to the hello world.f outside of cmake so it's a mystery why -lrt can't be found. Presumably the linker is not looking in /usr/lib when invoked by cmake, no? rts1-4:/home/bzpl46/test2/CMakeFiles/CMakeTmp /usr/ccs/bin/cf77 CMakeFiles/cmTryCompileExec3453195864.dir/testFortranCompiler.f.o -o cmTryCompileExec3453195864 -rdynamic /usr/ccs/release/7.3/lib_ia32/ld: cannot find -lrt rts1-4:/home/bzpl46/test2/CMakeFiles/CMakeTmp /usr/ccs/bin/cf77 -v CMakeFiles/cmTryCompileExec3453195864.dir/testFortranCompiler.f.o -o cmTryCompileExec3453195864 -rdynamic environment: PDE_RELEASE = 7.3 environment: PDE_LINUX_RELEASE = i386-redhat-linux environment: PDE_GCC_VERSION = 4.1.2 environment: PDE_CPU = pentium4 Linking executable: /usr/ccs/release/7.3/lib_ia32/ld -t -melf_i386 -u MAIN__ -dynamic-linker /lib/ld-linux.so.2 --allow-multiple-definition /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc/i386-redhat-linux/4.1.2/crtbeginT.o -v CMakeFiles/cmTryCompileExec3453195864.dir/testFortranCompiler.f.o -r -L/usr/ccs/release/7.3/lib_ia32 -L/usr/lib/gcc/i386-redhat-linux/4.1.2 -lhU77 -lhF77 -lhI77 -lrt -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh -o cmTryCompileExec3453195864 /usr/lib/gcc/i386-redhat-linux/4.1.2/crtend.o /usr/lib/crtn.o GNU ld version 2.17.50.0.6-5.el5 20061020 /usr/ccs/release/7.3/lib_ia32/ld: mode elf_i386 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc/i386-redhat-linux/4.1.2/crtbeginT.o CMakeFiles/cmTryCompileExec3453195864.dir/testFortranCompiler.f.o (/usr/ccs/release/7.3/lib_ia32/libhF77.a)main.o (/usr/ccs/release/7.3/lib_ia32/libhF77.a)main2.o (/usr/ccs/release/7.3/lib_ia32/libhF77.a)no_lg.o (/usr/ccs/release/7.3/lib_ia32/libhF77.a)xarg.o (/usr/ccs/release/7.3/lib_ia32/libhF77.a)fperoundset.o (/usr/ccs/release/7.3/lib_ia32/libhF77.a)fpetrapset.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)close.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)err.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)f_errlist.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)hf77_io.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)lwrite.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)open.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)util.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)wrtfmt.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)dofio.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)dolio.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)douio.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)fmt.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)fmtlib.o (/usr/ccs/release/7.3/lib_ia32/libhI77.a)sue.o /usr/ccs/release/7.3/lib_ia32/ld: cannot find -lrt This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake
Re: [CMake] fortran compiler failed to compile simple test program
On 06/16/2015 09:31 AM, Ette, Anthony (CDS) wrote: rts1-4:/home/bzpl46/test2/CMakeFiles/CMakeTmp /usr/ccs/bin/cf77 CMakeFiles/cmTryCompileExec3453195864.dir/testFortranCompiler.f.o -o cmTryCompileExec3453195864 -rdynamic /usr/ccs/release/7.3/lib_ia32/ld: cannot find -lrt That shows it can be reproduced locally outside of CMake. Please try dropping -rdynamic from that command line. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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
Re: [CMake] fortran compiler failed to compile simple test program
rts1-4:/home/bzpl46/test2/CMakeFiles/CMakeTmp /usr/ccs/bin/cf77 CMakeFiles/cmTryCompileExec3453195864.dir/testFortranCompiler.f.o -o cmTryCompileExec3453195864 -rdynamic /usr/ccs/release/7.3/lib_ia32/ld: cannot find -lrt That shows it can be reproduced locally outside of CMake. Please try dropping -rdynamic from that command line. Ahh, you are correct. Success! What does this mean? This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] fortran compiler failed to compile simple test program
On 06/16/2015 01:21 AM, Ette, Anthony (CDS) wrote: what control does the user have over the compilation of the test program? Very little. The whole point is to test that the compiler works the way CMake will invoke it in the generated build system. I.e. can I tell cmake to add -L (where to look for libraries) or -v (cf77 compiler verbose flag) when compiling the test program to avoid having to go to a full toolchain file and forcing the compiler? If you use CMake 3.2 or higher then you can try a test project like this: cmake_minimum_required(VERSION 3.2) project(cf77test Fortran) and run CMake as cmake . -DCMAKE_EXE_LINKER_FLAGS=-v to get more verbose output from the link step. I have found the -lrt is coming from /usr/lib/librt.so [snip] If /usr/lib is in my path It shouldn't matter if /usr/lib is in your PATH. The linker does not pay attention to PATH. Linkers normally look in /usr/lib by default. rts1-4:/home/bzpl46/test2 cf77 -v -g test.f Linking executable: /usr/ccs/release/7.3/lib_ia32/ld ... -lrt ... One can see that cf77 indeed adds -lrt to the link line itself. So the question is: why does this work when invoked by hand but not when CMake invokes it? In the test project you sent in a sibling message, try this: $ cd CMakeFiles/CMakeTmp $ cat CMakeFiles/cmTryCompileExec4035725976.dir/link.txt /usr/ccs/bin/cf77 CMakeFiles/cmTryCompileExec4035725976.dir/testFortranCompiler.f.o -o cmTryCompileExec4035725976 -rdynamic Then run that command line by hand. You can add -v to it too. Note that the 4035725976 number will be different each time so adapt to your local build tree accordingly. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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
[cmake-developers] [CMake 0015618]: HDF5 headers have migrated in linux/debian/sid -- FindHDF5.cmake doesn't detect them
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15618 == Reported By:Sebastian Wouters Assigned To: == Project:CMake Issue ID: 15618 Category: Modules Reproducibility:always Severity: crash Priority: normal Status: new == Date Submitted: 2015-06-16 09:30 EDT Last Modified: 2015-06-16 09:30 EDT == Summary:HDF5 headers have migrated in linux/debian/sid -- FindHDF5.cmake doesn't detect them Description: I got the following comment from someone who's helping me package my code for debian: 4. The include for HDF5 in CheMPS2/include/chemps2/MyHDF5.h is not working for me, there's no /usr/include/hdf5.h (anymore?). If I replace that with '#include hdf5/serial/hdf5.h', it builds fine. I have currently used a work-around to make debuild work for sid: https://github.com/SebWouters/CheMPS2/blob/master/CheMPS2/CMakeLists.txt According to HDF5's specifications, one should include hdf5.h, see section 5 on the page http://www.hdfgroup.org/ftp/HDF5/current/src/unpacked/release_docs/INSTALL In sid's packaged hdf5 version, this file is installed in /usr/include/hdf5/serial/: https://packages.debian.org/sid/amd64/libhdf5-dev/filelist Would it be possible to modify the FindHDF5.cmake so that it detects the hdf5 headers on sid and correctly sets the HDF5_INCLUDE_DIRS variable? Steps to Reproduce: Download and install debian/sid Get cmake, libatlas3-base, libgsl0-dev, and libhdf5-dev with the package manager Download chemps2 commit 226b04dfc07589804fbf7bf2b78b409b08d937eb, or earlier Try to build chemps2 with cmake Additional Information: The discussion at debichem's mailing list: http://lists.alioth.debian.org/pipermail/debichem-devel/2015-June/005963.html == Issue History Date ModifiedUsername FieldChange == 2015-06-16 09:30 Sebastian WoutersNew Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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-commits] CMake branch, next, updated. v3.3.0-rc2-479-g8ec6b90
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 8ec6b905a24f367e12486e39ef47ef5d2a3ba495 (commit)
via 502430e39cb6c3c860baf90cd9a0c400503e16af (commit)
via da4cddd787500b9da71e7c7877de9a17c6a7d1fc (commit)
from 52a9b25dc586855b12f9b800c5ec92b25a60b45c (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8ec6b905a24f367e12486e39ef47ef5d2a3ba495
commit 8ec6b905a24f367e12486e39ef47ef5d2a3ba495
Merge: 52a9b25 502430e
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Jun 16 08:49:37 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Jun 16 08:49:37 2015 -0400
Merge topic 'update-kwsys' into next
502430e3 Merge branch 'upstream-kwsys' into update-kwsys
da4cddd7 KWSys 2015-06-15 (d217407c)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=502430e39cb6c3c860baf90cd9a0c400503e16af
commit 502430e39cb6c3c860baf90cd9a0c400503e16af
Merge: 84672a8 da4cddd
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Jun 16 08:49:12 2015 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Jun 16 08:49:12 2015 -0400
Merge branch 'upstream-kwsys' into update-kwsys
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=da4cddd787500b9da71e7c7877de9a17c6a7d1fc
commit da4cddd787500b9da71e7c7877de9a17c6a7d1fc
Author: KWSys Robot kwro...@kitware.com
AuthorDate: Mon Jun 15 09:50:46 2015 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Jun 16 08:48:52 2015 -0400
KWSys 2015-06-15 (d217407c)
Extract upstream KWSys using the following shell commands.
$ git archive --prefix=upstream-kwsys/ d217407c | tar x
$ git shortlog --no-merges --abbrev=8 --format='%h %s' 8533a79b..d217407c
Brad King (1):
d217407c SystemTools: Fix preprocessor check WIN32 = _WIN32
diff --git a/SystemTools.cxx b/SystemTools.cxx
index c834e34..fed1c9c 100644
--- a/SystemTools.cxx
+++ b/SystemTools.cxx
@@ -4408,7 +4408,7 @@ bool SystemTools::FileIsFullPath(const char* in_name,
size_t len)
bool SystemTools::GetShortPath(const kwsys_stl::string path,
kwsys_stl::string shortPath)
{
-#if defined(WIN32) !defined(__CYGWIN__)
+#if defined(_WIN32) !defined(__CYGWIN__)
const int size = int(path.size()) +1; // size of return
char *tempPath = new char[size]; // create a buffer
DWORD ret;
---
Summary of changes:
Source/kwsys/SystemTools.cxx |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
Re: [cmake-developers] Generator expressions for output directory/name (and install?)
On 06/15/2015 03:03 PM, Robert Goulet wrote:
Updated with improved tests and added docs.
Thanks. Here are more comments.
Please split the patch to do the OUTPUT_NAME/dir changes first.
Update the Tests/PerConfig test to cover these. Since the
RUNTIME_OUTPUT_DIRECTORY properties are learning this, please
do it for ARCHIVE_OUTPUT_DIRECTORY and LIBRARY_OUTPUT_DIRECTORY
too for completeness.
Then do the install DESTINATION changes in a second patch.
That will simplify review.
In this hunk:
cmInstallTargetGenerator(
-cmTarget t, const char* dest, bool implib,
+cmMakefile* mf, cmTarget t, const char* dest, bool implib,
The cmTarget has a GetMakefile() method so there should be no
need to pass the mf separately.
In this hunk:
@@ -216,6 +216,7 @@ void
cmScriptGenerator::GenerateScriptActionsPerConfig(std::ostream os,
i != this-ConfigurationTypes-end(); ++i)
{
const char* config = i-c_str();
+ this-ConfigurationName = config;
if(this-GeneratesForConfig(config))
{
// Generate a per-configuration block.
This should not be needed if things are factored correctly.
Everything in that block already passes config through
as a parameter.
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] fortran compiler failed to compile simple test program
Ahh, you are correct. Success! What does this mean? I found this in the cf77 release notes, not sure if it means anything to us at this point. Linking with gcc, g++ or g77: This release ships with its own updated linker (ld) that can interpret DWARF 3. If you link cf77generated code using the gcc, g++, or g77 commands, they should be directed to use this alternativeld. This may be done by setting the COMPILER_PATH environment variable to one of the followingvalues:COMPILER_PATH=/usr/ccs/release/7.2/lib_ia32COMPILER_PATH=/usr/ccs/release/7.2/lib_amd64for 32-bit Pentium code or 64-bit AMD64 code, respectively. It important that the correct path bechosen.To make the COMPILER_PATH effective for the duration of a shell invocation, it can be exported:export COMPILER_PATH=...Or the variable may be set for a single invocation:COMPILER_PATH=... gcc ...If the COMPILER_PATH environment variable is omitted, the default system linker will be used; it willwork on correct programs, but error diagnostics may be inaccurate.The cf77 command will use the alternative ld without requiring the user to set the COMPILER_PATHenvironment variable. This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v3.3.0-rc2-482-gdcae581
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via dcae581eee3c3ef75f0dd5d8241e8ae898e9db74 (commit) via 15c6a4c9199e245a31d1e4cf45bd35f279bbc44d (commit) via 157396b131c3d7f5c7324972afaf3e185ee726b5 (commit) from 8ec6b905a24f367e12486e39ef47ef5d2a3ba495 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dcae581eee3c3ef75f0dd5d8241e8ae898e9db74 commit dcae581eee3c3ef75f0dd5d8241e8ae898e9db74 Merge: 8ec6b90 15c6a4c Author: Brad King brad.k...@kitware.com AuthorDate: Tue Jun 16 09:10:00 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Jun 16 09:10:00 2015 -0400 Merge topic 'quote-doxygen-tools' into next 15c6a4c9 Utilities/Doxygen: Support tools installed in paths with spaces 157396b1 CMake Nightly Date Stamp http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=15c6a4c9199e245a31d1e4cf45bd35f279bbc44d commit 15c6a4c9199e245a31d1e4cf45bd35f279bbc44d Author: Michael Stürmer michael.stuer...@schaeffler.com AuthorDate: Tue Jun 16 13:17:55 2015 +0200 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Jun 16 09:07:41 2015 -0400 Utilities/Doxygen: Support tools installed in paths with spaces Quote paths to tools in generation script. diff --git a/Utilities/Doxygen/doc_makeall.sh.in b/Utilities/Doxygen/doc_makeall.sh.in index ed7b521..fceafdd 100755 --- a/Utilities/Doxygen/doc_makeall.sh.in +++ b/Utilities/Doxygen/doc_makeall.sh.in @@ -130,7 +130,7 @@ export RESULTING_HTML_TARZ_ARCHIVE_FILE=$DOXTEMP/$PROJECT_NAME-html.tar.gz if test x@VTK_SOURCE_DIR@ != x ; then if test x$PERL_PROG != xNOTFOUND ; then -$PERL_PROG $PATH_TO_VTK_DOX_SCRIPTS/doc_contributors.pl \ +$PERL_PROG $PATH_TO_VTK_DOX_SCRIPTS/doc_contributors.pl \ --authors $SOURCE_DIR/Utilities/Doxygen/authors.txt \ --cachedir $DOXTEMP/cache \ --class_group '^(cm[A-Z0-9][A-Za-z0-9]+)\.(?:c|cpp|cxx|h|fl)$' \ @@ -158,7 +158,7 @@ if test x@VTK_SOURCE_DIR@ != x ; then fi if test x$GNUPLOT_PROG != xNOTFOUND ; then -$GNUPLOT_PROG $DOXTEMP/contrib/history.plt +$GNUPLOT_PROG $DOXTEMP/contrib/history.plt fi fi @@ -168,7 +168,7 @@ fi if test x$DOXYGEN_PROG != xNOTFOUND ; then if test x$RM_PROG != xNOTFOUND ; then -$RM_PROG -fr $OUTPUT_DIRECTORY +$RM_PROG -fr $OUTPUT_DIRECTORY fi $DOXYGEN_PROG $DOXYFILE @@ -182,7 +182,7 @@ fi if test x@VTK_SOURCE_DIR@ != x ; then if test x$PERL_PROG != xNOTFOUND ; then -$PERL_PROG $PATH_TO_VTK_DOX_SCRIPTS/doc_rmpath.pl \ +$PERL_PROG $PATH_TO_VTK_DOX_SCRIPTS/doc_rmpath.pl \ --verbose \ --to $INTERMEDIATE_DOX_DIR \ --html $OUTPUT_DIRECTORY/html @@ -198,7 +198,7 @@ if test x$COMPILE_HTML_HELP == xON ; then if test x$HHC_PROG != xNOTFOUND ; then $HHC_PROG index.hhp if test x$MV_PROG != xNOTFOUND ; then -$MV_PROG -f index.chm $RESULTING_HTML_HELP_FILE +$MV_PROG -f index.chm $RESULTING_HTML_HELP_FILE fi fi fi @@ -212,15 +212,15 @@ if test x$CREATE_HTML_TARZ_ARCHIVE == xON ; then cd $OUTPUT_DIRECTORY if test x$TAR_PROG != xNOTFOUND ; then if test x$RM_PROG != xNOTFOUND ; then -$RM_PROG -f html.tar +$RM_PROG -f html.tar fi -$TAR_PROG -cf html.tar html +$TAR_PROG -cf html.tar html if test x$GZIP_PROG != xNOTFOUND ; then if test x$RM_PROG != xNOTFOUND ; then -$RM_PROG -f html.tar.gz +$RM_PROG -f html.tar.gz fi -$GZIP_PROG html.tar -$MV_PROG -f html.tar.gz $RESULTING_HTML_TARZ_ARCHIVE_FILE +$GZIP_PROG html.tar +$MV_PROG -f html.tar.gz $RESULTING_HTML_TARZ_ARCHIVE_FILE fi fi fi @@ -230,18 +230,18 @@ fi # Clean-up. if test x$RM_PROG != xNOTFOUND ; then -$RM_PROG -fr $INTERMEDIATE_DOX_DIR +$RM_PROG -fr $INTERMEDIATE_DOX_DIR if test x$DOWNLOAD_VTK_TAGFILE == xON ; then if test x$VTK_TAGFILE != x ; then -$RM_PROG -f $VTK_TAGFILE_DEST_DIR/$VTK_TAGFILE +$RM_PROG -f $VTK_TAGFILE_DEST_DIR/$VTK_TAGFILE fi fi if test x$COMPILE_HTML_HELP == xON ; then if test x$RESULTING_HTML_HELP_FILE != x ; then if test x$ALLOW_ERASE_OUTPUT_DIRECTORY == xON ; then -$RM_PROG -fr $OUTPUT_DIRECTORY +$RM_PROG -fr $OUTPUT_DIRECTORY fi fi
Re: [cmake-developers] [PATCH] if absolute path of a used tool (*_PROG) contains white spaces, generation of documentation may fail
On 06/16/2015 07:27 AM, Stuermer, Michael SP/HZA-ZSEP wrote: putting some around tool-names Applied, thanks: Utilities/Doxygen: Support tools installed in paths with spaces http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=15c6a4c9 -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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] fortran compiler failed to compile simple test program
On 06/16/2015 10:00 AM, Ette, Anthony (CDS) wrote: That shows it can be reproduced locally outside of CMake. Please try dropping -rdynamic from that command line. Ahh, you are correct. Success! What does this mean? This means CMake needs to be able to define and detect an id for this compiler so that it can know that -rdynamic is not supported. Currently the compiler looks like a GNU compiler which does support the flags. Even if a preprocessor symbol is not available CMake does have other ways to detect the compiler id. We need to be able to run the compiler with just one flag that causes it to print out some kind of identifying information but not compile anything. See here for some examples: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineFortranCompiler.cmake;hb=v3.3.0-rc2#l114 -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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
[Cmake-commits] CMake branch, master, updated. v3.3.0-rc2-170-gee223df
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via ee223dfa9138cfe960d5d7a6dc14b044b7e032bf (commit) via 83af11d4112443ed732cd240eb0bfdfd27048825 (commit) from e5ed8b22cb540425f7806257a96b834dcb3fb2c7 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ee223dfa9138cfe960d5d7a6dc14b044b7e032bf commit ee223dfa9138cfe960d5d7a6dc14b044b7e032bf Merge: e5ed8b2 83af11d Author: Brad King brad.k...@kitware.com AuthorDate: Tue Jun 16 10:39:12 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Jun 16 10:39:12 2015 -0400 Merge topic 'fix-windows-preprocessor-checks' 83af11d4 Fix preprocessor checks WIN32 = _WIN32 --- Summary of changes: Source/cmExecProgramCommand.cxx |6 +++--- Source/cmFileCommand.cxx|6 +++--- Source/cmQtAutoGenerators.cxx |2 +- 3 files changed, 7 insertions(+), 7 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.3.0-rc2-168-ge5ed8b2
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via e5ed8b22cb540425f7806257a96b834dcb3fb2c7 (commit)
via 90ad087ab9075cc9648df0623502da0caa44e971 (commit)
via 7195ec92b2f34ef16ff1382fb00f527a3609f3bf (commit)
from b6b4a1cb12c6aed2637961f380247f8234e864ef (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e5ed8b22cb540425f7806257a96b834dcb3fb2c7
commit e5ed8b22cb540425f7806257a96b834dcb3fb2c7
Merge: b6b4a1c 90ad087
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Jun 16 10:39:10 2015 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Jun 16 10:39:10 2015 -0400
Merge topic 'cmake--build-dir'
90ad087a cmake: Fix --build relative-dir for VS generators (#15609)
7195ec92 Tests: Extend RunCMake.CommandLine to cover --build with no arg
---
Summary of changes:
Source/cmakemain.cxx |2 +-
Tests/RunCMake/CommandLine/BuildDir.cmake |1 +
.../{Build.cmake = BuildDir/CMakeLists.txt} |0
Tests/RunCMake/CommandLine/RunCMakeTest.cmake | 17 +
.../build-bad-dir-result.txt} |0
Tests/RunCMake/CommandLine/build-bad-dir-stderr.txt |2 ++
.../build-no-dir-result.txt} |0
Tests/RunCMake/CommandLine/build-no-dir-stderr.txt|1 +
8 files changed, 22 insertions(+), 1 deletion(-)
create mode 100644 Tests/RunCMake/CommandLine/BuildDir.cmake
copy Tests/RunCMake/CommandLine/{Build.cmake = BuildDir/CMakeLists.txt} (100%)
copy Tests/RunCMake/{CMP0004/CMP0004-NEW-result.txt =
CommandLine/build-bad-dir-result.txt} (100%)
create mode 100644 Tests/RunCMake/CommandLine/build-bad-dir-stderr.txt
copy Tests/RunCMake/{CMP0004/CMP0004-NEW-result.txt =
CommandLine/build-no-dir-result.txt} (100%)
create mode 100644 Tests/RunCMake/CommandLine/build-no-dir-stderr.txt
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.3.0-rc2-484-gabf480d
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via abf480d40e0f5b628ba7c91efcfd839eb1f6a5a8 (commit) via 1199ebf1c53f7f591e412617afdaaf4ccd5bc0ff (commit) from dcae581eee3c3ef75f0dd5d8241e8ae898e9db74 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=abf480d40e0f5b628ba7c91efcfd839eb1f6a5a8 commit abf480d40e0f5b628ba7c91efcfd839eb1f6a5a8 Merge: dcae581 1199ebf Author: Brad King brad.k...@kitware.com AuthorDate: Tue Jun 16 10:33:59 2015 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Jun 16 10:33:59 2015 -0400 Merge topic 'GNUInstallDirs-doc-format' into next 1199ebf1 GNUInstallDirs: Improve documentation formatting http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1199ebf1c53f7f591e412617afdaaf4ccd5bc0ff commit 1199ebf1c53f7f591e412617afdaaf4ccd5bc0ff Author: Brad King brad.k...@kitware.com AuthorDate: Tue Jun 16 10:30:59 2015 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Jun 16 10:33:48 2015 -0400 GNUInstallDirs: Improve documentation formatting Also consolidate the description of each variable. diff --git a/Modules/GNUInstallDirs.cmake b/Modules/GNUInstallDirs.cmake index c61e7e9..82258d1 100644 --- a/Modules/GNUInstallDirs.cmake +++ b/Modules/GNUInstallDirs.cmake @@ -4,57 +4,62 @@ # # Define GNU standard installation directories # -# Provides install directory variables as defined for GNU software: +# Provides install directory variables as defined by the +# `GNU Coding Standards`_. # -# http://www.gnu.org/prep/standards/html_node/Directory-Variables.html +# .. _`GNU Coding Standards`: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html # # Inclusion of this module defines the following variables: # # ``CMAKE_INSTALL_dir`` -# destination for files of a given type +# +# Destination for files of a given type. This value may be passed to +# the ``DESTINATION`` options of :command:`install` commands for the +# corresponding file type. +# # ``CMAKE_INSTALL_FULL_dir`` -# corresponding absolute path # -# where dir is one of: +# The absolute path generated from the corresponding ``CMAKE_INSTALL_dir`` +# value. If the value is not already an absolute path, an absolute path +# is constructed typically by prepending the value of the +# :variable:`CMAKE_INSTALL_PREFIX` variable. +# +# where ``dir`` is one of: # # ``BINDIR`` -# user executables (bin) +# user executables (``bin``) # ``SBINDIR`` -# system admin executables (sbin) +# system admin executables (``sbin``) # ``LIBEXECDIR`` -# program executables (libexec) +# program executables (``libexec``) # ``SYSCONFDIR`` -# read-only single-machine data (etc) +# read-only single-machine data (``etc``) # ``SHAREDSTATEDIR`` -# modifiable architecture-independent data (com) +# modifiable architecture-independent data (``com``) # ``LOCALSTATEDIR`` -# modifiable single-machine data (var) +# modifiable single-machine data (``var``) # ``LIBDIR`` -# object code libraries (lib or lib64 or lib/multiarch-tuple on Debian) +# object code libraries (``lib`` or ``lib64`` +# or ``lib/multiarch-tuple`` on Debian) # ``INCLUDEDIR`` -# C header files (include) +# C header files (``include``) # ``OLDINCLUDEDIR`` -# C header files for non-gcc (/usr/include) +# C header files for non-gcc (``/usr/include``) # ``DATAROOTDIR`` -# read-only architecture-independent data root (share) +# read-only architecture-independent data root (``share``) # ``DATADIR`` -# read-only architecture-independent data (DATAROOTDIR) +# read-only architecture-independent data (``DATAROOTDIR``) # ``INFODIR`` -# info documentation (DATAROOTDIR/info) +# info documentation (``DATAROOTDIR/info``) # ``LOCALEDIR`` -# locale-dependent data (DATAROOTDIR/locale) +# locale-dependent data (``DATAROOTDIR/locale``) # ``MANDIR`` -# man documentation (DATAROOTDIR/man) +# man documentation (``DATAROOTDIR/man``) # ``DOCDIR`` -# documentation root (DATAROOTDIR/doc/PROJECT_NAME) +# documentation root (``DATAROOTDIR/doc/PROJECT_NAME``) # -# Each CMAKE_INSTALL_dir value may be passed to the DESTINATION -# options of install() commands for the corresponding file type. If the -# includer does not define a value the above-shown default will be used -# and the value will appear in the cache for editing by the user. Each -# CMAKE_INSTALL_FULL_dir value contains an absolute path constructed -# from the corresponding destination by prepending (if necessary) the -# value of CMAKE_INSTALL_PREFIX. +# If the includer does not
[Cmake-commits] CMake branch, next, updated. v3.3.0-rc2-489-g76e4fea
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 76e4fea2e61b35f16982973c8b25d954907c086a (commit) via 5e92047421a60a7287ff00fdc9dec33b1acc94ec (commit) via ee223dfa9138cfe960d5d7a6dc14b044b7e032bf (commit) via e5ed8b22cb540425f7806257a96b834dcb3fb2c7 (commit) via b6b4a1cb12c6aed2637961f380247f8234e864ef (commit) from abf480d40e0f5b628ba7c91efcfd839eb1f6a5a8 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=76e4fea2e61b35f16982973c8b25d954907c086a commit 76e4fea2e61b35f16982973c8b25d954907c086a Merge: abf480d 5e92047 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Jun 16 10:39:27 2015 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Jun 16 10:39:27 2015 -0400 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[CMake] Xcode project generation failed
Running OS X 10.8.5 with Xcode 5.1.1 and Cmake 3.2.x and 3.3.RC and neither generate a Xcode project file that can be opened by Xcode. We get valid Ninja and Makefile projects for our project. I was wondering if anyone else has seen this issue. Not sure if there is something in our project that is hanging up CMake. Thanks for any insights. Mike Jackson BlueQuartz Software. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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
[CMake] --sphinx-qthelp leads to build error with CMake 3.2.3
Hi, I'm trying to build the latest CMake release, with the Qt4 gui and including the docs in Qt help format. I'm using the same recipe as for the 3.2.2 release, but now I see this: [ 95%] sphinx-build qthelp: see Utilities/Sphinx/build-qthelp.log cd /build//cmake-3.2.3/Utilities/Sphinx /opt/local/bin/sphinx-build-3.4 -c /build//cmake-3.2.3/Utilities/Sphinx -d /build//cmake-3.2.3/Utilities/Sphinx/doctrees -b qthelp /build//cmake-3.2.3/Help /build//cmake-3.2.3/Utilities/Sphinx/qthelp build-qthelp.log WARNING: 'default' html theme has been renamed to 'classic'. Please change your html_theme setting either to the new 'alabaster' default theme, or to 'classic' to keep using the old default. cd /build//cmake-3.2.3/Utilities/Sphinx ../../Bootstrap.cmk/cmake -DCSS_DIR=/build//cmake-3.2.3/Utilities/Sphinx/qthelp/_static -P /build//cmake-3.2.3/Utilities/Sphinx/apply_qthelp_css_workaround.cmake CMake Error at apply_qthelp_css_workaround.cmake:4 (file): file failed to open for reading (No such file or directory): /build//cmake-3.2.3/Utilities/Sphinx/qthelp/_static/default.css Utilities/Sphinx/CMakeFiles/documentation.dir/build.make:63: recipe for target 'Utilities/Sphinx/doc_format_qthelp' failed make[2]: *** [Utilities/Sphinx/doc_format_qthelp] Error 1 I cannot vouch that the WARNING wasn't already there last time, but the fact that a file called default.css is missing while there is a classic.css might be significant. I've google the error a bit, but so far haven't found anything relevant AND recent. Thanks, René -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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
Re: [CMake] fortran compiler failed to compile simple test program
http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineFortranCompiler.cmake;hb=v3.3.0-rc2#l114 Ok. I'm still struggling getting anything unique from the cf77 command line. They have plenty of custom functions that can be invoked outside of cf77 but that wouldn't be suitable for cmake. Also, I got a response from Concurrent on the issue with the -rdynamic option. Please see his resonse below and let me know what you think. I need to get Cmake to work and, ideally, I'd like it to work with -rdynamic. I'm wondering if there is something they can change (other than the ugly kludge he references) to get -rdynamic to work. Hi Anthony: Okay, the -rdynamic option to cf77 instructs it to build a shared object (shared library), not an executable program. I doubt this is what you intended, rather CMake just wanted to link the program with the system dynamic libraries -- it's unclear. By default, cf77 links in all system libraries dynamically anyway, which is a standard default way most compilers operate in the Linux world. I'm not sure why CMake would be passing -rdynamic along, unless you really are trying to build a dynamic fortran shared library. (It is possible it is trying to force a transitive closure of symbol references for debugging purposes -- that's what gcc describes its -rdynamic option as doing). I don't use CMake, and I can imagine it may be difficult to use if it isn't flexible wrt compilation and linking options. If you could abandon CMake for standard GNU make, that would be good, but of course that may not be acceptable to you in terms of man power, style, etc. If CMake is indeed forcing this option on every command that links a program, the best I can recommend is to replace the /usr/css/bin/cf77 with a wrapper that strips out the option and then continues to invoke the real cf77. That is of course a horrible kludge. If you would like me to supply you with that (albeit disgusting) workaround, just let me know. I'd recommend fighting with CMake first. Alternative, I can supply you with some simple example gmake Makefiles that you might use with cf77. Please let me know what you think about this. Also, I'm concerned that your man pages are not installed properly (the CF77 man pages). I recommend doing the following to rectify that: rpm -q ccurf77-manpages-7.3 --nodeps rpm -Uvh cf77-manpages-7.3*.rpm # File attached man cf77 If that does not work, please try the following: man -M /opt/ccur/compilers-7.3/man cf77 If that works, then you can put that path in your MANPATH environment variable, or edit /etc/man.config and put the path in that file so everyone will benefit from it. Alternatively, we can chase this down to the final bit depending on how much time you want to spend on it. -- Jeff This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] fortran compiler failed to compile simple test program
What is the output of cf77 --version? Garbage (see below): rts1-4:/home/bzpl46 cf77 --version cf77 Fatal Error: invalid flag -io I've scoured the cf77 docs and found nothing native so I've responded to concurrent and again asked how I can find unique identifying information for cmake to latch onto. Will report back. That may be what it tells cf77 but that is not what it tells gcc. From man gcc: Anyway we should drop it for cf77 once we can identify that compiler as distinct from a GNU compiler. Agreed on both counts although I've challenged concurrent to justify their decision to treat -rdynamic different than standard GNU. I think ideally cf77 would handle -rdynamic same as standard GNU. If that's really not an option, we should continue down the path of having cmake identify cf77 and strip the option. Thank you again for all your help - you rock! This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] fortran compiler failed to compile simple test program
On 06/16/2015 01:44 PM, Ette, Anthony (CDS) wrote: I'm still struggling getting anything unique from the cf77 command line. What is the output of cf77 --version? Okay, the -rdynamic option to cf77 instructs it to build a shared object (shared library), not an executable program. That may be what it tells cf77 but that is not what it tells gcc. From man gcc: -rdynamic Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker to add all symbols, not only used ones, to the dynamic symbol table. This option is needed for some uses of dlopen or to allow obtaining backtraces from within a program. Anyway we should drop it for cf77 once we can identify that compiler as distinct from a GNU compiler. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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
Re: [CMake] Xcode project generation failed
Hello, I applied some fixes to what becomes CMake 3.3. could you please test the release candidate? On 16/06/15 16:27, Michael Jackson wrote: Running OS X 10.8.5 with Xcode 5.1.1 and Cmake 3.2.x and 3.3.RC and neither generate a Xcode project file that can be opened by Xcode. We get valid Ninja and Makefile projects for our project. I was wondering if anyone else has seen this issue. Not sure if there is something in our project that is hanging up CMake. Could you share your project.pbxproj file (if don't want to share it here you could also mail it to me directly). Thanks, Gregor -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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
Re: [CMake] Xcode project generation failed
On 16/06/15 21:27, Gregor Jasny wrote: Hello, I applied some fixes to what becomes CMake 3.3. could you please test the release candidate? Sorry, somehow overlooked the statement about RC in your mail. On 16/06/15 16:27, Michael Jackson wrote: Running OS X 10.8.5 with Xcode 5.1.1 and Cmake 3.2.x and 3.3.RC and neither generate a Xcode project file that can be opened by Xcode. We get valid Ninja and Makefile projects for our project. I was wondering if anyone else has seen this issue. Not sure if there is something in our project that is hanging up CMake. Could you share your project.pbxproj file (if don't want to share it here you could also mail it to me directly). -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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
[cmake-developers] [CMake 0015619]: ctest stderr vs stdout
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15619
==
Reported By:Clinton Stimpson
Assigned To:
==
Project:CMake
Issue ID: 15619
Category: CTest
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-06-16 18:41 EDT
Last Modified: 2015-06-16 18:41 EDT
==
Summary:ctest stderr vs stdout
Description:
I have a ctest script which basically has:
ctest_start()
...
ctest_build()
ctest_test()
I invoke that script with
ctest -V -S my.ctest 1mytest.stdout 2mytest.stderr
And I'm hoping that mytest.stderr will contain only errors in my script, not
build or test errors from within ctest_build() and ctest_test().
However, errors like
Unable to find executable: /path/to/executable
from ctest_test() can leak into the mytest.stderr if there are build errors.
I don't think that is expected behavior.
Steps to Reproduce:
All in the same directory:
=== CMakeLists.txt ===
include (CTest)
add_test(NAME MyTest COMMAND nonexist_executable)
=== my.ctest ===
set(CTEST_SOURCE_DIRECTORY ${CMAKE_CURRENT_LIST_DIR})
set(CTEST_BINARY_DIRECTORY ${CMAKE_CURRENT_LIST_DIR})
ctest_start(Experimental)
ctest_test()
=== CTestConfig.cmake ===
empty
Then run
cmake .
ctest -V -S my.ctest 1 mytest.stdout 2 mytest.stderr
Look at the output of mytest.stdout and mytest.stderr
Also, mytest.stderr contains:
Error in read script: /home/cjstimp/cubit/cdash/test-ctest/my.ctest
However, the script itself did run successfully.
==
Issue History
Date ModifiedUsername FieldChange
==
2015-06-16 18:41 Clinton StimpsonNew Issue
==
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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-commits] CMake branch, master, updated. v3.3.0-rc2-173-gee5c40a
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via ee5c40a5f8e7dbbea7b0576c184003a7f86646ba (commit) from 5e92047421a60a7287ff00fdc9dec33b1acc94ec (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ee5c40a5f8e7dbbea7b0576c184003a7f86646ba commit ee5c40a5f8e7dbbea7b0576c184003a7f86646ba Author: Kitware Robot kwro...@kitware.com AuthorDate: Wed Jun 17 00:01:04 2015 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Wed Jun 17 00:01:04 2015 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 495551b..c0f56d2 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 3) -set(CMake_VERSION_PATCH 20150616) +set(CMake_VERSION_PATCH 20150617) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
Re: [cmake-developers] Startup Project Configuration [mantis 15578]
Okay, The first 3 points are easy and done. But for the unit test, I'm a little lost. I found the files you're talking about. I'm not quite sure what those undocumented macros are doing. I would say though, that I'm not trying to parse the 'GlobalSection' part of the .sln file, I just need to make sure that the specified project is the first Project( statement in the .sln file. Would that involve different macro's anyhow? I could try and write a macro specifically to check that, or were you thinking I should be able to use the macros that are already there? And would you be opposed to my writing a dedicated one? Thanks On 06/04/2015 08:03 AM, Brad King wrote: On 06/03/2015 04:35 PM, Davy Durham wrote: Okay, here's my patch. It worked on my system. I tested with the versions I have installed: VS 2008 and VS 2013, and it worked great. Fairly simple. Updated the docs [sufficiently, I think]. That looks pretty good. A few comments: * Please provide a proposed commit message. The first line should end with (#15578) to reference the issue tracker entry. * Please wrap lines in C++ sources to = 79 columns. * Please use this- for references to member variables (e.g. this-FirstProject). * Please look at adding a test case, perhaps as a new case in Tests/RunCMake/SolutionGlobalSections/RunCMakeTest.cmake. That test already has code to parse the generated solution. You can parse it to verify the desired project is first (and perhaps a second case to verify ALL_BUILD is the default). Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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] [PATCH] fixed msvc 64 bit build
-Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Monday, June 15, 2015 4:11 PM To: Stuermer, Michael SP/HZA-ZSEP Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] [PATCH] fixed msvc 64 bit build On 06/15/2015 07:58 AM, Stuermer, Michael SP/HZA-ZSEP wrote: This is just a one-char-bugfix, WIN32 instead of _WIN32 macro was used. Thanks. There are several instances of this in Source/*. I've fixed the one you pointed out and more: Fix preprocessor checks WIN32 = _WIN32 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=83af11d4 There is one other in Source/kwsys that I've fixed in upstream KWSys: http://review.source.kitware.com/19926 and will integrate back to CMake after testing there. Are there any regular Win64 builds done actually? Yes. We have nightly testing for it which has been clean. It is also my main Windows development architecture. The WIN32 symbol is normally defined by CMAKE_CXX_FLAGS if the default flags are used for MSVC. How did you configure the build? -Brad My setup was roughly: - Visual Studio 2013 - CMake 3.0.2 - Qt4.8.6 - Qt dialog enabled - Documentation enabled - cpack with NSIS WIX enabled - no special compiler configuration or so ... I can not really reproduce if there was something broken in my CMake installation as I replaced it after successful build, but I didn't change any flags deliberately. It doesn't really matter, but isn't the WIN32 symbol defined in a common place for both 32 and 64 bit configurations? This makes it a bit interesting, as the 32 bit build worked flawlessly. Michael -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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] Compact dependency graph
On 06/15/2015 09:46 PM, Richard Ulrich wrote:
So here is the patch with tests and passing the git hooks.
Thank you for the update and sorry again for the inconvenience.
- Your commit's subject line looks a bit too long; I'd move the issue
number into the bulk of the message (It should nicely fit into the
console in git log).
- In RegexReplacerCallback you've got lowercase members that start with
underscore. I'd change that to follow the same convention you used in
e.g. RegexReplacer (camel case starting upper case).
- I think the tests visible to ctest are a bit too granular. I would
subsume related tests into one ctest visible test (e.g. as is done for
CommandLineTar).
- The RunCMake.graphviz_no_filter and RunCMake.graphviz_filter_even
tests currently seem to fail for me.
Comparing expected.dot with the actual output of e.g.
RunCMake.graphviz_no_filter shows basically the same content but the
node numbering is entirely different.
I'd try to see if either node numbering could be made consistent (I am
not sure why it isn't) or use regular expression matching on the
expected results instead (as is e.g. done by RunCMake for stderr/stdout).
Something like ...
file(READ ... actual)
file(READ ... expected)
if(NOT actual MATCHES ${expected})
message(FATAL_ERROR ... ${actual} ... ${expected})
endif()
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] CMake Build RPM for Centos/RHEL
2. Is there a way to generate a RPM with standard name:
I mean, something like: cmake-3.2.3-1.el6.x86_64.rpm
Instead of: cmake-3.2.3-Linux-x86_64.rpm
You can add
-D CPACK_OUTPUT_FILE_NAME=cmake-${RPM_RELEASE}.el6.x86_64.rpm
to your packaging command. This will force package name.
Forcing the name will cause a CPack error:
CPack Error: Problem copying the package
but at that point the package was already created - you just have to
find it as it wasn't copied from rpmbuild dir to cmake root dir:
find . -name *.rpm | xargs -i{ cp { ./
3. I tried what I built, but:
CMake Error: Could not find CMAKE_ROOT !!!
CMake has most likely not been installed correctly.
Modules directory not found in
/usr/share/cmake-3.2
CMake Error: Error executing cmake::LoadCache(). Aborting.
Problem is that the created directory exists but it can't be read
because of permissions: drwxr-x---.
That's odd... If I run the command below on rpm created from cmake
repository master branch I get different permissions:
rpm -qp --qf [%-15{=NAME} %-36{FILENAMES} %{FILEMODES:perms}\n]
cmake-3.3.20150607-gcb1a9-Linux-x86_64.rpm | grep Modules
cmake /usr/share/cmake-3.3/Modules drwxr-xr-x
Regards,
Domen
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] determining which system headerfile provides a given function
On Monday June 15 2015 23:05:07 Alexander Neundorf wrote: if you have multiple candidate headers, try them all, and use separate result variables for every one. Is that the problem you have ? Yes. That's probably the thing I missed and why it didn't work; I used a single variable. Still, it seems surprising there's no predefined macro that would help make things easier in this kind of scenario that cannot be that uncommon (at least it used to be quite common, like for instance with string.h vs. strings.h). A macro that takes a list of candidates and returns the name of the appropriate file would seem useful, no? R. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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
Re: [cmake-developers] CMake Build RPM for Centos/RHEL
Hi Domen,
Thanks, I'll try the CPACK_OUTPUT_FILE_NAME option.
This morning I found an alternative for the permission issue.
As the default attribute in the SPEC file is (-, root, root, -) I tried to
fix generated files.
So I added umask at the beginning of my script and it works!
$ umask 0022
$ wget http://www.cmake.org/files/v3.2/cmake-${VERSION}.tar.gz
Regards,
Jean
-Original Message-
From: Domen Vrankar [mailto:domen.vran...@gmail.com]
Sent: mardi 16 juin 2015 10:00
To: Jean Audibert
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] CMake Build RPM for Centos/RHEL
2. Is there a way to generate a RPM with standard name:
I mean, something like: cmake-3.2.3-1.el6.x86_64.rpm
Instead of: cmake-3.2.3-Linux-x86_64.rpm
You can add
-D CPACK_OUTPUT_FILE_NAME=cmake-${RPM_RELEASE}.el6.x86_64.rpm
to your packaging command. This will force package name.
Forcing the name will cause a CPack error:
CPack Error: Problem copying the package
but at that point the package was already created - you just have to find it as
it wasn't copied from rpmbuild dir to cmake root dir:
find . -name *.rpm | xargs -i{ cp { ./
3. I tried what I built, but:
CMake Error: Could not find CMAKE_ROOT !!!
CMake has most likely not been installed correctly.
Modules directory not found in
/usr/share/cmake-3.2
CMake Error: Error executing cmake::LoadCache(). Aborting.
Problem is that the created directory exists but it can't be read
because of permissions: drwxr-x---.
That's odd... If I run the command below on rpm created from cmake repository
master branch I get different permissions:
rpm -qp --qf [%-15{=NAME} %-36{FILENAMES} %{FILEMODES:perms}\n]
cmake-3.3.20150607-gcb1a9-Linux-x86_64.rpm | grep Modules
cmake /usr/share/cmake-3.3/Modules drwxr-xr-x
Regards,
Domen
_
This message may contain confidential information and is intended for specific
recipients unless explicitly noted otherwise. If you have reason to believe you
are not an intended recipient of this message, please delete it and notify the
sender. This message may not represent the opinion of Euronext N.V. or any of
its subsidiaries or affiliates, and does not constitute a contract or
guarantee. Unencrypted electronic mail is not secure and the recipient of this
message is expected to provide safeguards from viruses and pursue alternate
means of communication where privacy or a binding message is desired.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] How does :: actually works?
On Monday 15 June 2015 22:43:41 you wrote: Just a last question: I assume that most find module scripts distributed with cmake are not using this feature at the moment, right? Sadly, no. After reading your explaination I looked at documentation for FindBoost and FindGTest which are both used in all my projects and they dont seem to provide import targets. Are there plans to update the cmake scripts distributed with CMake On the one hand, FindPackage modules are, as far as I'm aware, slowly being updated to use imported targets. On the other hand, quite a few packages are missing a maintainer[1]. If you are using a package and want it to provide imported targets, I think your best bet is to propose a patch for the module and get it into cmake. That said, its worth mentioning that FindPackage modules are only intended for legacy projects which do not provide a PackageConfig.cmake file. If you are writing a new project, especially if it's based on cmake, you should write a PackageConfig.cmake file instead [2]. or is it just assumed that projects willing to use importing targets will write them somewhere before using them? Creating imported targets on your own is not the way to go. Better file a bug report or write a patch to add the functionality and get that into cmake. IMO, until the official module provides imported targets, you're better off using the old way. Cheers, Johannes [1] http://www.cmake.org/Wiki/CMake:Module_Maintainers#List [2] http://www.cmake.org/Wiki/CMake/Tutorials#CMake_Packages -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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
[cmake-developers] [PATCH] if absolute path of a used tool (*_PROG) contains white spaces, generation of documentation may fail
I have doxygen, gnuplot, html help and the UnxUtils in C:\Program Files (x86)\ This leads to errors when using one of these tools. I hope putting some around tool-names does not break anything on linux. Best Regards Michael Stürmer 0001-if-absolute-path-of-a-used-tool-_PROG-contains-white.patch Description: 0001-if-absolute-path-of-a-used-tool-_PROG-contains-white.patch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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
