Re: [CMake] VC8 projects generated multiple times
Hi all,
I changed the GenerateProject macro to cache my file lists. In this way
I'm only globbing once. I included the changed macro below, maybe
someone will find it useful.
We gained about 20% using the caches, which makes it worthwile. I
somehow expected more. CMake takes some time to analyze dependencies, I
guess, and there's a lot of them: peak memory usage for generating all
our projects was around 150MB.
Cheers,
Laurentiu
/CMakeMacros.txt
# gather source files in ProjectSources
MACRO ( GenerateProject ProjectSources Source)
SET ( FoundSourcesFile FoundSourcesFile-NOTFOUND )
FIND_FILE ( FoundSourcesFile ${Source}Sources.cmake PATHS
${CMAKE_CURRENT_BINARY_DIR} NO_DEFAULT_PATH )
IF ( FoundSourcesFile )
# read cached file list
MESSAGE ( STATUS Found extra sources file ${FoundSourcesFile}
)
INCLUDE ( ${CMAKE_CURRENT_BINARY_DIR}/${Source}Sources.cmake )
ELSE ( FoundSourcesFile )
# get the file lists
FILE ( GLOB_RECURSE AllSources *.c *.cpp *.h *.inl *.rc
*.ico )
# write cached file list
MESSAGE ( STATUS Generating ${Source}Sources.cmake )
CONFIGURE_FILE ( ${CMAKE_HOME_DIR}/CMake/QSourceFiles.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/${Source}Sources.cmake @ONLY )
ENDIF ( FoundSourcesFile )
SET ( ${ProjectSources} ${AllSources} )
FOREACH ( Source ${AllSources} )
STRING ( REGEX REPLACE ${CMAKE_CURRENT_SOURCE_DIR} RelativePath
${Source} )
STRING ( REGEX REPLACE [/][^/]*$ RelativePath
${RelativePath} )
STRING ( REGEX REPLACE ^[/] RelativePath
${RelativePath}
)
STRING ( REGEX REPLACE / RelativePath
${RelativePath} )
SOURCE_GROUP ( ${RelativePath} FILES ${Source} )
ENDFOREACH ( Source )
ENDMACRO ( GenerateProject )
###
--
Laurentiu Nicolae
Senior Software Engineer
Quintiq
Tel: +31 (0)73 691 07 39
Fax: +31 (0)73 691 07 54
[EMAIL PROTECTED]
www.quintiq.com
--
This message contains information that may be privileged or
confidential and is the property of Quintiq. It is only intended for the
person to whom it is addressed. If you are not the intended recipient,
you are not authorized to read, print, retain, copy disseminate,
distribute or use this message or any part thereof. If you receive this
message in error, please notify the sender immediately and delete all
copies of this message. Please note that e-mails are susceptible to
change.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] WIN32 definition gone in cmake 2.4.2
Jan Woetzel wrote: Mike Talbot wrote: 2.4.2 ... doesn't define the preprocessor symbol WIN32 ... for the VS 7.1 generator. I cannot confirm this. It works here as expected - with cmake 2.4.2 on Windows - using Visual studio .net 2003 generator. Have a look at a hello world example, buildlog etc. Jan. Found the problem - the WIN32 definition has moved into CMAKE_CXX_FLAGS, where previously it was just generated automatically in the project. Unfortunately my project sets CMAKE_CXX_FLAGS (and didn't include /DWIN32 as it wasn't necessary before) - easy to add though. Thanks, Mike ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] framework, plugin and umbrella frameworks with cmake ?
Hi, AFAIK cmake doesn't support building these types of frameworks out-of-the-box. Is it possible to do this using cmake macros ? Or is it even planned to implement it directly in cmake ? Bye Alex -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! Feel free mit GMX DSL! http://www.gmx.net/de/go/dsl ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] g++ -frepo and cmake
Manuel Klimek wrote:
Hi,
i'm trying to use cmake with g++ to build template using code
with -frepo for shared libraries.
With -frepo g++ automatically includes the object code only for
template instantiations that are needed at link time. If
you link an executable with g++, say
g++ -frepo -o hello hello.o main.o
and hello.cc uses templates, g++ will insert missing template
instantiations into hello.o until the executable links.
Now this doesn't work for shared libraries:
g++ -frepo -shared -o libhello.so hello.o
will simply compile without adding the extra template instantions
into hello.o.
The gcc mailing list suggests the following solution:
First compile a dummy 'closure' executable, which fails:
g++ -frepo -o libhello_closure hello.cc
(fails complaining about missing symbols)
Afterwards, hello.o contains all the required symbols.
Then
g++ -frepo -shared -o libhello.so hello.o
will yield a library with all symbols as expected.
At the moment I implement this solution using a wrapper
script around g++, which simply looks for -shared, and in
case of -shared first performs the closure step and than
compiles the whole executable.
Because an additional shell indirection slows down my
build process, I wondered if I can integrate the -frepo
concept into my cmake process.
I tried:
- using ADD_EXECUTABLE (with a simple closure.cpp containing a main(...)):
fails, because in linux symbols are only required at executable
link time, not at library link time
- using ADD_CUSTOM_COMMAND:
I don't know how to get the command line cmake would use to create
a library, so I can't write a custom command - and because g++ would
return an error code, the build wouldn't work anyways, would it?
So the question is: do you think using a wrapper script is the
only way, or did I miss something and I can do it with cmake?
Look at the current setting of CMAKE_CXX_CREATE_SHARED_LIBRARY:
MESSAGE(CMAKE_CXX_CREATE_SHARED_LIBRARY =
[${CMAKE_CXX_CREATE_SHARED_LIBRARY}])
This is the variable CMake uses to construct the link rule for the
shared library. You could try adding your wrapper shell script to it:
SET(CMAKE_CXX_CREATE_SHARED_LIBRARY
/path/to/wrapper/script ${CMAKE_CXX_CREATE_SHARED_LIBRARY})
Then your script would be called only for linking instead of for every
object file built.
Otherwise you could get some improvement by replacing your wrapper
script with a small C program that would load faster than a shell script
and then exec g++.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] target_link_libraries doubt
Von: Vikas Kumar [EMAIL PROTECTED] Hi I have a library that links to other shared libraries. For example I am trying to build libFoo.so , which links to a shared library libBar.so. How do i link in libBar.so statically instead ? is there a way to do that like by saying -static just before libBar.so This way I will have to worry about distributing one library instead of two. I think this is not possible. You either have to build and distribute two libraries, or simply put everything in one library. Having the source files in different directories is no problem. Bye Alex -- Feel free – 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] target_link_libraries doubt
I understand that it is currently not possible. But take the case where you as a software product developer, are given a proprietary .dll/.so file and you are creating a library that links with that file. If ld -o foo.so -static bar.so foo.o , can be written in a makefile and made to work, why cannot cmake have such an option ? Vikas On 6/14/06, Alexander Neundorf [EMAIL PROTECTED] wrote: Von: Vikas Kumar [EMAIL PROTECTED] Hi I have a library that links to other shared libraries. For example I am trying to build libFoo.so , which links to a shared library libBar.so. How do i link in libBar.so statically instead ? is there a way to do that like by saying -static just before libBar.so This way I will have to worry about distributing one library instead of two. I think this is not possible. You either have to build and distribute two libraries, or simply put everything in one library. Having the source files in different directories is no problem. Bye Alex -- Feel free – 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
