Re: [CMake] CMakeEd Eclipse Plugin has another Release Candidate Ready.
2008/12/1 Michael Jackson [EMAIL PROTECTED]: If you use the built in help from Eclipse you can browse and search the complete CMake documentation as generated from CMake itself. If you bring up the Eclipse Help there should be a new section for CMake. Yes that's right and I missed that. In fact I almost never use the eclipse help system because its an extra window :=) I'd rather have the full help text when requesting completion. If this is not what you want then file a feature request at the CMakeEd sourceforge site. http://sourceforge.net/tracker/?group_id=193949 I filed a feature request https://sourceforge.net/tracker/index.php?func=detailaid=2369701group_id=193949atid=947466 however it may be redundant with the eclipse help system. -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] IMPORTED_LOCATION
Hello,
I have two questions for the listening below.
1. Out-commenting the line #4
results in a linker error LINK : fatal error LNK1104: File
_sLib-NOTFOUND.obj can't be opened
What is the purpose of this command (line #4)?
2. If line #4 is active. An inspection of the project properties (link
- command line) shows in the implib-section the following result:
/IMPLIB:C:\WORK-C\ArchiveCMake\CMakeListsNeu\BuildDLL-2\TestDLL\CMake
\Debug\TestDll2.lib /ERRORREPORT:PROMPT kernel32.lib user32.lib
gdi32.lib winspool.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib comdlg32.lib advapi32.lib
\WORK-C\ArchiveCMake\CMakeListsNeu\BuildDLL-2\DLL\CMake\Debug\SLib.lib
For what reason is there a TestDll2.lib?
Michael
Start of listening
1:PROJECT(TestDLL)
2:CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
3:ADD_LIBRARY(_sLib SHARED IMPORTED)
4:SET_PROPERTY(TARGET _sLib PROPERTY IMPORTED_LOCATION /Path/SLib.dll)
5:SET_PROPERTY(TARGET _sLib PROPERTY IMPORTED_IMPLIB /Path/SLib.lib)
6:INCLUDE_DIRECTORIES(/myIncludeDir)
7:SET(_src MRTestC.c)
8:ADD_EXECUTABLE(TestDll2 ${_src})
9:TARGET_LINK_LIBRARIES(TestDll2 _sLib)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] IMPORTED_LOCATION
Micha Renner wrote:
Hello,
I have two questions for the listening below.
1. Out-commenting the line #4
results in a linker error LINK : fatal error LNK1104: File
_sLib-NOTFOUND.obj can't be opened
What is the purpose of this command (line #4)?
The imported targets are new. Looks like a small glitch...
Here are the docs:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:IMPORTED_LOCATION
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:IMPORTED_IMPLIB
Looks like IMPORTED_LOCATION should be ignored if IMPORTED_IMPLIB is found.
2. If line #4 is active. An inspection of the project properties (link
- command line) shows in the implib-section the following result:
/IMPLIB:C:\WORK-C\ArchiveCMake\CMakeListsNeu\BuildDLL-2\TestDLL\CMake
\Debug\TestDll2.lib /ERRORREPORT:PROMPT kernel32.lib user32.lib
gdi32.lib winspool.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib comdlg32.lib advapi32.lib
\WORK-C\ArchiveCMake\CMakeListsNeu\BuildDLL-2\DLL\CMake\Debug\SLib.lib
For what reason is there a TestDll2.lib?
You can export symbols from an executable on windows. So, CMake will
create the import library file.
Michael
Start of listening
1:PROJECT(TestDLL)
2:CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
3:ADD_LIBRARY(_sLib SHARED IMPORTED)
4:SET_PROPERTY(TARGET _sLib PROPERTY IMPORTED_LOCATION /Path/SLib.dll)
5:SET_PROPERTY(TARGET _sLib PROPERTY IMPORTED_IMPLIB /Path/SLib.lib)
6:INCLUDE_DIRECTORIES(/myIncludeDir)
7:SET(_src MRTestC.c)
8:ADD_EXECUTABLE(TestDll2 ${_src})
9:TARGET_LINK_LIBRARIES(TestDll2 _sLib)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Future of debian package generator?
Hi list, ok, my question is already in the subject. After some tests I like the idea of packaging debs with cmake [0] very much, but I would like to know how the future plans for this feature are. I will describe why I'm uncertain of it's future: AFAIK Mathieu Malaterre implemented the packaging of debs for cmake (thank you very much!) and was criticized by the debian developers for not doing it the right way. Mathieu tried to improve the packaging for getting more accordance by the debian developers. All this can be read in the debian-devel mailing list. The last mail from Mathieu at this list with reference to cmake was this: http://www.mail-archive.com/[EMAIL PROTECTED]/msg261679.html I did not find anything regards the future of the debian packaging on the cmake website or the mailing-list so far... So will there be a deb-packer in cmake 2.8? Is there any hope to get the blessing of the debian developers for it? Greetings from Germany Johannes [0]: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#DEB_.28UNIX_only.29 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] IMPORTED_LOCATION
Am Montag, den 01.12.2008, 08:09 -0500 schrieb Bill Hoffman:
Micha Renner wrote:
Hello,
I have two questions for the listening below.
1. Out-commenting the line #4
results in a linker error LINK : fatal error LNK1104: File
_sLib-NOTFOUND.obj can't be opened
What is the purpose of this command (line #4)?
The imported targets are new. Looks like a small glitch...
This doesn't answer my question.
Why is it helpful to know the location of the Windows-DLL during the
build-process?
I'm not an expert, but for me it makes only sense, if I want to use a
DLL, which is not located in an execution-directory of the OS.
This would a nice feature.
Here are the docs:
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:IMPORTED_LOCATION
http://www.cmake.org/cmake/help/cmake2.6docs.html#prop_tgt:IMPORTED_IMPLIB
No, without http://www.cmake.org/Wiki/CMake_2.6_Notes
you are helpless.
Looks like IMPORTED_LOCATION should be ignored if IMPORTED_IMPLIB is found.
That is not the case, okay.
2. If line #4 is active. An inspection of the project properties (link
- command line) shows in the implib-section the following result:
/IMPLIB:C:\WORK-C\ArchiveCMake\CMakeListsNeu\BuildDLL-2\TestDLL\CMake
\Debug\TestDll2.lib /ERRORREPORT:PROMPT kernel32.lib user32.lib
gdi32.lib winspool.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib comdlg32.lib advapi32.lib
\WORK-C\ArchiveCMake\CMakeListsNeu\BuildDLL-2\DLL\CMake\Debug\SLib.lib
For what reason is there a TestDll2.lib?
You can export symbols from an executable on windows. So, CMake will
create the import library file.
Who needs this?
Anyway, thanks for help.
Michael
Michael
Start of listening
1:PROJECT(TestDLL)
2:CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
3:ADD_LIBRARY(_sLib SHARED IMPORTED)
4:SET_PROPERTY(TARGET _sLib PROPERTY IMPORTED_LOCATION /Path/SLib.dll)
5:SET_PROPERTY(TARGET _sLib PROPERTY IMPORTED_IMPLIB /Path/SLib.lib)
6:INCLUDE_DIRECTORIES(/myIncludeDir)
7:SET(_src MRTestC.c)
8:ADD_EXECUTABLE(TestDll2 ${_src})
9:TARGET_LINK_LIBRARIES(TestDll2 _sLib)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] IMPORTED_LOCATION
Am Montag, 1. Dezember 2008 schrieb Micha Renner: Why is it helpful to know the location of the Windows-DLL during the build-process? mingw's linker ignores the import .lib and takes .dll directly. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Automatically listing source files with GLOB (Re: How to make FILE() append to the list of files?)
find . -name *.c source_files.txt edit source_files.txt and put that list of files exiplicitly into a CMakeLists.txt file. file(GLOB is a bad way to get source lists for CMake. CMake has no way of knowing when new files have been put in the directory. But unless I am missing a fundamental feature somewhere, GLOB still seems to be the better alternative. While it may not intrinsically know when new files have appeared on the filesystem, the programmer can simply re-run the CMake command to get an updated project with the newly added source files without editing the CMakeLists.txt file directly. Yes but when he add a source file, he won't necessarily remember he MUST rerun CMake manually [...] Whereas with hard-written sources files in CMakeLists.txt, the user will get accustomed to simple CMakeList.txt editing [...] [...] It usually looks like a better alternative (but I may be wrong) when you are in the process of converting several project to CMake and you end-up writing a lot of boring CMakeLists.txt in the startup process :=) Actually, when I was last faced with this task I decided the easier alternative for me was to cut and paste a lot of boring directory listings into my CMakeLists.txt files. (This was in a much earlier version of CMake, and IIRC there was some problem with file globbing back then that was fixed soon afterward.) The reason for my choice at that time was user acceptance. I had a brief window of opportunity to introduce a new build system based on CMake, which did not give me time to train all the developers in CMake before deploying it. One of the first objections I received was that it was much harder to add, remove, or rename source files in CMake than via the Visual Studio interface. So I made it a pushbutton process: the developer just had to run a script named something like MakeWorkspace.bat. Besides the project developers themselves, I also had users who needed to be able just to build the project without doing any development on it. I actually got in trouble with those users on account of the one directory where I had listed the source files individually instead of globbing them. The problem was solved when we globbed that directory too. I've had second thoughts about all this, for example the other day when someone forgot to tell a developer newly introduced to this project that he needed to run the script after adding source files--that is, we forgot until he came to me asking about his link errors. On the other hand, it takes very little time for people to develop new habits that tell them when to re-run the script. I'm probably going to change some things about the build procedure sooner or later, but I don't know if or when this will be one of them. The conclusion for me is that when I write a CMakeLists.txt file for a personal project, I never glob the files; but the build design of a long-running project needs to account for who is working on it and what procedures will work best for them. That may imply listing the files explicitly, but it could conceivably imply globbing them. David Karr ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Invoking make with CMake scripts?
Robert Dailey schrieb: I generally like keeping libraries in version control because it makes it convenient to start working from a fresh checkout. This is really only an issue with Windows, since most linux distributions have a package management system that makes it trivial to install third party library dependencies. On Windows, it's quite a pain to visit various websites and downloads the limitless number of dependencies. If you flatten the dependency tree, you'll probably end up downloading 10 or more different libraries, each of which is pretty difficult to build on Windows. A developer on windows could be looking at a couple of hours before the project is ready to compile. Am I looking at this the wrong way, or is this just the reality all Windows developers have to face? I would keep this separate. You only need to setup the environment once. This is a completely different task then the actual development. Additionally: why not provide one package for your developers that they only have to unpack to some dir and can start? Why should they all compile the same thing? This way, only one has to go through the trouble of porting an compiling the stuff. That is roughly equal to installing your distribution's packages. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Invoking make with CMake scripts?
On Mon, Dec 1, 2008 at 9:54 AM, Hendrik Sattler [EMAIL PROTECTED]wrote: I would keep this separate. You only need to setup the environment once. This is a completely different task then the actual development. Additionally: why not provide one package for your developers that they only have to unpack to some dir and can start? Why should they all compile the same thing? This way, only one has to go through the trouble of porting an compiling the stuff. That is roughly equal to installing your distribution's packages. Well on Linux this would be trivial, but as I said on Windows doing this could take hours, even if I do provide a simple package they can extract to some directory, they'll still be faced with the challenge of building all libraries in that package that I provide. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Controlling the locations of files produced by Visual Studio
The context of this question is that I'm porting an existing project from Visual Studio 6.0 to Visual Studio 2008. This project has used CMake for several years, but before that it already had its own file structure into which it put all the files that it built. [...] It would be ever so much easier for me if CMake just provided a couple of extra options to say where certain output files got written. Another alternative might be to have CMake generate Visual Studio 6 project files, using the variable that controls whether or not CMake rules get added to turn off the re-run CMake rules and then use Visual Studio 2008 to convert those project files...? This would be a viable alternative if I wanted to check in the VCPROJ files under source code control and abandon CMake for all future versions of the software under this project. Which I don't. (I actually did this once just to see what I really wanted the VCPROJ files to look like, so I can confirm that it does work, but it would never be accepted as part of the nightly build process of the larger system.) Since there seems to be no other comment on the mailing list, I'll try the issue tracker. David Karr ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] IMPORTED_LOCATION
Maik Beckmann schrieb: Am Montag, 1. Dezember 2008 schrieb Micha Renner: Why is it helpful to know the location of the Windows-DLL during the build-process? mingw's linker ignores the import .lib and takes .dll directly. AFAIK, it can use both, means unlike msvc it doesn't depend on the presence of the .lib file. But if you give him that, it will use it. Actually, when using -lfoo, it will choose the .dll.a instead of the .dll file. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automatically listing source files with GLOB (Re: How to make FILE() append to the list of files?)
[EMAIL PROTECTED] schrieb: The reason for my choice at that time was user acceptance. I had a brief window of opportunity to introduce a new build system based on CMake, which did not give me time to train all the developers in CMake before deploying it. One of the first objections I received was that it was much harder to add, remove, or rename source files in CMake than via the Visual Studio interface. So I made it a pushbutton process: the developer just had to run a script named something like MakeWorkspace.bat. When the decision to change the build system for whatever reason, just tell your developers to not complain about it. Tell them to live with it _POINT_. At least if the complaints are only personal habits that can easily be changed with some good will. It's not some cryptic language, after all. Besides the project developers themselves, I also had users who needed to be able just to build the project without doing any development on it. I actually got in trouble with those users on account of the one directory where I had listed the source files individually instead of globbing them. The problem was solved when we globbed that directory too. They change nothing on the project? Why would the source file listings be a problem for them, then? Well unless they added something, so they actually _are_ doing development on it. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Invoking make with CMake scripts?
Robert Dailey schrieb: On Mon, Dec 1, 2008 at 9:54 AM, Hendrik Sattler [EMAIL PROTECTED]wrote: I would keep this separate. You only need to setup the environment once. This is a completely different task then the actual development. Additionally: why not provide one package for your developers that they only have to unpack to some dir and can start? Why should they all compile the same thing? This way, only one has to go through the trouble of porting an compiling the stuff. That is roughly equal to installing your distribution's packages. Well on Linux this would be trivial, but as I said on Windows doing this could take hours, even if I do provide a simple package they can extract to some directory, they'll still be faced with the challenge of building all libraries in that package that I provide. a BINARY package, not a source package. Like Debian, not like Gentoo. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Invoking make with CMake scripts?
On Mon, Dec 1, 2008 at 10:21 AM, Hendrik Sattler [EMAIL PROTECTED]wrote: Robert Dailey schrieb: Well on Linux this would be trivial, but as I said on Windows doing this could take hours, even if I do provide a simple package they can extract to some directory, they'll still be faced with the challenge of building all libraries in that package that I provide. a BINARY package, not a source package. Like Debian, not like Gentoo. How many binary packages are we talking about here? One for Windows, one for MacOS, and one for Linux? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] IMPORTED_LOCATION
Am Montag, 1. Dezember 2008 schrieb Hendrik Sattler: Maik Beckmann schrieb: Am Montag, 1. Dezember 2008 schrieb Micha Renner: Why is it helpful to know the location of the Windows-DLL during the build-process? mingw's linker ignores the import .lib and takes .dll directly. AFAIK, it can use both, means unlike msvc it doesn't depend on the presence of the .lib file. But if you give him that, it will use it. Actually, when using -lfoo, it will choose the .dll.a instead of the .dll file. Didn't know that, thank you for elaborating. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] source_group(): Which project is it added to?
On Tue, Nov 25, 2008 at 1:39 PM, Robert Dailey [EMAIL PROTECTED] wrote: I'm having an issue right now where I'm trying to setup 2 projects in 1 CMakeLists.txt file. Basically what I do is: project( p1 ) add_executable() project( p2 ) source_group() add_library() For project p1, the visual studio project that is output (p1.vcproj) contains filters created by the source_group() call several lines below it. Why does this happen? Only p2 should be affected by source_group() correct? Bump. Can anyone explain this behavior? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Invoking make with CMake scripts?
Robert Dailey schrieb: On Mon, Dec 1, 2008 at 10:21 AM, Hendrik Sattler [EMAIL PROTECTED]wrote: Robert Dailey schrieb: Well on Linux this would be trivial, but as I said on Windows doing this could take hours, even if I do provide a simple package they can extract to some directory, they'll still be faced with the challenge of building all libraries in that package that I provide. a BINARY package, not a source package. Like Debian, not like Gentoo. How many binary packages are we talking about here? One for Windows, one for MacOS, and one for Linux? Depends on your preference, possibly. Unless your developers use different compilers, that could be one for Windows. It could as well contain the compiler if that is mingw. Or build a nifty installer where you can select the components. Your solutions for MacOS X and Linux might be something else. A personal repository for the development crew would be my personal preference. Not sure about MacOS X, never used that. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] source_group(): Which project is it added to?
On Mon, Dec 1, 2008 at 10:52 AM, cyril_wobow [EMAIL PROTECTED] wrote:
It's my understanding that you are trying to declare two solutions p1 and
p2 (using visual studio's terminology).
The source_group() calls affects the next project declaration (which is
done with add_executable() or add_library()) in the cmake module where they
occur .
That is indeed how I would expect it to work, but that's not what is
happening. Below is the actual CMake code I'm using to generate projects:
macro( component project_name )
cmake_minimum_required( VERSION 2.6 )
set_include_directories()
add_definitions( -DBOOST_ALL_NO_LIB )
if( EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/test )
project( ${project_name}_test )
file( GLOB_RECURSE testsrc test/*.[chi]pp )
add_executable( ${project_name}_test ${testsrc} )
else()
message( WARNING: No unit test found for component
vfx/${project_name} )
endif()
project( ${project_name} )
file( GLOB_RECURSE inc RELATIVE ${CMAKE_CURRENT_SOURCE_DIR}
include/*.[chi]pp )
file( GLOB_RECURSE src RELATIVE ${CMAKE_CURRENT_SOURCE_DIR}
source/*.[chi]pp )
foreach( file ${inc};${src} )
get_filename_component( path ${file} PATH )
string( REPLACE / \\ group ${path} )
source_group( ${group} FILES ${file} )
endforeach()
endmacro()
macro( library_component project_name )
component( ${project_name} )
add_library( ${project_name} STATIC ${inc};${src} )
endmacro()
Inside of another CMakeLists.txt file in a different subdirectory, I'll call
*library_component( ProjectName )*. Is this a bug in CMake or am I just
doing this incorrectly? Help would be appreciated! Thank you.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automatically listing source files with GLOB (Re: How to make FILE() append to the list of files?)
On Mon, Dec 1, 2008 at 4:50 PM, [EMAIL PROTECTED] wrote: Yes but when he add a source file, he won't necessarily remember he MUST rerun CMake manually [...] Whereas with hard-written sources files in CMakeLists.txt, the user will get accustomed to simple CMakeList.txt editing [...] [...] Actually, when I was last faced with this task I decided the easier alternative for me was to cut and paste a lot of boring directory listings into my CMakeLists.txt files. (This was in a much earlier version of CMake, and IIRC there was some problem with file globbing back then that was fixed soon afterward.) Just thinking out loud here, but would it be possible for the trigger that determines whether CMake should be rerun or not to check if any files were added/removed? That would make the globbing method as convenient as the manual editing. Cheers, -- Bart Janssens ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automatically listing source files with GLOB (Re: How to make FILE() append to the list of files?)
The root problem here is one of expense. It is an expensive question to ask has a single file been added or removed from this directory tree of thousands of source code files... So we never ask that question. (Doing two file(GLOB's and comparing the results to say has there been a change? is more expensive than just doing it once and assuming there has been a change...) In the end, the developer always has to be trained about how to add a source file to a project. If you and all of your developers *always* work like this (#1): - make any changes you like - run cmake - run make (or build with an IDE) ...then the file(GLOB technique is feasible because your developers always run cmake before building. If instead you work like this (#2): - make any changes you like - run make (or build with an IDE) ...then the file(GLOB technique does not work when you have added a source file. But the explicit listing of those files in CMakeLists.txt still works... The developers need to know that if they add source files then cmake has to be re-run. *Unless* you explicitly list the sources in CMakeLists -- then cmake automatically reruns because the CMakeLists has changed... Explicit listing of sources in CMakeLists.txt always works. file(GLOB only works sometimes depending on dev workflow preference. That's why we always recommend explicitly listing sources. Ignore our advice if you wish, but file(GLOB will always be an unreliable technique unless you have a magic way of enforcing workflow #1. HTH, David On Mon, Dec 1, 2008 at 12:56 PM, Bart Janssens [EMAIL PROTECTED]wrote: On Mon, Dec 1, 2008 at 4:50 PM, [EMAIL PROTECTED] wrote: Yes but when he add a source file, he won't necessarily remember he MUST rerun CMake manually [...] Whereas with hard-written sources files in CMakeLists.txt, the user will get accustomed to simple CMakeList.txt editing [...] [...] Actually, when I was last faced with this task I decided the easier alternative for me was to cut and paste a lot of boring directory listings into my CMakeLists.txt files. (This was in a much earlier version of CMake, and IIRC there was some problem with file globbing back then that was fixed soon afterward.) Just thinking out loud here, but would it be possible for the trigger that determines whether CMake should be rerun or not to check if any files were added/removed? That would make the globbing method as convenient as the manual editing. Cheers, -- Bart Janssens ___ 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
Re: [CMake] source_group(): Which project is it added to?
Robert Dailey a écrit :
On Mon, Dec 1, 2008 at 10:52 AM, cyril_wobow [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
It's my understanding that you are trying to declare two
solutions p1 and p2 (using visual studio's terminology).
The source_group() calls affects the next project declaration
(which is done with add_executable() or add_library()) in the
cmake module where they occur .
That is indeed how I would expect it to work, but that's not what is
happening. Below is the actual CMake code I'm using to generate projects:
macro( component project_name )
cmake_minimum_required( VERSION 2.6 )
set_include_directories()
add_definitions( -DBOOST_ALL_NO_LIB )
if( EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/test )
project( ${project_name}_test )
file( GLOB_RECURSE testsrc test/*.[chi]pp )
add_executable( ${project_name}_test ${testsrc} )
else()
message( WARNING: No unit test found for component
vfx/${project_name} )
endif()
project( ${project_name} )
file( GLOB_RECURSE inc RELATIVE ${CMAKE_CURRENT_SOURCE_DIR}
include/*.[chi]pp )
file( GLOB_RECURSE src RELATIVE ${CMAKE_CURRENT_SOURCE_DIR}
source/*.[chi]pp )
foreach( file ${inc};${src} )
get_filename_component( path ${file} PATH )
string( REPLACE / \\ group ${path} )
source_group( ${group} FILES ${file} )
endforeach()
endmacro()
macro( library_component project_name )
component( ${project_name} )
add_library( ${project_name} STATIC ${inc};${src} )
endmacro()
Inside of another CMakeLists.txt file in a different subdirectory,
I'll call *library_component( ProjectName )*. Is this a bug in CMake
or am I just doing this incorrectly? Help would be appreciated! Thank you.
I remember an issue (still pending) where the PROJECT() macro would have
to be invoked from within the root CMakeList file. This problem occured
to me while writing my homemade macros and I had to work it around by
splitting my macro in half and having the following in my root CMakeList
file :
MYMACRO1(...)
PROJECT(xxx)
MYMACRO2(...)
... which is ugly and could really use a fix.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake-gui(beta) does not show a change in CMAKE_CXX_FLAGS
Hi,
In a Visual Studio Generator context...
I set a compiler flag in my CMakeLists.txt, but the change is not
reflected in the gui (advanced values), even if the project setting is
correct. I find this error prone, because it gives the user incorrect
information about the current configuration. Is this by design?
Example code:
Set (CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /EHa)
I would expect to see this change in the gui also. But now I see /EHsc.
Thanks,
David.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Automatically listing source files with GLOB (Re: How to make FILE() append to the list of files?)
When the decision to change the build system for whatever reason, just tell your developers to not complain about it. Tell them to live with it _POINT_. The point is, not everyone who is in a position to introduce a useful tool into a project is in a position to do it in that way. Sometimes it has to be sold to other people rather than dictated. Besides the project developers themselves, I also had users who needed to be able just to build the project without doing any development on it. I actually got in trouble with those users on account of the one directory where I had listed the source files individually instead of globbing them. The problem was solved when we globbed that directory too. They change nothing on the project? Why would the source file listings be a problem for them, then? I forget the exact sequence of events, but as I recall, the inconsistency was introduced somehow during one of the steps between the actual developer's build and when the source code (including CMakeLists.txt) ended up on a certain source code control branch. All these other users did was to check out all source code on that branch and attempt to build it. Presumably a similar outcome could have occurred via a different chain of events with DSP files that were maintained directly through Visual Studio, but that argument didn't impress people who chose to blame the problem on the fact that we used CMake. What I think is really remarkable is that despite all the many implicit requirements of the environment within which this particular build system had to operate--of which I've barely been able to mention a small part--CMake was able to adapt to work within them, even when those requirements didn't match anybody's idea of the best environment within which to use a tool like CMake. This says something about the power of the tool. David Karr ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] source_group(): Which project is it added to?
On Mon, Dec 1, 2008 at 12:25 PM, cyril_wobow [EMAIL PROTECTED] wrote: Robert Dailey a écrit : That is indeed how I would expect it to work, but that's not what is happening. Below is the actual CMake code I'm using to generate projects: snip Inside of another CMakeLists.txt file in a different subdirectory, I'll call *library_component( ProjectName )*. Is this a bug in CMake or am I just doing this incorrectly? Help would be appreciated! Thank you. I remember an issue (still pending) where the PROJECT() macro would have to be invoked from within the root CMakeList file. This problem occured to me while writing my homemade macros and I had to work it around by splitting my macro in half and having the following in my root CMakeList file : MYMACRO1(...) PROJECT(xxx) MYMACRO2(...) ... which is ugly and could really use a fix. That's going to be obnoxious if that is indeed the case. Was the problem you were experiencing anything like mine? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] IMPORTED_LOCATION
Micha Renner wrote: I have two questions for the listening below. 1. Out-commenting the line #4 results in a linker error LINK : fatal error LNK1104: File _sLib-NOTFOUND.obj can't be opened What is the purpose of this command (line #4)? When one adds a shared library that is built in the project, CMake knows both the dll and lib location that it will build. It is useful in some cases to know both locations even for imported targets (like configuring an environment with the location of the dll in its PATH). If you change the library type to UNKNOWN (2.6.2 and higher) then you can just set IMPORTED_LOCATION with the location of the lib and forget the dll. 2. If line #4 is active. An inspection of the project properties (link - command line) shows in the implib-section the following result: /IMPLIB:C:\WORK-C\ArchiveCMake\CMakeListsNeu\BuildDLL-2\TestDLL\CMake \Debug\TestDll2.lib /ERRORREPORT:PROMPT kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib \WORK-C\ArchiveCMake\CMakeListsNeu\BuildDLL-2\DLL\CMake\Debug\SLib.lib For what reason is there a TestDll2.lib? If any object files in the executable have a __declspec(dllexport) then the linker will produce an import library for the executable. This tells it where to put the library. Usually it doesn't show up, but CMake adds the option just in case. It is useful when exporting symbols from an executable for use by plugins it loads. 3:ADD_LIBRARY(_sLib SHARED IMPORTED) 4:SET_PROPERTY(TARGET _sLib PROPERTY IMPORTED_LOCATION /Path/SLib.dll) 5:SET_PROPERTY(TARGET _sLib PROPERTY IMPORTED_IMPLIB /Path/SLib.lib) As mentioned above, you can write CMAKE_MINIMUM_REQUIRED(VERSION 2.6.2) ADD_LIBRARY(_sLib UNKNOWN IMPORTED) SET_PROPERTY(TARGET _sLib PROPERTY IMPORTED_LOCATION /Path/SLib.lib) -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Getting rid of unwanted quotes that CMake inserts into commands
Second try.
Surely somebody here knows why VERBATIM fails to work properly (inserts
unwanted double quotes in the command) for certain kinds of stderr and
stdout redirection but not for the basic kind?
If/when there is a fix in the cvs version of CMake, I would be happy to test
it.
Alan
-- Forwarded message --
Date: Sat, 29 Nov 2008 21:08:22 -0800 (PST)
From: Alan W. Irwin [EMAIL PROTECTED]
To: cmake@cmake.org
Subject: [CMake] Getting rid of unwanted quotes that CMake inserts into commands
I have defined the following custom command:
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/grid_EOS1_2.out
COMMAND ${free_eos_test_LOCATION}
${CMAKE_CURRENT_BINARY_DIR}/grid_EOS1_2.in
${CMAKE_CURRENT_BINARY_DIR}/grid_EOS1_2.out
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/grid_EOS1_2.in free_eos_test
VERBATIM
)
The COMMAND line will get wrapped in this e-mail, but it appears all in one
line in the CMakeLists.txt file.
For both 2.6.1 and 2.6.2, the resulting command that is executed is fine
except that is transformed to and those inserted double quotes
interfere with the desired redirection. If I use instead (which makes
stderr default to the terminal rather than mixing it in with grid_EOS1_2.out
like I would like), then there are no double quotes surrounding that in the
generated command. If I use 2 and 1 redirection to generate two files
(one for stderr, one for stdout), they are transformed to 2 and 1 by
CMake and those inserted double quotes again interfere with the desired
redirection.
Is this a CMake bug (since double quotes are being inserted into the
generated command for , 2, and 1 despite the VERBATIM above)?
Regardless of that bug question, is there a way to work around this CMake
issue?
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 mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake-gui(beta) does not show a change in CMAKE_CXX_FLAGS
Bill,
cache. set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /EHa CACHE FORCE )
will do what you want.
I tried adding CACHE FORCE , but I still see /EHsc in the ui.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to automate cmake installation on windows
Hi, Is there a way to run the cmake windows installer without user intervention? I did not find any documentation on the subject. I would like to be able to install from a script. What is the best way achieve this ? Thank you, David ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake-gui(beta) does not show a change in CMAKE_CXX_FLAGS
David Genest wrote:
Bill,
cache. set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /EHa CACHE FORCE )
will do what you want.
I tried adding CACHE FORCE , but I still see /EHsc in the ui.
___
My mistake...
http://www.cmake.org/cmake/help/cmake2.6docs.html#command:set
set(variable value [[CACHE type docstring [FORCE]] |
PARENT_SCOPE])
Should be:
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /EHa CACHE STRING cxx flags
FORCE)
This will still be odd for your users. It will also append /EHa every
time CMake is run...
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] source_group(): Which project is it added to?
Robert Dailey a écrit : On Mon, Dec 1, 2008 at 12:25 PM, cyril_wobow [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Robert Dailey a écrit : That is indeed how I would expect it to work, but that's not what is happening. Below is the actual CMake code I'm using to generate projects: snip Inside of another CMakeLists.txt file in a different subdirectory, I'll call *library_component( ProjectName )*. Is this a bug in CMake or am I just doing this incorrectly? Help would be appreciated! Thank you. I remember an issue (still pending) where the PROJECT() macro would have to be invoked from within the root CMakeList file. This problem occured to me while writing my homemade macros and I had to work it around by splitting my macro in half and having the following in my root CMakeList file : MYMACRO1(...) PROJECT(xxx) MYMACRO2(...) which is ugly and could really use a fix. That's going to be obnoxious if that is indeed the case. Was the problem you were experiencing anything like mine? I did not compare our problems when I read your code, I just realized that you were invoking project() from within a macro. Here is some (old) discussion about it: http://www.cmake.org/pipermail/cmake/2005-February/006082.html ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to automate cmake installation on windows
David Genest wrote: Hi, Is there a way to run the cmake windows installer without user intervention? I did not find any documentation on the subject. I would like to be able to install from a script. What is the best way achieve this ? You could use the zip file installer. It would not go into the start menu, but you could still run it. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Can't get include() to work!
For some reason I cannot get include() to work. In a CMakeLists.txt of mine (not the root CMakeLists.txt) I call the following: cmake_minimum_required( VERSION 2.6 ) include( includes.cmake ) project( vfx ) And I have a file called includes.cmake in the same directory containing the CMakeLists.txt above. When I run *cmake -G Visual Studio 9 2008*, I get the following output: C:\IT\work\jewettcmake -G Visual Studio 9 2008 CMake Error at vfx/CMakeLists.txt:2 (include): include could not find load file: includes.cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Getting rid of unwanted quotes that CMake inserts into commands
Alan W. Irwin wrote:
I have defined the following custom command:
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/grid_EOS1_2.out
COMMAND ${free_eos_test_LOCATION}
${CMAKE_CURRENT_BINARY_DIR}/grid_EOS1_2.in
${CMAKE_CURRENT_BINARY_DIR}/grid_EOS1_2.out
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/grid_EOS1_2.in free_eos_test
VERBATIM
)
The COMMAND line will get wrapped in this e-mail, but it appears all in one
line in the CMakeLists.txt file.
For both 2.6.1 and 2.6.2, the resulting command that is executed is fine
except that is transformed to and those inserted double quotes
interfere with the desired redirection. If I use instead (which makes
stderr default to the terminal rather than mixing it in with
grid_EOS1_2.out
like I would like), then there are no double quotes surrounding that in the
generated command. If I use 2 and 1 redirection to generate two files
(one for stderr, one for stdout), they are transformed to 2 and 1 by
CMake and those inserted double quotes again interfere with the desired
redirection.
Is this a CMake bug (since double quotes are being inserted into the
generated command for , 2, and 1 despite the VERBATIM above)?
It can be considered a bug or a feature. VERBATIM means literally
verbatim, as in pass these exact options and avoid all shell
translation. Originally even the normal redirections were escaped too.
In 2.6 we added some special cases for common (basic) redirections.
We can add more. Are you aware of a complete list of redirection
operators that work in all make shells?
Regardless of that bug question, is there a way to work around this CMake
issue?
Don't use VERBATIM. Alternatively, create your own script or helper
program to do the redirecion.
-Brad
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't get include() to work!
On Dec 1, 2008, at 5:12 PM, Robert Dailey wrote:
For some reason I cannot get include() to work.
In a CMakeLists.txt of mine (not the root CMakeLists.txt) I call the
following:
cmake_minimum_required( VERSION 2.6 )
include( includes.cmake )
project( vfx )
And I have a file called includes.cmake in the same directory
containing the CMakeLists.txt above. When I run cmake -G Visual
Studio 9 2008, I get the following output:
C:\IT\work\jewettcmake -G Visual Studio 9 2008
CMake Error at vfx/CMakeLists.txt:2 (include):
include could not find load file:
includes.cmake
How is your cmake file being called? If it is being called with
include(...) then basically your file contents is substituted for
the include(...) call. So the file includes.cmake without any
leading prefix directory makes sense that it can not be found.
You basically need to get the current directory that CMake is
traversing to figure out what prefix to use.
Do you _really_ need to place the include(includes.cmake) BEFORE the
project() command? If you can swap these two lines then you can do
something like:
project (vfx)
include ( ${vfx_SOURCE_DIR}/includes.cmake ) and it should find the
includes.cmake file in the same directory as the vfx CMakeLists.txt
file.
Hope that helps.
___
Mike Jackson [EMAIL PROTECTED]
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer Dayton, Ohio
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Getting rid of unwanted quotes that CMake inserts into commands
On 2008-12-01 18:55-0500 Brad King wrote: Alan W. Irwin wrote: [...] For both 2.6.1 and 2.6.2, the resulting command that is executed is fine except that is transformed to and those inserted double quotes interfere with the desired redirection. [...] Is this a CMake bug (since double quotes are being inserted into the generated command for , 2, and 1 despite the VERBATIM above)? It can be considered a bug or a feature. VERBATIM means literally verbatim, as in pass these exact options and avoid all shell translation. Shouldn't that be up to the user to insert quotes where needed in the command rather than CMake anticipating their needs (incorrectly in this case)? Thus, I suggest you implement a VERBATIM that means pass the original form of command exactly as specified in the CMakeLists.txt file (except for CMake variable substitution) without any extra quotes (or anything else) being inserted. Quotes are pretty powerful shell operators so I don't see why CMake should ever insert extra ones. If CMake has the capability of keeping track of the original form of COMMAND (or reproducing it) the implementation should be trivial. Originally even the normal redirections were escaped too. In 2.6 we added some special cases for common (basic) redirections. We can add more. Are you aware of a complete list of redirection operators that work in all make shells? I just found a pretty good bash tutorial on redirection (http://bash-hackers.org/wiki/doku.php?id=howto:redirection_tutorial). I assume you already have at least , , and | in the list and from the tutorial it appears you should add in at least (, 2, 1, and 21) as well. But I frankly don't understand why a list is necessary to eliminate the quotes that CMake inserts when you use VERBATIM. (see question above and comment below). Regardless of that bug question, is there a way to work around this CMake issue? Don't use VERBATIM. Thanks very much for that suggestion. Indeed, that works for the following test case: project(test_redirection NONE) cmake_minimum_required(VERSION 2.6) add_custom_target(test_target cat /dev/null /dev/null) The generated command is cat /dev/null /dev/null However, just to give a simple test case illustrating the original issue, if I use project(test_redirection NONE) cmake_minimum_required(VERSION 2.6) add_custom_target(test_target cat /dev/null /dev/null VERBATIM) the generated command is cat /dev/null /dev/null which, of course, generates errors. So VERBATIM inserts quotes while if you don't specify VERBATIM, then the generated command is exactly the same as you specified. That's confusing (at least to me) since that behaviour is contrary to the normal English meaning of verbatim. The 2.6.2 documentation implies you should use VERBATIM except for old projects so that is why I adopted it in this particular case. Also, I assumed that dropping VERBATIM would add even more unwanted stuff to the COMMAND so I didn't try that until you suggested it. Anyhow, I am very glad of this (drop VERBATIM keyword) workaround for now, but I also hope you implement a change so that VERBATIM never inserts quotes in the generated COMMAND. 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
Re: [CMake] Can't get include() to work!
On Mon, Dec 1, 2008 at 7:59 PM, Michael Jackson [EMAIL PROTECTED]
wrote:
On Dec 1, 2008, at 5:12 PM, Robert Dailey wrote:
For some reason I cannot get include() to work.
In a CMakeLists.txt of mine (not the root CMakeLists.txt) I call the
following:
cmake_minimum_required( VERSION 2.6 )
include( includes.cmake )
project( vfx )
And I have a file called includes.cmake in the same directory containing
the CMakeLists.txt above. When I run cmake -G Visual Studio 9 2008, I get
the following output:
C:\IT\work\jewettcmake -G Visual Studio 9 2008
CMake Error at vfx/CMakeLists.txt:2 (include):
include could not find load file:
includes.cmake
How is your cmake file being called? If it is being called with
include(...) then basically your file contents is substituted for the
include(...) call. So the file includes.cmake without any leading prefix
directory makes sense that it can not be found.
You basically need to get the current directory that CMake is traversing to
figure out what prefix to use.
Do you _really_ need to place the include(includes.cmake) BEFORE the
project() command? If you can swap these two lines then you can do something
like:
project (vfx)
include ( ${vfx_SOURCE_DIR}/includes.cmake ) and it should find the
includes.cmake file in the same directory as the vfx CMakeLists.txt file.
Hope that helps.
include( ${CMAKE_CURRENT_SOURCE_DIR}/includes.cmake)
should also work.
CMAKE_MODULE_PATH may also help you if you have a lot of includes.
http://www.vtk.org/Wiki/CMake_Useful_Variables
--
Philip Lowman
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake-gui(beta) does not show a change in CMAKE_CXX_FLAGS
On Mon, Dec 1, 2008 at 3:39 PM, Bill Hoffman [EMAIL PROTECTED]wrote:
David Genest wrote:
Hi,
In a Visual Studio Generator context...
I set a compiler flag in my CMakeLists.txt, but the change is not
reflected in the gui (advanced values), even if the project setting is
correct. I find this error prone, because it gives the user incorrect
information about the current configuration. Is this by design?
Example code:
Set (CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /EHa)
I would expect to see this change in the gui also. But now I see /EHsc.
Thanks,
That is because you are setting the value in memory and not in the cache.
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /EHa CACHE FORCE ) will do what
you want. However, the user will NOT be able to edit from the gui if you do
that. Because each time cmake is run the cache FORCE will change the
values.
Has a FORCE_ONCE option ever been considered? The idea would be to allow
the user to (as a one time operation) to force a cache value on top of an
already existing cache entry. It would be useful for appending options, for
example.
--
Philip Lowman
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't get include() to work!
On Mon, Dec 1, 2008 at 9:53 PM, Philip Lowman [EMAIL PROTECTED] wrote:
include( ${CMAKE_CURRENT_SOURCE_DIR}/includes.cmake)
should also work.
CMAKE_MODULE_PATH may also help you if you have a lot of includes.
http://www.vtk.org/Wiki/CMake_Useful_Variables
I definitely tried this (using CMAKE_CURRENT_SOURCE_DIR) and it didn't work.
I'll try Michael's method tomorrow and see if I get any different results.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] IMPORTED_LOCATION
Am Montag, den 01.12.2008, 15:58 +0100 schrieb Maik Beckmann: Am Montag, 1. Dezember 2008 schrieb Micha Renner: Why is it helpful to know the location of the Windows-DLL during the build-process? mingw's linker ignores the import .lib and takes .dll directly. This makes sense. Thank you. Michael ___ 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
[CMake] Exporting from an Installation Tree
Good morning, The lines add_library(foo STATIC foo1.c) install(TARGETS foo DESTINATION lib EXPORTS myproj-targets) install(EXPORT myproj-targets DESTINATION lib/myproj) create a file myproj-targets.cmake and a file myproj-targets-debug.cmake. How can I create a myproj-targets-release.cmake file (Windows)? Michael By the way, .lib and .dll are not always in the same directory. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
