Re: [CMake] Possiblity to speedup the build by compiling multiple files in one compiler invocation
Is this of use to you? http://www.gmixer.com/archives/46/comment-page-1#comment-320 Regards, Arjen From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Martin Nielsen Sent: dinsdag 26 april 2011 15:11 To: cmake@cmake.org Subject: [CMake] Possiblity to speedup the build by compiling multiple files in one compiler invocation Hi, I have been asked to look into the possibilities of compiling multiple files in one invocation of the compiler like: armcc.exe ... file1.c file2.c ... fileN.c -o mylib.lib The cross compiler we are using requires a license in order to compile the file. It is a network floating license mechanism and the majority of the time it take to build the code is spent on acquiring the license. Parallel build is sadly not an option either since it just requests multiple licenses and we quickly run out. I was wondering if CMake could be directed to somehow do this? or it would break some dependency between the source files and the generation of the library. I suspect it isn't possible but would like to confirm this or explore other ideas on how to get around this problem. Med venlig hilsen / Best Regards Martin Nielsen Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom ___ 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] Replacing compiler flags for certain project subdirectories
Tim, I don't think cmake can facilitate this out of the box (to my knowledge). The problem is that some compilers and fortran code just don't mix with +O3 (blas, lapack). We have worked around it by reimplementing a mechanism from our old build system, where optimization for fortran c and cxx were parameterized, e.g. MDFC_OPT_LVLX (0-3 (up to 7 for Altix I think)). We have a wrapper function that sets COMPILE_FLAGS to this value with set_source_files_properties(). The catch is that at top level you have to strip CMAKE_LANG_FLAGS from any optimization instruction: HPUX-IA64: set (CMAKE_C_LINK_FLAGS +DSitanium2 +DD64 +DO11.23 -Aa -Ae -D_HPUX_SOURCE +Z) Note: you may also have to redefine the default link flags. Hope this helps, Arjen -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Whitcomb, Mr. Tim Sent: woensdag 30 maart 2011 20:00 To: 'cmake@cmake.org' Subject: Re: [CMake] Replacing compiler flags for certain project subdirectories Shortening to reduce wall-of-text: I have a Fortran project with a top-level CMakeLists.txt file with 47 add_subdirectory calls. Three of the subdirectories require a different set of preprocessor definitions and compiler flags than the other 47. I can add the preprocessor definitions, but am having trouble with the compiler flags. I need to have a completely different set in those subdirectories, so COMPILE_FLAGS target property won't work as it augments what's already there. How can I replace (not extend) the compiler flags for these few subdirectories? Tim -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Whitcomb, Mr. Tim Sent: Friday, March 25, 2011 3:18 PM To: 'cmake@cmake.org' Subject: [CMake] Replacing compiler flags for certain project subdirectories I'm in the process of adding Cmake-build capability to a Fortran project that currently follows a traditional recursive-make build structure. I've converted all the makefiles to CMakeLists.txt files and can now produce all the target libraries and executables with their dependencies correctly recognized. These dependencies have made a huge difference in allowing us to perform parallel builds and have the project ready to go *much* faster than before. I have a top-level CMakeLists.txt file that contains a few library searches (e.g. LAPACK, BLAS) and then an add_subdirectory call for each subdirectory in the project. Each subdirectory corresponds to a library and/or an executable. Now that the listing files contain all the sources files they need, my current task is to go through and set the proper compiler/preprocessor flags to match the original makefiles. We have several directories in our source tree that are auxiliary libraries that we store in our Subversion repository and build as part of our regular build process. The libraries that are built in these directories are compiled with different compiler flags and different preprocessor definitions than the rest of the project. I've been able to handle the preprocessor definitions by using add_definitions in the CMakeLists.txt files in the lower-level directories. I see based on reading through some past threads (including the recent Different CMAKE_CXX_FLAGS for different executables) on this list and on some StackOverflow questions that the COMPILE_FLAGS target property is very close to what I need (and actually *was* what I needed in several cases) but only appends flags to those currently in use. What I need is to be able to define a new set of compile flags (i.e. forget everything you were using before and use THIS set in this directory). I've started going through the documentation for Building External Projects[*] but the first line states that [a]n external project is one that you can get the source code for, but does not readily build with a simple ADD_SUBDIRECTORY call in your CMakeLists.txt file. This feels like it's designed to solve a slightly different problem than what I'm trying to do - I have an add_subdirectory call in my CMakeLists.txt file - is the proper fix for this issue to make the pieces that require different flags external projects? Will making some of these libraries external projects mess with the dependency calculation? I'm just getting started and trying to wrap my head around the options available. What is the standard way of dealing with this issue? Is there anything I'm missing? Thank you for your assistance! Tim [w] [*] http://www.kitware.com/products/html/BuildingExternalProjectsW ithCMake2.8.html ___ 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:
Re: [CMake] Specify an alternate C++ compiler for some source files
Since our default compilers are not gcc (icc, pgcc, cc, xlc_r etc) we've
introduced FLEXLM_C_COMPILER and friends to be able to compile this from a
single source tree.
But perhaps it would be cleaner to off-load it with ExternalProject_Add().
Seriously, how often do you want to compile LAPACK, BLAS, MPI, FLEXlm
yourself...
Regards,
Arjen
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Michael Wild
Sent: woensdag 30 maart 2011 14:11
To: cmake@cmake.org
Subject: Re: [CMake] Specify an alternate C++ compiler for some source
files
On 03/30/2011 01:42 PM, Marc Tajchman wrote:
Hi,
How to specify different compilers for different source files in
CMakeLists.txt, e.g. if
test1.cxx must be compiled with g++
test2.cxx must be compiled with mpicxx (mpi compiler)
I tried
add_executable(test1.exe test1.cxx)
set_source_files_properties(test2.cxx PROPERTIES CMAKE_CXX_COMPILER
${MPI_COMPILER})
add_executable(test2.exe test2.cxx)
but it didn't work (i.e. g++ is still used for test2.cxx - test2.o).
Any help appreciated.
Best Regards,
Marc
CMake can't do that. But if you need MPI, use
find_package(MPI REQUIRED)
include_directories(${MPI_INCLUDE_PATH})
add_executable(test1 test1.cxx)
add_executable(test2 test2.cxx)
target_link_libraries(test2 ${MPI_LIBRARIES})
set_target_properties(test2 PROPERTIES
COMPILE_FLAGS ${MPI_COMPILE_FLAGS}
LINK_FLAGS ${MPI_LINK_FLAGS})
HTH
Michael
___
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] Unify entire tree into a single static library?
Doug,
There is no convenient way to do this in Cmake you have you program around this
issue with a GLOBAL list of source files.
Michael Wild has offered a nice example at
http://www.mail-archive.com/cmake@cmake.org/msg27780.html
Hopefully this is useful to you as well.
Regards,
Arjen
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Doug
Sent: woensdag 23 februari 2011 6:48
To: cmake@cmake.org
Subject: [CMake] Unify entire tree into a single static library?
Hi,
If this has been answered somewhere already in the WIKI or something, please
just link me up; it seems like a simple question, but I can't figure it out.
So, basically I have my code split into a series of sub-directories:
project/
project/utils/
project/common/
project/desktop/
etc.
Each sub directory currently has it's own CMakeLists.txt, as follows:
file(GLOB SOURCE *.c)
add_library (shared ${SOURCE})
The parent CMakeLists.txt file define these as dependencies:
# Shared code
include_directories(${PROJECT_SOURCE_DIR}/shared)
add_subdirectory(shared)
set (EXTRA_LIBS ${EXTRA_LIBS} shared)
# Utility libraries
include_directories(${PROJECT_SOURCE_DIR}/utils)
add_subdirectory(utils)
set (EXTRA_LIBS ${EXTRA_LIBS} utils)
...
# Source files~
file(GLOB sources src/*.c)
add_library (project ${sources})
target_link_libraries (project ${EXTRA_LIBS})
This builds fine. However, it generates a library.a file for each directory, eg.
per-ms006:build douglasl$ du -a |grep \.a
./desktop/libdesktop.a
./libcommon.a
./shared/libshared.a
./utils/libutils.a
The problem is that if I want to depend on this with an external project, I can
do so via this:
# Add lib
include_directories(/path/to/project/include/)
link_directories(/path/to/project/build/)
set(EXTRA_LIBS ${EXTRA_LIBS} project)
...but... obviously this does not link any of the other sub libraries like
-lutils -lcommon -ldesktop, so my build fails with a pile of undefined symbol
errors.
So, what's the way to solve this?
Can I either:
1) Somehow depend on an external project directory with some kind of
add_subdirectory() directive?
2) Somehow force cmake to combine all the symbols into a single static library
for the project, rather than several individual ones?
(The only suggestions I've seen so far are (2), where you define a single
CMakeLists,txt and list _all_ source files in all directories in it. This is a
silly solution, or (2) where you manually uncompress the .a files and recombine
all the .o files into a single .a file. This is also just ridiculous. Surely
this is a problem that comes up a lot...?)
Cheers,
Doug.
___
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] Expected boost path structure.
Just to make sure:
set BOOST_ROOT=X:\32bit\VC.90\Libraries\boost-1.45.0
Won't work? Or setting it to this value in the Computer Properties
Environment variables section?
I thought cmake worked fine with the path separator that is native to the OS.
Would be strange if it didn't.
Arjen
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of David Cole
Sent: donderdag 17 februari 2011 17:42
To: John Drescher
Cc: CMake mailing list
Subject: Re: [CMake] Expected boost path structure.
On Thu, Feb 17, 2011 at 11:37 AM, John Drescher dresche...@gmail.com
wrote:
According to FindBoost.cmake:
if (NOT BOOST_ROOT AND NOT $ENV{BOOST_ROOT} STREQUAL )
set(BOOST_ROOT $ENV{BOOST_ROOT})
endif()
So, it should work with an ENV var, too. But the way this is phrased,
it would have to have forward slashes / and no spaces in it for it
to work.
I launched cmake-gui from a Visual Studio 2008 32 bit command prompt
with the BOOST_ROOT environment variable set in that command prompt.
X:\Other\Libraries\boost_1_45_0set BOOST_ROOT
BOOST_ROOT=X:/32bit/VC.90/Libraries/boost-1.45.0
Is there a way to have cmake-gui show its environment variables?
John
--
John M. Drescher
Take away the quotes in the env var. They are actually embedded in the
env var, so they'll end up in the CMake variable, too. If you print
out the CMake variable that gets set based on that env value, then it
will have double quotes in it.
___
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] feed parsed information from source files into compile process
Thanks Tyler, -Original Message- From: Tyler Roscoe [mailto:ty...@cryptio.net] You can't use add_custom_command() to drive this because the results of any custom commands will only be available at build time. You need stuff to happen at CMake configure time. I noticed. Add_custom_target(foo ALL ... ) results are only processed at make+1 and not immediately :( Hence, I would use execute_process() to run your python script at configure time. It would deposit its results into a file, which you could then include() (or file(READ ...)). While this does work, it will only function properly if cmake needs to run. If for whatever reason (say a -O2/-O3 omp compiler bug in xlf_r ;) ) you change the in-file compiler flags they will not be picked up until you run cmake. I'm gonna try a few things, but I'm not too hopeful :P 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
[CMake] feed parsed information from source files into compile process
Hi, I'm looking for a way to parse information from source files and feed the outcome as input to the build process. In more detail, I have Fortran files that contain information about what optimization flags should be fed to the compiler. Currently there is a python script that does preprocessing of all source, stores information in override.cmake files using set_source_file_properties(). This works fine, but makes maintaining source more error prone than it was. For instance a developer might use the code for an FE element, use it as the basis for a collapsed version and inherit specific optimizations which are now ignored. I have looked at a way to chain this step using add_custom_command(), but I see no possibility to tell the generator about some variable an external program will fill in during the build phase. Do Fortran developers have to learn to live with this, or is there a way to sneak information from source file into the makefile generation? Thanks, 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.3 forces -rdynamic for pf90 in pure fortran projects
Hi Brad,
Please try the patch below.
It gets rid of -rdynamic for pure F90. I will try in a C/C++/F77/F90 project
soonish (hopefully today). I didn't check if other flags get cleared as well.
Thanks,
Arjen
diff --git a/Modules/Platform/Linux-PGI.cmake b/Modules/Platform/Linux-
PGI.cmake
index ef06acd..43e0232 100644
--- a/Modules/Platform/Linux-PGI.cmake
+++ b/Modules/Platform/Linux-PGI.cmake
@@ -22,4 +22,5 @@ macro(__linux_compiler_pgi lang)
# Shared library compile and link flags.
set(CMAKE_SHARED_LIBRARY_${lang}_FLAGS -fPIC)
set(CMAKE_SHARED_LIBRARY_CREATE_${lang}_FLAGS -shared)
+ set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS )
endmacro()
___
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.3 forces -rdynamic for pf90 in pure fortran projects
Hi, -rdynamic is used for linking with pgf90 even though it is not supported. The flag is imported from Linux-GNU.cmake and I guess it is included because cmake (2.8.3) checks for C and C++ compilers by default. http://www.vtk.org/Bug/view.php?id=9985 talks about this bug, but I'm unsure what the final conclusion is and if the bug is considered fixed. Even though this is a Fortran test, I can imagine it will break linking multi-language code as well, if you mix PGI (pgf90) with GNU (gcc/g++) and end up with -rdynamic because of it. Thanks, 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] Converting a large C++-Project to CMake
Benjamin, If you haven't already, you might want to take a lot at JOM, which is essentially parallel nmake: http://qt.gitorious.org/qt-labs/jom. JOM is supported by CMake. Thank you Pedro. One of our developers already tried to plug jom into our current build system, but some trouble with forward slashes in path names occurred. I'll give it a shot with CMake! Make sure you take 0.9.4 or better, I haven't had much success with older versions, although I didn't try every version. This was the newest at the time and it works for me (tm). 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
[CMake] cmake 2.8.2 doesn't build on suse 9.3
Hi, For some reason bootstrap on a plain SuSE 9.3 fails to find sys/wait.h. Manually defining HAVE_SYS_WAIT_H to 1 in config.h allows cmake and friends to be built. Regards, Arjen -rw-r--r-- 1 root root 6620 2005-06-11 00:58 /usr/include/sys/wait.h -- Looking for include files HAVE_SYS_WAIT_H -- Looking for include files HAVE_SYS_WAIT_H - not found. ___ 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] Merge two static libraries
Hi, -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Marcel Loose The downside to this solution is that you have duplicates of the object files that are part of common, but that's the price you'll have to pay if you want to have just one static library. HTH, Marcel Loose. I think at least for Linux and Unices this gets solved when linking the final executable. Stuff in an archive (static library for you AIX users) that is not referenced evaporates. It's also need for fast linking. You just create a link line that creates an executable based on one or more objects files in front of an archive. The symbols in the object file take precedence, which can make incremental builds really fast. This last bit is where cmake is much slower than my original build system, but arguably more safe. 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.2 doesn't build on suse 9.3
Hi Brad,
Yes:
Determining if files
sys/types.h;ctype.h;dlfcn.h;errno.h;fcntl.h;grp.h;inttypes.h;langinfo.h;limits.h;linux/fs.h;locale.h;memory.h;paths.h;poll.h;pwd.h;regex.h;signal.h;stdarg.h;stdint.h;stdlib.h;string.h;strings.h;sys/ioctl.h;sys/param.h;sys/poll.h;sys/select.h;sys/stat.h;sys/time.h;sys/wait.h
exist failed with the following output:
Change Dir: /usr2/people/verweija/cmake/cmake-2.8.2/CMakeFiles/CMakeTmp
Run Build Command:/usr/bin/gmake cmTryCompileExec/fast
gmake -f CMakeFiles/cmTryCompileExec.dir/build.make
CMakeFiles/cmTryCompileExec.dir/build
gmake[1]: Entering directory
`/usr2/people/verweija/cmake/cmake-2.8.2/CMakeFiles/CMakeTmp'
/usr2/people/verweija/cmake/cmake-2.8.2/Bootstrap.cmk/cmake -E
cmake_progress_report
/usr2/people/verweija/cmake/cmake-2.8.2/CMakeFiles/CMakeTmp/CMakeFiles 1
Building C object CMakeFiles/cmTryCompileExec.dir/CheckIncludeFiles.c.o
/usr/local/bin/cc-o CMakeFiles/cmTryCompileExec.dir/CheckIncludeFiles.c.o
-c
/usr2/people/verweija/cmake/cmake-2.8.2/CMakeFiles/CMakeTmp/CheckIncludeFiles.c
In file included from
/usr2/people/verweija/cmake/cmake-2.8.2/CMakeFiles/CMakeTmp/CheckIncludeFiles.c:30:
/usr/include/sys/wait.h:103: error: syntax error before numeric constant
gmake[1]: *** [CMakeFiles/cmTryCompileExec.dir/CheckIncludeFiles.c.o] Error 1
gmake[1]: Leaving directory
`/usr2/people/verweija/cmake/cmake-2.8.2/CMakeFiles/CMakeTmp'
gmake: *** [cmTryCompileExec/fast] Error 2
gcc version:
/usr/local/bin/cc -v
Reading specs from /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.5/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada
--disable-checking --libdir=/usr/lib64 --enable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-shared --enable-__cxa_atexit x86_64-suse-linux
Thread model: posix
gcc version 3.3.5 20050117 (prerelease) (SUSE Linux)
Attached wait.h.
Regards,
Arjen
-Original Message-
From: Brad King [mailto:brad.k...@kitware.com]
Sent: dinsdag 5 oktober 2010 18:59
To: Verweij, Arjen
Cc: cmake@cmake.org
Subject: Re: [CMake] cmake 2.8.2 doesn't build on suse 9.3
On 10/05/2010 08:34 AM, Verweij, Arjen wrote:
For some reason bootstrap on a plain SuSE 9.3 fails to find
sys/wait.h.
Manually defining HAVE_SYS_WAIT_H to 1 in config.h allows cmake and
friends to be built.
-rw-r--r-- 1 root root 6620 2005-06-11 00:58 /usr/include/sys/wait.h
-- Looking for include files HAVE_SYS_WAIT_H
-- Looking for include files HAVE_SYS_WAIT_H - not found.
It looks like the bootstrap CMake builds but fails to configure the
full build. Does information about this check appear in the
CMakeFiles/CMakeError.log file?
-Brad
/* Copyright (C) 1991-1994,1996-2001,2003,2004 Free Software Foundation, Inc.
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA. */
/*
* POSIX Standard: 3.2.1 Wait for Process Termination sys/wait.h
*/
#ifndef _SYS_WAIT_H
#define _SYS_WAIT_H 1
#include features.h
__BEGIN_DECLS
#include signal.h
#include sys/resource.h
/* These macros could also be defined in stdlib.h. */
#if !defined _STDLIB_H || !defined __USE_XOPEN
/* This will define the `W*' macros for the flag
bits to `waitpid', `wait3', and `wait4'. */
# include bits/waitflags.h
# ifdef __USE_BSD
/* Lots of hair to allow traditional BSD use of `union wait'
as well as POSIX.1 use of `int' for the status word. */
# if defined __GNUC__ !defined __cplusplus
# define __WAIT_INT(status) \
(__extension__ ({ union { __typeof(status) __in; int __i; } __u;\
__u.__in = (status); __u.__i; }))
# else
# define __WAIT_INT(status) (*(int *) (status))
# endif
/* This is the type of the argument to `wait'. The funky union
causes redeclarations with ether `int *' or `union wait *' to be
allowed without complaint. __WAIT_STATUS_DEFN is the type used in
the actual function definitions. */
# if !defined __GNUC__ || __GNUC__ 2 || defined __cplusplus
# define __WAIT_STATUSvoid *
# define __WAIT_STATUS_DEFN void *
# else
/* This works in GCC 2.6.1 and later
Re: [CMake] How to invoke 64 bit cmd.exe from cmake script onWindows 7 (x64).
I would be interested to learn how. Because of similar issues we got rid of a shell script on Win64 because UnxUtil zsh.exe doesn't run from the 64bit cmd.exe. Also, when in a 64bit VS shell, I now need to run the 32bit nmake.exe because otherwise my 32bit flex.exe will crash. I have tried directly, with bat files, cmd /c etc. Regards, Arjen -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Rolf Eike Beer Sent: maandag 23 augustus 2010 21:57 To: cmake@cmake.org Subject: Re: [CMake] How to invoke 64 bit cmd.exe from cmake script onWindows 7 (x64). Am Monday 23 August 2010 schrieb Eric Noulard: I'm not a windows expert but since execute_process somehow Fork/CreateThread/CreateProcess from 32 bits CMake I doubt that this 32bits app may fork a 64bits one. You can start a 64 bit process from a 32 one as you can do the other way round. You just can't use libraries of different pointer length without magic. Eike ___ 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] Setting CMAKE_CXX_FLAGS..., CMAKE_C_FLAGS... and CMAKE_C_STANDARD_LIBRARIES_INIT and friends on a per target basis
I can't say I share this experience. We use this mechanism to substitute
standard flags with less or more optimization and/or other options. Usually
-O3 instead of -O2, and I don't get them both on the commandline.
Arjen
From: Brian Davis [mailto:bitmi...@gmail.com]
set_source_files_properties(${CMAKE_BINARY_DIR}/path/to/file.f PROPERTIES
GENERATED TRUE COMPILE_FLAGS ${FFLAG_OPT})
COMPILE flags only appends to thoes already set CMAKE_... vars. I need a way
to override all the other vars on a per target basis.
___
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] Setting CMAKE_CXX_FLAGS..., CMAKE_C_FLAGS... and CMAKE_C_STANDARD_LIBRARIES_INIT and friends on a per target basis
Hi Brian,
We override the standard CMAKE_LANG_FLAGS (C CXX Fortran) and use it as a
baseline. Then, for individual source files it is possible to override them in
a separate file using:
set_source_files_properties(${CMAKE_BINARY_DIR}/path/to/file.f PROPERTIES
GENERATED TRUE COMPILE_FLAGS ${FFLAG_OPT})
These override files are included OPTIONALly and the directives executed when
applicable.
Regards,
Arjen
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Brian Davis
Sent: woensdag 18 augustus 2010 22:48
To: cmake Mailing List
Subject: [CMake] Setting CMAKE_CXX_FLAGS..., CMAKE_C_FLAGS... and
CMAKE_C_STANDARD_LIBRARIES_INIT and friends on a per target basis
CMAKE_CXX_FLAGS..., CMAKE_C_FLAGS... and CMAKE_C_STANDARD_LIBRARIES_INIT and
friends are seemingly global variables. Is there a way to override (all of)
these on a per target basis? A method which is not tied to the directory
(properties). One that does not simply append such as COMPILE_FLAGS, but blasts
away and makes it what I specify? Basically all the goop in Windows-icl.cmake,
Windows-cl.cmake, etc. Possibly involving set_target_properties?
___
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] 64 bit windows: rsp file not employed in build.make
Hi, The objects1.rsp file is generated by CMake during configuration. The start/end temp file syntax tells NMake to use response files at build time. Why is this scheme only used for shared libs and not static libs? For static libs it works automagically somehow. The link rule uses objects1.rsp with cl but not icl because cl.cmake has: SET(CMAKE_C_USE_RESPONSE_FILE_FOR_OBJECTS 1) SET(CMAKE_CXX_USE_RESPONSE_FILE_FOR_OBJECTS 1) OK. But in cl.cmake these variables are only set after the definition of CMAKE_C_CREATE_STATIC_LIBRARY and CMAKE_CXX_CREATE_STATIC_LIBRARY (i.e. for shared libs), so I didn't think of it. These should probably be added to Windows-icl.cmake too. We already have SET(CMAKE_Fortran_USE_RESPONSE_FILE_FOR_OBJECTS 1) in Windows-ifort.cmake. Indeed for pure Fortran it works. I can happily link 40k files into a single lib. I have added suggested settings locally to my Windows-icl.cmake and I can build a lib from a large number of objects now. Please find a patch attached. It has the definitions in the top like Windows-ifort.cmake (as opposed to cl.cmake) NOTE: this does not include the change from /INCREMENTAL:YES to /INCREMENTAL:NO that stops the ICE with Intel C/C++ and Intel Fortran 9.1. I still use that locally, but after reading Bill's comments it seems the wrong way to fix it. Thanks, Arjen Windows-icl.cmake.patch Description: Windows-icl.cmake.patch ___ 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] ifort 9.1 unable to compile a simple test program
Hi, Interesting. It works for ifort 11.1. So does ifort /incremental:yes myfile.f ICE for any file with ifort 9.1? Hrm, no not really :| Not too sure why this is breaking. Is this technically an ICE? I see ifort reporting it, but it occurs when linking and both ifort and xilink call link of visual studio to link stuff? Maybe I can try other ways of linking later on (i.e. the way cmake attempts in the trycompile step), access to the machine has been suspended for a bit pending an upgrade. sq.f: function my0(x) real x my0 = x**2 WRITE (*, *) my0 return end main.f: * C Hello World in Fortran 77 C (lines must be 6 characters indented) * PROGRAM HELLOW real myvar WRITE(UNIT=*, FMT=*) 'Hello World' myvar = my0(2.) END Z:\testbinifort /c sq.f Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.1 Build 20060324 Copyright (C) 1985-2006 Intel Corporation. All rights reserved. Z:\testbinifort /c main.f Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.1 Build 20060324 Copyright (C) 1985-2006 Intel Corporation. All rights reserved. Z:\testbinlink /incremental:yes main.obj sq.obj Microsoft (R) Incremental Linker Version 8.00.50727.762 Copyright (C) Microsoft Corporation. All rights reserved. Z:\testbinmain.exe Hello World 4 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
[CMake] 64 bit windows: rsp file not employed in build.make
Hi, I'm investigating a problem where on 64-bit Windows the generated build.make (NMake or NMake JOM) does not make use of response files. I have tried transplanting the settings file for the 32 bit platform and minimizing differences, but still I cannot get it to use rsp files. This is a problem because I can't create one of the static libraries, since the command line is too long. Except for the missing rsp mechanism, I'm also unsure why in one case the linking is done through link.exe and by lib in the other. I've made sure to: - use a fresh copy of cmake 2.8.2 on both machines - not to mess with CMAKE_START_TEMP_FILE / CMAKE_END_TEMP_FILE Is there a way to see how cmake arrives at a generated rule, perhaps as it is generating? Of course if you know anything that might cause this behavior I would be keen to learn it. Thanks, Arjen Generated on win32 (VS2003 SE): @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --red --bold Linking CXX static library \win32p_cmake\lib\ulib\dom.lib cd E:\build\src\ulib\dom $(CMAKE_COMMAND) -P CMakeFiles\dom.dir\cmake_clean_target.cmake cd E:\build cd E:\build\src\ulib\dom E:\PROGRA~1\MICROS~1.NET\Vc7\bin\link.exe /lib /out:\win32p_cmake\lib\ulib\dom.lib @CMakeFiles\dom.dir\objects1.rsp cd E:\build Generated on win64 (Intel C/C++ 9.1, VS2005 SE): @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --red --bold Linking CXX static library \em64t-win_cmake\lib\ulib\dom.lib cd E:\build\src\ulib\dom $(CMAKE_COMMAND) -P CMakeFiles\dom.dir\cmake_clean_target.cmake cd E:\build cd E:\build\src\ulib\dom lib /out:\em64t-win_cmake\lib\ulib\dom.lib $(dom_OBJECTS) $(dom_EXTERNAL_OBJECTS) cd E:\build ___ 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] comments wrong in Windows-ifort.cmake
Patch attached :P Arjen Windows-ifort.cmake.patch Description: Windows-ifort.cmake.patch ___ 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] ifort 9.1 unable to compile a simple test program
Brad, I have access to the machine again. I've tried another approach. What do you make of this? I'm sure you know what cmake -E vs_link_exe is supposed to do. :) The first works, the second does, even with /INCREMENTAL:YES Regards, Arjen ACCORDING TO build.make: E:\trycompile\CMakeFiles\CMakeTmpE:\cmake28\bin\cmake.exe -E vs_link_exe E:\PROGRA~1\Intel\Compiler\Fortran\9.1\em64t\bin\ifort.e xe /nologo CMakeFiles/cmTryCompileExec.dir/testFortranCompiler.f.obj /W1 /nologo /fpp /libs:dll /threads /debug:full /dbglibs /F ecmTryCompileExec.exe -link /implib:cmTryCompileExec.lib /INCREMENTAL:YES /debug /subsystem:console user32.lib backend signals Severe: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error. ifort: error: problem during multi-file optimization compilation (code 3) LINK Pass 1 failed. with 3 STRIPPED -- E:\trycompile\CMakeFiles\CMakeTmpE:\cmake28\bin\cmake.exe -E vs_link_exe E:\trycompile\CMakeFiles\CMakeTmpE:\PROGRA~1\Intel\Compiler\Fortran\9.1\em64t\bin\ifort.exe /nologo CMakeFiles/cmTryCompileExec.d ir/testFortranCompiler.f.obj /W1 /nologo /fpp /libs:dll /threads /debug:full /dbglibs /FecmTryCompileExec.exe -link /implib:cmTr yCompileExec.lib /INCREMENTAL:YES /debug /subsystem:console user32.lib E:\trycompile\CMakeFiles\CMakeTmpcmTryCompileExec.exe Hello -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Verweij, Arjen Sent: maandag 9 augustus 2010 16:15 To: Brad King Cc: cmake@cmake.org Subject: Re: [CMake] ifort 9.1 unable to compile a simple test program Hi, Interesting. It works for ifort 11.1. So does ifort /incremental:yes myfile.f ICE for any file with ifort 9.1? Hrm, no not really :| Not too sure why this is breaking. Is this technically an ICE? I see ifort reporting it, but it occurs when linking and both ifort and xilink call link of visual studio to link stuff? Maybe I can try other ways of linking later on (i.e. the way cmake attempts in the trycompile step), access to the machine has been suspended for a bit pending an upgrade. sq.f: function my0(x) real x my0 = x**2 WRITE (*, *) my0 return end main.f: * C Hello World in Fortran 77 C (lines must be 6 characters indented) * PROGRAM HELLOW real myvar WRITE(UNIT=*, FMT=*) 'Hello World' myvar = my0(2.) END Z:\testbinifort /c sq.f Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.1Build 20060324 Copyright (C) 1985-2006 Intel Corporation. All rights reserved. Z:\testbinifort /c main.f Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.1Build 20060324 Copyright (C) 1985-2006 Intel Corporation. All rights reserved. Z:\testbinlink /incremental:yes main.obj sq.obj Microsoft (R) Incremental Linker Version 8.00.50727.762 Copyright (C) Microsoft Corporation. All rights reserved. Z:\testbinmain.exe Hello World 4 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 ___ 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] 64 bit windows: rsp file not employed in build.make
Hi Bill,
I'm also unsure why in one case the linking is done through link.exe and by
lib in the other.
One is using visual studio, and one is using the intel compiler. They
have different files in the Platform directory. That is why they can be
different. See Windows-icl.cmake.
Thanks, that was silly to overlook.
Both link rules for static libraries however do not contain
${CMAKE_START_TEMP_FILE} or ${CMAKE_END_TEMP_FILE} yet one platform I end up
with objects1.rsp but on the other the lists of objects are passed as arguments
to lib. Is there some implicit rule for static libraries when using cl.exe?
Regards,
Arjen
cl.cmake:
# create a C++ static library
SET(CMAKE_CXX_CREATE_STATIC_LIBRARY CMAKE_LINKER /lib ${CMAKE_CL_NOLOGO}
LINK_FLAGS /out:TARGET OBJECTS )
Windows-icl.cmake:
# create a C++ static library
SET(CMAKE_CXX_CREATE_STATIC_LIBRARY lib ${CMAKE_CL_NOLOGO} LINK_FLAGS
/out:TARGET OBJECTS )
___
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] ifort 9.1 unable to compile a simple test program
Hi Brad, Apparently it breaks because of /INCREMENTAL:YES -- E:\build\CMakeFiles\CMakeTmpE:\cmake28\bin\cmake.exe -E vs_link_exe E:\PROGRA~1\Intel\Compiler\Fortran\9.1\em64t\bin\if ort.exe /nologo @CMakeFiles\cmTryCompileExec.dir\objects1.rsp /W1 /nologo /fpp /libs:dll /threads /debug:full /dbglib s /FecmTryCompileExec.exe -link /implib:cmTryCompileExec.lib /INCREMENTAL:YES /debug /subsystem:console user32.lib backend signals Severe: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it oc curred in a Software Problem Report. Note: File and line given may not be explicit cause of this error. ifort: error: problem during multi-file optimization compilation (code 3) LINK Pass 1 failed. with 3 /INCREMENTAL:NO -- E:\build\CMakeFiles\CMakeTmpE:\cmake28\bin\cmake.exe -E vs_link_exe E:\PROGRA~1\Intel\Compiler\Fortran\9.1\em64t\bin\if ort.exe /nologo @CMakeFiles\cmTryCompileExec.dir\objects1.rsp /W1 /nologo /fpp /libs:dll /threads /debug:full /dbglib s /FecmTryCompileExec.exe -link /implib:cmTryCompileExec.lib /INCREMENTAL:NO /debug /subsystem:console user32.lib E:\build\CMakeFiles\CMakeTmpcmTryCompileExec.exe Hello Can I just turn this off in Windows-ifort.cmake or is this symptomatic of another problem? Thanks, Arjen -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: vrijdag 6 augustus 2010 22:28 To: Verweij, Arjen Cc: cmake@cmake.org Subject: Re: [CMake] ifort 9.1 unable to compile a simple test program On 08/06/2010 04:22 PM, Verweij, Arjen wrote: I did it is below the cmake error in the previous email. No error just a prompt And no noticeable difference to me. Your previous message did E:\cmake28\bin\cmake.exe -E vs_link_exe E:\PROGRA~1\Intel\Compiler\Fortran\9.1\em64t\bin\ifort.exe /nologo @CMakeFiles\cmTryCompileExec.dir\objects1.rsp @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\nm1395.tmp The @...tmp needs to be replaced with the rest of the command from build.make. -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
[CMake] ifort 9.1 unable to compile a simple test program
Hi, Ifort 9.1 is unable to compile a simple test program on WinXP 64 bit with cmake 2.8.2. I can execute the linkline manually and it seems to link fine. How can I debug what's going on? Thanks, Arjen E:\buildcmake Z:\f90example -G NMake Makefiles --debug-trycompile debug trycompile on -- The C compiler identification is MSVC -- The CXX compiler identification is MSVC -- Check for CL compiler version -- Check for CL compiler version - 1400 -- Check if this is a free VC compiler -- Check if this is a free VC compiler - no -- Check for working C compiler: E:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/cl.exe -- Check for working C compiler: E:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: E:/Program Files (x86)/Microsoft Visual Studi o 8/VC/bin/cl.exe -- Check for working CXX compiler: E:/Program Files (x86)/Microsoft Visual Studi o 8/VC/bin/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- The Fortran compiler identification is unknown -- Check for working Fortran compiler: E:/Program Files (x86)/Intel/Compiler/For tran/9.1/em64t/bin/ifort.exe -- Check for working Fortran compiler: E:/Program Files (x86)/Intel/Compiler/For tran/9.1/em64t/bin/ifort.exe -- broken CMake Error at E:/cmake28/share/cmake-2.8/Modules/CMakeTestFortranCompiler.cmake :40 (MESSAGE): The Fortran compiler E:/Program Files (x86)/Intel/Compiler/Fortran/9.1/em64t/bin/ifort.exe is not able to compile a simple test program. It fails with the following output: Change Dir: E:/build/CMakeFiles/CMakeTmp Run Build Command:nmake /NOLOGO cmTryCompileExec\fast E:\Program Files (x86)\Microsoft Visual Studio 8\VC\BIN\nmake.exe -f CMakeFiles\cmTryCompileExec.dir\build.make /nologo -L CMakeFiles\cmTryCompileExec.dir\build E:\cmake28\bin\cmake.exe -E cmake_progress_report E:\build\CMakeFiles\CMakeTmp\CMakeFiles 1 Building Fortran object CMakeFiles/cmTryCompileExec.dir/testFortranCompiler.f.obj E:\PROGRA~1\Intel\Compiler\Fortran\9.1\em64t\bin\ifort.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\nm1173.tmp Linking Fortran executable cmTryCompileExec.exe E:\cmake28\bin\cmake.exe -E vs_link_exe E:\PROGRA~1\Intel\Compiler\Fortran\9.1\em64t\bin\ifort.exe /nologo @CMakeFiles\cmTryCompileExec.dir\objects1.rsp @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\nm1174.tmp backend signals Severe: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error. ifort: error: problem during multi-file optimization compilation (code 3) LINK Pass 1 failed. with 3 NMAKE : fatal error U1077: 'E:\cmake28\bin\cmake.exe' : return code '0x' Stop. NMAKE : fatal error U1077: 'E:\Program Files (x86)\Microsoft Visual Studio 8\VC\BIN\nmake.exe' : return code '0x2' Stop. CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:11 (enable_language) -- Configuring incomplete, errors occurred! ___ 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] ifort 9.1 unable to compile a simple test program
Hi Brad, Uh, I don't know how that happened. I pulled a fresh copy of the initial virtual machine, it does get recognized as Intel. I started again, and included the manual link line. The rsp file exists and contains CMakeFiles/cmTryCompileExec.dir/testFortranCompiler.f.obj, the tmp file is nowhere to be found. Spam below. Regards, Arjen E:\buildcmake Z:\f90example -GNMake Makefiles --debug-trycompile debug trycompile on -- The C compiler identification is MSVC -- The CXX compiler identification is MSVC -- Check for CL compiler version -- Check for CL compiler version - 1400 -- Check if this is a free VC compiler -- Check if this is a free VC compiler - no -- Check for working C compiler: E:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/amd64/cl.exe -- Check for working C compiler: E:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/amd64/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: E:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/amd64/cl.exe -- Check for working CXX compiler: E:/Program Files (x86)/Microsoft Visual Studio 8/VC/bin/amd64/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Hoi dit is status een -- The Fortran compiler identification is Intel -- Check for working Fortran compiler: E:/Program Files (x86)/Intel/Compiler/Fortran/9.1/em64t/bin/ifort.exe -- Check for working Fortran compiler: E:/Program Files (x86)/Intel/Compiler/Fortran/9.1/em64t/bin/ifort.exe -- broken CMake Error at E:/cmake28/share/cmake-2.8/Modules/CMakeTestFortranCompiler.cmake:40 (MESSAGE): The Fortran compiler E:/Program Files (x86)/Intel/Compiler/Fortran/9.1/em64t/bin/ifort.exe is not able to compile a simple test program. It fails with the following output: Change Dir: E:/build/CMakeFiles/CMakeTmp Run Build Command:nmake /NOLOGO cmTryCompileExec\fast E:\Program Files (x86)\Microsoft Visual Studio 8\VC\BIN\amd64\nmake.exe -f CMakeFiles\cmTryCompileExec.dir\build.make /nologo -L CMakeFiles\cmTryCompileExec.dir\build E:\cmake28\bin\cmake.exe -E cmake_progress_report E:\build\CMakeFiles\CMakeTmp\CMakeFiles 1 Building Fortran object CMakeFiles/cmTryCompileExec.dir/testFortranCompiler.f.obj E:\PROGRA~1\Intel\Compiler\Fortran\9.1\em64t\bin\ifort.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\nm1394.tmp Linking Fortran executable cmTryCompileExec.exe E:\cmake28\bin\cmake.exe -E vs_link_exe E:\PROGRA~1\Intel\Compiler\Fortran\9.1\em64t\bin\ifort.exe /nologo @CMakeFiles\cmTryCompileExec.dir\objects1.rsp @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\nm1395.tmp backend signals Severe: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error. ifort: error: problem during multi-file optimization compilation (code 3) LINK Pass 1 failed. with 3 NMAKE : fatal error U1077: 'E:\cmake28\bin\cmake.exe' : return code '0x' Stop. NMAKE : fatal error U1077: 'E:\Program Files (x86)\Microsoft Visual Studio 8\VC\BIN\amd64\nmake.exe' : return code '0x2' Stop. CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:14 (enable_language) -- Configuring incomplete, errors occurred! E:\build E:\buildcd CMakeFiles E:\build\CMakeFilescd CMakeTmp E:\build\CMakeFiles\CMakeTmpls CMakeCache.txt CMakeFiles CMakeLists.txt Makefile cmTryCompileExec.exe cmTryCompileExec.exe.embed.manifest cmTryCompileExec.exe.embed.manifest.res cmTryCompileExec.exe.intermediate.manifest cmTryCompileExec.exe.resource.txt cmTryCompileExec.ilk cmake_install.cmake cmtrycompileexec.pdb testCCompiler.c testCXXCompiler.cxx testFortranCompiler.f E:\build\CMakeFiles\CMakeTmpE:\cmake28\bin\cmake.exe -E vs_link_exe E:\PROGRA~1\Intel\Compiler\Fortran\9.1\em64t\bin\if ort.exe /nologo @CMakeFiles\cmTryCompileExec.dir\objects1.rsp @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\nm1395.tmp E:\build\CMakeFiles\CMakeTmpls CMakeCache.txt CMakeFiles CMakeLists.txt Makefile cmTryCompileExec.exe cmTryCompileExec.exe.embed.manifest cmTryCompileExec.exe.embed.manifest.res cmTryCompileExec.exe.intermediate.manifest cmTryCompileExec.exe.resource.txt cmTryCompileExec.ilk cmake_install.cmake cmtrycompileexec.pdb testCCompiler.c testCXXCompiler.cxx testFortranCompiler.f E:\build\CMakeFiles\CMakeTmp -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: vrijdag 6 augustus 2010 17:49 To: Verweij, Arjen Cc: cmake@cmake.org Subject: Re: [CMake] ifort 9.1 unable to compile a simple test program On 08/06/2010 11:26 AM, Verweij, Arjen wrote: I can execute the linkline manually and it seems to link fine. How can I debug what's going on? [snip] -- The Fortran compiler identification is unknown
Re: [CMake] ifort 9.1 unable to compile a simple test program
I did it is below the cmake error in the previous email. No error just a prompt And no noticeable difference to me. Arjen -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: vrijdag 6 augustus 2010 21:39 To: Verweij, Arjen Cc: cmake@cmake.org Subject: Re: [CMake] ifort 9.1 unable to compile a simple test program On 08/06/2010 03:12 PM, Verweij, Arjen wrote: it does get recognized as Intel. [snip] -- The Fortran compiler identification is Intel Good. I started again, and included the manual link line. The rsp file exists and contains CMakeFiles/cmTryCompileExec.dir/testFortranCompiler.f.obj, the tmp file is nowhere to be found. [snip] -- Check for working Fortran compiler: E:/Program Files (x86)/Intel/Compiler/Fortran/9.1/em64t/bin/ifort.exe -- broken [snip] E:\PROGRA~1\Intel\Compiler\Fortran\9.1\em64t\bin\ifort.exe /nologo @CMakeFiles\cmTryCompileExec.dir\objects1.rsp @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\nm1395.tmp The tmp file is generated by NMAKE temporarily when it runs the command. You can see the full command in CMakeFiles\cmTryCompileExec.dir\build.make. Can you try the full command manually? -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
[CMake] linking large lib on windows 64 bit
Hi,
I'm trying to link my project on Windows. Part of the task is constructing a
big archive. Relevant compilers: Intel C/C++, Intel Fortran, Microsoft VS 2005
SE SP1.
Apparently the link line is too long (expanded command line lib bla too long).
I have attempted to circumvent it with:
# create a C++ static library
#SET(CMAKE_CXX_CREATE_STATIC_LIBRARY lib ${CMAKE_CL_NOLOGO} LINK_FLAGS
/out:TARGET OBJECTS )
SET(CMAKE_CXX_CREATE_STATIC_LIBRARY lib ${CMAKE_CL_NOLOGO} LINK_FLAGS
/out:TARGET ${CMAKE_START_TEMP_FILE} OBJECTS ${CMAKE_END_TEMP_FILE} )
according to http://www.itk.org/Bug/view.php?id=7217 - but cmake doesn't fill
in the link flags. Is Bill's suggestion to patch Windows-cl.cmake the fix, or
is it fix otherwise?
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] eliminating -blibpath on AIX
SKIP_BUILD_RPATH ? -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Dave Semeraro Sent: woensdag 4 augustus 2010 15:58 To: cmake@cmake.org Subject: [CMake] eliminating -blibpath on AIX Hello, I am building projects on an AIX system and I want the contents of the link.txt file to not include the -blibpath information at the end. I have tried all combinations of the CMAKE_SKIP_RPATH and other rpath related commands and can not get rid of it. I have read the rpath info on the wiki. Is there a setting for cmake that will allow me to do this or do I have to edit the link.txt files by hand. I would rather not do that as there are lots of them. Best, Dave Semeraro NCSA - University of Illinois ___ 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] eliminating -blibpath on AIX
Patch Modules/Platform/AIX.cmake ? -Original Message- From: Dave Semeraro [mailto:semer...@ncsa.illinois.edu] Sent: woensdag 4 augustus 2010 16:42 To: Verweij, Arjen Subject: Re: [CMake] eliminating -blibpath on AIX Arjen and Denis, Neither suggestion worked. There seems to be no way to get rid of the -blibpath:/usr/lib:lib at the end of the link command. Unfortunately, it seems that under aix this is all that goes into the loader section of the executable and so all the other libs that are linked are not found. I can get around this with the LIBPATH env variable but I really dont want to. If there is no -blibpath at link time the loader section of the executable gets packed with the directories specified by the -L option to ld. Which is what I want. I suppose I can go the other route and just include all those libraries in the -blibpath option string. Not the most elegant solution. But then again elegance is overrated. Dave - Original Message - SKIP_BUILD_RPATH ? -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Dave Semeraro Sent: woensdag 4 augustus 2010 15:58 To: cmake@cmake.org Subject: [CMake] eliminating -blibpath on AIX Hello, I am building projects on an AIX system and I want the contents of the link.txt file to not include the -blibpath information at the end. I have tried all combinations of the CMAKE_SKIP_RPATH and other rpath related commands and can not get rid of it. I have read the rpath info on the wiki. Is there a setting for cmake that will allow me to do this or do I have to edit the link.txt files by hand. I would rather not do that as there are lots of them. Best, Dave Semeraro NCSA - University of Illinois ___ 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-developers] Bug fix requests for the *next* release of CMake...
I'd like to see those fixed: http://public.kitware.com/Bug/view.php?id=11030 That one is closed. ___ 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] libraryname decoration
Olaf, Why? I'm still waiting for someone to post a reason of why a decorated name is a problem for them. Also waiting on an answer to the code duplication issue. Perhaps you should write a proposal that takes care of details, like how you would like to see this decorated. Then write a patch or create a cmake module that takes care of this. I don't see code duplication. 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] Debug/Release configurations for codeblocks ?
Hi, The default is for CMake to generate a Release configuration for Makefile based projects. ie, if you do NOT specify or otherwise set CMAKE_BUILD_TYPE then you will be a Release configuration. I think this statement is false for Windows, or I am misunderstanding Windows-cl.cmake -- I had an interesting time getting rid of all the debug stuff. 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] Debug/Release configurations for codeblocks ?
Hi, Isn't build_type = Release sufficient? Not for the way I'm mistreating cmake ;) set (CMAKE_BUILD_TYPE RELEASE FORCE) SET (CMAKE_EXE_LINKER_FLAGS_INIT FORCE) set (CMAKE_C_FLAGS_RELEASE_INIT ) set (CMAKE_CXX_FLAGS_RELEASE_INIT ) set (CMAKE_Fortran_FLAGS_RELEASE_INIT ) Also I have to add -nodefaultlib:msvcrt.lib (I want libcmt) and if I add a list of libs to exclude (-nodefaultlib:xxx.lib -nodefaultlib:yyy.lib -nodefaultlib:zzz) the last one can't have the .lib extension because I get it twice. (zzz.lib.lib if you don't omit the extension yourself. Perhaps a bug, but I don't have time to investigate right-now. 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] [VS gen] Multiple configurations code
David, I hear what you are saying, but a lot of legacy Makefile based system support make and make debug alongside each other. I'm still looking for the cmake way to easily mark a small part of a project to be built with debug flags. For instance, if you have functionality in a static archive, you just link the new debug enabled object file against the main.o and the archive and you end up with some debugging symbols in no time. Regards, Arjen From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of David Cole [snip] Since this is a prevalent scheme that is widely used by folks coming from single-config, single-architecture (makefile based) build systems... it's the way CMake has gotten to the point it's at now. I'm not saying this is good or bad, just explaining that this is the way it is, and that there are historical reasons why we got to this point. ___ 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] Debug/Release configurations for codeblocks ?
Hi, Which is why I stated Makefile based generators. Not nmake or msvc. Alright, I didn't know you implied Unix Makefiles :) 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 generators on windows: nmake versus jom
Hi Alex, Will this do? http://www.cmake.org/Wiki/CMake_Generator_Specific_Information#Makefile_generators Regards, Arjen -Original Message- From: Alexander Neundorf [mailto:a.neundorf-w...@gmx.net] Sent: zondag 25 juli 2010 19:09 To: cmake@cmake.org Cc: Verweij, Arjen; Brad King Subject: Re: [CMake] cmake generators on windows: nmake versus jom On Thursday 22 July 2010, Verweij, Arjen wrote: Brad, I found another repository with jom binaries. It works fine with 0.9.4. Apparently the original link I used to download JOM was ancient. Here ( http://www.cmake.org/Wiki/CMake_Generator_Specific_Information#Makefile_ generators ) is some documentation about the available generators. Feel free to add some notes about the jom generator there :-) It's a wiki, you can simply get a login. Alex ___ 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] how to set ar/ranlib flags per target
Hi Kelly,
I'm using cmake to migrate from a legacy build system. The source consists of C
C++ Fortran and Fortran90. I think -in all- there are 15 binaries.
One of the problems for us is linking. Cmake somehow decides to take compiler X
to link executable Y. But in some cases it didn't use the one we expected.
So we wrapped add_executable() inside a function that takes an extra argument
to control the linker language:
function (FEXECUTABLE EXE_NAME LINK_LANG )
[...]
add_executable (${EXE_NAME_EXE} ${FILE_LIST_M})
if ( ${LINK_LANG} STREQUAL CXX )
set_target_properties (${EXE_NAME_EXE} PROPERTIES LINKER_LANGUAGE CXX)
elseif ( ${LINK_LANG} STREQUAL C )
set_target_properties (${EXE_NAME_EXE} PROPERTIES LINKER_LANGUAGE C)
elseif ( ${LINK_LANG} STREQUAL Fortran )
set_target_properties (${EXE_NAME_EXE} PROPERTIES LINKER_LANGUAGE
Fortran)
else ()
message( FATAL Unknown linker language specified for function
FEXECUTABLE: ${LINK_LANG )
endif ()
[...]
endfunction (FEXECUTABLE)
I'm not saying that this is proper usage of cmake, but it works for me (tm).
Perhaps you can try a similar approach with add_library() -
myadd_static_library() ? - to indicate if you want to use a 32-bit or 64-bit
archiver.
Regards,
Arjen
-Original Message-
From: Hickel, Kelly [mailto:kelly_hic...@bmc.com]
Sent: donderdag 22 juli 2010 13:46
To: Hickel, Kelly; Verweij, Arjen; cmake@cmake.org
Subject: RE: how to set ar/ranlib flags per target
Arjen, I saw your response about wrapping add_library on the list, but
for some reason it didn't get to my inbox.
I'm not sure what you mean by wrapping, are you talking about a code
change, or some sort of macro? So far, I haven't been able to come up
with any way of jamming -X64 into the right place in the ar command.
Thanks,
Kelly Hickel
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On
Behalf Of Hickel, Kelly
Sent: Wednesday, July 21, 2010 3:46 PM
To: Verweij, Arjen; cmake@cmake.org
Subject: Re: [CMake] how to set ar/ranlib flags per target
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On
Behalf Of Verweij, Arjen
Sent: Wednesday, July 21, 2010 3:43 PM
To: cmake@cmake.org
Subject: Re: [CMake] how to set ar/ranlib flags per target
Kelly,
I suffer from the same problem and solved it like this:
SET(CMAKE_C_ARCHIVE_CREATE CMAKE_AR -X64 cr TARGET LINK_FLAGS
OBJECTS)
SET(CMAKE_C_ARCHIVE_APPEND CMAKE_AR -X64 r TARGET LINK_FLAGS
OBJECTS)
SET(CMAKE_C_ARCHIVE_FINISH CMAKE_RANLIB -X64 TARGET)
SET(CMAKE_CXX_ARCHIVE_CREATE ${CMAKE_C_ARCHIVE_CREATE})
SET(CMAKE_CXX_ARCHIVE_APPEND ${CMAKE_C_ARCHIVE_APPEND})
SET(CMAKE_CXX_ARCHIVE_FINISH ${CMAKE_C_ARCHIVE_FINISH})
SET(CMAKE_Fortran_ARCHIVE_CREATE ${CMAKE_C_ARCHIVE_CREATE})
SET(CMAKE_Fortran_ARCHIVE_APPEND ${CMAKE_C_ARCHIVE_APPEND})
SET(CMAKE_Fortran_ARCHIVE_FINISH ${CMAKE_C_ARCHIVE_FINISH})
Does that help you?
Regards,
Arjen
Thanks Arjen, but I don't believe it does.
As far as I know that sets the flag globally, I have some targets that
are 32 bit and some that are 64 bit, so I need to set it per target.
Reading the source, I found STATIC_LIBRARY_FLAGS, which *almost*
works,
but it puts the flags AFTER the name of the output library, and ar on
AIX doesn't like that, complains it can't find the object file -X64.
Apparently the flag must come before the cr or r commands, e.g.
ar
-X64 cr foo.a bar.o baz.o.
Thanks,
-Kelly
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On
Behalf
Of Hickel, Kelly
Sent: woensdag 21 juli 2010 21:00
To: cmake@cmake.org
Subject: [CMake] how to set ar/ranlib flags per target
Hello,
I'm using CMake 2.8.1, and have a problem on AIX similar to this
one:
http://web.archiveorange.com/archive/v/5y7PkUbT6iizO31eshQa .
I have the additional complication of needing to build both 32 and
64
bit libraries from the same set of CMake files.
I've tried a number of things (list below), does anyone have any
ideas?
(Wherever I write CMAKE_C_xyz below, I've also changed
CMAKE_CXX_xyz
at the same time, where I write xyz_ARCHIVE_CREATE, I've also
changed
xyz_ARCHIVE_APPEND)
1) Adding the flag to LINK_FLAGS because the definition for
CMAKE_C_ARCHIVE_CREATE appears to include that on the command
line,
but the generated link.txt input files don't include any
options.
2) Changed the definition for CMAKE_C_ARCHIVE_CREATE in a private
toolchain file that I specify on the command line. By writing
messages that show the value of that variable, I can see my
change
take, but it appears to get reset to the default before
processing
of
my CMakeLists.txt file begins.
3) Frequently set CMAKE_C_ARCHIVE_CREATE to CMAKE_AR AR_FLAGS
r
TARGET LINK_FLAGS OBJECTS, when I did this, I ended up
Re: [CMake] cmake generators on windows: nmake versus jom
Brad, I found another repository with jom binaries. It works fine with 0.9.4. Apparently the original link I used to download JOM was ancient. Thanks, Arjen -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Verweij, Arjen Sent: woensdag 21 juli 2010 23:07 To: cmake@cmake.org Subject: Re: [CMake] cmake generators on windows: nmake versus jom Hi, The generators are testing and inspecting the toolchain. Something is not building as expected so it reports the problem up front rather than waiting for some subtle error when building the main project. OK. NMake Makefiles JOM [snip] -- FIXME: altered Windows.cmake for debugging purposes. What is this? What was altered? # uncomment these out to debug nmake and borland makefiles # uncommented by AVE message (STATUS FIXME: altered Windows.cmake for debugging purposes.) SET(CMAKE_START_TEMP_FILE ) SET(CMAKE_END_TEMP_FILE ) SET(CMAKE_VERBOSE_MAKEFILE 1) I want to see all the compile flags. It turns out that for reasons unknown the default setting for CMAKE_BUILD_TYPE is Debug for MSVC7.1, causing all kinds of trouble like mixing debug and non-debug libraries when linking the executable. -- Check for working Fortran compiler: E:/Program Files/Intel/Fortran/compiler80/IA32/BIN/ifort.exe -- Check for working Fortran compiler: E:/Program Files/Intel/Fortran/compiler80/IA32/BIN/ifort.exe -- works This means the basic capability to compile an executable seems to work, at least the build tool does not return failure. Do you actually have JOM installed in the environment? It is in the path. Please post CMakeError.log and CMakeOutput.log from the CMakeFiles directory in the build tree. Enclosed. Thanks, 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
[CMake] cmake generators on windows: nmake versus jom
Hi, I'm having trouble generating the Makefiles I want on Windows. I can't generate Unix Makefiles because cmake fails to compile a simple program. But also using generators that should be very much alike, NMake Makefiles and NMake Makefiles JOM, the first will finish and the second will not. This is on a fresh install (Virtual machine) with Ifort 8.1, MSVC++ 7.1 and cmake 2.8.2, no specials. Is it normal for generators to be this picky? Is there documentation on this subject? While browsing email archives I've read that cmake assumes your compiler works but I guess there's more going on under the hood than a mere compilation check. Thanks, Arjen NMake Makefiles: -- Windows! -- FLEXLM=Z:/projects/nastia_src/src/ext/flexlm/v11.6.1 -- ALSDK=Z:/projects/nastia_src/src/ext/alsdk/v10.0.0 -- FLEXLMARCH=i86_n3 -- The Fortran compiler identification is Intel -- FIXME: altered Windows.cmake for debugging purposes. -- Check for working Fortran compiler: E:/Program Files/Intel/Fortran/compiler80/IA32/BIN/ifort.exe -- Check for working Fortran compiler: E:/Program Files/Intel/Fortran/compiler80/IA32/BIN/ifort.exe -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether E:/Program Files/Intel/Fortran/compiler80/IA32/BIN/ifort.exe supports Fortran 90 -- Checking whether E:/Program Files/Intel/Fortran/compiler80/IA32/BIN/ifort.exe supports Fortran 90 -- yes -- The C compiler identification is MSVC -- Check for CL compiler version -- Check for CL compiler version - 1310 -- Check if this is a free VC compiler -- Check if this is a free VC compiler - no -- Check for working C compiler: E:/Program Files/Microsoft Visual Studio .NET 2003/Vc7/bin/cl.exe -- Check for working C compiler: E:/Program Files/Microsoft Visual Studio .NET 2003/Vc7/bin/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- The CXX compiler identification is MSVC -- Check for working CXX compiler: E:/Program Files/Microsoft Visual Studio .NET 2003/Vc7/bin/cl.exe -- Check for working CXX compiler: E:/Program Files/Microsoft Visual Studio .NET 2003/Vc7/bin/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Found FLEX: E:/UnxUtils/usr/local/wbin/flex.exe -- Found BISON: E:/UnxUtils/usr/local/wbin/bison.exe NMake Makefiles JOM -- Windows! -- FLEXLM=Z:/projects/nastia_src/src/ext/flexlm/v11.6.1 -- ALSDK=Z:/projects/nastia_src/src/ext/alsdk/v10.0.0 -- FLEXLMARCH=i86_n3 -- The Fortran compiler identification is Intel -- FIXME: altered Windows.cmake for debugging purposes. -- Check for working Fortran compiler: E:/Program Files/Intel/Fortran/compiler80/IA32/BIN/ifort.exe -- Check for working Fortran compiler: E:/Program Files/Intel/Fortran/compiler80/IA32/BIN/ifort.exe -- works -- Detecting Fortran compiler ABI info CMake Error: Could not COPY_FILE. OutputFile: '' copyFile: 'E:/build/CMakeFiles/CMakeDetermineCompilerABI_Fortran.bin' Unable to find executable for try_compile: tried E:/build/CMakeFiles/CMakeTmp/cmTryCompileExec.exe and E:/build/CMakeFiles/CMakeTmp/Debug /cmTryCompileExec.exe and E:/build/CMakeFiles/CMakeTmp/Development/cmTryCompileExec.exe. -- Detecting Fortran compiler ABI info - done CMake Error at E:/cmake28/share/cmake-2.8/Modules/CMakeDetermineCompilerABI.cmake:40 (FILE): file STRINGS file E:/build/CMakeFiles/CMakeDetermineCompilerABI_Fortran.bin cannot be read. Call Stack (most recent call first): E:/cmake28/share/cmake-2.8/Modules/CMakeTestFortranCompiler.cmake:59 (CMAKE_DETERMINE_COMPILER_ABI) compilers.cmake:45 (enable_language) CMakeLists.txt:4 (include) -- Checking whether E:/Program Files/Intel/Fortran/compiler80/IA32/BIN/ifort.exe supports Fortran 90 -- Checking whether E:/Program Files/Intel/Fortran/compiler80/IA32/BIN/ifort.exe supports Fortran 90 -- yes -- The C compiler identification is MSVC -- Check for CL compiler version -- Check for CL compiler version - 1310 -- Check if this is a free VC compiler -- Check if this is a free VC compiler - no -- Check for working C compiler: E:/Program Files/Microsoft Visual Studio .NET 2003/Vc7/bin/cl.exe -- Check for working C compiler: E:/Program Files/Microsoft Visual Studio .NET 2003/Vc7/bin/cl.exe -- works -- Detecting C compiler ABI info CMake Error: Could not COPY_FILE. OutputFile: '' copyFile: 'E:/build/CMakeFiles/CMakeDetermineCompilerABI_C.bin' Unable to find executable for try_compile: tried E:/build/CMakeFiles/CMakeTmp/cmTryCompileExec.exe and E:/build/CMakeFiles/CMakeTmp/Debug /cmTryCompileExec.exe and E:/build/CMakeFiles/CMakeTmp/Development/cmTryCompileExec.exe. -- Detecting C compiler ABI info - done CMake Error at E:/cmake28/share/cmake-2.8/Modules/CMakeDetermineCompilerABI.cmake:40 (FILE): file STRINGS file
Re: [CMake] incremental build slow because of F90 (cmake_copy_f90_mod)
Brad, Is this normal behaviour after all? Or at least intended? Thanks, Arjen -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Verweij, Arjen Sent: dinsdag 13 juli 2010 13:27 To: cmake@cmake.org Subject: Re: [CMake] incremental build slow because of F90 (cmake_copy_f90_mod) Sent Brad source code to reproduce the bahaviour. Also discovered that the time is actually spent in make and not cmake_copy_f90_mod or touch; they are fast. Regards, Arjen PS Attempting to attach log and source code for completeness here as well -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Verweij, Arjen Sent: maandag 12 juli 2010 20:31 To: Brad King Cc: cmake@cmake.org Subject: Re: [CMake] incremental build slow because of F90 (cmake_copy_f90_mod) Hi Brad, It's not *supposed* to do that. Can you produce a minimal project that reproduces that behavior? This is reassuring. I'm probably not able to reproduce it with something small, but I could try. I would imagine that if it's not supposed to do it, it likely won't :) Apparently, the project has been set up in a peculiar way causing cmake to require touch cmake_copyf90_mod. The current build system has issues with this part of the code as well, with incremental builds. Thanks, 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 ___ 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 generators on windows: nmake versus jom
Hi Kelly, Thanks for your reply. To circumvent these issues we've taken a fresh Windows XP VM and installed compilers cmake UnxUtils but nothing else. No special environment variables clouding the view either :) Regards, Arjen From: Kelly Thompson [mailto:k...@lanl.gov] Sent: woensdag 21 juli 2010 17:00 To: Verweij, Arjen; cmake@cmake.org Subject: RE: [CMake] cmake generators on windows: nmake versus jom Hi Arjen, This may be totally the wrong direction, but we have seen similar errors that appear to be caused by resident programs that crawl the local filesystem. Desktop search engines (Microsoft or Google) or anti-virus software may try to open your build files (including temporary files) for indexing and have the side effect of locking CMake out. You might try disabling your antivirus or desktop search tools while running CMake. -kt From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Verweij, Arjen Sent: Wednesday, July 21, 2010 8:32 AM To: cmake@cmake.org Subject: [CMake] cmake generators on windows: nmake versus jom Hi, I'm having trouble generating the Makefiles I want on Windows. I can't generate Unix Makefiles because cmake fails to compile a simple program. But also using generators that should be very much alike, NMake Makefiles and NMake Makefiles JOM, the first will finish and the second will not. This is on a fresh install (Virtual machine) with Ifort 8.1, MSVC++ 7.1 and cmake 2.8.2, no specials. Is it normal for generators to be this picky? Is there documentation on this subject? While browsing email archives I've read that cmake assumes your compiler works but I guess there's more going on under the hood than a mere compilation check. Thanks, Arjen NMake Makefiles: -- Windows! -- FLEXLM=Z:/projects/nastia_src/src/ext/flexlm/v11.6.1 -- ALSDK=Z:/projects/nastia_src/src/ext/alsdk/v10.0.0 -- FLEXLMARCH=i86_n3 -- The Fortran compiler identification is Intel -- FIXME: altered Windows.cmake for debugging purposes. -- Check for working Fortran compiler: E:/Program Files/Intel/Fortran/compiler80/IA32/BIN/ifort.exe -- Check for working Fortran compiler: E:/Program Files/Intel/Fortran/compiler80/IA32/BIN/ifort.exe -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether E:/Program Files/Intel/Fortran/compiler80/IA32/BIN/ifort.exe supports Fortran 90 -- Checking whether E:/Program Files/Intel/Fortran/compiler80/IA32/BIN/ifort.exe supports Fortran 90 -- yes -- The C compiler identification is MSVC -- Check for CL compiler version -- Check for CL compiler version - 1310 -- Check if this is a free VC compiler -- Check if this is a free VC compiler - no -- Check for working C compiler: E:/Program Files/Microsoft Visual Studio .NET 2003/Vc7/bin/cl.exe -- Check for working C compiler: E:/Program Files/Microsoft Visual Studio .NET 2003/Vc7/bin/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- The CXX compiler identification is MSVC -- Check for working CXX compiler: E:/Program Files/Microsoft Visual Studio .NET 2003/Vc7/bin/cl.exe -- Check for working CXX compiler: E:/Program Files/Microsoft Visual Studio .NET 2003/Vc7/bin/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Found FLEX: E:/UnxUtils/usr/local/wbin/flex.exe -- Found BISON: E:/UnxUtils/usr/local/wbin/bison.exe NMake Makefiles JOM -- Windows! -- FLEXLM=Z:/projects/nastia_src/src/ext/flexlm/v11.6.1 -- ALSDK=Z:/projects/nastia_src/src/ext/alsdk/v10.0.0 -- FLEXLMARCH=i86_n3 -- The Fortran compiler identification is Intel -- FIXME: altered Windows.cmake for debugging purposes. -- Check for working Fortran compiler: E:/Program Files/Intel/Fortran/compiler80/IA32/BIN/ifort.exe -- Check for working Fortran compiler: E:/Program Files/Intel/Fortran/compiler80/IA32/BIN/ifort.exe -- works -- Detecting Fortran compiler ABI info CMake Error: Could not COPY_FILE. OutputFile: '' copyFile: 'E:/build/CMakeFiles/CMakeDetermineCompilerABI_Fortran.bin' Unable to find executable for try_compile: tried E:/build/CMakeFiles/CMakeTmp/cmTryCompileExec.exe and E:/build/CMakeFiles/CMakeTmp/Debug /cmTryCompileExec.exe and E:/build/CMakeFiles/CMakeTmp/Development/cmTryCompileExec.exe. -- Detecting Fortran compiler ABI info - done CMake Error at E:/cmake28/share/cmake-2.8/Modules/CMakeDetermineCompilerABI.cmake:40 (FILE): file STRINGS file E:/build/CMakeFiles/CMakeDetermineCompilerABI_Fortran.bin cannot be read. Call Stack (most recent call first): E:/cmake28/share/cmake-2.8/Modules/CMakeTestFortranCompiler.cmake:59 (CMAKE_DETERMINE_COMPILER_ABI) compilers.cmake:45 (enable_language) CMakeLists.txt:4 (include) -- Checking whether E:/Program Files/Intel/Fortran/compiler80/IA32/BIN/ifort.exe supports Fortran
Re: [CMake] how to set ar/ranlib flags per target
Kelly,
I suffer from the same problem and solved it like this:
SET(CMAKE_C_ARCHIVE_CREATE CMAKE_AR -X64 cr TARGET LINK_FLAGS OBJECTS)
SET(CMAKE_C_ARCHIVE_APPEND CMAKE_AR -X64 r TARGET LINK_FLAGS OBJECTS)
SET(CMAKE_C_ARCHIVE_FINISH CMAKE_RANLIB -X64 TARGET)
SET(CMAKE_CXX_ARCHIVE_CREATE ${CMAKE_C_ARCHIVE_CREATE})
SET(CMAKE_CXX_ARCHIVE_APPEND ${CMAKE_C_ARCHIVE_APPEND})
SET(CMAKE_CXX_ARCHIVE_FINISH ${CMAKE_C_ARCHIVE_FINISH})
SET(CMAKE_Fortran_ARCHIVE_CREATE ${CMAKE_C_ARCHIVE_CREATE})
SET(CMAKE_Fortran_ARCHIVE_APPEND ${CMAKE_C_ARCHIVE_APPEND})
SET(CMAKE_Fortran_ARCHIVE_FINISH ${CMAKE_C_ARCHIVE_FINISH})
Does that help you?
Regards,
Arjen
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Hickel, Kelly
Sent: woensdag 21 juli 2010 21:00
To: cmake@cmake.org
Subject: [CMake] how to set ar/ranlib flags per target
Hello,
I'm using CMake 2.8.1, and have a problem on AIX similar to this one:
http://web.archiveorange.com/archive/v/5y7PkUbT6iizO31eshQa .
I have the additional complication of needing to build both 32 and 64
bit libraries from the same set of CMake files.
I've tried a number of things (list below), does anyone have any ideas?
(Wherever I write CMAKE_C_xyz below, I've also changed CMAKE_CXX_xyz
at the same time, where I write xyz_ARCHIVE_CREATE, I've also changed
xyz_ARCHIVE_APPEND)
1) Adding the flag to LINK_FLAGS because the definition for
CMAKE_C_ARCHIVE_CREATE appears to include that on the command line,
but the generated link.txt input files don't include any options.
2) Changed the definition for CMAKE_C_ARCHIVE_CREATE in a private
toolchain file that I specify on the command line. By writing
messages that show the value of that variable, I can see my change
take, but it appears to get reset to the default before processing of
my CMakeLists.txt file begins.
3) Frequently set CMAKE_C_ARCHIVE_CREATE to CMAKE_AR AR_FLAGS r
TARGET LINK_FLAGS OBJECTS, when I did this, I ended up with
the
literal string AR_FLAGS in the link.txt file, not that useful!
I'm sure I'm missing something, any hints will be appreciated!
Thanks,
Kelly
___
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 generators on windows: nmake versus jom
Hi, The generators are testing and inspecting the toolchain. Something is not building as expected so it reports the problem up front rather than waiting for some subtle error when building the main project. OK. NMake Makefiles JOM [snip] -- FIXME: altered Windows.cmake for debugging purposes. What is this? What was altered? # uncomment these out to debug nmake and borland makefiles # uncommented by AVE message (STATUS FIXME: altered Windows.cmake for debugging purposes.) SET(CMAKE_START_TEMP_FILE ) SET(CMAKE_END_TEMP_FILE ) SET(CMAKE_VERBOSE_MAKEFILE 1) I want to see all the compile flags. It turns out that for reasons unknown the default setting for CMAKE_BUILD_TYPE is Debug for MSVC7.1, causing all kinds of trouble like mixing debug and non-debug libraries when linking the executable. -- Check for working Fortran compiler: E:/Program Files/Intel/Fortran/compiler80/IA32/BIN/ifort.exe -- Check for working Fortran compiler: E:/Program Files/Intel/Fortran/compiler80/IA32/BIN/ifort.exe -- works This means the basic capability to compile an executable seems to work, at least the build tool does not return failure. Do you actually have JOM installed in the environment? It is in the path. Please post CMakeError.log and CMakeOutput.log from the CMakeFiles directory in the build tree. Enclosed. Thanks, Arjen CMakeError.log Description: CMakeError.log CMakeOutput.log Description: CMakeOutput.log ___ 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] how to set ar/ranlib flags per target
Well the thread you reference asks the TS to submit a bug in Mantis. Was such a
bug ever submitted?
I did a quick check and I can't find one using several queries.
No other ideas for fixing your problem except for wrapping add_library to
include 32/64 bit argument.
Regards,
Arjen
-Original Message-
From: Hickel, Kelly [mailto:kelly_hic...@bmc.com]
Sent: woensdag 21 juli 2010 22:46
To: Verweij, Arjen; cmake@cmake.org
Subject: RE: how to set ar/ranlib flags per target
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On
Behalf Of Verweij, Arjen
Sent: Wednesday, July 21, 2010 3:43 PM
To: cmake@cmake.org
Subject: Re: [CMake] how to set ar/ranlib flags per target
Kelly,
I suffer from the same problem and solved it like this:
SET(CMAKE_C_ARCHIVE_CREATE CMAKE_AR -X64 cr TARGET LINK_FLAGS
OBJECTS)
SET(CMAKE_C_ARCHIVE_APPEND CMAKE_AR -X64 r TARGET LINK_FLAGS
OBJECTS)
SET(CMAKE_C_ARCHIVE_FINISH CMAKE_RANLIB -X64 TARGET)
SET(CMAKE_CXX_ARCHIVE_CREATE ${CMAKE_C_ARCHIVE_CREATE})
SET(CMAKE_CXX_ARCHIVE_APPEND ${CMAKE_C_ARCHIVE_APPEND})
SET(CMAKE_CXX_ARCHIVE_FINISH ${CMAKE_C_ARCHIVE_FINISH})
SET(CMAKE_Fortran_ARCHIVE_CREATE ${CMAKE_C_ARCHIVE_CREATE})
SET(CMAKE_Fortran_ARCHIVE_APPEND ${CMAKE_C_ARCHIVE_APPEND})
SET(CMAKE_Fortran_ARCHIVE_FINISH ${CMAKE_C_ARCHIVE_FINISH})
Does that help you?
Regards,
Arjen
Thanks Arjen, but I don't believe it does.
As far as I know that sets the flag globally, I have some targets that
are 32 bit and some that are 64 bit, so I need to set it per target.
Reading the source, I found STATIC_LIBRARY_FLAGS, which *almost* works,
but it puts the flags AFTER the name of the output library, and ar on
AIX doesn't like that, complains it can't find the object file -X64.
Apparently the flag must come before the cr or r commands, e.g. ar
-X64 cr foo.a bar.o baz.o.
Thanks,
-Kelly
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On
Behalf
Of Hickel, Kelly
Sent: woensdag 21 juli 2010 21:00
To: cmake@cmake.org
Subject: [CMake] how to set ar/ranlib flags per target
Hello,
I'm using CMake 2.8.1, and have a problem on AIX similar to this one:
http://web.archiveorange.com/archive/v/5y7PkUbT6iizO31eshQa .
I have the additional complication of needing to build both 32 and 64
bit libraries from the same set of CMake files.
I've tried a number of things (list below), does anyone have any
ideas?
(Wherever I write CMAKE_C_xyz below, I've also changed CMAKE_CXX_xyz
at the same time, where I write xyz_ARCHIVE_CREATE, I've also changed
xyz_ARCHIVE_APPEND)
1) Adding the flag to LINK_FLAGS because the definition for
CMAKE_C_ARCHIVE_CREATE appears to include that on the command
line,
but the generated link.txt input files don't include any options.
2) Changed the definition for CMAKE_C_ARCHIVE_CREATE in a private
toolchain file that I specify on the command line. By writing
messages that show the value of that variable, I can see my change
take, but it appears to get reset to the default before processing
of
my CMakeLists.txt file begins.
3) Frequently set CMAKE_C_ARCHIVE_CREATE to CMAKE_AR AR_FLAGS r
TARGET LINK_FLAGS OBJECTS, when I did this, I ended up with
the
literal string AR_FLAGS in the link.txt file, not that useful!
I'm sure I'm missing something, any hints will be appreciated!
Thanks,
Kelly
___
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.2 win32: invalid escape sequence when finding fortran compiler
Spot on Bill:
C:\Users\madymo\build\CMakeFiles\CMakeTmpcat CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
PROJECT(CMAKE_TRY_COMPILE Fortran)
SET(CMAKE_VERBOSE_MAKEFILE 1)
SET(CMAKE_Fortran_FLAGS /w /I:C:\Program Files\VNI\CTT5.0\include\IA32
/fpe:3 /nologo ${COMPILE_DEFINITIONS})
INCLUDE_DIRECTORIES(${INCLUDE_DIRECTORIES})
SET(CMAKE_SUPPRESS_REGENERATION 1)
LINK_DIRECTORIES(${LINK_DIRECTORIES})
ADD_EXECUTABLE(cmTryCompileExec
C:/Users/madymo/build/CMakeFiles/CMakeTmp/testFortranCompiler.f)
TARGET_LINK_LIBRARIES(cmTryCompileExec ${LINK_LIBRARIES})
Also, what is in your environment? Anything like CFLAGS, FFLAGS or
others that CMake might pick up and try to use?
F90FLAGS=/w /I:C:\Program Files\VNI\CTT5.0\include\IA32 /fpe:3 /nologo
FFLAGS=/w /I:C:\Program Files\VNI\CTT5.0\include\IA32 /fpe:3 /nologo
I guess you get all these for free when you install the intel fortran compiler.
I'll see if I can get rid of these without breaking the current build system :)
Thanks,
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.2 win32: invalid escape sequence when finding fortran compiler
Hi Bill, I don't think we ended up with those flags after installing the intel compiler for the dashboard we run at Kitware. Are you sure that came from the installer? Not really. I wasn't around when that system was set up. I tried from cmd.exe, MKS ksh and cygwin shell to get something with Makefiles on Windows after unsetting the FFLAGS and F90FLAGS, but the only thing I can successfully generate is solution files. With Makefiles is borks somehow (cmake can't generate for me). Well, I'll go see if --debug-trycompile helps me point in the right direction or if I can find something online or in the book and otherwise start another thread :P Thanks, 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
[CMake] cmake 2.8.2 win32: invalid escape sequence when finding fortran compiler
Hi,
I'm trying a little F90 example on Windows with cmake. Apparently something is
amiss, but I can't find much on Google about it; at least not about this
particular case.
All I do is cmake ..\f90example and the following appears in my terminal:
S:\mnt\usr3\people\verweija\buildcmake ..\f90example
-- Building for: Visual Studio 7 .NET 2003
-- Check for working C compiler using: Visual Studio 7 .NET 2003
-- Check for working C compiler using: Visual Studio 7 .NET 2003 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 7 .NET 2003
-- Check for working CXX compiler using: Visual Studio 7 .NET 2003 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working Fortran compiler using: Visual Studio 7 .NET 2003
CMake Error at CMakeLists.txt:4 (SET):
Syntax error in cmake code at
S:/mnt/usr3/people/verweija/build/CMakeFiles/CMakeTmp/CMakeLists.txt:4
when parsing string
C:\Program
Invalid escape sequence \P
CMake Error at CMakeLists.txt:4 (SET):
Syntax error in cmake code at
S:/mnt/usr3/people/verweija/build/CMakeFiles/CMakeTmp/CMakeLists.txt:4
when parsing string
Files\VNI\CTT5.0\include\IA32 /fpe:3 /nologo ${COMPILE_DEFINITIONS}
Invalid escape sequence \V
CMake Error: Internal CMake error, TryCompile configure of cmake failed
-- Configuring incomplete, errors occurred!
Please advise :)
Thanks,
Arjen
Arjen Verweij
QA/Test Engineer
[cid:image001.gif@01CB236F.5D309C80]
Einsteinlaan 6
2289 CC Rijswijk
The Netherlands
Phone: +31 88 827 7086
Fax: +31 88 827 7003
Email: arjen.verw...@tass-safe.com
www.tass-safe.com
This e-mail and its contents are subject to a DISCLAIMER with important
RESERVATIONS.
inline: image001.gif___
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_LANG_FLAGS added to link rule
Hello Michael, Apparently, there may be - at least with GCC and shared libraries - a need to specify flags on the link line if they have been specified on the compile line before. Though, I don't know an example of a damaged binary due to different sets of flags for compiling and linking. Thanks. I understand it a bit better now, but I'm not sure how other compilers implement this. Fortunately I can redefine the way cmake generates rules for the Fortran linkstage, so I'm a happy camper. Hopefully when I'm done the spirit of cmake is still alive and we have a somewhat crossplatform implementation of our build system. I need to find some more resources on how to handle special cases without manhandling cmake. Well, I digress. 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_LANG_FLAGS added to link rule
Hi, AFAIK there is nothing that will be broken on AIX by removing FLAGS from the link rule for Fortran executables. OK, I will just redefine the Fortran linker to keep the cmake generator compatible then start scrubbing link flags based on compiler documentation, because: What flags are causing the problem? -xlf77=noleadzero and -xlf77=gedit77 -- as it turns out (reading documentation to figure out what these flags are supposed to do) they are incorrect and should read: -qxlf77=noleadzero and -qxlf77=gedit77. Why xlf_r only complains during the linkstage and not while compiling I don't know, but this gets rid of the error. I guess fixing the propagation of link flags in cmake is probably not a good idea until the implications are fully understood and not a pressing matter for me (anymore). Thank you for investigating, 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] incremental build slow because of F90 (cmake_copy_f90_mod)
Sent Brad source code to reproduce the bahaviour. Also discovered that the time is actually spent in make and not cmake_copy_f90_mod or touch; they are fast. Regards, Arjen PS Attempting to attach log and source code for completeness here as well -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Verweij, Arjen Sent: maandag 12 juli 2010 20:31 To: Brad King Cc: cmake@cmake.org Subject: Re: [CMake] incremental build slow because of F90 (cmake_copy_f90_mod) Hi Brad, It's not *supposed* to do that. Can you produce a minimal project that reproduces that behavior? This is reassuring. I'm probably not able to reproduce it with something small, but I could try. I would imagine that if it's not supposed to do it, it likely won't :) Apparently, the project has been set up in a peculiar way causing cmake to require touch cmake_copyf90_mod. The current build system has issues with this part of the code as well, with incremental builds. Thanks, 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 cmake version 2.8.1 Usage cmake [options] path-to-source cmake [options] path-to-existing-build Options -C initial-cache = Pre-load a script to populate the cache. -D var:type=value = Create a cmake cache entry. -U globbing_expr = Remove matching entries from CMake cache. -G generator-name = Specify a makefile generator. -Wno-dev= Suppress developer warnings. -Wdev = Enable developer warnings. -E = CMake command mode. -i = Run in wizard mode. -L[A][H]= List non-advanced cached variables. --build dir = Build a CMake-generated project binary tree. -N = View mode only. -P file = Process script mode. --graphviz=[file] = Generate graphviz of dependencies. --system-information [file] = Dump information about this system. --debug-trycompile = Do not delete the try compile directories.. --debug-output = Put cmake in a debug mode. --trace = Put cmake in trace mode. --help-command cmd [file] = Print help for a single command and exit. --help-command-list [file] = List available listfile commands and exit. --help-commands [file] = Print help for all commands and exit. --help-compatcommands [file]= Print help for compatibility commands. --help-module module [file] = Print help for a single module and exit. --help-module-list [file] = List available modules and exit. --help-modules [file] = Print help for all modules and exit. --help-custom-modules [file]= Print help for all custom modules and exit. --help-policy cmp [file]= Print help for a single policy and exit. --help-policies [file] = Print help for all policies and exit. --help-property prop [file] = Print help for a single property and exit. --help-property-list [file] = List available properties and exit. --help-properties [file]= Print help for all properties and exit. --help-variable var [file] = Print help for a single variable and exit. --help-variable-list [file] = List documented variables and exit. --help-variables [file] = Print help for all variables and exit. --copyright [file] = Print the CMake copyright and exit. --help = Print usage information and exit. --help-full [file] = Print full help and exit. --help-html [file] = Print full help in HTML format. --help-man [file] = Print full help as a UNIX man page and exit. --version [file]= Show program name/version banner and exit. Generators The following generators are available on this platform: Unix Makefiles = Generates standard UNIX makefiles. CodeBlocks - Unix Makefiles = Generates CodeBlocks project files. Eclipse CDT4 - Unix Makefiles = Generates Eclipse CDT 4.0 project files. KDevelop3 = Generates KDevelop 3 project files. KDevelop3 - Unix Makefiles = Generates KDevelop 3 project files. f90example.tgz Description: f90example.tgz ___ 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] incremental build slow because of F90 (cmake_copy_f90_mod)
Wrong log.txt :P -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Verweij, Arjen Sent: dinsdag 13 juli 2010 13:27 To: cmake@cmake.org Subject: Re: [CMake] incremental build slow because of F90 (cmake_copy_f90_mod) Sent Brad source code to reproduce the bahaviour. Also discovered that the time is actually spent in make and not cmake_copy_f90_mod or touch; they are fast. Regards, Arjen PS Attempting to attach log and source code for completeness here as well -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Verweij, Arjen Sent: maandag 12 juli 2010 20:31 To: Brad King Cc: cmake@cmake.org Subject: Re: [CMake] incremental build slow because of F90 (cmake_copy_f90_mod) Hi Brad, It's not *supposed* to do that. Can you produce a minimal project that reproduces that behavior? This is reassuring. I'm probably not able to reproduce it with something small, but I could try. I would imagine that if it's not supposed to do it, it likely won't :) Apparently, the project has been set up in a peculiar way causing cmake to require touch cmake_copyf90_mod. The current build system has issues with this part of the code as well, with incremental builds. Thanks, 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 /usr2/people/verweija/local/bin/cmake -H/mnt/usr3/people/verweija/f90example -B/mnt/usr3/people/verweija/build --check-build-system CMakeFiles/Makefile.cmake 0 /usr2/people/verweija/local/bin/cmake -E cmake_progress_start /mnt/usr3/people/verweija/build/CMakeFiles /mnt/usr3/people/verweija/build/CMakeFiles/progress.marks /usr1/people/maddev/util/bin/make -f CMakeFiles/Makefile2 all make[1]: Entering directory `/mnt/usr3/people/verweija/build' /usr1/people/maddev/util/bin/make -f CMakeFiles/mytest.dir/build.make CMakeFiles/mytest.dir/depend make[2]: Entering directory `/mnt/usr3/people/verweija/build' cd /mnt/usr3/people/verweija/build /usr2/people/verweija/local/bin/cmake -E cmake_depends Unix Makefiles /mnt/usr3/people/verweija/f90example /mnt/usr3/people/verweija/f90example /mnt/usr3/people/verweija/build /mnt/usr3/people/verweija/build /mnt/usr3/people/verweija/build/CMakeFiles/mytest.dir/DependInfo.cmake --color= make[2]: Leaving directory `/mnt/usr3/people/verweija/build' /usr1/people/maddev/util/bin/make -f CMakeFiles/mytest.dir/build.make CMakeFiles/mytest.dir/requires make[2]: Entering directory `/mnt/usr3/people/verweija/build' /usr1/people/maddev/util/bin/make -f CMakeFiles/mytest.dir/build.make CMakeFiles/mytest.dir/exec.f90.o.provides.build make[3]: Entering directory `/mnt/usr3/people/verweija/build' /usr2/people/verweija/local/bin/cmake -E cmake_copy_f90_mod execute CMakeFiles/mytest.dir/execute.mod.stamp /usr2/people/verweija/local/bin/cmake -E touch CMakeFiles/mytest.dir/exec.f90.o.provides.build make[3]: Leaving directory `/mnt/usr3/people/verweija/build' /usr1/people/maddev/util/bin/make -f CMakeFiles/mytest.dir/build.make CMakeFiles/mytest.dir/init.f90.o.provides.build make[3]: Entering directory `/mnt/usr3/people/verweija/build' /usr2/people/verweija/local/bin/cmake -E cmake_copy_f90_mod initialize CMakeFiles/mytest.dir/initialize.mod.stamp /usr2/people/verweija/local/bin/cmake -E touch CMakeFiles/mytest.dir/init.f90.o.provides.build make[3]: Leaving directory `/mnt/usr3/people/verweija/build' /usr1/people/maddev/util/bin/make -f CMakeFiles/mytest.dir/build.make CMakeFiles/mytest.dir/output.f90.o.provides.build make[3]: Entering directory `/mnt/usr3/people/verweija/build' /usr2/people/verweija/local/bin/cmake -E cmake_copy_f90_mod output CMakeFiles/mytest.dir/output.mod.stamp /usr2/people/verweija/local/bin/cmake -E touch CMakeFiles/mytest.dir/output.f90.o.provides.build make[3]: Leaving directory `/mnt/usr3/people/verweija/build' make[2]: Leaving directory `/mnt/usr3/people/verweija/build' /usr1/people/maddev/util/bin/make -f CMakeFiles/mytest.dir/build.make CMakeFiles/mytest.dir/build make[2]: Entering directory `/mnt/usr3/people/verweija/build' /usr2/people/verweija/local/bin/cmake -E cmake_copy_f90_mod execute CMakeFiles/mytest.dir/execute.mod.stamp /usr2/people/verweija/local/bin/cmake -E touch CMakeFiles/mytest.dir/exec.f90.o.provides.build /usr2/people/verweija/local/bin/cmake -E cmake_copy_f90_mod initialize CMakeFiles/mytest.dir/initialize.mod.stamp /usr2/people/verweija/local/bin/cmake -E touch CMakeFiles/mytest.dir/init.f90.o.provides.build /usr2/people/verweija/local/bin/cmake -E cmake_copy_f90_mod output CMakeFiles/mytest.dir/output.mod.stamp /usr2/people/verweija/local/bin/cmake -E touch CMakeFiles/mytest.dir/output.f90.o.provides.build
[CMake] incremental build slow because of F90 (cmake_copy_f90_mod)
Hi, We're finding incremental builds to be slow, because the F90 source seems to be privy to a processing step known as cmake_copy_f90_mod. While cmake and the compiler race through C/CXX/Fortran(77) source, this is not the case for F90. What does cmake_copy_f90_mod do? I can hardly find any documentation for it :) Are there workarounds that may decrease time spent in this area during incremental compiles? Thanks, Arjen Arjen Verweij QA/Test Engineer [cid:image001.gif@01CB21C7.4E698DA0] Einsteinlaan 6 2289 CC Rijswijk The Netherlands Phone: +31 88 827 7086 Fax: +31 88 827 7003 Email: arjen.verw...@tass-safe.com www.tass-safe.com This e-mail and its contents are subject to a DISCLAIMER with important RESERVATIONS. inline: image001.gif___ 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_LANG_FLAGS added to link rule
Hi, It seems that in our project the contents of CMAKE_LANG_FLAGS is added to the link line. This causes problems for some of our platforms. Is there a mechanism to separate language specific compile and link flags out? It would be nice if you could define CMAKE_LANG_COMPILER_FLAGS and CMAKE_LANG_LINK_FLAGS separately. I could write a wrapper around add_executable() and add_library() but I would prefer something standard. Looking at cmake-2.8.1/Modules/CMakeFortranInformation.cmake, I can't really find much except that CMAKE_Fortran_LINK_EXECUTABLE is set, but CMAKE_Fortran_FLAGS are not included. Regards, Arjen Arjen Verweij QA/Test Engineer [cid:image001.gif@01CB21E8.0002BDA0] Einsteinlaan 6 2289 CC Rijswijk The Netherlands Phone: +31 88 827 7086 Fax: +31 88 827 7003 Email: arjen.verw...@tass-safe.com www.tass-safe.com This e-mail and its contents are subject to a DISCLAIMER with important RESERVATIONS. inline: image001.gif___ 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_LANG_FLAGS added to link rule
As a follow-up: redefining CMAKE_Fortran_LINK_EXECUTABLE to not include FLAGS gets rid of the CMAKE_Fortran_FLAGS.. but perhaps other (useful) stuff as well? As a sidetrack I'm starting to wonder what the purpose of CMAKE_LANG_FLAGS is. The book lists it as cmake's counterpart of the environment variable, e.g. CMAKE_CXX_FLAGS and CXXFLAGS from the shell, which means it doesn't make sense to include it when linking. Am I overlooking something here :) Regards, Arjen From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Verweij, Arjen Sent: maandag 12 juli 2010 18:13 To: cmake@cmake.org Subject: [CMake] CMAKE_LANG_FLAGS added to link rule Hi, It seems that in our project the contents of CMAKE_LANG_FLAGS is added to the link line. This causes problems for some of our platforms. Is there a mechanism to separate language specific compile and link flags out? It would be nice if you could define CMAKE_LANG_COMPILER_FLAGS and CMAKE_LANG_LINK_FLAGS separately. I could write a wrapper around add_executable() and add_library() but I would prefer something standard. Looking at cmake-2.8.1/Modules/CMakeFortranInformation.cmake, I can't really find much except that CMAKE_Fortran_LINK_EXECUTABLE is set, but CMAKE_Fortran_FLAGS are not included. Regards, Arjen Arjen Verweij QA/Test Engineer [cid:image001.gif@01CB21F5.056CED80] Einsteinlaan 6 2289 CC Rijswijk The Netherlands Phone: +31 88 827 7086 Fax: +31 88 827 7003 Email: arjen.verw...@tass-safe.com www.tass-safe.com This e-mail and its contents are subject to a DISCLAIMER with important RESERVATIONS. inline: image001.gif___ 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] incremental build slow because of F90 (cmake_copy_f90_mod)
Hi Brad, Actually the copy-f90-mod step is a *feature* to make incremental rebuilds faster. It is an optimization for the case that the .f90 source file that provides a module gets recompiled but the *interface* to the module does not change. Many compilers update the timestamp on the .mod file anyway. In this case we do not want all the sources that use the module to recompile needlessly. The copy-f90-mod step copies the .mod file to a module timestamp file in a way that does not modify the timestamp unless the module really changed. Cmake_copy_f90_mod gets called every time I type make for (as far as I can tell) every F90 file that provides a module. So for instance I change a comment in my main.f, the compile and linktime for the executable (4000 ish files) NOT including the time spent in the F90 portion of the tree is 5 seconds, but the F90 part takes a minute. I don't see any recompiling going on for the F90 part. Does cmake_copy_f90_mod get called even if you don't have to compile any F90 files? Thanks, 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_LANG_FLAGS added to link rule
Brad, Can you comment on what other stuff ends up in FLAGS? If it's just CMAKE_LANG_FLAGS, I guess redefining CMAKE_LANG_LINK_EXECUTABLE would be a viable workaround. Thanks, Arjen -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: maandag 12 juli 2010 19:20 To: Verweij, Arjen Cc: cmake@cmake.org Subject: Re: [CMake] CMAKE_LANG_FLAGS added to link rule On 07/12/2010 01:12 PM, Verweij, Arjen wrote: As a follow-up: redefining CMAKE_Fortran_LINK_EXECUTABLE to not include FLAGS gets rid of the CMAKE_Fortran_FLAGS.. but perhaps other (useful) stuff as well? As a sidetrack I'm starting to wonder what the purpose of CMAKE_LANG_FLAGS is. The book lists it as cmake's counterpart of the environment variable, e.g. CMAKE_CXX_FLAGS and CXXFLAGS from the shell, which means it doesn't make sense to include it when linking. Am I overlooking something here J AFAIK no one designed it this way, it just happened over time during development. My guess is that people wanted compile flags like -m64 to be passed when the compiler is used as a front-end to the linker. Since it's been in the default rules for years we cannot change it without breaking compatibility. All of this was developed before CMake supported Fortran. I've seen very few C and C++ compilers that do not accept/ignore all of their compiler flags even when used as a linking front-end. That's likely why this wasn't caught at the beginning. -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] incremental build slow because of F90 (cmake_copy_f90_mod)
Hi Brad, It's not *supposed* to do that. Can you produce a minimal project that reproduces that behavior? This is reassuring. I'm probably not able to reproduce it with something small, but I could try. I would imagine that if it's not supposed to do it, it likely won't :) Apparently, the project has been set up in a peculiar way causing cmake to require touch cmake_copyf90_mod. The current build system has issues with this part of the code as well, with incremental builds. Thanks, 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_LANG_FLAGS added to link rule
Brad, That sounds fine, I'm already in the habit of specifying link flags per language anyway. In fact I will take a looksie and recompile cmake with your suggested fix. Regards, Arjen Looking at the implementation I see it gets architecture flags on the Mac (-arch and -isysroot), which is consistent with the -m64 type flags I mentioned before. However it looks to me like things have been refactored enough to simply move these into the link-only flags with a one-line change. The change would not solve the original problem but would enable your workaround. Bill? -Brad diff --git a/Source/cmMakefileExecutableTargetGenerator.cxx b/Source/cmMakefileExecutableTargetGenerator.cxx index 93c981a..cb41e74 100644 --- a/Source/cmMakefileExecutableTargetGenerator.cxx +++ b/Source/cmMakefileExecutableTargetGenerator.cxx @@ -229,7 +229,7 @@ void cmMakefileExecutableTargetGenerator::WriteExecutableRule(bool relink) // Add language feature flags. this-AddFeatureFlags(flags, linkLanguage); - this-LocalGenerator-AddArchitectureFlags(flags, this-Target, + this-LocalGenerator-AddArchitectureFlags(linkFlags, this-Target, linkLanguage, this- ConfigName); // Add target-specific linker flags. ___ 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_LANG_FLAGS added to link rule
Brad, That bit of code is #IFDEF'ed for __APPLE__. I doubt it is causing the problem on AIX. Regards, Arjen -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Verweij, Arjen Sent: maandag 12 juli 2010 20:47 To: Brad King Cc: cmake@cmake.org; Bill Hoffman Subject: Re: [CMake] CMAKE_LANG_FLAGS added to link rule Brad, That sounds fine, I'm already in the habit of specifying link flags per language anyway. In fact I will take a looksie and recompile cmake with your suggested fix. Regards, Arjen Looking at the implementation I see it gets architecture flags on the Mac (-arch and -isysroot), which is consistent with the -m64 type flags I mentioned before. However it looks to me like things have been refactored enough to simply move these into the link-only flags with a one-line change. The change would not solve the original problem but would enable your workaround. Bill? -Brad diff --git a/Source/cmMakefileExecutableTargetGenerator.cxx b/Source/cmMakefileExecutableTargetGenerator.cxx index 93c981a..cb41e74 100644 --- a/Source/cmMakefileExecutableTargetGenerator.cxx +++ b/Source/cmMakefileExecutableTargetGenerator.cxx @@ -229,7 +229,7 @@ void cmMakefileExecutableTargetGenerator::WriteExecutableRule(bool relink) // Add language feature flags. this-AddFeatureFlags(flags, linkLanguage); - this-LocalGenerator-AddArchitectureFlags(flags, this-Target, + this-LocalGenerator-AddArchitectureFlags(linkFlags, this-Target, linkLanguage, this- ConfigName); // Add target-specific linker flags. ___ 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] problems with creating static library on aix
Hi,
Apparently it had to do with the setting for ncargs. Increasing it to 256
(blocks of 4K) solved it.
Regards,
Arjen
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Verweij, Arjen
Sent: dinsdag 6 juli 2010 18:55
To: cmake@cmake.org
Subject: [CMake] problems with creating static library on aix
Hi,
We're experiencing two problems with creating static libraries through
cmake on our AIX system.
The first one is that a cmake based build environment will come up with
64-bit XCOFF, but ar and friends won't play ball unless you add -X64. I
suppose this issue has just been overlooked and is in fact minor.
The other problem is that even though I have added the below workaround
referenced in a thread from July '08, ar cr will choke on the amount
or objects I'm feeding it. I'm sure this is a problem with the ar itself
and not cmake, but I would be interested to learn of a possible
workaround. It works fine for smaller archives.
Thanks,
Arjen
SET(CMAKE_C_ARCHIVE_CREATE CMAKE_AR -X64 cr TARGET LINK_FLAGS
OBJECTS)
SET(CMAKE_C_ARCHIVE_APPEND CMAKE_AR -X64 r TARGET LINK_FLAGS
OBJECTS)
SET(CMAKE_C_ARCHIVE_FINISH CMAKE_RANLIB -X64 TARGET)
SET(CMAKE_CXX_ARCHIVE_CREATE ${CMAKE_C_ARCHIVE_CREATE})
SET(CMAKE_CXX_ARCHIVE_APPEND ${CMAKE_C_ARCHIVE_APPEND})
SET(CMAKE_CXX_ARCHIVE_FINISH ${CMAKE_C_ARCHIVE_FINISH})
SET(CMAKE_Fortran_ARCHIVE_CREATE ${CMAKE_C_ARCHIVE_CREATE})
SET(CMAKE_Fortran_ARCHIVE_APPEND ${CMAKE_C_ARCHIVE_APPEND})
SET(CMAKE_Fortran_ARCHIVE_FINISH ${CMAKE_C_ARCHIVE_FINISH})
___
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
[CMake] problems with creating static library on aix
Hi,
We're experiencing two problems with creating static libraries through cmake on
our AIX system.
The first one is that a cmake based build environment will come up with 64-bit
XCOFF, but ar and friends won't play ball unless you add -X64. I suppose this
issue has just been overlooked and is in fact minor.
The other problem is that even though I have added the below workaround
referenced in a thread from July '08, ar cr will choke on the amount or
objects I'm feeding it. I'm sure this is a problem with the ar itself and not
cmake, but I would be interested to learn of a possible workaround. It works
fine for smaller archives.
Thanks,
Arjen
SET(CMAKE_C_ARCHIVE_CREATE CMAKE_AR -X64 cr TARGET LINK_FLAGS OBJECTS)
SET(CMAKE_C_ARCHIVE_APPEND CMAKE_AR -X64 r TARGET LINK_FLAGS OBJECTS)
SET(CMAKE_C_ARCHIVE_FINISH CMAKE_RANLIB -X64 TARGET)
SET(CMAKE_CXX_ARCHIVE_CREATE ${CMAKE_C_ARCHIVE_CREATE})
SET(CMAKE_CXX_ARCHIVE_APPEND ${CMAKE_C_ARCHIVE_APPEND})
SET(CMAKE_CXX_ARCHIVE_FINISH ${CMAKE_C_ARCHIVE_FINISH})
SET(CMAKE_Fortran_ARCHIVE_CREATE ${CMAKE_C_ARCHIVE_CREATE})
SET(CMAKE_Fortran_ARCHIVE_APPEND ${CMAKE_C_ARCHIVE_APPEND})
SET(CMAKE_Fortran_ARCHIVE_FINISH ${CMAKE_C_ARCHIVE_FINISH})
___
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] pgf90 error
Hi, Sorry for reviving this, but I've read it and I didn't understand. Will some version of 2.8.x clear this flag on Linux when the compiler is pgf90 or is this now a documented feature for which you need to clear the flags manually? For the record, when using pgf90 you also need to clear CMAKE_SHARED_LIBRARY_LINK_Fortran_FLAGS since it is set to whatever is in CMAKE_SHARED_LIBRARY_LINK_C_FLAGS if it isn't set. Regards, Arjen From: cmake-boun...@cmake.org [cmake-boun...@cmake.org] On Behalf Of Brad King [brad.k...@kitware.com] Brad King wrote: John Vines (CISD/CIV) wrote: pgf90-Error-Unknown switch: -rdynamic Due to some historic cruft this compiler is not supported on Linux right now. In Modules/Platform/Linux.cmake comment out the line SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS -rdynamic) This is on our TODO list for 2.8.x but we didn't want to mess with the widely used Linux.cmake platform file just before the 2.8.0 release. http://www.cmake.org/Bug/view.php?id=9985 ___ 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] pgf90: influencing link flags for the binary
Hi, After clearing a lot of FLAGS, the final link rule for my executable has been reduced to something that resembles what is being used to link it with the current make system. But I still want to get rid of some other stuff like -lpgc and -lnspgc. Is there a possibility to influence this as well? Thanks, 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] pgf90: influencing link flags for the binary
Never mind, it's CMAKE_XXX_IMPLICIT_LINK_LIBRARIES. Regards, Arjen -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Verweij, Arjen Sent: dinsdag 30 maart 2010 16:02 To: cmake@cmake.org Subject: [CMake] pgf90: influencing link flags for the binary Hi, After clearing a lot of FLAGS, the final link rule for my executable has been reduced to something that resembles what is being used to link it with the current make system. But I still want to get rid of some other stuff like -lpgc and -lnspgc. Is there a possibility to influence this as well? Thanks, 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 ___ 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] How to run shell command in CMakeLists.txt
Hi, Please guide me how to create one static lib from multiple static libs. Can I use ar -x libname and then again make ar from the *.o files? Is there any other way? -- Thanks Regards, Kiran Patil Don't even try. Create the single static lib in the first place. There has been a long discussion about this just recently, refer to that for more info (please read to the end, there were some dependency problems in the posted solutions): http://marc.info/?l=cmakem=126841136518109w=2 Also note (as I am finding out) that cmake doesn't really seem suitable to develop binaries in this fashion. Previously we would create a new binary with the preexisting stuff and just put a new object file in the link rule for the binary. That was pretty fast. Now cmake takes care of these things, and this no longer is an option. So you may want to consider creating a shared objects version for your developers. 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] static library from several subdirectories
Hi Markus, -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Markus Raab I have exactly the same problem, please share if you get a good solution. Any luck yet? I think we got it nailed so far, but now it needs to refactoring and reusage of common code. Once it has been cleaned up it could be in the FAQ I guess, until cmake supports it like Hendrik proposed it ;) 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] Nice handling of code coverage option?
Hi Brad, -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Brad Hards Any comments or suggestions on this? We use gcov and lcov for our C++ code. I think you should take care to make sure you have the same version gcov as gcc/g++. Also I think you get better results if you compile using -O0. Optimization will confuse the postprocessing. Like you we have a special config option in the build system for it. 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] Nice handling of code coverage option?
Hi Brad, -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Brad Hards Do you have something else? Not really, but I don't build debug either (no -g). I don't know about an iron clad way to prevent cmake from optimizing anything, so I just use verbose makefiles and log the build output. The default for gcc is -O0, so if the log is spotless (i.e. no -O) I assume I'm in the clear. I think you can use --coverage for both building and linking btw. But no matter, you've already typed it out :) 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] scope of set_source_files_properties?
Hi, -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Simmons, Aaron All the sources are going into a single *library*. I could make a bunch of static libraries corresponding to each folder, but I'm not sure how to subsequently link all them into a single static library. (It's been mentioned elsewhere on this list, but the answer was vague.) For our Fortran code, we're currently migrating from Makefiles and RCS to SVN and CMake. It is apparent that CMake and static libraries over more than a single source directory don't play nice. Fortunately Michael Wild was nice enough to type it out for the inadvertent cmake user. Also, we ran into the problem referenced in this thread, where the source flags that were overridden mysteriously disappeared. Sometimes, inside the source (mostly Fortran) are compiler flags differing from the default that need to be set, as well as openmp statements. So instead of setting the source flags in the local directory, we're now going to set it from the top level target, and wrap the functionality in a my_add_library() that will parse the source list, look for override cmake files, set the overrides for the particular file and THEN add the library. Easy as pie. At any rate, it seems like a rather elaborate workaround... I agree. But linking is really expensive, so I'm seriously considering making a customer version (also for innight testing) and a development version that will use shared objects so you don't have to link a tonne of objects everytime you changed a source file. Previously, we would have source and binaries sit in a shared directory, and the make system would just link the updated object again the already existing binary, to keep it fast. Of course this has drawbacks, but I'm looking for something equally fast and I don't think I will achieve it without going to an .so model for the subcomponents. If only there were a function like add_objects() that would provide you with targets to be used further along the line, eh :) But I guess this usage really is a corner case and not used much. 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] scope of set_source_files_properties?
Hi, -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Hendrik Sattler That's a convenience library approach, and it's not really supported (partly because there is no way to implement it on some toolchains such as MSVC). The problem comes up once in a while. And the argument for why this doesn't work is that you cannot link static libraries into another. Well, then don't, I'd say. CMake knows the names of the object files to link into the final library, it just needs a frame to let the CMake user work with it. One could be a VIRTUAL key word for add_library that makes it just a place-holder for a group of object files: no link stage. When such a library is linked to another, well... obvious... Yes please! :) It would make my life much easier. 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] static library from several subdirectories
Hi,
From: Michael Wild [mailto:them...@gmail.com]
You have to call ADD_SOURCES for all your sources BEFORE you do the
ADD_LIBRARY call.
I am already doing this, but since the files I was adding to the
library didn't exist, the call failed. I somehow expected cmake to start
executing the custom command since there was a previously defined
dependency, but apparently cmake wasn't set up for the way I'm
mistreating it :)
What triggers a custom command to be executed? With your help I have
arrived at:
You should add a DEPENDS input_file1 input_file2 ... option to
your ADD_CUSTOM_COMMAND calls, then CMake will know when to invoke it,
otherwise it can't know anything about the dependency.
Alright. I have spent a considerable amount of time experimenting, rewriting
and testing. I have reduced my problem to hello world inside a hello.cr file.
add_sources() has been molested and reduced to a mere shadow of its former
glory. With or without DEPENDS doesn't change matters, although I'm sure
without is bad form. Layout:
CMakeLists.txt (code below)
h -- CMakeLists.txt (it just calls add_sources() -- without any arguments)
| -- hello.cr (your typical hello world)
So, when I call add_sources() directly from the top level CMakeLists.txt file,
I obtain my executable test. If I comment out the add_sources() call, and use
add_subdirectory(h) instead, and call add_sources() from there, it fails. The
complaint is that it cannot find source file hello.c Apparently the problem
is that add_custom_command() calls are local to the directory they are called
in, and since the executable is assembled from a list on a higher level, it
expects to find the source file on disc already :(
PROJECT(Test)
enable_language( C )
cmake_minimum_required(VERSION 2.8)
function (add_sources)
define_property(GLOBAL PROPERTY list BRIEF_DOCS brief FULL_DOCS full)
SET ( out_file /mnt/usr3/people/verweija/cmake2/build/h/hello.c )
SET ( in_file /mnt/usr3/people/verweija/cmake2/h/hello.cr )
ADD_CUSTOM_COMMAND(
OUTPUT ${out_file}
COMMAND ${CMAKE_COMMAND} -E copy ${in_file} ${out_file}
DEPENDS /mnt/usr3/people/verweija/cmake2/h/hello.cr
)
LIST( APPEND mylist ${out_file} )
set_property(GLOBAL APPEND PROPERTY list ${mylist})
endfunction(add_sources)
add_sources()
#add_subdirectory( h )
get_property(list GLOBAL PROPERTY list)
message ( STATUS list=${list} )
ADD_EXECUTABLE( test ${list} )
I have found some threads about this, and I will be reading them shortly :)
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] static library from several subdirectories
Hi, -Original Message- From: Michael Wild [mailto:them...@gmail.com] Problem is the following: Dependencies between stuff in different directories only work for top- level targets (add_library, add_executable and add_custom_target). So, you would need to add a ADD_CUSTOM_TARGET call with a unique target name in your ADD_SOURCES function, add that name to a global list (as you do with the sources) and then after your ADD_EXECUTABLE call you have to do an ADD_DEPENDENCIES. Further, you need to tell CMake at the top-level that the sources are generated by setting the source file property GENERATED to TRUE. OK. Indeed, we found it was possible to create an empty target, adding subdirectories, obtaining the global src list, adding a library based on the src list for which source file properties were set to GENERATED 1 and adding a dependency between the lib and the custom target worked. add_sources() was modified to add local custom targets and add dependencies to the top level target on the fly. This is in the cmake wiki and it seems rather hackish, but against better judgement we moulded it a bit anyway ;) http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_add_a_dependency_to_a_source_file_which_is_generated_in_a_subdirectory.3F All very complicated and error prone. So I suggest, you move the whole logic of your preprocessing to your top-level CMakeLists.txt file. Thanks. I would much prefer something clean like that, although I think that wrapping the entire process in add_Sources() has reduced the chances of errors. I'm looking to make the CMakeLists.txt files as readable as possible, and offloading the functionality to a functions.cmake file, or so. The lib builds now, hopefully I can assemble the binary tomorrow. :) When it gets to the top level target, make chokes somewhat, but I guess that's to be expected, I'll see tomorrow about make -j x. Thanks Michael. 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] static library from several subdirectories
Hi,
-Original Message-
From: Michael Wild [mailto:them...@gmail.com]
I'd recommend to change the add_sources function to do all the
preprocessing and then only add the products (.f, .f90, .c etc.) files
to the list. You can do the preprocessing like this (of course, you'll
have to change things for your setup, perhaps even do different things
depending on filename extension etc.)
find_program(FPP_EXECUTABLE fpp)
if(NOT FPP_EXECUTABLE)
message(SEND_ERROR Failed to find fpp)
endif()
set(SRCS)
foreach(src IN LISTS ARGN)
get_filename_component(abs_src ${src} ABSOLUTE)
file(RELATIVE_PATH rel_src ${CMAKE_CURRENT_SOURCE_DIR} ${abs_src})
set(pre ${CMAKE_CURRENT_BINARY_DIR}/${rel_src})
add_custom_command(OUTPUT ${pre}
COMMAND ${FPP_EXECUTABLE} ${abs_src} -o ${pre}
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
COMMENT Creating ${pre}
VERBATIM
)
list(APPEND SRCS ${pre})
endforeach()
set_property(GLOBAL APPEND PROPERTY ${target}_SRCS ${SRCS})
OK, so I finally found some time to implement AND email the results. I tried it
a little differently, then I tried Michael's approach. Both seem to fail, since
at the moment I call add_library() my source file is unavailable. I hoped it
would resolve the source file to a dependency through the custom command, but
it doesn't and I can't get cmake to execute the conversion inline.
What am I missing? I'm trying again with my simple a/liba.c and b/b/libb.c
setup, but this time I start out with liba.cr and libb.cr that need to be
converted to liba.c and libb.c.
function(add_sources target)
# define the target_SRCS properties if necessary
get_property(prop_defined GLOBAL PROPERTY ${target}_SRCS DEFINED)
if(NOT prop_defined)
define_property(GLOBAL PROPERTY ${target}_SRCS
BRIEF_DOCS Sources for the ${target} target
FULL_DOCS List of source files for the ${target} target)
endif()
# create list of sources (absolute paths)
set(SRCS)
foreach(src IN LISTS ARGN)
string (REGEX REPLACE ^(.+)\\.cr$ \\1 BASECR ${src} )
string (COMPARE EQUAL ${src} ${BASECR}.cr FILE_IS_C)
if(NOT IS_ABSOLUTE ${src})
get_filename_component(path_to_src ${src} ABSOLUTE )
get_filename_component(path_to_src ${path_to_src} PATH )
get_filename_component(src ${src} ABSOLUTE)
endif()
add_custom_command(
OUTPUT ${path_to_src}/${BASECR}.c
COMMAND cat ${path_to_src}/${BASECR}.cr ${path_to_src}/${BASECR}.c
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
COMMENT Creating ${path_to_src}/${BASECR}.c
VERBATIM
)
#add_custom_command (
# OUTPUT ${path_to_src}/${BASECR}.c
# COMMAND cat ${path_to_src}/${BASECR}.cr ${path_to_src}/${BASECR}.c
# DEPENDS ${path_to_src}/${BASECR}.cr
# )
list(APPEND SRCS ${path_to_src}/${BASECR}.c)
endforeach()
# append to global property
set_property(GLOBAL APPEND PROPERTY ${target}_SRCS ${SRCS})
endfunction()
___
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] static library from several subdirectories
Hi,
This is a bit length, sorry.
-Original Message-
From: Michael Wild [mailto:them...@gmail.com]
What am I missing? I'm trying again with my simple a/liba.c and
b/b/libb.c setup, but this time I start out with liba.cr and libb.cr
that need to be converted to liba.c and libb.c.
function(add_sources target)
# define the target_SRCS properties if necessary
get_property(prop_defined GLOBAL PROPERTY ${target}_SRCS DEFINED)
if(NOT prop_defined)
define_property(GLOBAL PROPERTY ${target}_SRCS
BRIEF_DOCS Sources for the ${target} target
FULL_DOCS List of source files for the ${target} target)
endif()
# create list of sources (absolute paths)
set(SRCS)
foreach(src IN LISTS ARGN)
I know I used this syntax, but it is relatively new. Please check that
it is supported by the CMake version you use...
I'm using cmake 2.8.0 on linux. But eventually it should run on a variety of
platforms, including windows, altix, ibm and hpux itanium2.
string (REGEX REPLACE ^(.+)\\.cr$ \\1 BASECR ${src} )
string (COMPARE EQUAL ${src} ${BASECR}.cr FILE_IS_C)
You're removing .cr from the file and then add it back again and compare
it with the original name? that should always be TRUE, right?
Yes. But only if the file in ${src} is of the extension .cr. It is a crude way
of setting up an identifier for a filetype, then matching if that filetype is
set and do a custom command based on that, e.g.:
foreach (FILE ${FILE_LIST})
string (REGEX REPLACE ^(.+)\\.fr$ \\1 BASEFR ${FILE})
string (REGEX REPLACE ^(.+)\\.f90r$ \\1 BASEF90R ${FILE})
string (REGEX REPLACE ^(.+)\\.cr$ \\1 BASECR ${FILE})
string (REGEX REPLACE ^(.+)\\.cppr$ \\1 BASECPPR ${FILE})
string (REGEX REPLACE ^(.+)\\.hr$ \\1 BASEHR ${FILE})
string (COMPARE EQUAL ${FILE} ${BASEFR}.fr FILE_IS_FORTRAN)
string (COMPARE EQUAL ${FILE} ${BASEF90R}.f90r FILE_IS_FORTRAN90)
string (COMPARE EQUAL ${FILE} ${BASECR}.cr FILE_IS_C)
string (COMPARE EQUAL ${FILE} ${BASECPPR}.cppr FILE_IS_CPP)
string (COMPARE EQUAL ${FILE} ${BASEHR}.hr FILE_IS_HEADER)
if ($FILE_IS_...)
add_custom_command( ... )
# append to file list
# some macro
Elseif ( ... )
...
Else ( ... )
#foreach
if(NOT IS_ABSOLUTE ${src})
get_filename_component(path_to_src ${src} ABSOLUTE )
get_filename_component(path_to_src ${path_to_src} PATH )
get_filename_component(src ${src} ABSOLUTE)
endif()
This is dangerous, because if src is originally absolute, path_to_src
will be undefined! Change it to this:
if(NOT IS_ABSOLUTE ${src})
get_filename_component(src ${src} ABSOLUTE)
endif()
get_filename_component(path_to_src ${src} PATH)
OK, that would be bad. Thanks for the pointer. I was trying to obtain a handle
to a file in the same directory as my unprocessed source, so I could add it
there. I will look into it using your next pointer.
You should NEVER write to the source directory. Don't even think about
it. And output-redirection doesn't work. So for your test-purposes, you
could try:
file(RELATIVE_PATH rel_path_to_src ${CMAKE_CURRENT_SOURCE_DIR}
${path_to_src})
set(out_file
${CMAKE_CURRENT_BINARY_DIR}/${rel_path_to_src}/${BASECR}.c)
add_custom_command(
OUTPUT ${out_file}
COMMAND ${CMAKE_COMMAND} -E copy ${src} ${out_file}
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
COMMENT Creating ${out_file}
VERBATIM
)
Understood. I was told this before by someone else. Thanks for reminding me.
#add_custom_command (
# OUTPUT ${path_to_src}/${BASECR}.c
# COMMAND cat ${path_to_src}/${BASECR}.cr
${path_to_src}/${BASECR}.c
# DEPENDS ${path_to_src}/${BASECR}.cr
# )
list(APPEND SRCS ${path_to_src}/${BASECR}.c)
Of course, change this then to
list(APPEND SRCS ${out_file})
endforeach()
# append to global property
set_property(GLOBAL APPEND PROPERTY ${target}_SRCS ${SRCS})
endfunction()
OK.
You have to call ADD_SOURCES for all your sources BEFORE you do the
ADD_LIBRARY call.
I am already doing this, but since the files I was adding to the library didn't
exist, the call failed. I somehow expected cmake to start executing the custom
command since there was a previously defined dependency, but apparently cmake
wasn't set up for the way I'm mistreating it :)
What triggers a custom command to be executed? With your help I have arrived at:
project(superDuper Fortran)
enable_language( C )
cmake_minimum_required(VERSION 2.8)
#- Add sources for a target
#
# ADD_SOURCES(target source1 [source2 ...])
#
function(add_sources target)
# define the target_SRCS properties if necessary
get_property(prop_defined GLOBAL PROPERTY ${target}_SRCS DEFINED)
if(NOT prop_defined)
define_property(GLOBAL PROPERTY ${target}_SRCS
BRIEF_DOCS Sources for the ${target} target
FULL_DOCS List of source files for the ${target} target)
endif()
# create list of sources (absolute paths)
set(SRCS)
foreach(src IN LISTS ARGN)
string (REGEX
Re: [CMake] static library from several subdirectories
Hi,
From: Michael Wild [mailto:them...@gmail.com]
I'd recommend to change the add_sources function to do all the
preprocessing and then only add the products (.f, .f90, .c etc.) files
to the list. You can do the preprocessing like this (of course, you'll
have to change things for your setup, perhaps even do different things
depending on filename extension etc.)
find_program(FPP_EXECUTABLE fpp)
if(NOT FPP_EXECUTABLE)
message(SEND_ERROR Failed to find fpp)
endif()
set(SRCS)
foreach(src IN LISTS ARGN)
get_filename_component(abs_src ${src} ABSOLUTE)
file(RELATIVE_PATH rel_src ${CMAKE_CURRENT_SOURCE_DIR} ${abs_src})
set(pre ${CMAKE_CURRENT_BINARY_DIR}/${rel_src})
add_custom_command(OUTPUT ${pre}
COMMAND ${FPP_EXECUTABLE} ${abs_src} -o ${pre}
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
COMMENT Creating ${pre}
VERBATIM
)
list(APPEND SRCS ${pre})
endforeach()
set_property(GLOBAL APPEND PROPERTY ${target}_SRCS ${SRCS})
The flow currently is:
# build mybiglib.a
- loop over a file list retrieved from a leaf cmake file
- determine the file type (FORTRAN FORTRAN90 C C++ header file etc etc)
- add_custom_command that creates a DEPENDS of the required OUTPUT source file
based on its source*r file based on a COMMAND.
- add the OUTPUT to a filelist_m or filelist_h if is is a header file
- setup a FORTRAN module directory in ${CMAKE_BINARY_DIR}
- add a dependency between the header files and the current dir for
preprocessing
- ADD_SOURCES( ${BIG_LIB} ${filelist_m} ) # Michael's code
- process some out of tree include directories # this requires touching up, but
seems to work in the old setup
- add them as a dependency for biglib
- add a dependency between biglib and the current dir preprocessing target
- call include_directories() for every out of tree include directory
The calls that are failing are:
- add_dependencies (${BIG_LIB} ${P1TARGET}_preprocessing) (2x)
- add_dependencies (${BIG_LIB} ${CUR_DIR}_preprocessing)
The context is:
# use one mod dir per CMAKE_BINARY_DIR instead of a single mod dir per
CMAKE_CURRENT_BINARY_DIR
# FIXME there may be a problem with duplicate names for the modules --
check with development
set (CMAKE_Fortran_MODULE_DIRECTORY ${CMAKE_BINARY_DIR}/mod)
add_custom_target (${CUR_DIR}_preprocessing DEPENDS ${FILE_LIST_H})
ADD_SOURCES( ${BIG_LIB} ${FILE_LIST_M} )
message ( STATUS filelist_m=${FILE_LIST_M} )
# refactor later
foreach (IDIR ${INCLUDE_DIRECTORIES_PREPRO})
include_directories (${CMAKE_BINARY_DIR}/${IDIR})
string (REPLACE / _ PTARGET ${IDIR})
string (REGEX REPLACE ^(.+)_$ \\1 P1TARGET ${PTARGET})
add_dependencies (${BIG_LIB} ${P1TARGET}_preprocessing) #fails now
endforeach (IDIR)
add_dependencies (${BIG_LIB} ${CUR_DIR}_preprocessing) #fails now
foreach (IDIR ${INCLUDE_DIRECTORIES})
include_directories (${IDIR})
endforeach (IDIR)
I'll be looking into this some more at the end of the day.
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] static library from several subdirectories
Hi,
-Original Message-
From: Michael Wild [mailto:them...@gmail.com]
I think the problem is that the ${BIG_LIB} target does not exist when
you call ADD_DEPENDENCIES. Probably you should also collect all the
custom targets into a global property and then after the
ADD_LIBRARY(${BIG_LIB} ...) do the ADD_DEPENDENCIES call.
Woops. Indeed so, before the dependency was added after add_library() was
called to create a target for the ${CMAKE_CURRENT_BINARY_DIR} -- add_library()
has now made way for add_sources(). I think I will assemble these dependencies
globally as well. Thanks again.
PS: Sorry about my last message which was a bit messy (missing
dependency stuff, wrong output name etc). My only apology is that it was
still early in the morning ;-)
Agreed, it was so early, you probably didn't even had coffee yet ;) Still, it's
much appreciated, no need to apologise at all.
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] static library from several subdirectories
Hi,
Hopefully I'm misunderstanding you, since otherwise the list would
contain
close to 4000 files.
Well, I don't see a real problem with this. If this makes your files too
long,
just separate the setting of these source-variables into separate files.
I would prefer to keep the source listing with the source files, so perhaps I
should chain .cmake files from the level where I wish to generate
mystaticlib.a. That would make maintaining the source lists easier for
inadvertent users. To clarify, the average Fortran77 user (mathematician,
physicist, structural engineer etc.) I know usually does not have a computer
science background, so usability is a relative big issue.
But I took a look at Michael Wild's approach (thanks Tyler) which
leads me
to believe there is no clean way to go about it. I suppose in the
spirit of
his solution I could create a global list of the archives I obtain,
and
feed them to target_link_libraries (myexecutable
${my_global_list_of_archives}) in the same scope where I call
add_executable().
If you are creating an executable (I thought you were creating a static
library as end result), you can just link your executable against all
these
static libs.
I am. Well, it's complicated. We provide one big archive to link against, so
the core of the program is inside the binary when they define their own
routines. There is no point in making it a shared object since it is never
shared. Most users will just use the binary we provide.
It just seems that cmake was set up with a different mindset, in which it is
frowned upon to create a single library (static or not) composed of multiple
source directories. I will try to wrap something around add_subdirectory() and
have my_add_subdirectory() take care of propagation of the (127 :) source lists
to the parent scope, so I can get a list for add_library(). If that fails
perhaps just be satisfied with referencing all source lists explicitly from the
top... Any other suggestions very welcome.
Thanks,
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] static library from several subdirectories
Hi Markus, I have tested Michael's suggestion. It works wonders for combining source files into a single lib, regardless of the directory levels. For instance, I tested with: CMakeLists.txt a/CMakeLists.txt a/liba.c b/CMakeLists.txt b/b/CMakeLists.txt b/b/libb.c Just keep add_subdirectory()'ing until you can add_sources( yourlib [sources] ). So if you have FORTRAN source, you should be done. I don't have FORTRAN source, but .fr .f90r .cppr .cr .hr files that need to be preprocessed with fpp to obtain the resulting .f .f90 .cpp .c .h files, which can be used in add_sources(). This seem to cause problems with the setup I had so far, since I get the error: add_dependencies Adding dependency to non-existent target: bar3d You have called ADD_LIBRARY for library madymo3d without any source files. This typically indicates a problem with your CMakeLists.txt file If I manage to solve it I will report back here. Regards, Arjen -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Markus Raab Sent: dinsdag 16 maart 2010 17:43 To: cmake@cmake.org Subject: Re: [CMake] static library from several subdirectories Verweij, Arjen wrote: I'm looking for a cmake-way to create a static library from several subdirectories. I have exactly the same problem, please share if you get a good solution. What about collecting all files in a cache variable? Then you could add files per directory, but with a global scope. Could that work? I would really like to avoid to have them all listed in a file. cmake was the tool of choice, exactly because I want to get rid of a single configure.ac. This is important because folders might be excluded depending on options or available libraries. thank you Markus -- http://www.markus-raab.org | Die Geschichte lehrt dauernd, aber sie -o) | findet keine Schüler. -- Dr. Ingeborg Kernel 2.6.24-1-a /\ | Bachmann on a x86_64 _\_v | ___ 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
[CMake] static library from several subdirectories
Hi, For a legacy FORTRAN project, I'm looking for a cmake-way to create a static library from several subdirectories. The current solution is using a custom POST_BUILD step with ar and ranlib, but the resulting archive is not known to cmake and can't be used to link to the main. As an alternative we've tried to propagate the list of archives using PARENT_SCOPE, but this seems like a hack as well. Is there a clean way to go about it? 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] static library from several subdirectories
Hi,
For a legacy FORTRAN project, I'm looking for a cmake-way to create a
static library from several subdirectories. The current solution is
using a
custom POST_BUILD step with ar and ranlib, but the resulting archive
is not
known to cmake and can't be used to link to the main.
You can just list all source files in the top level CMakeLists.txt, no
matter
whether they are in a subdirectory or in the same directory.
Alex
Hopefully I'm misunderstanding you, since otherwise the list would contain
close to 4000 files.
But I took a look at Michael Wild's approach (thanks Tyler) which leads me to
believe there is no clean way to go about it. I suppose in the spirit of his
solution I could create a global list of the archives I obtain, and feed them
to target_link_libraries (myexecutable ${my_global_list_of_archives}) in the
same scope where I call add_executable().
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] ctest with cmake without compiler
Hi, Yes, it certainly disables some checks. Thanks for the pointer. However, on an NT system without Visual Studio for instance, but with nmake.exe (or make.exe of msys), I still cannot have cmake generate Makefiles: $ cmake . CMake Error: CMake was unable to find a build program corresponding to Visual Studio 6. CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. -- Configuring incomplete, errors occurred! The CMakeFiles directory is mostly empty except for cmake.check_cache which only contains comments. What I want, is to be able to deploy a tarball or an installer, install some test tools, and test the binaries that were provided in a clean environment, like a virtual machine. Testing on build machines is undesirable. Setting CMAKE_MAKE_PROGRAM to (n)make.exe does not help. Regards, Arjen | Verweij, Arjen wrote: | Well, obviously the problem is requiring a compiler when it makes no | sense. Like on test-only systems. | | | Not that obvious | | project(FooBar NONE) | | That will stop CMake from enabling any compilers or languages. ___ 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] ctest with cmake without compiler
Hi, I'm looking for the switch that kills the compiler check in cmake. Is there such a switch? Through Google I found http://www.mail-archive.com/cmake@cmake.org/msg08245.html but the answer is not in there. Regards, Arjen ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ctest with cmake without compiler
Well, obviously the problem is requiring a compiler when it makes no sense. Like on test-only systems. Arjen From: cmake-boun...@cmake.org on behalf of Alexander Neundorf Sent: Wed 2/4/2009 7:49 PM To: cmake@cmake.org Subject: Re: [CMake] ctest with cmake without compiler On Wednesday 04 February 2009, Verweij, Arjen wrote: Hi, I'm looking for the switch that kills the compiler check in cmake. Is there such a switch? Which problem do you have with the check ? It should work. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
