Re: [CMake] CMake 2.8.1 RC 3 is ready to try
I think I have found a bug with 3.8.1. I have a few projects that use relative link paths and they throw a warning for CMP0015. I have pushed to the policy stack CMP0015 OLD to avoid the warnings till I fix the projects and currently the policy being set to old does nothing. On Fri, Feb 19, 2010 at 8:25 AM, Brad King brad.k...@kitware.com wrote: On 2/18/2010 8:38 PM, Samuel E. Henley wrote: I have a new warning warning: -fPIC ignored for target (all code is position independent) Under Windows - Mingw CMAKE_SHARED_LIBRARY_C_FLAGS and CMAKE_SHARED_LIBRARY_CXX_FLAGS has to be cleared of -fPIC, -fIPC is not used with gcc in Windows. This release candidate had some major platform information file reorganization to make it easier to add new compilers. The new files generically use -fPIC for compiling objects with GCC for shared libraries on all platforms. In the Platform/CYGWIN-GNU.cmake file we remove the flag, but it should be removed by Platform/Windows-GNU.cmake also. Fixed in CVS HEAD: Suppress GNU flag -fPIC on Windows /cvsroot/CMake/CMake/Modules/Platform/Windows-GNU.cmake,v -- Modules/Platform/Windows-GNU.cmake new revision: 1.2; previous revision: 1.1 I'll stage this for 2.8.1-rc4. -Brad ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
Philip Schwartz wrote:
Currently when setting CMP0015 to old, the warnings are still displayed.
As the policy is only a warning policy at this time there is no breakage
of the configure step other then a lot of unneeded warnings.
Use cmake_policy(GET) to check the policy value right before the call
to link_directories. The code in question looks like this:
switch (this-Makefile-GetPolicyStatus(cmPolicies::CMP0015))
{
case cmPolicies::WARN:
e policies-GetPolicyWarning(cmPolicies::CMP0015);
this-Makefile-IssueMessage(cmake::AUTHOR_WARNING, e.str());
case cmPolicies::OLD:
// OLD behavior does not convert
break;
...
}
so if it is warning then we can be fairly sure the command does not
see your setting.
Note that any call to cmake_minimum_required(VERSION ...) will reset
all policies to the defaults for the specified version. If that comes
after your call to cmake_policy(SET) then it will erase your setting.
-Brad
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
Currently when setting CMP0015 to old, the warnings are still displayed. As the policy is only a warning policy at this time there is no breakage of the configure step other then a lot of unneeded warnings. On Thu, Feb 25, 2010 at 1:23 PM, David Cole david.c...@kitware.com wrote: The policy being set to old is supposed to give the same behavior as prior versions of CMake, but also suppress the warning. What behavior are you seeing that makes you say setting it to old does nothing? On Thu, Feb 25, 2010 at 10:39 AM, Philip Schwartz phi...@progmad.comwrote: I think I have found a bug with 3.8.1. I have a few projects that use relative link paths and they throw a warning for CMP0015. I have pushed to the policy stack CMP0015 OLD to avoid the warnings till I fix the projects and currently the policy being set to old does nothing. On Fri, Feb 19, 2010 at 8:25 AM, Brad King brad.k...@kitware.com wrote: On 2/18/2010 8:38 PM, Samuel E. Henley wrote: I have a new warning warning: -fPIC ignored for target (all code is position independent) Under Windows - Mingw CMAKE_SHARED_LIBRARY_C_FLAGS and CMAKE_SHARED_LIBRARY_CXX_FLAGS has to be cleared of -fPIC, -fIPC is not used with gcc in Windows. This release candidate had some major platform information file reorganization to make it easier to add new compilers. The new files generically use -fPIC for compiling objects with GCC for shared libraries on all platforms. In the Platform/CYGWIN-GNU.cmake file we remove the flag, but it should be removed by Platform/Windows-GNU.cmake also. Fixed in CVS HEAD: Suppress GNU flag -fPIC on Windows /cvsroot/CMake/CMake/Modules/Platform/Windows-GNU.cmake,v -- Modules/Platform/Windows-GNU.cmake new revision: 1.2; previous revision: 1.1 I'll stage this for 2.8.1-rc4. -Brad ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
The policy being set to old is supposed to give the same behavior as prior versions of CMake, but also suppress the warning. What behavior are you seeing that makes you say setting it to old does nothing? On Thu, Feb 25, 2010 at 10:39 AM, Philip Schwartz phi...@progmad.comwrote: I think I have found a bug with 3.8.1. I have a few projects that use relative link paths and they throw a warning for CMP0015. I have pushed to the policy stack CMP0015 OLD to avoid the warnings till I fix the projects and currently the policy being set to old does nothing. On Fri, Feb 19, 2010 at 8:25 AM, Brad King brad.k...@kitware.com wrote: On 2/18/2010 8:38 PM, Samuel E. Henley wrote: I have a new warning warning: -fPIC ignored for target (all code is position independent) Under Windows - Mingw CMAKE_SHARED_LIBRARY_C_FLAGS and CMAKE_SHARED_LIBRARY_CXX_FLAGS has to be cleared of -fPIC, -fIPC is not used with gcc in Windows. This release candidate had some major platform information file reorganization to make it easier to add new compilers. The new files generically use -fPIC for compiling objects with GCC for shared libraries on all platforms. In the Platform/CYGWIN-GNU.cmake file we remove the flag, but it should be removed by Platform/Windows-GNU.cmake also. Fixed in CVS HEAD: Suppress GNU flag -fPIC on Windows /cvsroot/CMake/CMake/Modules/Platform/Windows-GNU.cmake,v -- Modules/Platform/Windows-GNU.cmake new revision: 1.2; previous revision: 1.1 I'll stage this for 2.8.1-rc4. -Brad ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
Arjen Markus wrote: On Thu, 18 Feb 2010 16:21:33 -0800 (PST) Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: I have a lot more CMake-2.8.1-RC3 testing to do myself ... I have come across a nasty little error: Under Cygwin it turns out that CMake 2.8.1rc3 is not recognising gfortran, but instead g77. I cannot reproduce this. I have a simple project: # CMakeLists.txt cmake_minimum_required(VERSION 2.6) project(Foo Fortran) I get: -- The Fortran compiler identification is GNU -- Check for working Fortran compiler: /usr/bin/gfortran.exe -- Check for working Fortran compiler: /usr/bin/gfortran.exe -- works even with both gfortran and g77 in my path. The list of possible compilers is in Modules/CMakeDetermineFortranCompiler.cmake and it is this: SET(CMAKE_Fortran_COMPILER_LIST ifort ifc efc f95 pgf95 lf95 xlf95 fort gfortran gfortran-4 g95 f90 pgf90 xlf90 epcf90 fort77 frt pgf77 xlf fl32 af77 g77 f77 ) Note that gfortran comes well before g77. CMake 2.8 has a new feature that once one language's compiler is enabled then it changes the search order to look for compilers from the same vendor for other languages. If the GNU C compiler is recognized first, then enabling Fortran uses this list: SET(_Fortran_COMPILER_NAMES_GNU gfortran gfortran-4 g95 g77) Again, gfortran comes first. Are you using a modified CMakeDetermineFortranCompiler.cmake in your own CMAKE_MODULE_PATH? -Brad ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
Hi Brad, I will need to check that - PLplot does/did have a file CMakeFortranInformation.cmake, maybe that is the culprit. I will try your minimal project myself, hopefully that will give the same result, otherwise we will have a mystery at our hands. Regards, Arjen On 2010-02-22 14:35, Brad King wrote: Arjen Markus wrote: On Thu, 18 Feb 2010 16:21:33 -0800 (PST) Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: I have a lot more CMake-2.8.1-RC3 testing to do myself ... I have come across a nasty little error: Under Cygwin it turns out that CMake 2.8.1rc3 is not recognising gfortran, but instead g77. I cannot reproduce this. I have a simple project: # CMakeLists.txt cmake_minimum_required(VERSION 2.6) project(Foo Fortran) I get: -- The Fortran compiler identification is GNU -- Check for working Fortran compiler: /usr/bin/gfortran.exe -- Check for working Fortran compiler: /usr/bin/gfortran.exe -- works even with both gfortran and g77 in my path. The list of possible compilers is in Modules/CMakeDetermineFortranCompiler.cmake and it is this: SET(CMAKE_Fortran_COMPILER_LIST ifort ifc efc f95 pgf95 lf95 xlf95 fort gfortran gfortran-4 g95 f90 pgf90 xlf90 epcf90 fort77 frt pgf77 xlf fl32 af77 g77 f77 ) Note that gfortran comes well before g77. CMake 2.8 has a new feature that once one language's compiler is enabled then it changes the search order to look for compilers from the same vendor for other languages. If the GNU C compiler is recognized first, then enabling Fortran uses this list: SET(_Fortran_COMPILER_NAMES_GNU gfortran gfortran-4 g95 g77) Again, gfortran comes first. Are you using a modified CMakeDetermineFortranCompiler.cmake in your own CMAKE_MODULE_PATH? -Brad ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
On Fri, Feb 19, 2010 at 6:46 AM, Brad King brad.k...@kitware.com wrote: On 2/18/2010 4:35 PM, Ben Medina wrote: However, with VS2010, CMake is re-run in the middle of the build. Did this work in CMake 2.8.0? I tried some test cases that seem similar to yours but I was unable to reproduce this problem. Perhaps the generate.stamp file is removed by whatever goes wrong with the Qt custom commands. I've seen this as well with my FindCUDA code (also a code generator like Qt's moc). It happens with CMake 2.6 as well, but it happens so infrequently that I haven't been able to reliably reproduce it. I have a hunch that it is related to the same file trying to be built by more than one project that gets compiled in parallel. Once I prevented the build collisions problems like this tended to go away. James ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
On 2010-02-22 08:35-0500 Brad King wrote:
Are you using a modified CMakeDetermineFortranCompiler.cmake
in your own CMAKE_MODULE_PATH?
Hi Brad:
I am probably the best person to answer that question. Here is how
I currently implement CMAKE_MODULE_PATH in our svn trunk version of
PLplot.
if(CMAKE_MAJOR_VERSION EQUAL 2 AND CMAKE_MINOR_VERSION EQUAL 6)
set(CMAKE_MODULE_PATH
${PROJECT_SOURCE_DIR}/cmake/modules
${PROJECT_SOURCE_DIR}/cmake/modules/language_support/cmake
${PROJECT_SOURCE_DIR}/cmake/modules/language_support/cmake-2.6
)
else(CMAKE_MAJOR_VERSION EQUAL 2 AND CMAKE_MINOR_VERSION EQUAL 6)
set(CMAKE_MODULE_PATH
${PROJECT_SOURCE_DIR}/cmake/modules
${PROJECT_SOURCE_DIR}/cmake/modules/language_support/cmake
${PROJECT_SOURCE_DIR}/cmake/modules/language_support/cmake-2.8
)
endif(CMAKE_MAJOR_VERSION EQUAL 2 AND CMAKE_MINOR_VERSION EQUAL 6)
modules has the normal PLplot module stuff that has nothing to do with language
support. language_support/cmake has our language-support files that
are independent of CMake version and
language_support/cmake-2.6 and language_support/cmake-2.8 contain
the relevant version-dependent language support files.
Here is the complete list of our language_support files:
cmake/modules/language_support/cmake-2.6/Platform/Cygwin-GNU-Fortran.cmake
cmake/modules/language_support/cmake-2.6/Platform/Windows-df.cmake
cmake/modules/language_support/cmake-2.6/Platform/Windows-GNU-Fortran.cmake
cmake/modules/language_support/cmake-2.6/Platform/Windows-f90.cmake
cmake/modules/language_support/cmake-2.6/CMakeFortranInformation.cmake
cmake/modules/language_support/cmake/Platform/Windows-dmd.cmake
cmake/modules/language_support/cmake/Platform/Darwin-dmd.cmake
cmake/modules/language_support/cmake/Platform/Linux-dmd.cmake
cmake/modules/language_support/cmake/Platform/Windows-gdc.cmake
cmake/modules/language_support/cmake/Platform/Linux-gdc.cmake
cmake/modules/language_support/cmake/CMakeDetermineAdaCompiler.cmake
cmake/modules/language_support/cmake/CMakeDInformation.cmake
cmake/modules/language_support/cmake/CMakeD_Copyright.txt
cmake/modules/language_support/cmake/CMakeAdaCompiler.cmake.in
cmake/modules/language_support/cmake/CMakeDetermineDCompiler.cmake
cmake/modules/language_support/cmake/CMakeAdaInformation.cmake
cmake/modules/language_support/cmake/CMakeTestAdaCompiler.cmake
cmake/modules/language_support/cmake/CMakeDCompiler.cmake.in
cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake
The files in /cmake support Ada and D. If I cannot resolve the 2.8
issue I am currently facing with D static libraries in a manner that is
independent of CMake version I may have to move/modify the D support files.
The files in /cmake-2.6 are our CMake-2.6 Fortran support files.
cmake/modules/language_support/cmake-2.6/Platform/Windows-df.cmake is
different from the version of that file in CMake (all versions). Once Arjen
has confirmed our version is better, it should be moved to the .../cmake
tree so it will be used by both our 2.6 and 2.8 users. Of course, it should
be donated to CMake as well to update their older version.
Currently /cmake-2.8 is empty on the assumption that CMake-2.8.1-RC3 has
complete support for all Fortran compiler platforms we are interested in.
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); 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
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
On 2010-02-22 08:35-0500 Brad King wrote: I cannot reproduce this. I have a simple project: # CMakeLists.txt cmake_minimum_required(VERSION 2.6) project(Foo Fortran) I don't have access to Cygwin myself, but as a convenience for more Cygwin testing by you and Arjen, I put together a simple test project that detects Fortran identically to how it is done in PLplot except I haven't bothered with our soft-landing code to deal with missing/broken Fortran compilers. If the Cygwin results from this test are fine, than obviously there is more work for Arjen and me to figure out what is the essential difference between this test project and the full PLplot build. However, because this simple test is so similar to what PLplot does, I would be very surprised if this test doesn't reproduce the Cygwin error seen for the full PLplot project both for Brad and Arjen. Please see the attached tarball. It includes all our current Fortran support files, and the logic for deciding the CMAKE_MODULE_PATH that I posted to this list just previously. 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); 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 __ test_cmake.tar.gz Description: Simple test project for Cygwin Fortran ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
On 2/22/2010 1:12 PM, Alan W. Irwin wrote: I don't have access to Cygwin myself, but as a convenience for more Cygwin testing by you and Arjen, I put together a simple test project that detects Fortran identically to how it is done in PLplot Thanks. I still get this: -- The Fortran compiler identification is GNU -- Check for working Fortran compiler: /usr/bin/gfortran.exe -- Check for working Fortran compiler: /usr/bin/gfortran.exe -- works -Brad ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
On Mon, 22 Feb 2010 10:12:12 -0800 (PST) Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: On 2010-02-22 08:35-0500 Brad King wrote: I cannot reproduce this. I have a simple project: # CMakeLists.txt cmake_minimum_required(VERSION 2.6) project(Foo Fortran) I don't have access to Cygwin myself, but as a convenience for more Cygwin testing by you and Arjen, I put together a simple test project that detects Fortran identically to how it is done in PLplot except I haven't bothered with our soft-landing code to deal with missing/broken Fortran compilers. I just tried Brad's simple project and that worked fine. I then rebuilt PLplot and came across the following messages: -- The C compiler identification is GNU -- Check for working C compiler: /bin/gcc.exe -- Check for working C compiler: /bin/gcc.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- CMake version = 2.8.1 -- Checking whether system has ANSI C header files -- Check for isnan in cmath - found -- Check for using stdint.h with CXX compiler -- Check for using stdint.h with CXX compiler - ok -- CMAKE_GENERATOR = Unix Makefiles -- The Fortran compiler identification is GNU -- Check for working Fortran compiler: /cygdrive/c/arjen/gfortran/bin/gfortran.exe -- Check for working Fortran compiler: /cygdrive/c/arjen/gfortran/bin/gfortran.exe -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether /cygdrive/c/arjen/gfortran/bin/gfortran.exe supports Fortran 90 -- Checking whether /cygdrive/c/arjen/gfortran/bin/gfortran.exe supports Fortran 90 -- yes -- Configuring done -- Generating done -- Build files have been written to: /cygdrive/c/arjen/plplot-svn/install-cygwin/language_tests/Fortran -- The Fortran compiler identification is GNU -- Check for working Fortran compiler: /bin/g77.exe -- Check for working Fortran compiler: /bin/g77.exe -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether /bin/g77.exe supports Fortran 90 -- Checking whether /bin/g77.exe supports Fortran 90 -- no -- WARNING: fortran compiler does not support f90/95. Disabling f95 bindings -- Check for f77 command line support -- Check for f77 command line support - found -- Check if isnan function is available in fortran -- Check for isnan in fortran - not found -- NOTICE: Found: /bin/g77.exe So it sees that CMake first finds gfortran and then, upon processing the language_support part of PLplot, decides that it should continue with g77. I will now look at Alan's test project. Hopefully that will give a similar result. Regards, Arjen ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
On Mon, 22 Feb 2010 14:28:05 -0500 Brad King brad.k...@kitware.com wrote: On 2/22/2010 1:12 PM, Alan W. Irwin wrote: I don't have access to Cygwin myself, but as a convenience for more Cygwin testing by you and Arjen, I put together a simple test project that detects Fortran identically to how it is done in PLplot Thanks. I still get this: -- The Fortran compiler identification is GNU -- Check for working Fortran compiler: /usr/bin/gfortran.exe -- Check for working Fortran compiler: /usr/bin/gfortran.exe -- works -Brad I am getting the same. Here is the full output: -- The Fortran compiler identification is GNU -- Check for working Fortran compiler: /cygdrive/c/arjen/gfortran/bin/gfortran.exe -- Check for working Fortran compiler: /cygdrive/c/arjen/gfortran/bin/gfortran.exe -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether /cygdrive/c/arjen/gfortran/bin/gfortran.exe supports Fortran 90 -- Checking whether /cygdrive/c/arjen/gfortran/bin/gfortran.exe supports Fortran 90 -- yes -- Configuring done -- Generating done -- Build files have been written to: /cygdrive/c/arjen/plplot-svn/test-alan/test_build So, there _is_ a difference between this test project and PLplot. Regards, Arjen ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
On Thu, 18 Feb 2010 16:21:33 -0800 (PST) Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: I have a lot more CMake-2.8.1-RC3 testing to do myself ... I have come across a nasty little error: Under Cygwin it turns out that CMake 2.8.1rc3 is not recognising gfortran, but instead g77. The output from the test is ambiguous: INFO:compiler[GNU] INFO:platform[Cygwin] Regards, Arjen ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
I have just solved the java issue I had discovered. The cause was a recently introduced regression in our own build system and nothing to do with cmake-2.8.x. From the PLplot build-system perspective, that leaves just the D static library issue on Linux which I am still working on, and the Fortran issues on Windows that Arjen is in the middle of testing. 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); 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 Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
On 2/18/2010 8:38 PM, Samuel E. Henley wrote: I have a new warning warning: -fPIC ignored for target (all code is position independent) Under Windows - Mingw CMAKE_SHARED_LIBRARY_C_FLAGS and CMAKE_SHARED_LIBRARY_CXX_FLAGS has to be cleared of -fPIC, -fIPC is not used with gcc in Windows. This release candidate had some major platform information file reorganization to make it easier to add new compilers. The new files generically use -fPIC for compiling objects with GCC for shared libraries on all platforms. In the Platform/CYGWIN-GNU.cmake file we remove the flag, but it should be removed by Platform/Windows-GNU.cmake also. Fixed in CVS HEAD: Suppress GNU flag -fPIC on Windows /cvsroot/CMake/CMake/Modules/Platform/Windows-GNU.cmake,v -- Modules/Platform/Windows-GNU.cmake new revision: 1.2; previous revision: 1.1 I'll stage this for 2.8.1-rc4. -Brad ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
On Fri, Feb 19, 2010 at 8:46 AM, Brad King brad.k...@kitware.com wrote: On 2/18/2010 4:35 PM, Ben Medina wrote: I just took it for a spin on the Windows side of my projects. It worked flawlessly with VS2005 and VS2008. Great, thanks for trying it. However, with VS2010, CMake is re-run in the middle of the build. Did this work in CMake 2.8.0? I tried some test cases that seem similar to yours but I was unable to reproduce this problem. Perhaps the generate.stamp file is removed by whatever goes wrong with the Qt custom commands. It happens as soon as I hit a project that depends on Qt, and running of moc fails. [snip] Is there a way to tell what commands it's giving to moc? You can either open the build properties in the IDE to inspect the command lines, or ask the IDE to show more verbose output during the build: Tools - Options - Projects and Solutions - Build and Run - MSBuild project build output verbosity Please try to reproduce this problem in a small test case so that we can try it, fix it, and test it. I have seen this problem (under visual studio 2005) with moc and cmake-2.6.X versions on a few occasions however moving to cmake-2.8.0 I have not had that since. John ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
On 2010-02-17 10:39-0500 Bill Hoffman wrote: CMake 2.8.1 RC 3 is ready to try: http://www.cmake.org/files/v2.8/?C=M;O=D Please try your projects with it. If you find any issues, let me know. I think we are getting very close to the actual release. Pretty much regressions only at this point, so PLEASE test your software with this release. The PLplot build system works fine for CMake-2.6.4 both for static and shared libraries. It also appears to work for shared libraries and CMake 2.8.1 RC 3. However, there are some issues with RC3 for the static libraries case. Our Fortran static library issue for CMake-2.8.x has been mentioned before on list, and Arjen and Brad are still pursuing it and perhaps are even done with the CMake part, but the corresponding PLplot build system adjustments have not been made yet. For example, I don't really know how we can simultaneously support the different Fortran language infrastructures for CMake-2.6.x and CMake-2.8.x. Brad recommended using two separate CMAKE_MODULE_PATH's for the two cases, but that would involve duplicating a lot of PLplot CMake modules that are common to both cases. Could CMAKE_MODULE_PATH be treated as a colon-separate list of paths that are searched one after another? That would solve the common modules issue for us. I also just discovered that our special CMake D language support infrastructure fails for the static library case for CMake 2.8.1 RC 3. It should take me quite a while to see what is wrong in that case, since language support is so magic with its own set of hard-to-understand (at least for me) rules. Ultimately, the issue will probably be something specific to 2.6.x in the way we have written our D language support rather than something intrinsic to the CMake core. So there is no point in waiting for us to resolve that D static library issue before making the 2.8.1 release. 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); 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 Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
On 2/17/10 4:39 PM, Bill Hoffman wrote: CMake 2.8.1 RC 3 is ready to try: http://www.cmake.org/files/v2.8/?C=M;O=D Please try your projects with it. If you find any issues, let me know. I think we are getting very close to the actual release. Pretty much regressions only at this point, so PLEASE test your software with this release. Thanks. Here are the changes: snip - FindQt4: Misc enhancements, sync with KDE vesion snip Hi BIll Would these enhancements include finding qmake-mac (as it is named on OSX installed by MacPorts?) Up until 2.8.0 I have found I need to modify this file to make it find the qmake binary. Simply adding qmake-mac to the list of executable names is sufficient. thanks Craig ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
Craig Bradney wrote: Would these enhancements include finding qmake-mac (as it is named on OSX installed by MacPorts?) Up until 2.8.0 I have found I need to modify this file to make it find the qmake binary. Simply adding qmake-mac to the list of executable names is sufficient. Yes, that change is in the release, please try it and verify that it works for you. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
Alan W. Irwin wrote: Could CMAKE_MODULE_PATH be treated as a colon-separate list of paths that are searched one after another? That would solve the common modules issue for us. It is already a list: set(CMAKE_MODULE_PATH /some/path /some/other/path) list(APPEND CMAKE_MODULE_PATH /some/third/path) -Brad ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
Alan W. Irwin wrote: I also just discovered that our special CMake D language support infrastructure fails for the static library case for CMake 2.8.1 RC 3. It should take me quite a while to see what is wrong in that case, since language support is so magic with its own set of hard-to-understand (at least for me) rules. Ultimately, the issue will probably be something specific to 2.6.x in the way we have written our D language support rather than something intrinsic to the CMake core. So there is no point in waiting for us to resolve that D static library issue before making the 2.8.1 release. It would be good if you were to track this D issue down a bit more. Perhaps create a very small example and show the VERBOSE=1 output from 2.6 and 2.8 (I assume 2.8.0 did not work either but it was never tested with PlPlot?). -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
On 2010-02-18 08:20-0500 Bill Hoffman wrote: Alan W. Irwin wrote: I also just discovered that our special CMake D language support infrastructure fails for the static library case for CMake 2.8.1 RC 3. It should take me quite a while to see what is wrong in that case, since language support is so magic with its own set of hard-to-understand (at least for me) rules. Ultimately, the issue will probably be something specific to 2.6.x in the way we have written our D language support rather than something intrinsic to the CMake core. So there is no point in waiting for us to resolve that D static library issue before making the 2.8.1 release. It would be good if you were to track this D issue down a bit more. Perhaps create a very small example and show the VERBOSE=1 output from 2.6 and 2.8 (I assume 2.8.0 did not work either but it was never tested with PlPlot?). This D language support is someone else's, and I am not that familiar with the D language itself, but I will try. Also, I will let you know how it is going by late this (Thursday) evening (at the latest) so you can make an informed decision about the release. And your assumption was correct. Because of the 2.8.0 Fortran problem (which only showed up in the static library case), I had been avoiding build testing of PLplot in the static case for 2.8.0 which is why this D static library issue was only discovered yesterday. 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); 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 Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
On 2010-02-18 08:14-0500 Brad King wrote: Alan W. Irwin wrote: Could CMAKE_MODULE_PATH be treated as a colon-separate list of paths that are searched one after another? That would solve the common modules issue for us. It is already a list: set(CMAKE_MODULE_PATH /some/path /some/other/path) list(APPEND CMAKE_MODULE_PATH /some/third/path) Thanks, Brad, for that information. That's going to help a lot in the language support transition between 2.6.x and 2.8.x. The documentation in 2.8.1-RC3 currently says this about CMAKE_MODULE_PATH. CMAKE_MODULE_PATH Path to look for cmake modules to load. Specifies a path to override the default search path for CMake modules. For example include commands will look in this path first for modules to include. Could you add a few words to make clear that CMAKE_MODULE_PATH is a 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); 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 Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
Alan W. Irwin wrote: On 2010-02-18 08:14-0500 Brad King wrote: Alan W. Irwin wrote: Could CMAKE_MODULE_PATH be treated as a colon-separate list of paths that are searched one after another? That would solve the common modules issue for us. It is already a list: set(CMAKE_MODULE_PATH /some/path /some/other/path) list(APPEND CMAKE_MODULE_PATH /some/third/path) Thanks, Brad, for that information. That's going to help a lot in the language support transition between 2.6.x and 2.8.x. The documentation in 2.8.1-RC3 currently says this about CMAKE_MODULE_PATH. CMAKE_MODULE_PATH Path to look for cmake modules to load. Specifies a path to override the default search path for CMake modules. For example include commands will look in this path first for modules to include. Could you add a few words to make clear that CMAKE_MODULE_PATH is a list? Clarify CMAKE_MODULE_PATH documentation /cvsroot/CMake/CMake/Source/cmDocumentVariables.cxx,v -- Source/cmDocumentVariables.cxx new revision: 1.47; previous revision: 1.46 -Brad ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
On Wed, Feb 17, 2010 at 7:39 AM, Bill Hoffman bill.hoff...@kitware.com wrote: CMake 2.8.1 RC 3 is ready to try: http://www.cmake.org/files/v2.8/?C=M;O=D Please try your projects with it. If you find any issues, let me know. I think we are getting very close to the actual release. Pretty much regressions only at this point, so PLEASE test your software with this release. I just took it for a spin on the Windows side of my projects. It worked flawlessly with VS2005 and VS2008. However, with VS2010, CMake is re-run in the middle of the build. It happens as soon as I hit a project that depends on Qt, and running of moc fails. Here is the relevant output (with some names changed to protect the innocent): 19-- Rebuild All started: Project: xxx_qt, Configuration: Debug x64 -- 19Build started 2/18/2010 1:25:53 PM. 19InitializeBuildStatus: 19 Creating xxx_qt.dir\Debug\xxx_qt.unsuccessfulbuild because AlwaysCreate was specified. 19CustomBuild: 19 Generating __/intern/moc_EventReceiverDestroyedListener.cxx 19 Generating __/moc_GLDrawArea.cxx 19 The system cannot find the path specified. 19 moc: Cannot open options file specified with @ 19 Usage: moc [options] header-file 19-ofile write output to file rather than stdout 19-Idiradd dir to the include path for header files 19-E preprocess only; do not generate meta object code 19-Dmacro[=def] define macro, with optional definition 19-Umacro undefine macro 19-i do not generate an #include statement 19-ppath path prefix for included file 19-f[file] force #include, optional file name 19-nwdo not display warnings 19@fileread additional options from file 19-v display version of moc 19 Building Custom Rule C:/dev/vs2010/sdk/trunk/libs/integrationmanager/qt/_build/CMakeLists.txt 19 CMake is re-running because CMakeFiles/generate.stamp dependency file is missing. You can see it successfully mocs one item, then fails on the next. Is there a way to tell what commands it's giving to moc? Thanks, Ben ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
On 2010-02-18 08:52-0800 Alan W. Irwin wrote: [The information about CMAKE_MODULE_PATH being a list] is going to help a lot in the language support transition between 2.6.x and 2.8.x. To Arjen, Brad, and Bill: Setting up CMAKE_MODULE_PATH as a list whose contents depended on CMake version meant quite a few reorganizational changes had to be made to the PLplot build system, but according to my initial limited tests with CMake-2.8.1-RC1 on Linux with gfortran compiler (which doesn't really use any of Arjen's Windows-related Fortran changes) the reorganization appears to work OK with Fortran, Ada, and D for shared libraries. If I have interpreted Brad's various discussions with Arjen correctly, all Arjen's Windows Fortran support files are now redundant (both for CMake-2.6.x and CMake-2.8.x) except for the Compaq Visual Fortran file for CMake-2.6.x. Also, he needs a different version of that file (with different name?) for CMake-2.8.x (which I believe Arjen has already implemented). But he still has a number of deletions and one addition to make to his language support files consistent with the newly reorganized directories for those support files in the PLplot svn repository, and then he needs to do extensive testing of that result to make sure all those changes work well for PLplot fortran both for CMake-2.6.x and CMake-2.8.1-RC3 for various Windows platforms. I have no idea what Arjen's schedule is like, but if he states here he does have time to deal with all of this testing right now, it might be worth Bill's while to wait until Arjen's tests confirm all is well with PLplot and various forms of Windows Fortran before releasing CMake-2.8.1. I have a lot more CMake-2.8.1-RC3 testing to do myself because now a Java-related error has showed up as well as the D issue I mentioned previously. So, Bill, forget what I said about finishing my testing by late this (Thursday) night. It's all fairly open-ended so I cannot give you a definite time scale for when I will be finished at this stage, but I do promise to work steadily on it until I have either solved the issues (if either/both are mine) or else implemented a simple test case that shows an issue with CMake-2.8.1-RC3. Since resolving these issues is open-ended, it may not be a good idea to delay the release for me, but perhaps you should get in touch with me off list to discuss where I am in the process once your other release issues are solved. (Or if the other issues are just waiting for Arjen's testing, then you might not wish to wait for either of us. :-)) 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); 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 Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake 2.8.1 RC 3 is ready to try
I have a new warning warning: -fPIC ignored for target (all code is position independent) Under Windows - Mingw CMAKE_SHARED_LIBRARY_C_FLAGS and CMAKE_SHARED_LIBRARY_CXX_FLAGS has to be cleared of -fPIC, -fIPC is not used with gcc in Windows. Samuel E. Henley OSRail.net ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake 2.8.1 RC 3 is ready to try
CMake 2.8.1 RC 3 is ready to try: http://www.cmake.org/files/v2.8/?C=M;O=D Please try your projects with it. If you find any issues, let me know. I think we are getting very close to the actual release. Pretty much regressions only at this point, so PLEASE test your software with this release. Thanks. Here are the changes: Changes in CMake 2.8.1 RC 3 - Add CMAKE_XCODE_ATTRIBUTE_attr interface to set compiler (#9125) - Fix Eclipse files for targets in subdirectories (#9978) - Fix custom command rule hashes to avoid extra rebuilds - Print non-make generator name in initial compiler test Changes in CMake 2.8.1 RC 2 - CPack: Avoid deleting long PATH values with NSIS (#10257) - CTest: Fix and test cost-based test scheduler - CTest: Fix and test git updates for case of out-dated index - CTest: Fix regression caused by fix for (#2336) in rc1 - CTest: Setup command-line dashboard support with Git - FindCUDA: Improve docs, use -rpath on Apple, fix dependency scanning - Fix OS X deployment-target and sysroot defaults (#9959,#9898,#10155) - Recognize the Compaq Fortran compiler Changes in CMake 2.8.1 RC 1 - Add NMake Makefiles JOM generator - Add PathScale compiler support - Add per-configuration OUTPUT_DIRECTORY properties - Add per-target OSX_ARCHITECTURES property - check_type_size(): Handle mixed-size universal binaries - CPack: Document Mac generators - CPack: Improve RPM spec files - Create CMAKE_FORCE_Fortran_COMPILER for cross-compiling - CTest: Add --http1.0 command-line option - CTest: Add --timeout command-line option - CTest: Do not munge UTF-8 output in XML files - CTest: Document CTEST_USE_LAUNCHERS option - CTest: Fix killing of whole test process trees - CTest: Handle failure of running invalid executables - CTest: Honor the -C arg to ctest (#2336) - CTest: Improve host system introspection - CTest: Optionally randomize test order (--schedule-random) - CTest: Skip tests with unsatisfied REQUIRED_FILES test property - CTest: Submit arbitrary results with ATTACHED_FILES test property - ctest_build(): Enhance signature - ctest_start(): Add APPEND option - ctest_start(): Move CTEST_CHECKOUT_COMMAND from ctest_update - ctest_update(): Submit global tree revision in Update.xml - Cygwin: Do not export all symbols from DLLs (#10122) - Cygwin: Name DLLs with SOVERSION, not VERSION (#10122) - Detect 32/64-bit Windows with Intel compiler - Eclipse generator enhancements - ExternalProject: Add TIMEOUT parameter - FindCUDA: Respect CUDA version differences - FindCURL: Find import libraries on Windows - FindDCMTK: Look in more places - FindGTest: Handle spaces better (#10065) - FindGTK2: Look in fink locations on Mac OS X - FindHDF5: Follow find-module API conventions - FindJava: Support for versioned find - FindJNI: Honor find_package() REQUIRED and QUIET options - FindMPI: Improve Windows support - FindOpenSSL: Fix MinGW support - FindPythonLibs: Look in config for static library - FindQt4: Misc enhancements, sync with KDE vesion - FindRuby: Fix version convention on Windows - FindX11: Improve documentation - Fortran: Detect address size (#10119) - FortranCInterface: Honor user flags - Improve VS 2010 beta2 support - link_directories(): Treat relative paths consistently (CMP0015) - Modernize FindLibXslt and FindLibXml.cmake - Refactor platform info to simplify adding new compilers - Support cross-compiling versioned DLLs - UseQt4: Provide dependencies only for static Qt (#10021) - Address issues: #2336, #3571, #5041, #7541, #8725, #9011, #9042, #9054, #9163, #9171, #9450, #9697, #9764, #9782, #9792, #9862, #9894, #9913, #9916, #9917, #9918, #9949, #9965, #9970, #9982, #9985, #10003, #10014, #10021, #10032, #10055, #10060, #10065, #10114, #10119, #10122, #10126, #10136. -Bill ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.1 RC 3 is ready to try
On 2010-02-17 10:39-0500 Bill Hoffman wrote: CMake 2.8.1 RC 3 is ready to try: http://www.cmake.org/files/v2.8/?C=M;O=D Bill, could you please include gpg signature files with each form of your downloadable release files? If the user imports your public key from your website or a keyserver using gpg --import and downloads both FILENAME.asc and FILENAME, the gpg --verify FILENAME.asc command allows him to verify (a) that there were no download errors and (b) FILENAME was signed by someone with access to a private key that corresponds to your public key. I have asked for gpg signature files before for your releases, and you showed enough interest to read the PLplot notes (look for anything gpg-related in http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/README.Release_Manager_Cookbook?view=markup) on how we set up signature files for our releases, but then we both let it slide after that. Anyhow, virtually every major piece of free and open source software infrastructure (e.g., the GNU project, many Linux distros, etc.) has been broken into from time to time, and one by one they have all gone to a model like above for signing their releases to make it a lot more difficult to distribute malware despite such breakins. I think it is important for CMake releases to be signed for the same reason. 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); 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 Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
