Re: [CMake] How to find fortran library
Maik Beckmann wrote: Am Mittwoch, 3. Dezember 2008 schrieb Javier Gonzalez: Hi all, I have a project that links to another project built with Fortran. My own project is a C++ project and I usually need to link against a fortran library of some sort to use the first one. I use gcc, so it usually is libgfortran or libg2c. Now my question is: if I enable Fortran, will there be a variable that tells me the location of the library I need to link to? No. The compiler frontend (gfortran, g77, ...) makes the decision which system and compiler libraries have to be linked in. If you or cmake link an fortran executable with g77 -o myapp a.o b.o .. libg2c will be linked in by g77. When doing g77 -o myapp a.o b.o .. libgfortran will be linked in by gfortran. The same is true for g++, which links in libstdc++ by default. What I do at the moment is that I guess which library I need to link to based on the Fortran compiler's name and, since I use gcc, try to find it in the path given by 'gcc -print-search-dirs'. Is this the right way? I would expect that cmake defines a variable with this information somewhere. This is the right way. Maybe an effort to write cmake module which handles this task is worthy. Best, -- Maik ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake I see. Later I saw Bill's message about the new release. One of the changes in 2.6.3 RC5 is: - Add FortranCInterface.cmake module to discover Fortran/C interfaces I wonder if that is precisely what I was looking for so I will check it out. thanks, Javier ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] MSVC100?
I think this came up on the mailing list recently but I didn't couldn't find the thread To prevent the above abomination of a variable name ever being created by CMake when Microsoft releases version 10 of their wonderful compiler, I suggest doing away with the whole MSVC60 / MSVC70 / MSVC71 / MSVC80 / MSVC90 thing for future releases and creating a new variable and setting it to the current major minor point release version of Microsoft's compiler: SET(MSVC_DECIMAL_VERSION 9.0) Yes, I realize that MSVC_VERSION exists, but seriously who wants to do integer comparison with confusing values like 1310 and 1400 that require a search engine to fathom to say nothing of the fact that computers seem to have floating point processors in them these days. I will happily submit a patch for this (which shouldn't take long to fix) provided someone with commit rights can tell me what variable name to use. CMake seems divided on the whole should we use CMAKE_COMPILER_2005 or MSVC80; MSVC vs.CMAKE_COMPILER_IS_GNUCC; MINGW or CMAKE_COMPILER_IS_MINGW. Not to start a flamewar or anything but this is awefully bizarre and confusing nomenclature. Is CMAKE_COMPILER_... the path forward or is it obsolete? Also, CMAKE_COMPILER_2005 seems to be true on VS9/2008 at least with the NMake generator. Not sure if this is a documentation bug or a real bug. -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] absolute include paths to resource compiler
Due to some weirdness in Visual Studio, I need to be able to give the
resource compiler an absolute path:
rc ... -I${CMAKE_SOURCE_DIR}/include
If I put
include_directories(${CMAKE_SOURCE_DIR}/include)
CMake converts the CMAKE_SOURCE_DIR absolute path to a relative
one. Why? And how do I get around it. I can't find any flags for
setting resource compiler options.
--
/Jesper
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] absolute include paths to resource compiler
Due to some weirdness in Visual Studio, I need to be able to give the
resource compiler an absolute path:
rc ... -I${CMAKE_SOURCE_DIR}/include
If I put
include_directories(${CMAKE_SOURCE_DIR}/include)
CMake converts the absolute path to a relative one.
--
/Jesper
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Invoke a target on a separate project in a generic way?
Good day all,
I am looking for a way within a CMakeLists.txt make sure that:
-- at *build* time
-- cmake is invoked on a *separate* project, and then also the
all-target is invoked
How do I do that?
The following is a first rough sketch (that is not good enough, I believe):
ADD_CUSTOM_TARGET(
build_separate_project
WORKING_DIRECTORY separate_project/build
COMMAND ${CMAKE_COMMAND} ../src
COMMAND ${CMAKE_BUILD_TOOL} all
)
-- The above only works for a ${CMAKE_BUILD_TOOL} that happens to
accept a commandline that contains a target and nothing else (like
GNU-make does).
So is there a more *generic* way to, at build time, invoke cmake and
then the all-target on a separate project?
(The following is a bit of background: We have a project called FOO
that generates source code that eventually also needs to be compiled.
The generated source files end up in a *directory* that is known
CMake-time, but the *filenames* are not known until *build*-time. Thus
there is no way with in project FOO to create a target to compile
the generated source-code. (Doing FILE(GLOB...) within project FOO
will not work, because the globbing will take place at cmake-time, at
which time there are no files there). Therefore, together with the
generated source files we generate a CMakeLists.txt that defines a
*separate* project called BAR that contains a target to compile the
generated source code. Hence the question above -- how do I invoke the
all target in the BAR project in a way that works for all build-tools,
not only GNU-make?)
Best Regards
Hugo Heden
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Invoke a target on a separate project in a generic way?
2008/12/4 Hugo Heden [EMAIL PROTECTED]:
Good day all,
I am looking for a way within a CMakeLists.txt make sure that:
-- at *build* time
-- cmake is invoked on a *separate* project, and then also the
all-target is invoked
How do I do that?
Before anyone else answers this: I think I should be looking at
try_compile, it seems to do what I am looking for. (I will get back
here and report, for future reference if nothing else.)
http://cmake.org/cmake/help/cmake2.6docs.html#command:try_compile
quote
try_compile: Try compiling some code.
try_compile(RESULT_VAR bindir srcdir
projectName targetname [CMAKE_FLAGS Flags]
[OUTPUT_VARIABLE var])
Try compiling a program. In this form, srcdir should contain a
complete CMake project with a CMakeLists.txt file and all sources. The
bindir and srcdir will not be deleted after this command is run. If
target name is specified then build just that target otherwise the
all or ALL_BUILD target is built.
...
...
/quote
The following is a first rough sketch (that is not good enough, I believe):
ADD_CUSTOM_TARGET(
build_separate_project
WORKING_DIRECTORY separate_project/build
COMMAND ${CMAKE_COMMAND} ../src
COMMAND ${CMAKE_BUILD_TOOL} all
)
-- The above only works for a ${CMAKE_BUILD_TOOL} that happens to
accept a commandline that contains a target and nothing else (like
GNU-make does).
So is there a more *generic* way to, at build time, invoke cmake and
then the all-target on a separate project?
(The following is a bit of background: We have a project called FOO
that generates source code that eventually also needs to be compiled.
The generated source files end up in a *directory* that is known
CMake-time, but the *filenames* are not known until *build*-time. Thus
there is no way with in project FOO to create a target to compile
the generated source-code. (Doing FILE(GLOB...) within project FOO
will not work, because the globbing will take place at cmake-time, at
which time there are no files there). Therefore, together with the
generated source files we generate a CMakeLists.txt that defines a
*separate* project called BAR that contains a target to compile the
generated source code. Hence the question above -- how do I invoke the
all target in the BAR project in a way that works for all build-tools,
not only GNU-make?)
Best Regards
Hugo Heden
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Future of debian package generator?
On Mon, Dec 1, 2008 at 2:38 PM, Johannes Dohmen [EMAIL PROTECTED] wrote: 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? I am pretty sure there will be. Kitware (esp. CMake) has a pretty darn good backward compatibility policy. Is there any hope to get the blessing of the debian developers for it? Yeah, that's a whole lot different story, I doubt anyone can answer here. You'll need to be some kind of DD mentor... Anyway long story short. The debian binary package generator works for us. It will do the simple job of packaging binaries generated by cmake into a so-called deb bundle, which will allows you to redistribute it within your small organization to remote station. It will *never* replace what is being done by the dpkg-* tools. If you are planning on releasing any kind of project as a mainstream open source package to the debian project, then stop right now, and start using the default debian/* files. You are of course free to call cmake within the debian/rules file. Hope this answer your questions, -- Mathieu ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't get include() to work!
Robert Dailey wrote: The problem isn't about MAC line endings not working. I could care less about line ending requirements, I'll go with whatever works. The main problem I have is that CMake didn't TELL me what the problem was. It should have said, Hey dummy, your line endings are unacceptable. Please change them to LINUX line endings. That would have saved me hours of time! Sure, it is just that you are the very first person to run into this in the last 8 years. I am curious how you created the file. I will try to come up with a way to detect mac files and issue an error. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Getting a list of the defined CMake cache variables along with properties and documentation?
Philip Lowman wrote: 1. A chicken and the egg problem, a configure has to occur and CMakeCache.txt created first before you can even parse it for documentation. Depending on the system being configured generation of a CMakeCache.txt can take some time due to all of the time needed to do compilation checks, etc. It's not as if the user is going to be able to run cmake --configure-help . and have it immediately spit out documentation like GNU AutoTools prior to the user even configuring the build. There would have to be an initial delay as the cache is created. Obviously there is the apriori option here though (distribute configuration help ahead of time or require the user to configure manually first). 2. The generated documentation (as Bill alluded to) would be dependent on which branches were taken during the configure Every time we talk about this, I think the only way to solve it is to have all the options in some central place. Basically add some sort of argv/argc handler code into CMake. It would be up to the project maintainer to put the publishable options into that file. Any sort of code that makes all if statement branches true will just not work, and will be a huge hack. Something like: ProjectOptions.cmake add_option(enable-testing Enable the testing part of the project ENABLE_TESTING) add_option(build-with-mpi Use MPI with this project BUILD_WITH_MPI) The option would have a command line option, the documentation, and the cache variable. A documentation feature could search the project source tree for PRojectOptions.cmake files and quickly find them all. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to find fortran library
Javier Gonzalez wrote: Maik Beckmann wrote: Am Mittwoch, 3. Dezember 2008 schrieb Javier Gonzalez: Hi all, I have a project that links to another project built with Fortran. My own project is a C++ project and I usually need to link against a fortran library of some sort to use the first one. I use gcc, so it usually is libgfortran or libg2c. Now my question is: if I enable Fortran, will there be a variable that tells me the location of the library I need to link to? No. The compiler frontend (gfortran, g77, ...) makes the decision which system and compiler libraries have to be linked in. If you or cmake link an fortran executable with g77 -o myapp a.o b.o .. libg2c will be linked in by g77. When doing g77 -o myapp a.o b.o .. libgfortran will be linked in by gfortran. The same is true for g++, which links in libstdc++ by default. What I do at the moment is that I guess which library I need to link to based on the Fortran compiler's name and, since I use gcc, try to find it in the path given by 'gcc -print-search-dirs'. Is this the right way? I would expect that cmake defines a variable with this information somewhere. This is the right way. Maybe an effort to write cmake module which handles this task is worthy. Best, -- Maik ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake I see. Later I saw Bill's message about the new release. One of the changes in 2.6.3 RC5 is: - Add FortranCInterface.cmake module to discover Fortran/C interfaces I wonder if that is precisely what I was looking for so I will check it out. No not really. That module figures out the name mangling scheme of the fortran compiler. It does not figure out the run time libraries. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] absolute include paths to resource compiler
[EMAIL PROTECTED] wrote:
Due to some weirdness in Visual Studio, I need to be able to give the
resource compiler an absolute path:
rc ... -I${CMAKE_SOURCE_DIR}/include
If I put
include_directories(${CMAKE_SOURCE_DIR}/include)
CMake converts the absolute path to a relative one.
What is the weirdness? It should work without a full path?
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Invoke a target on a separate project in a generic way?
Hugo Heden wrote:
Good day all,
I am looking for a way within a CMakeLists.txt make sure that:
-- at *build* time
-- cmake is invoked on a *separate* project, and then also the
all-target is invoked
How do I do that?
The following is a first rough sketch (that is not good enough, I believe):
ADD_CUSTOM_TARGET(
build_separate_project
WORKING_DIRECTORY separate_project/build
COMMAND ${CMAKE_COMMAND} ../src
COMMAND ${CMAKE_BUILD_TOOL} all
)
-- The above only works for a ${CMAKE_BUILD_TOOL} that happens to
accept a commandline that contains a target and nothing else (like
GNU-make does).
So is there a more *generic* way to, at build time, invoke cmake and
then the all-target on a separate project?
(The following is a bit of background: We have a project called FOO
that generates source code that eventually also needs to be compiled.
The generated source files end up in a *directory* that is known
CMake-time, but the *filenames* are not known until *build*-time. Thus
there is no way with in project FOO to create a target to compile
the generated source-code. (Doing FILE(GLOB...) within project FOO
will not work, because the globbing will take place at cmake-time, at
which time there are no files there). Therefore, together with the
generated source files we generate a CMakeLists.txt that defines a
*separate* project called BAR that contains a target to compile the
generated source code. Hence the question above -- how do I invoke the
all target in the BAR project in a way that works for all build-tools,
not only GNU-make?)
You should look at ctest --build-and-test. It can do what you want, and
invoke all build systems supported by CMake. It is used in the testing
of CMake. See CMake/Tests/CMakeLists.txt, and ctest --help for information.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] absolute include paths to resource compiler
Due to some weirdness in Visual Studio, I need to be able to give the
resource compiler an absolute path:
rc ... -I${CMAKE_SOURCE_DIR}/include
If I put
include_directories(${CMAKE_SOURCE_DIR}/include)
CMake converts the absolute path to a relative one.
What is the weirdness? It should work without a full path?
Building works, but the resource view in Visual Studio can for some
reason not locate the resource file (in
${CMAKE_SOURCE_DIR}/include). It seems as if Visual Studio does not
always expand relative paths the same way. The result is that we can't
edit our resource files in Visual Studio, since Visual Studio can't
find them.
--
/Jesper
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] How does ctest impose CVS checkout time?
Hello, Does anyone know how CTest is able to set the CVS checkout time (with the -D option I would guess) when I am the one that provides the CVS checkout command in my Ctest script file by setting CTEST_CVS_CHECKOUT or CTEST_CVS_COMMAND? Is the CVS checkout followed by some sort of 'cvs update -D ' command to set the date or something? This information is not being eched with 'ctest -S xxx -VV'. In my opinon, the verbose option should show *all* the major commands that are being made to the system so that I can debug problems when they occur. Can Ctest be modified to or a new super-verbose option be added to show me all of the major commands that it runs? Thanks, - Ross ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Pre-chekout configure vs. post-checkout configure
Hello, One of my nightly tests just failed last night because it tried to do a configure using outdated CMake files after I had enabled new options that caused it to fail. I need to understand how to make the nightly testing scripts more robust. Perhaps using extended Ctest scripting is the way to go? - Ross ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't get include() to work!
On Thu, Dec 4, 2008 at 6:53 AM, Bill Hoffman [EMAIL PROTECTED]wrote: Robert Dailey wrote: The problem isn't about MAC line endings not working. I could care less about line ending requirements, I'll go with whatever works. The main problem I have is that CMake didn't TELL me what the problem was. It should have said, Hey dummy, your line endings are unacceptable. Please change them to LINUX line endings. That would have saved me hours of time! Sure, it is just that you are the very first person to run into this in the last 8 years. I am curious how you created the file. I will try to come up with a way to detect mac files and issue an error. I used Notepad++ to edit my file. I didn't change line endings manually, so MAC must be set as the default for some reason. Notepad++ has some great syntax highlighting for CMake scripts. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How does ctest impose CVS checkout time?
Bartlett, Roscoe A wrote: Hello, Does anyone know how CTest is able to set the CVS checkout time (with the -D option I would guess) when I am the one that provides the CVS checkout command in my Ctest script file by setting CTEST_CVS_CHECKOUT or CTEST_CVS_COMMAND? Is the CVS checkout followed by some sort of 'cvs update -D ' command to set the date or something? This information is not being eched with 'ctest -S xxx -VV'. In my opinon, the verbose option should show *all* the major commands that are being made to the system so that I can debug problems when they occur. It comes from CTestConfig.cmake for the project. set(CTEST_NIGHTLY_START_TIME 21:00:00 EDT) Can Ctest be modified to or a new super-verbose option be added to show me all of the major commands that it runs? ctest --debug -VV -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Invoke a target on a separate project in a generic way?
2008/12/4 Bill Hoffman [EMAIL PROTECTED]:
Hugo Heden wrote:
Good day all,
I am looking for a way within a CMakeLists.txt make sure that:
-- at *build* time
-- cmake is invoked on a *separate* project, and then also the
all-target is invoked
How do I do that?
The following is a first rough sketch (that is not good enough, I
believe):
ADD_CUSTOM_TARGET(
build_separate_project
WORKING_DIRECTORY separate_project/build
COMMAND ${CMAKE_COMMAND} ../src
COMMAND ${CMAKE_BUILD_TOOL} all
)
-- The above only works for a ${CMAKE_BUILD_TOOL} that happens to
accept a commandline that contains a target and nothing else (like
GNU-make does).
So is there a more *generic* way to, at build time, invoke cmake and
then the all-target on a separate project?
(The following is a bit of background: We have a project called FOO
that generates source code that eventually also needs to be compiled.
The generated source files end up in a *directory* that is known
CMake-time, but the *filenames* are not known until *build*-time. Thus
there is no way with in project FOO to create a target to compile
the generated source-code. (Doing FILE(GLOB...) within project FOO
will not work, because the globbing will take place at cmake-time, at
which time there are no files there). Therefore, together with the
generated source files we generate a CMakeLists.txt that defines a
*separate* project called BAR that contains a target to compile the
generated source code. Hence the question above -- how do I invoke the
all target in the BAR project in a way that works for all build-tools,
not only GNU-make?)
You should look at ctest --build-and-test. It can do what you want, and
invoke all build systems supported by CMake. It is used in the testing of
CMake. See CMake/Tests/CMakeLists.txt, and ctest --help for information.
Aha, yes, that's it! Thank you!
/Hugo Heden
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to make ctest not buffer its output?
Good day all, I use ctest --build-and-test to do some stuff that takes a long time. It seems that ctest buffers the output of its subcommands so that nothing is written (to the terminal) until at the end. This is a little unconvenient -- as a human I feel more comfortable actually seeing that something is happening. Is there a way I can force ctest to not buffer the output of subcommands, but rather just flush it? Best regards Hugo Heden ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] list( LENGTH ) problem
Le Wed, 3 Dec 2008 10:09:56 -0600,
Robert Dailey [EMAIL PROTECTED] a écrit :
On Tue, Dec 2, 2008 at 3:00 PM, Alexander Neundorf
[EMAIL PROTECTED]wrote:
It expects a variable which holds a list:
set(myList foo bar)
list( LENGTH myList listlen )
message( ${listlen} )
(didn't test or check docs, but I think that should be it)
Why did you do:
list( LENGTH myList listlen )
instead of:
list( LENGTH ${myList} listlen )
This seems pretty inconsistent with how I pass variables into
functions in other places, like message() for example.
Nope it is consistent.
list command is working on the object list whereas
message is generally interested in the value of your object.
There is the same idea/issue/feature with if command which can
work either on content (i.e. value) or on the variable itself (object).
if(variable STRLESS string)
if(string STRLESS string)
I do attach a file for playing with value and object try
to execute it with cmake -P playing_with_value_and_object.cmake.
You may eventually find it interesting.
--
Erk
# classic VAR
SET(VALUE Value)
SET(NAME Name)
# use value for VAR name
SET(Toto.${VALUE} another value)
SET(Toto.${NAME} nice name)
# use those in message
MESSAGE(VALUE=${VALUE})
MESSAGE(NAME=${NAME})
MESSAGE(Toto.${VALUE}=${Toto.${VALUE}})
MESSAGE(Toto.${NAME}=${Toto.${NAME}})
# Now with list
SET(MyList1 a b c)
SET(MyList2 a d)
IF(UNIX)
SET(C MyList1)
ELSE(UNIX)
SET(C MyList2)
ENDIF(UNIX)
LIST(LENGTH ${C} len)
MESSAGE(len = ${len})
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] source_group() and solution directories
Hi, Is it possible to have source_group() place files into a solution directory? This would be a folder directly under the solution instead of inside of a project. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Why does dependency scanning in version 2.6 seem so slow?
On Wednesday 03 December 2008, Senanu Pearson wrote: Hi folks, Is there a way to speed up the dependency scan in version 2.6? I recently installed a new Linux OS (Mandriva 2009) which included an upgrade to cmake 2.6 (I _think_ I had version 2.4 before). However, when If I remember correctly, I think in some 2.2.x version the dependency scanning got slower, but since then has been optimized again (may have been related to the makefile generator version 2 or 3). So maybe if you updated from 2.0 there would be a slowdown, from 2.4 there shouldn't be. Patches to speed it up would of course be welcome :-) But I'm afraid that won't be very easy. Maybe it could be multithreaded to scan multiple files at once ? Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Getting a list of the defined CMake cache variables along with properties and documentation?
On Thursday 04 December 2008, Bartlett, Roscoe A wrote: Hello, Is there a way in a CMakeLists.txt file to get a list of all of the defined CMake cache variables, get their properties, and their documentation? I would like to have this so that I can build more general documentation for our CMake project. I could of course just parse the CMakeCache.txt file myself but if there is a way to do this in CMake then that might be better. Otherwise, I will need to create a tool that would do a configure, then read the CMakeCache.txt file and build documentation output like you would see for our current autotools build system. If you want documentation for your custom cmake modules, this is possible. You can run cmake with the --help-custom-modules argument and it will generate the documentation for your custom cmake modules. You just have to tell cmake where they are: $ cmake -DCMAKE_MODULE_PATH=/opt/kdelibs/share/apps/cmake/modules\ --help-custom-modules Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [Fwd: Re: Why does dependency scanning in version 2.6 seem so slow?]
On Thursday 04 December 2008, Jose Luis Blanco wrote: If this helps anyone, I'm working on a large project using CMake and in two different computers, both with the same version of Ubuntu and cmake, it is *REALLY SLOW* in only one of them while scanning dependencies, but it's not in the other laptop. (The slow dep. scanning is ~1 min. too) I'd be happy to help debugging this, because it's really annoying :-( Running it in valgrind/callgrind to get some profiling information may help. Do a make VERBOSE=1 and write down the command which does the dependency scanning (cmake -E cmake_depends or something) Then run this exact command with valgrind: $ valgrind --tool=callgrind cmake -E cmake_depends ...the remaining argsuments Using kcachegrind you can analyze the resulting log file very nicely. Do this on both the fast and the slow machine and see if there are significant differences. I think it won't show you if you hit I/O delay, e.g. caused by a network as Bill suspects. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to make ctest not buffer its output?
On Thursday 04 December 2008, Hugo Heden wrote: Good day all, I use ctest --build-and-test to do some stuff that takes a long time. It seems that ctest buffers the output of its subcommands so that nothing is written (to the terminal) until at the end. This is a little unconvenient -- as a human I feel more comfortable actually seeing that something is happening. Is there a way I can force ctest to not buffer the output of subcommands, but rather just flush it? Does ctest -VV do what you want ? It switches to extra verbose mode. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] general question on documenting modules using the new FooConfig.cmake files
Hi, I've got a general question. Regular cmake FindFoo.cmake modules are documented by putting the docs at the top of the file. This documentation should list the variables, macros etc. provided by that module. Now if I switch to using FooConfig.cmake files and just very simple FindFoo.cmake files (basically only for getting some nicer messages etc.), how do I do this then ? I still could put the documentation in the FindFoo.cmake file, but this documentation would be for stuff which is in the FooConfig.cmake file, which is loaded later. While this is no technical problem, there is the real problem that the contents of the FooConfig.cmake file can change, i.e. a new variable can be added. But this doesn't necessarily mean that also the FindFoo.cmake changes. But if it doesn't, then the documentation is out of date. So, what would you prefer where to put the documentation ? In the FooConfig.cmake file, which is relatively hidden ? Or in the FindFoo.cmake file, which can get out of sync to the contents of the FooConfig.cmake file ? Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Question about transitive dependencies
Hi, Currently I have 3 projects named A, B, and C. A and B are both static libraries, and C is an executable. B depends on A, and C depends on B via add_dependencies(). When I generate a visual studio 9 project from this setup, how will the libraries be linked? The way I want this to work is for C to link against both A and B, and B will not link against A (Since B's dependencies should transfer to C). Is there a way to accomplish this behavior? I want to avoid using target_link_libraries for the most part because it's redundant. I'm already specifying B as a dependency of C through add_dependency(), why should I have to list B's static library file as a dependency of C's executable? Can't CMake pull this information from the call to add_dependency()? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about transitive dependencies
On Thursday 04 December 2008, Robert Dailey wrote: Hi, Currently I have 3 projects named A, B, and C. A and B are both static libraries, and C is an executable. B depends on A, and C depends on B via add_dependencies(). When I generate a visual studio 9 project from this setup, how will the libraries be linked? The way I want this to work is for C to link against both A and B, and B will not link against A (Since B's dependencies should transfer to C). Is there a way to accomplish this behavior? I want to avoid using target_link_libraries for the most part because it's redundant. I'm already specifying B as a dependency of C through add_dependency(), why should I have to list B's static library file as a dependency of C's executable? Can't CMake pull this information from the call to add_dependency()? target_link_libraries(B A) ... target_link_libraries(C B) should do it. Doesn't it ? Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about transitive dependencies
Hello, This discussion is based on my knowledge of the Gnu Compiler Collection. My understanding of the linking process is that B will never link against A, because static libraries don't link against other static libraries. Library B will have unresolved symbols when linking C. You must therefore add a dependency between C and A. Therefore: C links against B and A B doesn't link against anything B needs the header information for the functions of A. I never use shared libraries, but I think the dynamic linker may need to resolve a dynamic B against a dynamic A. Juan On Thu, Dec 4, 2008 at 3:25 PM, Robert Dailey [EMAIL PROTECTED] wrote: Hi, Currently I have 3 projects named A, B, and C. A and B are both static libraries, and C is an executable. B depends on A, and C depends on B via add_dependencies(). When I generate a visual studio 9 project from this setup, how will the libraries be linked? The way I want this to work is for C to link against both A and B, and B will not link against A (Since B's dependencies should transfer to C). Is there a way to accomplish this behavior? I want to avoid using target_link_libraries for the most part because it's redundant. I'm already specifying B as a dependency of C through add_dependency(), why should I have to list B's static library file as a dependency of C's executable? Can't CMake pull this information from the call to add_dependency()? ___ 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] Question about transitive dependencies
Robert Dailey wrote: Hi, Currently I have 3 projects named A, B, and C. A and B are both static libraries, and C is an executable. B depends on A, and C depends on B via add_dependencies(). When I generate a visual studio 9 project from this setup, how will the libraries be linked? The way I want this to work is for C to link against both A and B, and B will not link against A (Since B's dependencies should transfer to C). Is there a way to accomplish this behavior? I want to avoid using target_link_libraries for the most part because it's redundant. I'm already specifying B as a dependency of C through add_dependency(), why should I have to list B's static library file as a dependency of C's executable? Can't CMake pull this information from the call to add_dependency()? Sounds like you should be using target_link_libraries instead of add_dependency. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about transitive dependencies
On Thu, Dec 4, 2008 at 3:38 PM, Bill Hoffman [EMAIL PROTECTED]wrote: Robert Dailey wrote: Hi, Currently I have 3 projects named A, B, and C. A and B are both static libraries, and C is an executable. B depends on A, and C depends on B via add_dependencies(). When I generate a visual studio 9 project from this setup, how will the libraries be linked? The way I want this to work is for C to link against both A and B, and B will not link against A (Since B's dependencies should transfer to C). Is there a way to accomplish this behavior? I want to avoid using target_link_libraries for the most part because it's redundant. I'm already specifying B as a dependency of C through add_dependency(), why should I have to list B's static library file as a dependency of C's executable? Can't CMake pull this information from the call to add_dependency()? Sounds like you should be using target_link_libraries instead of add_dependency. I use target_link_libraries for only the case when I'm linking against libraries that are not part of the CMake project itself. After a quick test I found that John Doe's description of how this functions is correct. I tried the following CMake script: cmake_minimum_required( VERSION 2.6 ) project( Z ) add_library( Z STATIC Z.cpp ) project( A ) add_library( A STATIC A.cpp ) add_dependencies( A Z ) project( B ) add_library( B STATIC B.cpp ) add_dependencies( B A;Z ) project( C ) add_executable( C C.cpp ) add_dependencies( C B ) In this case, visual studio shows C to be linking against Z, A, and B. Both A and B, however, do not link against Z, which is exactly what I wanted. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about transitive dependencies
On Thu, Dec 4, 2008 at 3:47 PM, David Cole [EMAIL PROTECTED] wrote:
I think you're looking at Visual Studio project dependencies and not link
dependencies. It should not build *without* target_link_libraries calls.
They are necessary to get correct linker command lines. add_dependencies
does not link any libraries to anything, it just guarantees project building
order...
However, visual studio's option to Link Library Dependencies is enabled
for project C, so this shows up as my command line for project C:
*/OUT:C:\IT\work\cmaketest\Debug\C.exe /VERSION:0.0 /INCREMENTAL /NOLOGO
/LIBPATH:.\Debug /LIBPATH:. /MANIFEST
/MANIFESTFILE:C.dir\Debug\C.exe.intermediate.manifest
/MANIFESTUAC:level='asInvoker' uiAccess='false' /DEBUG
/PDB:C:/IT/work/cmaketest/Debug/C.pdb /SUBSYSTEM:CONSOLE /DYNAMICBASE
/NXCOMPAT /IMPLIB:C:\IT\work\cmaketest\Debug\C.lib /ERRORREPORT:PROMPT
kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib comdlg32.lib advapi32.lib myClb.lib .\debug\b.lib
.\debug\z.lib .\debug\a.lib*
Notice that both b.lib, z.lib, and a.lib are linked to C here. I'm only
using add_dependencies() and this happens. You state that it only guarantees
project building order, but why (for visual studio, at least) is it
providing link dependencies as well? Is this just an artifact of visual
studio? Can I expect this behavior to be portable to other CMake outputs?
I've also noticed another weird behavior that I can't seem to work around.
I've modified the code I previously posted to this:
cmake_minimum_required( VERSION 2.6 )
link_directories( ${CMAKE_CURRENT_SOURCE_DIR} )
project( Z )
add_library( Z STATIC Z.cpp )
target_link_libraries( Z Zlb )
project( A )
add_library( A STATIC A.cpp )
add_dependencies( A Z )
project( B )
add_library( B STATIC B.cpp )
add_dependencies( B A Z )
target_link_libraries( B Blb Bfoo )
project( C )
add_executable( C C.cpp )
add_dependencies( C B )
target_link_libraries( C myClb )
If you look at the command line I pasted earlier for project C, notice that
only myClb.lib is on the command line. I'm expecting to see Blb.lib,
Bfoo.lib, and Zlb.lib there as well. If I go to project B's command line, I
only see this:
*/OUT:C:\IT\work\cmaketest\Debug\B.lib /NOLOGO*
It's not even linking against Blb.lib or Bfoo.lib! Why are these target link
libraries being ignored?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about transitive dependencies
On Thursday 04 December 2008, John Doe wrote: Hello, This discussion is based on my knowledge of the Gnu Compiler Collection. My understanding of the linking process is that B will never link against A, because static libraries don't link against other static libraries. Library B will have unresolved symbols when linking C. That's correct. You must therefore add a dependency between C and A. Therefore: C links against B and A B doesn't link against anything B needs the header information for the functions of A. That's also correct. But, if you do in cmake: target_link_libraries(staticLibB staticLibA) this will not really link (as it would for a shared lib), but it will nevertheless keep track of the dependencies. So when liking target_link_libraries(myApp staticLibB) cmake knows that it has to add staticLibA to the linker command. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about transitive dependencies
On Thu, Dec 4, 2008 at 4:06 PM, Alexander Neundorf [EMAIL PROTECTED]wrote: But, if you do in cmake: target_link_libraries(staticLibB staticLibA) this will not really link (as it would for a shared lib), but it will nevertheless keep track of the dependencies. So when liking target_link_libraries(myApp staticLibB) cmake knows that it has to add staticLibA to the linker command. But that's one of the things that really bothers me. This is that redundancy I was talking about earlier. If I do: add_dependencies( C B ) target_link_libraries( C staticLibB ) It's a bit pointless. For example, CMake should be smart enough to know that by adding a dependency to B, it should look at the library that it is outputting (In this case, staticLibB.lib) and add that to an implicit call to target_link_libraries(). I only want to use target_link_libraries() to link against external third party libraries that aren't explicitly represented as a project in my CMake build process. If I decide to change the output name for the static library B outputs, I'm forced to then revisit all of the target_link_libraries() calls and rename staticLibB. This is a management issue (amongst other things). ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [Fwd: Re: Why does dependency scanning in version 2.6 seem so slow?]
These are my results: All the details go below, but in two computers, both with cmake 2.6.0 (from the Ubuntu repositories), it takes ~ 50sec vs. 19sec to recompile when only one file changes... and the longest delay happens in the better PC, though the CPU's are very similar in speeds. Both cases are local file systems (through ntfs, but the same in both cases). In addition, I started with a fresh CMAKE_BINARY_DIR directory in both cases. Please, let me know if I can do any more logging. Regards, JL = PC #1 DESKTOP PC, QuadCore 2.4Ghz: = == touch'ing just one .cpp file in the project, the time make VERBOSE=1 gives: 49.882s cd /home/jlblanco/code/mrpt-release /usr/local/bin/cmake -E cmake_depends Unix Makefiles /home/jlblanco/code/mrpt-src /home/jlblanco/code/mrpt-src/src/core /home/jlblanco/code/mrpt-release /home/jlblanco/code/mrpt-release/src/core /home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/DependInfo.cmake --color= Most of the time goes in these 3 steps: Dependee /home/jlblanco/code/mrpt-src/src/core/math/CMatrix.cpp is newer than depender src/core/CMakeFiles/mrpt-core.dir/math/CMatrix.o. Clearing dependencies in /home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/depend.make. Clearing dependencies in /home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/depend.make. Scanning dependencies of target mrpt-core Longest task real0m49.882s user0m5.424s sys0m7.064s == without touching (just realizing there's nothing to do): 12.89s Most of the time goes in: cd /home/jlblanco/code/mrpt-release /usr/local/bin/cmake -E cmake_depends Unix Makefiles /home/jlblanco/code/mrpt-src /home/jlblanco/code/mrpt-src/src/core /home/jlblanco/code/mrpt-release /home/jlblanco/code/mrpt-release/src/core /home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/DependInfo.cmake --color= real0m12.896s user0m1.384s sys0m1.560s = PC # 2 LAPTOP PC, DualCore 2.0Ghz: = == touch'ing just one .cpp file in the project, the time make VERBOSE=1 gives: 18.78s Most of the tiime goes to: cd /home/jlblanco/code/mrpt-release /usr/bin/cmake -E cmake_depends Unix Makefiles /home/jlblanco/code/mrpt-src /home/jlblanco/code/mrpt-src/src/core /home/jlblanco/code/mrpt-release /home/jlblanco/code/mrpt-release/src/core /home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/DependInfo.cmake --color= Dependee /home/jlblanco/code/mrpt-src/src/core/utils/CMRPTImage.cpp is newer than depender src/core/CMakeFiles/mrpt-core.dir/utils/CMRPTImage.o. Clearing dependencies in /home/jlblanco/code/mrpt-release/src/core/CMakeFiles/mrpt-core.dir/depend.make. Scanning dependencies of target mrpt-core real0m18.788s user0m7.456s sys0m4.552s == without touching (just realizing there's nothing to do): 2.23s real0m2.234s user0m1.468s sys0m0.528s On Thu, Dec 4, 2008 at 4:02 AM, Bill Hoffman [EMAIL PROTECTED]wrote: Jose Luis Blanco wrote: If this helps anyone, I'm working on a large project using CMake and in two different computers, both with the same version of Ubuntu and cmake, it is *REALLY SLOW* in only one of them while scanning dependencies, but it's not in the other laptop. (The slow dep. scanning is ~1 min. too) I'd be happy to help debugging this, because it's really annoying :-( I wonder if it is hitting a network mount disk or something like that... Are the same versions of cmake identical binaries? -Bill -- ___ Jose-Luis Blanco-Claraco Phone: +34 952 132848 Dpto. Ingenieria de Sistemas y Automatica E.T.S.I. Telecomunicacion Fax: +34 952 133361 Universidad de Malaga Campus Universitario de Teatinos 29071 Malaga, Spain http://www.isa.uma.es/jlblanco ___ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about transitive dependencies
target_link_libraries takes target names as its arguments as well as full paths to libraries. Just use CMake target names in target_link_libraries calls and do NOT use add_dependencies for libraries. add_dependencies is very useful for custom targets and custom commands to guarantee build order. I have never heard of anybody else using it to add library-to-library or executable-to-library dependencies. target_link_libraries is really the way to go. On Thu, Dec 4, 2008 at 5:12 PM, Robert Dailey [EMAIL PROTECTED] wrote: On Thu, Dec 4, 2008 at 4:06 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: But, if you do in cmake: target_link_libraries(staticLibB staticLibA) this will not really link (as it would for a shared lib), but it will nevertheless keep track of the dependencies. So when liking target_link_libraries(myApp staticLibB) cmake knows that it has to add staticLibA to the linker command. But that's one of the things that really bothers me. This is that redundancy I was talking about earlier. If I do: add_dependencies( C B ) target_link_libraries( C staticLibB ) It's a bit pointless. For example, CMake should be smart enough to know that by adding a dependency to B, it should look at the library that it is outputting (In this case, staticLibB.lib) and add that to an implicit call to target_link_libraries(). I only want to use target_link_libraries() to link against external third party libraries that aren't explicitly represented as a project in my CMake build process. If I decide to change the output name for the static library B outputs, I'm forced to then revisit all of the target_link_libraries() calls and rename staticLibB. This is a management issue (amongst other things). ___ 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] Question about transitive dependencies
Robert Dailey wrote: On Thu, Dec 4, 2008 at 4:06 PM, Alexander Neundorf [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: But, if you do in cmake: target_link_libraries(staticLibB staticLibA) this will not really link (as it would for a shared lib), but it will nevertheless keep track of the dependencies. So when liking target_link_libraries(myApp staticLibB) cmake knows that it has to add staticLibA to the linker command. But that's one of the things that really bothers me. This is that redundancy I was talking about earlier. If I do: add_dependencies( C B ) target_link_libraries( C staticLibB ) It's a bit pointless. For example, CMake should be smart enough to know that by adding a dependency to B, it should look at the library that it is outputting (In this case, staticLibB.lib) and add that to an implicit call to target_link_libraries(). I only want to use target_link_libraries() to link against external third party libraries that aren't explicitly represented as a project in my CMake build process. If I decide to change the output name for the static library B outputs, I'm forced to then revisit all of the target_link_libraries() calls and rename staticLibB. This is a management issue (amongst other things). You are missing something. The output name has nothing to do with the name used in target_link_libraries. add_dependencies has nothing to do with linking. It adds an artificial depend between two targets to make sure one is built before the other one for whatever reason needed. If you want to link something, you should use target_link_libraries. For arguments to target_link_libraries you should use the name of the target. add_library(A ...) add_library(B ...) target_link_libraries(B A) add_executable(C ...) target_link_libraries(C B) The above will link C to B and A. The output names of B and A will be correctly used when linking C. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about transitive dependencies
On Thu, Dec 4, 2008 at 4:20 PM, Bill Hoffman [EMAIL PROTECTED]wrote: Robert Dailey wrote: On Thu, Dec 4, 2008 at 4:06 PM, Alexander Neundorf [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: But, if you do in cmake: target_link_libraries(staticLibB staticLibA) this will not really link (as it would for a shared lib), but it will nevertheless keep track of the dependencies. So when liking target_link_libraries(myApp staticLibB) cmake knows that it has to add staticLibA to the linker command. But that's one of the things that really bothers me. This is that redundancy I was talking about earlier. If I do: add_dependencies( C B ) target_link_libraries( C staticLibB ) It's a bit pointless. For example, CMake should be smart enough to know that by adding a dependency to B, it should look at the library that it is outputting (In this case, staticLibB.lib) and add that to an implicit call to target_link_libraries(). I only want to use target_link_libraries() to link against external third party libraries that aren't explicitly represented as a project in my CMake build process. If I decide to change the output name for the static library B outputs, I'm forced to then revisit all of the target_link_libraries() calls and rename staticLibB. This is a management issue (amongst other things). You are missing something. The output name has nothing to do with the name used in target_link_libraries. add_dependencies has nothing to do with linking. It adds an artificial depend between two targets to make sure one is built before the other one for whatever reason needed. If you want to link something, you should use target_link_libraries. For arguments to target_link_libraries you should use the name of the target. add_library(A ...) add_library(B ...) target_link_libraries(B A) add_executable(C ...) target_link_libraries(C B) The above will link C to B and A. The output names of B and A will be correctly used when linking C. In your sample code above, I noticed you didn't use add_dependencies(). Does target_link_libraries() guarantee build order when targets are specified instead of libraries? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 'unset' not in --help-commands-list (also, attn: neundorf)
Philip Lowman wrote: On Tue, Nov 18, 2008 at 6:39 PM, Matthew Woehlke snipped wrote: Need a bug opened for this or is it trivial enough to fix on the spot? unset appears to be in --help-commands and --help-command-list. Was this a bug? If so, how was it fixed? Not for me it doesn't? $ cmake --help-command unset cmake version 2.6-patch 2 Argument unset to --help-command is not a CMake command. Use --help-command-list to see all commands. $ rpm -q cmake cmake-2.6.2-1.fc10.x86_64 What version of cmake are you looking at? Maybe I am wrong what version introduces 'unset'? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Microsoft, electricity, network connectivity. For a secure system pick any two. -- Iain D Broadfoot (paraphrased, from cluefire.net) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] if(MATCHES) broken??
Matthew Woehlke wrote:
Bill Hoffman wrote:
The problem is that if(something MATCHES something) works for either
strings or variable names. The way that works is by checking to see
if there is a variable defined by the string given to if. Even if
that string is in quotes, it can still be treated like a variable.
So, in this case cmake looks up CFLAGS and finds that there is a
variable of that name, and uses that value for the MATCHES statement.
Basically ending up with if(happyjoy MATCHES CFLAGS). You can
verify this by commenting out set(CFLAGS happyjoy) so that CFLAGS does
not have a definition, then your code works.
Yes, I figured that out. Hmm... at least it's documented, if annoying.
After poking at this further, there seems to be a bug here... we've
established that 'if(CFLAGS MATCHES CFLAGS)' expands the variable on the
LHS. That being the case, then it seems - from my reading of the doc -
that 'if(CFLAGS STREQUAL CFLAGS)' should be doing likewise, i.e. both
should be false. Further, it seems that 'if(bar MATCHES CFLAGS)' does
*not* expand bar... why?
I agree this is confusing... Perhaps there should be some new if
arguments that are always string based, and never look up variables.
What about simply inhibiting expansion when the LHS is quoted? (I
guess the concern would be compatibility? But given that the current
behavior seems buggy - i.e. inconsistent - already...) Since variable
names can't contain spaces (ah, they can't, right? :-) ), it seems
reasonable that if you are trying to dereference a variable that is
supposed to contain the name of another variable, whose value you want
to use, that this seems to make sense.
OTOH, given that '${${bar}}' is a legal construct that does exactly what
you'd expect (namely, expand the variable whose name is the expansion of
bar), I'm inclined to question using implicit expansion at all. But...
it can be convenient, so maybe that would be too much. Inhibiting
expansion in quoted-strings seems reasonable, though. (After all,
who's putting things that are supposed to be variable names in quotes?)
ping?
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Microsoft, electricity, network connectivity. For a secure system pick
any two. -- Iain D Broadfoot (paraphrased, from cluefire.net)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about transitive dependencies
Robert Dailey wrote: In your sample code above, I noticed you didn't use add_dependencies(). Does target_link_libraries() guarantee build order when targets are specified instead of libraries? Yes. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] what is wrong with this snippet? (bug?)
Matthew Woehlke wrote:
set(!BANG wacky CACHE STRING FORCE)
set(var with space wacky CACHE STRING FORCE)
message(STATUS This is !BANG: ${!BANG})
message(STATUS This is var with space: ${var with space})
The above snippet (as expected) causes a CMake error. What's interesting
is that the error is in the message, not the set. More so, the variables
do indeed end up in the cache!
The utility of a variable that can't be referenced seems... dubious.
Should CMake prevent this?
(cmake 2.6-2)
ping?
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Microsoft, electricity, network connectivity. For a secure system pick
any two. -- Iain D Broadfoot (paraphrased, from cluefire.net)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] if(MATCHES) broken??
Matthew Woehlke wrote: ping? I have created a bug report: http://public.kitware.com/Bug/view.php?id=8226 No ETA right now. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] what is wrong with this snippet? (bug?)
Matthew Woehlke wrote:
Matthew Woehlke wrote:
set(!BANG wacky CACHE STRING FORCE)
set(var with space wacky CACHE STRING FORCE)
message(STATUS This is !BANG: ${!BANG})
message(STATUS This is var with space: ${var with space})
The above snippet (as expected) causes a CMake error. What's
interesting is that the error is in the message, not the set. More so,
the variables do indeed end up in the cache!
The utility of a variable that can't be referenced seems... dubious.
Should CMake prevent this?
(cmake 2.6-2)
ping?
Please create a bug entry. Also, don't create variables with odd
characters in them as CMake does not correctly warn that this is invalid
right now. :)
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] source_group() and solution directories
On Thu, Dec 4, 2008 at 4:48 PM, [EMAIL PROTECTED] wrote: Is it possible to have source_group() place files into a solution directory? This would be a folder directly under the solution instead of inside of a project. I'm confused, because I don't think of SOURCE_GROUP() as placing any files in any directory. Instead, you need to call ADD_EXECUTABLE or ADD_LIBRARY to create a Visual Studio project file (DSP or VCPROJ), and all SOURCE_GROUP does is to specify which file names are in one of the folders described within that DSP or VCPROJ file. And of course the DSP or VCPROJ file specifies many different kinds of files that Visual Studio will produce. I've already asked the mailing list how to control where each one of _those_ files will be written. See my message in the list archive: http://www.cmake.org/pipermail/cmake/2008-December/025803.html If this has anything to do with what you're requesting, maybe we should combine the two requests. By the way, I've been following your other emails, and they remind me of some of what I went through when I first tried to apply CMake to an already existing software project about five years ago. (Yes, it did ultimately work and we've been using it on that project ever since.) Thanks for getting back with me David. By directories I mean Solution Folders, sorry for the confusion. This is a feature that allows you to add Folders to the solution. This has nothing to do with projects. You can add files to these solution folders. Solution folders are at the same level tree-wise as projects are (Directly under the solution). There are a couple of projects that I have that do not have any implementation files (Don't ask why lol). For these, I need solution folders since creating a project for these won't work- A project needs at least 1 CPP file to be usable. I'm hoping source_group() can be used without any project and simply add solution folders to the solution. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] if(MATCHES) broken??
Bill Hoffman wrote: Matthew Woehlke wrote: ping? I have created a bug report: http://public.kitware.com/Bug/view.php?id=8226 No ETA right now. Ok, thanks. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Microsoft, electricity, network connectivity. For a secure system pick any two. -- Iain D Broadfoot (paraphrased, from cluefire.net) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] what is wrong with this snippet? (bug?)
Bill Hoffman wrote:
Matthew Woehlke wrote:
Matthew Woehlke wrote:
set(!BANG wacky CACHE STRING FORCE)
set(var with space wacky CACHE STRING FORCE)
message(STATUS This is !BANG: ${!BANG})
message(STATUS This is var with space: ${var with space})
The above snippet (as expected) causes a CMake error. What's
interesting is that the error is in the message, not the set. More
so, the variables do indeed end up in the cache!
The utility of a variable that can't be referenced seems... dubious.
Should CMake prevent this?
(cmake 2.6-2)
ping?
Please create a bug entry.
Done [1], and thanks. I wasn't sure how this was supposed to work.
Also, don't create variables with odd
characters in them as CMake does not correctly warn that this is invalid
right now. :)
No worries, I was actually hoping the set would fail also. As mentioned
in [2] I was trying to work around bug 8226 [3], and wanted to verify
that such variables were invalid. So, I hope they will stay invalid ;-).
(But yes, it would be good for SET to fail, as well as expansion.)
1: http://public.kitware.com/Bug/view.php?id=8228
2: http://permalink.gmane.org/gmane.comp.programming.tools.cmake.user/17555
3: http://public.kitware.com/Bug/view.php?id=8226
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Microsoft, electricity, network connectivity. For a secure system pick
any two. -- Iain D Broadfoot (paraphrased, from cluefire.net)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] source_group() and solution directories
By directories I mean Solution Folders, sorry for the confusion. This is a feature that allows you to add Folders to the solution. This has nothing to do with projects. You can add files to these solution folders. Solution folders are at the same level tree-wise as projects are (Directly under the solution). There are a couple of projects that I have that do not have any implementation files (Don't ask why lol). For these, I need solution folders since creating a project for these won't work- A project needs at least 1 CPP file to be usable. So, for example, I open a .SLN file generated by CMake, look in the Solution Explorer pane of Visual Studio 2008, and see the infamous ALL_BUILD in the list between two of my projects. (I haven't opened any of these projects yet, so the entire list is at one level of indentation below the Solution icon.) ALL_BUILD shows up in this list because there's a file ALL_BUILD.vcproj in the same directory as my .SLN file in the filesystem. And there are no .CPP files that are built by ALL_BUILD itself (though of course ALL_BUILD depends on projects that do build .CPP files). I tend to call ALL_BUILD a project because it shows up at the same level of the hierarchy as all the projects in Solution Explorer and because the proj in the filename ALL_BUILD.vcproj suggests the word project to me. But I suppose technically I should call it a target. Anyway, I'm pretty sure now I completely misread the earlier email. Not so sure I read it correctly this time, though. I'm hoping source_group() can be used without any project and simply add solution folders to the solution. Actually this seems counterintuitive to me. There's no other case in which SOURCE_GROUP by itself would cause a .VCPROJ file to be generated. And the icon that shows up in Solution Explorer looks like a little manila file folder (the kind you could buy at a stationery store in 1970, before some genius decided it was a synonym for filesystem directory), whereas the icon for a project in Solution Explorer looks completely different (but is identical to the icon for ALL_BUILD). I guess one could question why one level of the hierarchy is different from all other levels, but it _is_ different (blame the designers of Visual Studio) and I think it would be too confusing to pretend otherwise. Also, you specifically don't want any source files in the thing you're creating, which seems already to say it's not a source group. It seems to me that what you want is a command that you can use instead of ADD_LIBRARY or ADD_EXECUTABLE to create a new target. Actually I think there are some such commands; maybe one of them does what you want (but if so, someone else will have to explain it, because I don't know how to use any of those commands). Otherwise, it seems to me you need a new command. David ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] MSVC71 WholeProgramOptimization flags (/LTCG and /GL)
Hi, I would like to reopen issue #0006794 dealing with this linker warning that is still present for MSVC 7.1 static library builds: Linking CXX static library ..\build\MT-DLL\Util-SL.lib XMLWriter.cpp.obj : warning LNK4218: non-native module found; restarting I did some more investigation of this problem, and I think I've nailed it down now. I thought it was the missing WholeProgramOptimization element that was causing the warning, when in fact it is the missing /LTCG flag that should be in the Librarian additional command-line options. I realize that for a static library project the linker flags are not included in the generated project file, but this should be an exception case to that rule. As a general rule of thumb, if the /GL compiler flag is passed to a static library project, then the /LTCG flag should be passed to the Librarian AdditionalOptions line. Tool Name=VCLibrarianTool AdditionalOptions=/LTCG Thank you for your time and effort. I appreciate the hard work that you have all done to make and keep CMake a high-quality software product. Sincerely, Luke ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Forcing CMake to place targets in directories?
Hi,
I'm trying to use set_target_properties() to make CMake place generated
vcproj files in a subdirectory of ${CMAKE_CURRENT_SOURCE_DIR}. This isn't
working and I'm not sure what I'm doing wrong. Below is what I'm doing:
set( test_project_name ${project_name}_test_${test_name} )
project( ${test_project_name} )
source_group( ${file} )
add_executable( ${test_project_name} ${file} )
set_target_properties( ${test_project_name} PROPERTIES
OUTPUT_NAME test_projects/${test_project_name} )
My project should be getting placed inside of a test_projects subdirectory,
right?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 'unset' not in --help-commands-list (also, attn: neundorf)
On Thu, Dec 4, 2008 at 5:36 PM, Matthew Woehlke [EMAIL PROTECTED] wrote: Philip Lowman wrote: On Tue, Nov 18, 2008 at 6:39 PM, Matthew Woehlke snipped wrote: Need a bug opened for this or is it trivial enough to fix on the spot? unset appears to be in --help-commands and --help-command-list. Was this a bug? If so, how was it fixed? Not for me it doesn't? $ cmake --help-command unset cmake version 2.6-patch 2 Argument unset to --help-command is not a CMake command. Use --help-command-list to see all commands. $ rpm -q cmake cmake-2.6.2-1.fc10.x86_64 What version of cmake are you looking at? Maybe I am wrong what version introduces 'unset'? As far as I know the unset command hasn't been backported to the CMake 2.6.x branch. If you want to use it in your scripts you probably would need to be running CVS CMake. -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to make ctest not buffer its output?
Alexander Neundorf wrote: On Thursday 04 December 2008, Hugo Heden wrote: Good day all, I use ctest --build-and-test to do some stuff that takes a long time. It seems that ctest buffers the output of its subcommands so that nothing is written (to the terminal) until at the end. This is a little unconvenient -- as a human I feel more comfortable actually seeing that something is happening. Is there a way I can force ctest to not buffer the output of subcommands, but rather just flush it? Does ctest -VV do what you want ? It switches to extra verbose mode. I submitted this some time ago as bug 0005814. I don't believe there is a way to view the output until the test finishes. -- Daniel ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Forcing CMake to place targets in directories?
CMAKE_CURRENT_SOURCE_DIR denotes your source tree and NOT the build
tree. Are you building in your source tree instead of using a
dedicated build directory?
To answer your code you are setting the output directory of where the
executable will be placed in a directory called test_projects at the
top level of your build tree.
Mike Jackson
On Thu, Dec 4, 2008 at 7:40 PM, Robert Dailey [EMAIL PROTECTED] wrote:
Hi,
I'm trying to use set_target_properties() to make CMake place generated
vcproj files in a subdirectory of ${CMAKE_CURRENT_SOURCE_DIR}. This isn't
working and I'm not sure what I'm doing wrong. Below is what I'm doing:
set( test_project_name ${project_name}_test_${test_name} )
project( ${test_project_name} )
source_group( ${file} )
add_executable( ${test_project_name} ${file} )
set_target_properties( ${test_project_name} PROPERTIES
OUTPUT_NAME test_projects/${test_project_name} )
My project should be getting placed inside of a test_projects subdirectory,
right?
___
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] Forcing CMake to place targets in directories?
I wanted my vcproj files to be placed in test_projects. Any idea how I can
make this happen?
On Thu, Dec 4, 2008 at 8:30 PM, Mike Jackson [EMAIL PROTECTED]wrote:
CMAKE_CURRENT_SOURCE_DIR denotes your source tree and NOT the build
tree. Are you building in your source tree instead of using a
dedicated build directory?
To answer your code you are setting the output directory of where the
executable will be placed in a directory called test_projects at the
top level of your build tree.
Mike Jackson
On Thu, Dec 4, 2008 at 7:40 PM, Robert Dailey [EMAIL PROTECTED] wrote:
Hi,
I'm trying to use set_target_properties() to make CMake place generated
vcproj files in a subdirectory of ${CMAKE_CURRENT_SOURCE_DIR}. This isn't
working and I'm not sure what I'm doing wrong. Below is what I'm doing:
set( test_project_name ${project_name}_test_${test_name} )
project( ${test_project_name} )
source_group( ${file} )
add_executable( ${test_project_name} ${file} )
set_target_properties( ${test_project_name} PROPERTIES
OUTPUT_NAME test_projects/${test_project_name} )
My project should be getting placed inside of a test_projects
subdirectory,
right?
___
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
