[CMake] RE: CMake Digest, Vol 44, Issue 9
Alin M Elena
alin.elena at qub.ac.uk
Tue Dec 4 07:27:34 EST 2007
Hi,
I try to compile a simple fortran project with cmake, intel fortran compiler
and nmake.
However I get the following error
nmake
Scanning dependencies of target print
[ 25%] Building Fortran object CMakeFiles/print.dir/source/constants.obj
'touch' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'touch' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
8\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
8\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
8\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
Here is the CMakeLists.txt
PROJECT(Hello Fortran)
##########################
###source files
set(target_name hell)
set(src_dir source)
##########################
set(LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/lib)
set(EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/bin)
add_library(print
${src_dir}/constants.f90
${src_dir}/print.f90
)
add_executable(${target_name}
${src_dir}/constants.f90
${src_dir}/test.f90
)
## sets the linking
link_directories (${LIBRARY_OUTPUT_PATH})
target_link_libraries(${target_name} print)
you can get all files for the project from here.
http://titus.phy.qub.ac.uk/group/Alin/hello.rar
Any thoughts?
Alin
____________________________________________________________________
"...if the universities will not study useless subjects, who will?"
G. F. Fitzgerald, Nature, 45/46, 392 (1892)
______________________________________________________________________
Mr. Alin M. ELENA
Atomistic Simulation Centre
School of Mathematics and Physics
Queen's University Belfast
Office: +44 (0)28 9097 1428
Fax: +44 (0)28 9097 5359
http://titus.phy.qub.ac.uk/group/Alin/
alin.elena at yahoo.co.uk
alin.elena at qub.ac.uk
______________________________________________________________________
-----Original Message-----
From: cmake-bounces+alin.elena=qub.ac.uk at cmake.org
[mailto:cmake-bounces+alin.elena=qub.ac.uk at cmake.org] On Behalf Of
cmake-request at cmake.org
Sent: 04 December 2007 10:58
To: cmake at cmake.org
Subject: CMake Digest, Vol 44, Issue 9
Send CMake mailing list submissions to
cmake at cmake.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.cmake.org/mailman/listinfo/cmake
or, via email, send a message with subject or body 'help' to
cmake-request at cmake.org
You can reach the person managing the list at
cmake-owner at cmake.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of CMake digest..."
Today's Topics:
1. Writing out dependencies (Joseph Winston)
2. Generating makefile from Visual Studio Project (Migrating to
Eclipse) (Olumide)
3. Re: Generating makefile from Visual Studio Project (Migrating
to Eclipse) (Jesper Eskilson)
4. FW: [CMake] Rediscovering the compiler. (Josef Karthauser)
5. nmake file create error (Ramazan Girgin)
----------------------------------------------------------------------
Message: 1
Date: Mon, 3 Dec 2007 16:56:15 -0600
From: Joseph Winston <josephwinston at mac.com>
Subject: [CMake] Writing out dependencies
To: cmake at cmake.org
Message-ID: <5D028E16-00FB-4390-898B-9B9973899F89 at mac.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
I'm a cmake novice, so please forgive any misconceptions that I have.
I'm attempting to use cmake for a project that contains multiple
libraries, which in turn have dependencies on libraries both inside
the project and outside. For example, let's call the project "a" and
it has two libraries named "one" and "two". "two" depends on "one"
and one then needs Motif, Xt, X11, etc to link. What is the best way
to export the information needed to compile and link these different
libraries so that another version of cmake can use "two" and
"everything just works"?
I tried EXPORT_LIBRARY_DEPENDENCIES and while this writes out "one"
and "two"'s libraries it does not give me any information on how the
code was compiled. I have also attempted to use:
CONFIGURE_FILE("one.pc.cmake" "${CMAKE_BINARY_DIR}/one.pc" @ONLY)
INSTALL(FILES "${CMAKE_BINARY_DIR}/one.pc" DESTINATION $
{PKGCONFIG_INSTALL_PREFIX})
Where one.pc.cmake contains:
prefix=@CMAKE_INSTALL_PREFIX@
exec_prefix=@CMAKE_INSTALL_PREFIX@
libdir=@LIB_INSTALL_DIR@
includedir=@MOTIF_INCLUDE_DIR@
Name: one
Description: one library
Version:
Requires:
Libs: -L at X11_LIBRARY_DIR@ @MOTIF_LIBRARIES@ @X11_Xt_LIB@ @X11_LIBRARIES@
Cflags: @CMAKE_C_FLAGS@ -I${includedir}
This is a bit better since Cflags now contains the -D commands but it
still is missing the compiler options.
The show stopping problem with this idea is that Libs: is not in a
form that pkg-config can use since it contains:
Libs: -L/usr/lib64 /usr/lib64/libXm.so /usr/lib64/libXt.so -lSM;/usr/
lib64/libICE.so;/usr/lib64/libX11.so;/usr/lib64/lib/Xext.so
What should I be doing?
------------------------------
Message: 2
Date: Tue, 04 Dec 2007 03:31:46 +0000
From: Olumide <50295 at web.de>
Subject: [CMake] Generating makefile from Visual Studio Project
(Migrating to Eclipse)
To: cmake at cmake.org
Message-ID: <4754CA22.2010703 at web.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello -
I'm a CMake newbie and I'd appreciate help creating a makefile *from* a
Visual Studio .NET 2003 project/solution. I'm trying like to migrate my
projects to eclipse and I hope CMake will help make that transition.
Many thanks,
- Olumide
PS: I've already tried creating the config file CMakeLists.txt using
vcproj2cmake.rb ( http://www.eskilson.se/vcproj2cmake.rb ). Below is the
config file generated from a small project -- commenting out the
offending add_locate directives(?). I'm not sure how of what I ought to
do next in order to generate a standard (UNIX) makefile.
#################################################################
project( TestTexturePlugin )
set(SOURCES
pluginMain.cpp
)
include_directories(
C:/Program Files/Alias/Maya6.5/include
)
add_definitions(
-DWIN32,_DEBUG,_WINDOWS,_AFXDLL,_MBCS,NT_PLUGIN,REQUIRE_IOSTREAM
)
add_library( TestTexturePlugin SHARED ${SOURCES} )
#add_locale( TestTexturePlugin ENU <RESFILE> )
#add_locale( TestTexturePlugin JPN <RESFILE> )
target_link_libraries( TestTexturePlugin Foundation OpenMaya )
#################################################################
------------------------------
Message: 3
Date: Tue, 04 Dec 2007 10:05:23 +0100
From: Jesper Eskilson <jesper at eskilson.se>
Subject: Re: [CMake] Generating makefile from Visual Studio Project
(Migrating to Eclipse)
To: Olumide <50295 at web.de>
Cc: cmake at cmake.org
Message-ID: <47551853.7050901 at eskilson.se>
Content-Type: text/plain; charset=ISO-8859-1
Olumide wrote:
> Hello -
>
> I'm a CMake newbie and I'd appreciate help creating a makefile *from* a
> Visual Studio .NET 2003 project/solution. I'm trying like to migrate my
> projects to eclipse and I hope CMake will help make that transition.
>
> Many thanks,
>
> - Olumide
>
>
> PS: I've already tried creating the config file CMakeLists.txt using
> vcproj2cmake.rb ( http://www.eskilson.se/vcproj2cmake.rb ). Below is the
> config file generated from a small project -- commenting out the
> offending add_locate directives(?). I'm not sure how of what I ought to
> do next in order to generate a standard (UNIX) makefile.
I've uploaded a new version of the vcproj2cmake.rb script which does not
emit any add_locale() macros.
> #################################################################
>
> project( TestTexturePlugin )
>
> set(SOURCES
> pluginMain.cpp
> )
>
> include_directories(
> C:/Program Files/Alias/Maya6.5/include
> )
You need double quotes around the path, since it contains spaces.
> add_definitions(
> -DWIN32,_DEBUG,_WINDOWS,_AFXDLL,_MBCS,NT_PLUGIN,REQUIRE_IOSTREAM
> )
No commas between the symbols.
> add_library( TestTexturePlugin SHARED ${SOURCES} )
>
> #add_locale( TestTexturePlugin ENU <RESFILE> )
> #add_locale( TestTexturePlugin JPN <RESFILE> )
>
> target_link_libraries( TestTexturePlugin Foundation OpenMaya )
>
> #################################################################
You should be able to run CMake directly on this file. If you're on
Unix, try
$ cd [your project dir]
$ cmake .
--
/Jesper
------------------------------
Message: 4
Date: Tue, 4 Dec 2007 09:24:46 -0000
From: "Josef Karthauser" <joe.karthauser at geomerics.com>
Subject: FW: [CMake] Rediscovering the compiler.
To: <cmake at cmake.org>
Message-ID:
<F5114451B5F49649A9337243D4F8E469088D8FC6 at THHS2EXBE1X.hostedservice2.net>
Content-Type: text/plain; charset="us-ascii"
> From: cmake-bounces+joe.karthauser=geomerics.com at cmake.org
> [mailto:cmake-bounces+joe.karthauser=geomerics.com at cmake.org] On
Behalf
> Of Brandon Van Every
> Sent: 03 December 2007 20:06
> To: cmake at cmake.org
> Subject: Re: [CMake] Rediscovering the compiler.
>
> On Dec 3, 2007 7:35 AM, Bill Hoffman <bill.hoffman at kitware.com> wrote:
> >
> > No, there is no way currently in cmake to switch compilers once
> picked...
>
> Which I think is a good thing. It would drive me nuts if I couldn't
> count on the compiler choice as an invariant.
Maybe, but there's something to be said for "Tools not Policy".
The good reasons I have for wanting to change the compiler without
rebuilding the build tree from scratch of course should not break the
default policy, which quite clearly should be what you say.
I'm sure thinks will get much better for me once the next version of
cmake is released with native cross compiler support. Alas it wasn't
there when I started using 2.4.7, and so I've had to glue this together
myself.
For interest this is what we're doing. We have a number of
configurations and platforms, each platform with its own compiler tool
chain. All of the configurations are described in the top level
CMakeLists.txt file like so:
#=======================================
# Win32 : RELEASE_WIN32 and DEBUG_WIN32
#=======================================
COMPILER_FLAG(WIN32_FLAGS "/D WIN32") # Compilation on
a win32 box
COMPILER_FLAG(WIN32_FLAGS "/EHsc") # C++ exception
handling
COMPILER_FLAG(WIN32_FLAGS "/arch:SSE2") # Create SSE2
code (x64 only)
COMPILER_FLAG(WIN32_FLAGS "/fp:fast") # Floating point
handling
COMPILER_FLAG(WIN32_FLAGS "/W3") # Warning level
COMPILER_FLAG(WIN32_FLAGS "/Wp64") # Detect 64 bit
portability issues
COMPILER_FLAG(WIN32_FLAGS "/Zi") # Debug format
is 'Program Database'
LINKER_FLAG(WIN32_LINK_FLAGS "") # Put linker
flags here.
COMPILER_FLAG(RELEASE_WIN32_FLAGS "/O2") # Creates fast
code
COMPILER_FLAG(RELEASE_WIN32_FLAGS "/D NDEBUG") # Not DEBUG code
COMPILER_FLAG(RELEASE_WIN32_FLAGS "/MT") # Multithreaded
code
ADD_CONFIGURATION(RELEASE WIN32 "${WIN32_FLAGS}
${RELEASE_WIN32_FLAGS}" "${WIN32_LINK_FLAGS}")
COMPILER_FLAG(DEBUG_WIN32_FLAGS "/Od") # Disable
optimisation
COMPILER_FLAG(DEBUG_WIN32_FLAGS "/D _DEBUG") # DEBUG Code
COMPILER_FLAG(DEBUG_WIN32_FLAGS "/D GEO_DEBUG") # Geomerics
Debug code
COMPILER_FLAG(DEBUG_WIN32_FLAGS "/MTd") # Multithreaded
debug code
COMPILER_FLAG(DEBUG_WIN32_FLAGS "/RTC1") # Enable
run-time error checking
ADD_CONFIGURATION(DEBUG WIN32 "${WIN32_FLAGS}
${DEBUG_WIN32_FLAGS}" "${WIN32_LINK_FLAGS}")
#=============================================
# XBOX360 : RELEASE_XBOX360 and DEBUG_XBOX360
#=============================================
COMPILER_FLAG(XBOX360_FLAGS "/D _XBOX") # Compilation on
an XBOX360
COMPILER_FLAG(XBOX360_FLAGS "/D XBOX") # Compilation on
an XBOX360
COMPILER_FLAG(XBOX360_FLAGS "/EHsc") # C++ exception
handling
COMPILER_FLAG(XBOX360_FLAGS "/W3") # Warning level
COMPILER_FLAG(RELEASE_XBOX360_FLAGS "/O2") # Creates fast
code
COMPILER_FLAG(RELEASE_XBOX360_FLAGS "/D NDEBUG")# Not DEBUG code
COMPILER_FLAG(RELEASE_XBOX360_FLAGS "/MT") # Multithreaded
code
ADD_CONFIGURATION(RELEASE XBOX360 "${XBOX360_FLAGS}
${RELEASE_XBOX360_FLAGS}" "")
COMPILER_FLAG(DEBUG_XBOX360_FLAGS "/Od") # Disable
optimisation
COMPILER_FLAG(DEBUG_XBOX360_FLAGS "/D _DEBUG") # DEBUG Code
COMPILER_FLAG(DEBUG_XBOX360_FLAGS "/D GEO_DEBUG")# Geomerics
Debug code
COMPILER_FLAG(DEBUG_XBOX360_FLAGS "/MTd") # Multithreaded
debug code
COMPILER_FLAG(DEBUG_XBOX360_FLAGS "/RTC1") # Enable
run-time error checking
COMPILER_FLAG(DEBUG_XBOX360_FLAGS "/Zi") # Generates
complete debug information
ADD_CONFIGURATION(DEBUG XBOX360 "${XBOX360_FLAGS}
${DEBUG_XBOX360_FLAGS}" "")
#=================================
# PS3 : RELEASE_PS3 and DEBUG_PS3
#=================================
COMPILER_FLAG(PS3_FLAGS "-D__GCC__") # It's a GNU
compiler
COMPILER_FLAG(PS3_FLAGS "-DPLATFORM_PS3") # NB: only
required for LuaPlus
COMPILER_FLAG(PS3_FLAGS "-DSN_TARGET_PS3") # PS3 build
COMPILER_FLAG(PS3_FLAGS "-Wall") # All warnings
COMPILER_FLAG(PS3_FLAGS "-fno-exceptions") # No exception
handlers
COMPILER_FLAG(PS3_FLAGS "-fno-strict-aliasing") # No strict
aliasing
COMPILER_FLAG(RELEASE_PS3_FLAGS "-O2") # Optimisation
ADD_CONFIGURATION(RELEASE PS3 "${PS3_FLAGS}
${RELEASE_PS3_FLAGS}" "")
COMPILER_FLAG(RELEASE_PS3_FLAGS "-O") # Disable
optimisation
COMPILER_FLAG(DEBUG_PS3_FLAGS "-g") # Include symbol
tables
COMPILER_FLAG(DEBUG_PS3_FLAGS "-DGEO_DEBUG") # Debug build
ADD_CONFIGURATION(DEBUG PS3 "${PS3_FLAGS} ${DEBUG_PS3_FLAGS}"
"")
When cmake is run the top level cmake spawns a cmake for each of the
configurations and makes several 'make' build trees which self manage.
It also makes a visual studio build tree, which generates (via a few
patches to cmake) external Make vcproj files (using VCNMakeTools) which
execute make commands in the right place. This allows us to use visual
studio as the development platform, but still have full control over the
build configurations. The ZERO_CHECK rules rebuild the project and
solution files only, and the per-configuration sub-build trees manage
themselves (with copious additionally 'make depend's run when
necessary).
There were a couple of reasons why we adopted this approach. We wanted
a single CMakeList infrastructure to deal with our entire source base
and all platforms. Both XBox and PS3 were integrated in non-orthogonal
ways into Visual Studio and in ways that CMake didn't support, and CMake
2.4.7 didn't allow us to make multiple platform visual studio files.
Maybe 2.5 or 2.6 will give us more flexibility, however what we have
right now works pretty well.
Joe
p.s. none of this explains why the compilers needed to be changed
without rebuilding! :) That's an entirely separate issue to do with the
fact that we made a transition of put putting the compilers and SDK
headers and libraries into our source repository (SVN) and I wanted to
get the developers build trees to transparently reconfigure without
unnecessarily blowing away their pre-built trees and forcing them to
individually recompile everything - a sizable amount of unnecessary
waiting time for a large team of developers approaching a deadline!
------------------------------
Message: 5
Date: Tue, 4 Dec 2007 12:57:36 +0200
From: "Ramazan Girgin" <ramazangirgin at gmail.com>
Subject: [CMake] nmake file create error
To: cmake at cmake.org
Message-ID:
<4f2df0310712040257h61319d67r193bf814c224b5ce at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Skipped content of type multipart/alternative-------------- next part
--------------
A non-text attachment was scrubbed...
Name: cmake_nmake_error.GIF
Type: image/gif
Size: 26125 bytes
Desc: not available
Url :
http://public.kitware.com/pipermail/cmake/attachments/20071204/14f31971/cmak
e_nmake_error.gif
------------------------------
_______________________________________________
CMake mailing list
CMake at cmake.org
http://www.cmake.org/mailman/listinfo/cmake
End of CMake Digest, Vol 44, Issue 9
************************************
More information about the CMake
mailing list