Re: [CMake] Pass variables to sub directory CMakeLists.txt
Hello,
On 2/21/08, Vandenbroucke Sander [EMAIL PROTECTED] wrote:
Hi,
I want to pass a variable to CMakeLists.txt's in sub directories:
Top directory CMakeLists.txt:
set( VAR1 )
add_subdirectory (subdir1)
add_subdirectory (subdir2)
Each subdir CMakeLists.txt:
...
set( VAR1 ${VAR1} extend_var1 )
...
I use VAR1 later on in the linker.
How can I make this work?
See this thread form yesterday for your answer ;)
http://www.cmake.org/pipermail/cmake/2008-February/019986.html
Regards,
Kind regards,
Sander.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
--
Olivier DOLE
Pleyo
Software Engineer
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Proposal for changing the visual studio generator
Hello,
I have a proposal to change the Visual Studio Generator.
The current version 2.4.8 works like this:
1.) CMake generates hardcoded paths for OutputFile, PDB File, Addition
Library Directories etc.
e.g.
OutputDirectory=Debug (or Release, etc. depending on the config)
OutputFile=D:\work\cmake-2.4.8\build\bin\Debug\cmake.exe
2.) OutputDirectory does not contain a directory, it's used like a
ConfigurationName.
Code Snippet (cmLocalVisualStudio7Generator.cxx):
0463 fout \t\tConfiguration\n
0464 \t\t\tName=\ configName | this-PlatformName \\n
0465 \t\t\tOutputDirectory=\ configName \\n;
3.) OutputFile contains a hardcoded path, that always contains the
configurationname (Debug|Release|...).
Code Snippet (cmLocalVisualStudio7Generator.cxx):
0882 temp = this-ExecutableOutputPath;
0883 temp += configName;
0884 temp += /;
0885 temp += targetNameFull;
0886 fout \t\t\t\tOutputFile=\
0887 this-ConvertToXMLOutputPathSingle(temp.c_str()) \\n;
The problem is that this hardcoded paths are very unflexible.
It should better use the macros that are used when you generate a
projects using the wizard.
My Proposal:
1.) Use the normal macros like its done by the wizard.
OutputDirectory=$(SolutionDir)$(ConfigurationName)
OutputFile=$(OutDir)\$(ProjectName).exe
Use this $(OutDir) also for pdb, manifest, etc.
This resolves to the same path as the hardcoded ones.
But you can easily change the output dir in the project by just changing
this single OutputDirectory,
that's what it was intended for.
2.) Using
SET(EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/mypath)
or
SET(LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/mypath)
it should be possible to replace the default value of OutputDirectory.
This way you can easily change the output directory from CMakeLists.txt and
it's not necassary to change it afterwards in the VS Project.
This way you can get rid of the autogenerated Debug/Release folders if
you don't want them,
but also keeps the current behaviour, or better the Visual Studio
default behavior
as long as you don't overwrite the output paths.
--
mit freundlichen Grüßen / best regards
*Gerhard Gappmeier*
ascolab GmbH - automation systems communication laboratory
Tel.: +49 9131 691 123
Fax: +49 9131 691 128
Web: http://www.ascolab.com
GPG-Key: http://www.ascolab.com/gpg/gg.asc
--
*ascolab GmbH*
Geschäftsführer: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrauß
Sitz der Gesellschaft: Am Weichselgarten 7 • 91058 Erlangen • Germany
Registernummer: HRB 9360
Registergericht: Amtsgericht Fürth
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Pass variables to sub directory CMakeLists.txt
On 2008-02-21 08:25+0100 Vandenbroucke Sander wrote:
Hi,
I want to pass a variable to CMakeLists.txt's in sub directories:
Top directory CMakeLists.txt:
set( VAR1 )
add_subdirectory (subdir1)
add_subdirectory (subdir2)
Each subdir CMakeLists.txt:
...
set( VAR1 ${VAR1} extend_var1 )
...
I use VAR1 later on in the linker.
How can I make this work?
The reason why this does not work in the present form is you are attempting
to pass VAR1 up from subdir1 to top-level, before passing it down again to
subdir2 from the top-level. Passing variables down is fine, but passing
variables from subdirectories to their parent normally does not occur with
CMake.
From recent discussion on this list you should use the
GET_DIRECTORY_PROPERTY command to pass variable information to parent
directories. So instead of the above use the following (subject to some
uncertainty since I have no practical experience with this method).
Top directory CMakeLists.txt:
set( VAR1 )
add_subdirectory (subdir1)
get_directory_property(VAR1 DIRECTORY subdir1 VARIABLES VAR1)
add_subdirectory (subdir2)
get_directory_property(VAR1 DIRECTORY subdir2 VARIABLES VAR1)
...
Anyhow, you get the general idea subject to some uncertainty on my part of
what the exact syntax for GET_DIRECTORY_PROPERTY should be. Perhaps I am
just too sleepy at this time in the morning, but that particular
documentation seems to be a bit unclear to me. So if the above syntax
doesn't work (which you can confirm by using the MESSAGE command), then you
may have to adjust it a bit.
Good luck.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Borland support
Hi,
I'm charged with creating a sane build system for a large Borland 2006
codebase, and having learned to love cmake in the KDE project, I wanted
to try to use cmake for this. Documentation on using cmake and borland
seems a bit scarce though.
Right now I'm having a problem getting the linker phase to work:
Linking CXX shared library GcStd100.dll
Borland C++ 5.82 for Win32 Copyright (c) 1993, 2005 Borland
Turbo Incremental Link 5.70 Copyright (c) 1997-2006 Borland
Error: Unable to open file 'GCLIB.RES'
** error 1 ** deleting libs\gcstd\GcStd100.dll
** error 1 ** deleting libs\gcstd\CMakeFiles\GcStd100.dir\all
** error 1 ** deleting all
This is the cmake file for this library:
-
include_directories( ${CMAKE_CURRENT_SOURCE_DIR}
${CMAKE_SOURCE_DIR}/dependencies/oniguruma )
FILE (GLOB GcStd100_LIB_SRCS *.cpp)
ADD_LIBRARY(GcStd100 SHARED ${GcStd100_LIB_SRCS} )
INSTALL(TARGETS GcStd100 DESTINATION ${LIB_INSTALL_DIR})
Oh -- and how can I make a bpl instead of a dll?
Yours,
Boudewijn
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Proposal for changing the visual studio generator
Hello,
I am also very intersted in this change. I usually put all my *.exe in
one folder, say bin. For release version, with the name
$(ProjectName).exe, and Debug version $(ProjectName)-D.exe.
As far as I understand, this is not possible with the current version of
CMake.
Regards,
Olivier
Gerhard Gappmeier a écrit :
Hello,
I have a proposal to change the Visual Studio Generator.
The current version 2.4.8 works like this:
1.) CMake generates hardcoded paths for OutputFile, PDB File, Addition
Library Directories etc.
e.g.
OutputDirectory=Debug (or Release, etc. depending on the config)
OutputFile=D:\work\cmake-2.4.8\build\bin\Debug\cmake.exe
2.) OutputDirectory does not contain a directory, it's used like a
ConfigurationName.
Code Snippet (cmLocalVisualStudio7Generator.cxx):
0463 fout \t\tConfiguration\n
0464 \t\t\tName=\ configName | this-PlatformName
\\n
0465 \t\t\tOutputDirectory=\ configName \\n;
3.) OutputFile contains a hardcoded path, that always contains the
configurationname (Debug|Release|...).
Code Snippet (cmLocalVisualStudio7Generator.cxx):
0882 temp = this-ExecutableOutputPath;
0883 temp += configName;
0884 temp += /;
0885 temp += targetNameFull;
0886 fout \t\t\t\tOutputFile=\
0887 this-ConvertToXMLOutputPathSingle(temp.c_str()) \\n;
The problem is that this hardcoded paths are very unflexible.
It should better use the macros that are used when you generate a
projects using the wizard.
My Proposal:
1.) Use the normal macros like its done by the wizard.
OutputDirectory=$(SolutionDir)$(ConfigurationName)
OutputFile=$(OutDir)\$(ProjectName).exe
Use this $(OutDir) also for pdb, manifest, etc.
This resolves to the same path as the hardcoded ones.
But you can easily change the output dir in the project by just
changing this single OutputDirectory,
that's what it was intended for.
2.) Using
SET(EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/mypath)
or
SET(LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/mypath)
it should be possible to replace the default value of OutputDirectory.
This way you can easily change the output directory from
CMakeLists.txt and
it's not necassary to change it afterwards in the VS Project.
This way you can get rid of the autogenerated Debug/Release folders if
you don't want them,
but also keeps the current behaviour, or better the Visual Studio
default behavior
as long as you don't overwrite the output paths.
--
Le temps des cerises reviendra. Dans l'immédiat, c'est le temps des noyaux.
Courage.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] absolute rpath
On Wednesday, 20. February 2008 19:08:27 Hendrik Sattler wrote: Windows searches in '.' for DLLs by default. You don't have to do anything to achieve that. Yes and windows has no rpath. Perhaps I wasn't clear enough. I want (more exactly: have) to have the windows behavior on linux. Which means I want to set the rpath to '.' in my linux executables and shared objects to enable them to find the shared objects they depend on automatically (in case they are installed in the same directory), without relinking them, changing PATH or LD_LIBRARY_PATH. Jörg ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Proposal for changing the visual studio generator
Thank you Joshua, nice tip.
Regards,
Olivier
Joshua Jensen a écrit :
- Original Message -
From: Olivier Tournaire
Date: 2/21/2008 3:54 AM
I am also very intersted in this change. I usually put all my *.exe
in one folder, say bin. For release version, with the name
$(ProjectName).exe, and Debug version $(ProjectName)-D.exe.
As far as I understand, this is not possible with the current version
of CMake.
This has worked for me.
IF (CMAKE_GENERATOR MATCHES Visual Studio)
SET_TARGET_PROPERTIES(${TargetName} PROPERTIES PREFIX ../)
SET_TARGET_PROPERTIES(${TargetName} PROPERTIES DEBUG_POSTFIX -D)
ENDIF(CMAKE_GENERATOR MATCHES Visual Studio)
Josh
--
Le temps des cerises reviendra. Dans l'immédiat, c'est le temps des noyaux.
Courage.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Proposal for changing the visual studio generator
- Original Message -
From: Olivier Tournaire
Date: 2/21/2008 3:54 AM
I am also very intersted in this change. I usually put all my *.exe in
one folder, say bin. For release version, with the name
$(ProjectName).exe, and Debug version $(ProjectName)-D.exe.
As far as I understand, this is not possible with the current version
of CMake.
This has worked for me.
IF (CMAKE_GENERATOR MATCHES Visual Studio)
SET_TARGET_PROPERTIES(${TargetName} PROPERTIES PREFIX ../)
SET_TARGET_PROPERTIES(${TargetName} PROPERTIES DEBUG_POSTFIX -D)
ENDIF(CMAKE_GENERATOR MATCHES Visual Studio)
Josh
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Proposal for changing the visual studio generator
Hi Joshua,
your solution is a good workaround. Thanks.
This workd for me too:
IF (CMAKE_GENERATOR MATCHES Visual Studio)
SET_TARGET_PROPERTIES(${TargetName} PROPERTIES PREFIX ../bin)
ENDIF(CMAKE_GENERATOR MATCHES Visual Studio)
Nevertheless I think my proposal makes sense anyway,
because it would work more like Visual Studio was intended for
and more like a CMake user would expect.
setting EXECUTABLE_OUTPUT_PATH should work without using
such workarounds.
Beside this I personly would prefer a path like
yourpath/bin/yourapp.exe
and not
yourpath/Debug/../bin/yourapp.exe ;-)
r as I understand, this is not possible with the current version of
CMake.
This has worked for me.
IF (CMAKE_GENERATOR MATCHES Visual Studio)
SET_TARGET_PROPERTIES(${TargetName} PROPERTIES PREFIX ../)
SET_TARGET_PROPERTIES(${TargetName} PROPERTIES DEBUG_POSTFIX -D)
ENDIF(CMAKE_GENERATOR MATCHES Visual Studio)
Josh
--
mit freundlichen Grüßen / best regards
*Gerhard Gappmeier*
ascolab GmbH - automation systems communication laboratory
Tel.: +49 9131 691 123
Fax: +49 9131 691 128
Web: http://www.ascolab.com
GPG-Key: http://www.ascolab.com/gpg/gg.asc
--
*ascolab GmbH*
Geschäftsführer: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrauß
Sitz der Gesellschaft: Am Weichselgarten 7 • 91058 Erlangen • Germany
Registernummer: HRB 9360
Registergericht: Amtsgericht Fürth
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] absolute rpath
On Thursday 21 February 2008, Jörg Becker wrote: On Wednesday, 20. February 2008 19:08:27 Hendrik Sattler wrote: Windows searches in '.' for DLLs by default. You don't have to do anything to achieve that. Yes and windows has no rpath. Perhaps I wasn't clear enough. I want (more exactly: have) to have the windows behavior on linux. Which means I want to set the rpath to '.' in my linux executables and shared objects to enable them to find the shared objects they depend on automatically (in case they are installed in the same directory), without relinking them, changing PATH or LD_LIBRARY_PATH. See my previous mail. If you want to have this rpath already in the build tree, additionally set the BUILD_WITH_INSTALL_RPATH target property to TRUE. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ctest - how to set environment
On 2/21/08, Jörg Becker [EMAIL PROTECTED] wrote: Until this will be implemented, I think about David's and Bill's suggestions for a workaround. I would go with Bill's suggestion actually. That will make it automatic for your developers and they will not have to set the environment manually... :-) David ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to prevent relinking targets with shared libraries
Hi guys I'm getting along very well (and quickly!) with porting two large projects from Makefiles to CMake. Actually, 3 projects will follow later on (and possibly more). Yeah, CMake is actually THAT great. I just wanted to share my delight and acknowledgement of this tool, it makes developing C/C++ code just more fun. Back to the topic: I wonder if it isn't possible to prevent relinking targets with a shared library if you didn't change any interface? Isn't this one of the reason for using shared libraries? I implemented a switch for either creating static libraries (like it used to be with the old Makefiles) or shared libraries. At the moment I'm just creating plain .so libs, without any version number (so far I didn't happen to come across a shared library tutorial with cmake), maybe this is the problem? Does cmake support such a versioning and would that resolve the relinking? Regards ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to prevent relinking targets with shared libraries
On 2008-02-21 21:57+0100 blinkeye wrote: [...]At the moment I'm just creating plain .so libs, without any version number (so far I didn't happen to come across a shared library tutorial with cmake), maybe this is the problem? Does cmake support such a versioning and would that resolve the relinking? There is full support for shared libraries (at least on my Linux platform). Look at the documentation of SET_TARGET_PROPERTIES (especially where it mentions VERSION, SOVERSION, and RPATH.) HTH. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Get the drive from a path
On windows I need a way to get a drive letter from a path. Does anybody have any tricks for doing this? -Neal ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Get the drive from a path
On Thu, Feb 21, 2008 at 6:51 PM, Neal Meyer [EMAIL PROTECTED] wrote: On windows I need a way to get a drive letter from a path. Does anybody have any tricks for doing this? Not a trick: string(REGEX MATCH ...) Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to prevent relinking targets with shared libraries
On Thu, February 21, 2008 22:23, Alan W. Irwin wrote:
On 2008-02-21 21:57+0100 blinkeye wrote:
[...]At the moment I'm just creating plain .so libs, without any
version number (so far I didn't happen to come across a shared library
tutorial with cmake), maybe this is the problem? Does cmake support such a
versioning and would that resolve the relinking?
There is full support for shared libraries (at least on my Linux platform).
Look at the documentation of SET_TARGET_PROPERTIES (especially where
it mentions VERSION, SOVERSION, and RPATH.)
Great, thanks for the hint. So, I set a VERSION and SOVERSION on my library:
add_library( mylib SHARED ${SRCS} )
set_target_properties( mylib PROPERTIES VERSION 1 SOVERSION 1 )
But still, any change to 'mylib' requires all targets linked against 'mylib' to
be
relinked again ...
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
