Re: [CMake] Coverage without bullseye?
On Dec 18, 2007 4:09 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Salvatore Iovene wrote: Hi, from http://www.cmake.org/Wiki/CTest:Coverage I seem to understand that coverage can be analyzed in the dart dashboard only by purchasing Bullseye. Is that true? If not, how to submit coverage analysis to the dashboard? Uhhh... How about the first paragraph of that wiki page: http://www.cmake.org/Wiki/CTest:Coverage#Coverage_With_C.2B.2B Currently, you can do coverage with gcc gcov or bullseye (in CVS CMake only). See the Coverage section here for examples: http://public.kitware.com/dashboard.php?name=cmake Here is a ctest script used to do gcc coverage: http://www.cmake.org/Testing/Sites/dash17.kitware/Linux-g++4.0/20071218-0100-Nightly/Notes.html Thanks, I'll try that. In the meantime I have another related question: some of my test are actually wrapped inside a python script. The python script will be run from ctest (as I added it with ADD_TEST) and it will spawn an executable built by cmake with the compiler options for coverage. Will the coverage report work in this case? Thanks! -- Salvatore Iovene http://www.iovene.com/ Key Fingerprint: 5647 944D D5AD 2E87 00B4 7D54 2864 359D FF20 16D8 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMAKE] Exclude Files From Clean Target
Hello I've got following question: Is there any way to exclude some particular files from clean target (affected files were generated using ADD_CUSTOM_COMMAND). Going through the CMAKE documentation I noticed that it is possible to add file to clean target, but i couldn't find anything regarding exclusion of file from clean target. Currently, the only way to do that for me is to, externally edit generated cmake files, and cut entries regarding files to be excluded from clean. Thanks in advance Marcin begin:vcard fn:Marcin Szczur n:Szczur;Marcin email;internet:[EMAIL PROTECTED] version:2.1 end:vcard ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Multiple executables sharing object files
Hi all, is there anything new regarding this issue : http://www.cmake.org/pipermail/cmake/2005-September/007271.html This is a real problem, and the static library hack doesn't work well if you have many executables that don't all use all the object files : changing one single file will cause a massive relink which is very slow. So is there a way around this? Is there a way to turn the executable.dir feature off? Thank you! joel ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CHECK_CXX_COMPILER_FLAG(-fprofile-arcs HAVE_FPROFILE_ARCS_FLAG)
How come this configure check fails for my gcc? $ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) After the line in the subject, HAVE_FPROFILE_ARCS_FLAG is OFF, even tho the compiler is supposed to have that flag. Thanks! -- Salvatore Iovene http://www.iovene.com/ Key Fingerprint: 5647 944D D5AD 2E87 00B4 7D54 2864 359D FF20 16D8 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Parsing cmake command line parameters
Gonzalo Garramuño wrote:
Alexander Neundorf wrote:
Yes.
In KDE we have the macro MACRO_OPTIONAL_FIND_PACKAGE(), which adds an
option around the find_package() call:
http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/MacroOptionalFindPackage.cmake?revision=520790view=markup
Beside that, it is really just a matter of syntax whether you do
--enable-build-this
or -DENABLE_BUILD_THIS=TRUE
No, it isn't *just* a matter of syntax (which is also horrible, btw). It
is also a matter of documentation. -DENABLE_BUILD_THIS is documented
nowhere. configure --enable-build-this is documented if you run it
without any flag.
But... what if we have this extreme case?
IF(${CMAKE_BUILD_TYPE} STREQUAL Debug)
add_command_line_parameter(whatever)
ENDIF()
So? You don't get the option if you don't run a debug build. As simple
as that. A better syntax for add_option would be:
add_option( NAME TYPE HELP [OPTS] )
with OPTS being:
CONFIGURATION Debug
REQUIRED someotheroption
That avoids the need for if-thens.
I have (currently) two ideas:
either a special file, e.g. CMakeCustomArgs.txt, which in some way
sets up the custom command line parameters.
Yuck!
Or have a cmake modules, which handles this stuff, and which also
creates a custom target help-args or something like that, which
prints the available args. This would not be available before cmake
has successfully run.
Yuck! Why wouldn't it be available? Have you guys used premake at all?
The premake.lua is ALWAYS read. If no parameter is passed, there's a
dry run of the file, and help with options get spit.
It is gorgeous.
Sure, lua runs 10 times faster than the cmake language does, but that's
a different story.
I don't think this has anything to do with speed. To find all the
options in a project you have to parse the entire project, no way around
it. The speed problem comes in because of try-compile/try-run stuff.
Just parsing cmake is fast. But, if we run the compiler 100 times then
well it has NOTHING to do with language! If we don't run all the try
stuff, then we can not accurately parse the while project as variables
will be set. The real answer is that the command line is a poor
interface to cmake projects. The new QT GUI is a much better way to go.
Due to the iterative nature of the cmake process running cmake once on
a project may run differently than running it twice on the project.
ccmake and the GUI's avoid this problem by not allowing generation of
projects until there are no new options. But, please, please stop
trying to make this a language issue!
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Parsing cmake command line parameters
Bill Hoffman escreveu: will be set. The real answer is that the command line is a poor interface to cmake projects. The new QT GUI is a much better way to go. Don't say that... I think that a command line interface capability should be pursued, even if it's non-optimal. God knows if someone have to call cmake within a shell script. Presenting a ccmake screen in this situation is not acceptable. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] single source cross-compilation
Is it possible to support different compilers and options from the same source tree? If so, how? TIA -- Fernando Cacciola SciSoft http://fcacciola.50webs.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: General modernization facility
I wonder if the cmake developers are following this thread, given its importance... ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
On Dec 19, 2007 7:34 AM, Joël Schaerer [EMAIL PROTECTED] wrote: Hi all, is there anything new regarding this issue : http://www.cmake.org/pipermail/cmake/2005-September/007271.html http://www.cmake.org/Wiki/CMake_FAQ#Does_that_mean_I_have_to_build_all_my_library_objects_twice.2C_once_for_shared_and_once_for_static.3F.21__I_don.27t_like_that.21 Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
I have read this FAQ entry, but it doesn't seem to adress my issue at all... joel Quoting Brandon Van Every [EMAIL PROTECTED]: On Dec 19, 2007 7:34 AM, Joël Schaerer [EMAIL PROTECTED] wrote: Hi all, is there anything new regarding this issue : http://www.cmake.org/pipermail/cmake/2005-September/007271.html http://www.cmake.org/Wiki/CMake_FAQ#Does_that_mean_I_have_to_build_all_my_library_objects_twice.2C_once_for_shared_and_once_for_static.3F.21__I_don.27t_like_that.21 Cheers, Brandon Van Every ___ 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] single source cross-compilation
El Wednesday 19 December 2007 15:36:49 Fernando Cacciola escribió: Is it possible to support different compilers and options from the same source tree? If so, how? This behaviour is present by default, I think: http://www.cmake.org/Wiki/CMake_FAQ#Out-of-source_build_trees ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
On Dec 19, 2007 10:47 AM, Joël Schaerer [EMAIL PROTECTED] wrote: I have read this FAQ entry, but it doesn't seem to adress my issue at all... Did you read http://www.cmake.org/Bug/view.php?id=5155 ? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: General modernization facility
On Dec 18, 2007 8:32 PM, Rodolfo Lima [EMAIL PROTECTED] wrote: Brandon Van Every escreveu: We would have to guarantee that version 2.4.7 executes correctly every script made up till now. I don't see how we could. Well, Kitware has always been concerned with backward compatibility, so every script out there would work with cmake-2.4.7. I'd also throw cmake-cvs in the mix, since they still fight hard to maintain backward compatibility. The author may have been completely unaware of the potential of the error condition, having never seen the circumstances in which the error occurs. We don't know that I wrote this using 2.4.7 means I want it frozen for 2.4.7. Let's even say, for sake of argument, that you provided an interface for the author to state exactly that. version_freeze(2.4.7). It still may not be a good idea, because the author may not have full knowledge of the consequences of his decision. But if you correct the behaviour, the script wouldn't work as expected. Is this a good thing? We don't want things to work as expected, we want things to work correctly. Can you create an example of such error condition? What if VERBATIM behavior becomes easier to work with? Or quoting behavior in corner cases? What if macros no longer consume double the number of escapes? What if ^ and $ start matching line endings instead of the beginning and end of the file? We don't know how much the author knew about the code he was writing. It would be better to handle variations of behavior according to the specific feature, rather than by version number, so that the author can tell us what he wanted. set_property(GLOBAL PROPERTIES CMAKE_MATCH_LINE_ENDINGS TRUE). I don't think we need to tie disruptive features to version numbers. I want set_property(GLOBAL PROPERTIES CMAKE_REQUIRE_BOOL TRUE). I'm willing to wait a loong time for it to become a default CMake behavior. I think include(Modern) is a good idea in principle, for people who want to use a well-defined collection of forward looking behaviors. The idea may need refinement in practice, but the general idea is opt in. Not tie my hands. If you turn something into default behavior, it'll break backward compatibility. Eventually that's acceptable. And as time goes by, the amount of disruptive features tends to grow. In the future to write a script I would have to write lot of set_property(GLOBAL PROPERTIES CMAKE_REQUIRE...)... That's what include(Modern) is for. You can look inside of include(Modern) to see what it specifies. That's what better documentation is for. It'd be better to specify the version of cmake I'm working on and that's it. No it isn't. It doesn't identify the specific behaviors that have changed. PS: feel free to correct any English mistakes I make. I won't learn if I keep writing wrongly. Haven't noticed any. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Lua performance
On Dec 19, 2007 1:52 AM, Gonzalo Garramuño [EMAIL PROTECTED] wrote: Sure, lua runs 10 times faster than the cmake language does, but that's a different story. So what's the story? Can you substantiate that? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Parsing cmake command line parameters
On Dec 19, 2007 9:09 AM, Bill Hoffman [EMAIL PROTECTED] wrote: However, this has been discussed many times over the years, and I still don't think a good solution has been found. Worse Is Better. From a marketing standpoint, this issue could have been solved a long time ago. You want people coming from the Autoconf world to get enough of a warm squishy feeling that they stick with CMake. Over time they learn how to use CMake properly, using CMakeSetup / CCMake, and forget their command line ways. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Next edition of Mastering CMake?
Hi, Is the next edition of Mastering CMake still planned for January 2008? I need to get at least another copy for work and maybe some teammates would be interested in it too. Cheers, David. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Calling a dynamically created macro
On Dec 18, 2007 9:50 PM, Rodolfo Lima [EMAIL PROTECTED] wrote: Is there a way to call a dynamically created macro name? You could use a macro to generate a CMake script containing a macro, and then call that script. :-) Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
On Dec 19, 2007 11:08 AM, Joel Schaerer [EMAIL PROTECTED] wrote: Thanks a lot. This is a real issue since compiling everything two or ten times just for the sake of it is *not* efficient. We are currently considering switching back to makefiles and a custom VS project because of this. I'd be happy to see your comments on this in the bug report. It's not going to get action unless someone other than myself lights a match under the issue. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Next edition of Mastering CMake?
David Lázaro Saz wrote: Hi, Is the next edition of Mastering CMake still planned for January 2008? I need to get at least another copy for work and maybe some teammates would be interested in it too. Yes, it is. It is currently at the printers. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
Brandon Van Every wrote: On Dec 19, 2007 11:08 AM, Joel Schaerer [EMAIL PROTECTED] wrote: Thanks a lot. This is a real issue since compiling everything two or ten times just for the sake of it is *not* efficient. We are currently considering switching back to makefiles and a custom VS project because of this. Maybe I am missing something, but why not create a static library and share it with the executables? Why try to reuse object files? CMake makes it very easy to create static libraries and link them to executables. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
Maybe I am missing something, but why not create a static library and share it with the executables? Why try to reuse object files? CMake makes it very easy to create static libraries and link them to executables. -Bill Because then you have to relink all executables each time you change one of the library files, even the ones that don't rely on that file. Which isn't efficient either. Say you have 100 library files, and 30 executables, which depend on average on 20 library files. Using a intermediary static library is not going to help you... Object files were probably created exactly for this, so they could be shared between multiple targets without being rebuilt needlessly. Why exactly isn't there an option to share the build directory between targets, like it was the standard behavior prior to 2005? joel ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- Joël Schaerer PhD. Student Advisors: Patrick Clarysse, Isabelle Magnin CREATIS-LRMN, UMR CNRS 5220, Inserm U630 INSA de Lyon 7 rue Jean Capelle bat. Blaise Pascal, 4ème étage F-69621 Villeurbanne CEDEX France Tel (+33) 4 72 43 63 06 Fax (+33) 4 72 43 85 26 http://www.creatis.insa-lyon.fr ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Multiple executables sharing object files
I work on a similarly large project and have found that building shared libraries for development is much faster (in terms of compile/link time) when making small changes (working in Visual Studio). Nightly or test builds can use static libraries to produce single executables. Provided you have setup suitable declspec macros etc, it is easy to switch between static or shared using the BUILD_SHARED_LIBS cmake option. Mike Maybe I am missing something, but why not create a static library and share it with the executables? Why try to reuse object files? CMake makes it very easy to create static libraries and link them to executables. -Bill Because then you have to relink all executables each time you change one of the library files, even the ones that don't rely on that file. Which isn't efficient either. Say you have 100 library files, and 30 executables, which depend on average on 20 library files. Using a intermediary static library is not going to help you... Object files were probably created exactly for this, so they could be shared between multiple targets without being rebuilt needlessly. Why exactly isn't there an option to share the build directory between targets, like it was the standard behavior prior to 2005? joel ___ 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] Multiple executables sharing object files
On Dec 19, 2007 11:28 AM, Bill Hoffman [EMAIL PROTECTED] wrote: Maybe I am missing something, but why not create a static library and share it with the executables? The end product may not be an executable, it may be a static library. A static library cannot include another static library. I came up with a hack to find CMake's objects and reuse them, so that the user of a static library would not have to add additional link flags. In particular, I wanted the user to be able to specify -lchicken, and not have to specify -lchicken -lpcre. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Calling a dynamically created macro
On Wednesday 19 December 2007, Brandon Van Every wrote: On Dec 18, 2007 9:50 PM, Rodolfo Lima [EMAIL PROTECTED] wrote: Is there a way to call a dynamically created macro name? You could use a macro to generate a CMake script containing a macro, and then call that script. :-) Yes, dynamically creating macro names isn't supported. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
On Wednesday 19 December 2007, Joel Schaerer wrote: Maybe I am missing something, but why not create a static library and share it with the executables? Why try to reuse object files? CMake makes it very easy to create static libraries and link them to executables. -Bill Because then you have to relink all executables each time you change one of the library files, even the ones that don't rely on that file. Which isn't You could organize your static libs so that the executables only link to what they need. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] single source cross-compilation
On Wednesday 19 December 2007, Alberto Luaces wrote: El Wednesday 19 December 2007 15:36:49 Fernando Cacciola escribió: Is it possible to support different compilers and options from the same source tree? If so, how? This behaviour is present by default, I think: http://www.cmake.org/Wiki/CMake_FAQ#Out-of-source_build_trees Yes, you can build one source tree multiple times out-of-source, but in each build tree you can only use one toolchain (or you hack around it, which brings problems). Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Lua performance
Brandon Van Every escreveu: On Dec 19, 2007 1:52 AM, Gonzalo Garramuño [EMAIL PROTECTED] wrote: Sure, lua runs 10 times faster than the cmake language does, but that's a different story. So what's the story? Can you substantiate that? There's an implementation of cmake with lua at http://www.vtk.org/Wiki/CMake:Experiments_With_Lua, it might be interesting to compare both. What I know is that, using a profiler (oprofile, on linux), in a big project cmake spends 5% of its execution time parsing the CMakeLists.txt (done by flex-generated code). It's not too much, IMHO. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: General modernization facility
Brandon Van Every escreveu: We don't want things to work as expected, we want things to work correctly. This is getting nowhere... Can you create an example of such error condition? What if VERBATIM behavior becomes easier to work with? Or quoting behavior in corner cases? What if macros no longer consume double the number of escapes? What if ^ and $ start matching line endings instead of the beginning and end of the file? We don't know how much the author knew about the code he was writing. It would be better to handle variations of behavior according to the specific feature, rather than by version number, so that the author can tell us what he wanted. set_property(GLOBAL PROPERTIES CMAKE_MATCH_LINE_ENDINGS TRUE). The solution I proposed solve these problems. If I write a script where my cmake matches ^ to line endings, I'd expect this behavior, and my script would work correctly as I, the developer, expected. Cmake may afterwards change this behavior, and when running scripts for a certain version range, do the old way. From the top version onwards, do the new way. If you turn something into default behavior, it'll break backward compatibility. Eventually that's acceptable. Maybe not... a solution the maintains complete backward compatibility should do it always to cope with legacy scripts. At least I think that's cool. That's what include(Modern) is for. You can look inside of include(Modern) to see what it specifies. That's what better documentation is for. So maybe one day we will have include(Modern), then include(Moderner), then include(Modernerst), then include(ÜberModern),... I think it's better to stick to version number designators. It'd be better to specify the version of cmake I'm working on and that's it. No it isn't. It doesn't identify the specific behaviors that have changed. Sorry, I cannot express myself clearer than I did in English, if someone here speaks Portuguese, please step in :) Brandon, I think it does. By 'identify the specific behaviors that have changed' you mean have a documentation of what has changed? It's up to Kitware to decide if something new breaks compatibility or not. If it does, a simple if clause would make cmake work the old way with old scripts and the new way with new scripts. I can't explain this any better... Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: single source cross-compilation
Alexander Neundorf wrote: On Wednesday 19 December 2007, Alberto Luaces wrote: El Wednesday 19 December 2007 15:36:49 Fernando Cacciola escribió: Is it possible to support different compilers and options from the same source tree? If so, how? This behaviour is present by default, I think: http://www.cmake.org/Wiki/CMake_FAQ#Out-of-source_build_trees Yes, you can build one source tree multiple times out-of-source, but in each build tree you can only use one toolchain (or you hack around it, which brings problems). Right, what I meant to ask was precisely that.. if there was some additional support beyond out of source builds. Fernando ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
Quoting Alexander Neundorf [EMAIL PROTECTED]: On Wednesday 19 December 2007, Joel Schaerer wrote: Maybe I am missing something, but why not create a static library and share it with the executables? Why try to reuse object files? CMake makes it very easy to create static libraries and link them to executables. -Bill Because then you have to relink all executables each time you change one of the library files, even the ones that don't rely on that file. Which isn't You could organize your static libs so that the executables only link to what they need. Yeah, you could even create one static library per executable... Awesome! What was the problem with putting all the object files in the same directory, again? Shouldn't that be an option, at least? It would be SO much easier than all the dirty hacks I'm being proposed... joel Alex ___ 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] Multiple executables sharing object files
On Wednesday 19 December 2007, you wrote: ... Yeah, you could even create one static library per executable... Awesome! What was the problem with putting all the object files in the same directory, again? Shouldn't that be an option, at least? It would be SO much easier than all the dirty hacks I'm being proposed... Different targets may be compiled with different compiler flags, defines, etc. So the object files for the same source files can differ. This is used in some projects. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
Quoting Alexander Neundorf [EMAIL PROTECTED]: On Wednesday 19 December 2007, you wrote: ... Yeah, you could even create one static library per executable... Awesome! What was the problem with putting all the object files in the same directory, again? Shouldn't that be an option, at least? It would be SO much easier than all the dirty hacks I'm being proposed... Different targets may be compiled with different compiler flags, defines, etc. So the object files for the same source files can differ. This is used in some projects. Of course this is subjective, but having this questionnably useful feature (I understand it must be useful for some big projects, but for normal small to mid-sized projects, I really don't see any use for that) at the expense of much increased compilation time should be an option (and if you ask me, should be turned off by default). Alex ___ 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] Multiple executables sharing object files
One other very good reason, too: Same target may have two source files of the exact same name, but they exist in different directories (Abc/Object.cxx and Def/Object.cxx). In that case, the object files will be further hidden in subdirectories to avoid two files in the object files directory from having a name collision. On 12/19/07, Alexander Neundorf [EMAIL PROTECTED] wrote: On Wednesday 19 December 2007, you wrote: ... Yeah, you could even create one static library per executable... Awesome! What was the problem with putting all the object files in the same directory, again? Shouldn't that be an option, at least? It would be SO much easier than all the dirty hacks I'm being proposed... Different targets may be compiled with different compiler flags, defines, etc. So the object files for the same source files can differ. This is used in some projects. Alex ___ 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] Multiple executables sharing object files
Quoting David Cole [EMAIL PROTECTED]: One other very good reason, too: Same target may have two source files of the exact same name, but they exist in different directories (Abc/Object.cxx and Def/Object.cxx). In that case, the object files will be further hidden in subdirectories to avoid two files in the object files directory from having a name collision. Does that really justify multiplying compilation time by 2 or more? Who would want multiple files with the same name in the same project anyways? Plus, you could very well create a tree structure in the build directory. I must be missing something but I really don't get how compiling things multiple times for nothing could seem acceptable. On 12/19/07, Alexander Neundorf [EMAIL PROTECTED] wrote: On Wednesday 19 December 2007, you wrote: ... Yeah, you could even create one static library per executable... Awesome! What was the problem with putting all the object files in the same directory, again? Shouldn't that be an option, at least? It would be SO much easier than all the dirty hacks I'm being proposed... Different targets may be compiled with different compiler flags, defines, etc. So the object files for the same source files can differ. This is used in some projects. Alex ___ 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] Multiple executables sharing object files
Compilation time is only multiplied if you are specifying the same source file in multiple targets. If you are seeing a 2x difference, then you must have *all* of your source files listed twice. Shouldn't this only be for a few of your source files at most? I would argue that it's better to be correct, if a bit slower, than it is to have a chance of being subtly incorrect and wasting hours figuring out the subtlety. I bet you have never spent hours or days figuring out that you should not have been re-using an .obj file, but should have recompiled it with the flags to match the rest of the library. I have, so I appreciate CMake's default choice in this case. On 12/19/07, Joël Schaerer [EMAIL PROTECTED] wrote: Quoting David Cole [EMAIL PROTECTED]: One other very good reason, too: Same target may have two source files of the exact same name, but they exist in different directories (Abc/Object.cxx and Def/Object.cxx). In that case, the object files will be further hidden in subdirectories to avoid two files in the object files directory from having a name collision. Does that really justify multiplying compilation time by 2 or more? Who would want multiple files with the same name in the same project anyways? Plus, you could very well create a tree structure in the build directory. I must be missing something but I really don't get how compiling things multiple times for nothing could seem acceptable. On 12/19/07, Alexander Neundorf [EMAIL PROTECTED] wrote: On Wednesday 19 December 2007, you wrote: ... Yeah, you could even create one static library per executable... Awesome! What was the problem with putting all the object files in the same directory, again? Shouldn't that be an option, at least? It would be SO much easier than all the dirty hacks I'm being proposed... Different targets may be compiled with different compiler flags, defines, etc. So the object files for the same source files can differ. This is used in some projects. Alex ___ 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] Multiple executables sharing object files
On Dec 19, 2007 3:41 PM, David Cole [EMAIL PROTECTED] wrote: One other very good reason, too: Same target may have two source files of the exact same name, but they exist in different directories (Abc/Object.cxx and Def/Object.cxx). In that case, the object files will be further hidden in subdirectories to avoid two files in the object files directory from having a name collision. If we had a standard way of finding the location of object files, this wouldn't be an issue as the directory name would be part of what's returned. You guys sure argue a lot about an easy feature to implement. Where's the harm in making it easy for the user to find the object files? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
On 12/19/07, Brandon Van Every [EMAIL PROTECTED] wrote: ...an easy feature to implement... So easy to implement that the attached patch was 0 bytes...? :-) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
On Dec 19, 2007 3:52 PM, David Cole [EMAIL PROTECTED] wrote: Compilation time is only multiplied if you are specifying the same source file in multiple targets. If you are seeing a 2x difference, then you must have *all* of your source files listed twice. Shouldn't this only be for a few of your source files at most? How would you know? It would depend entirely upon his hierarchy of source file abstractions. A static library cannot include another static library. That severely limits abstractions. That's why you guys end up talking about silliness like one static lib per exe. There are no available abstractions to do otherwise. I didn't want to be forced to recompile PCRE 6 times for all its different consumers, when I knew jolly well they were all supposed to receive exactly the same objects, no flag variations whatsoever. I didn't want the end user to be aware of PCRE, it was an implementation detail of Chicken that they should never have to think about. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple executables sharing object files
On Dec 19, 2007 4:24 PM, David Cole [EMAIL PROTECTED] wrote: On 12/19/07, Brandon Van Every [EMAIL PROTECTED] wrote: ...an easy feature to implement... So easy to implement that the attached patch was 0 bytes...? Bill's comments at http://www.cmake.org/Bug/view.php?id=5155 about the difficulty do not make any sense to me. It sounds like he tried to implement fullblown convenience libraries. I just want to know where object files are turning up. I did it in 10 lines of CMake script and it worked everywhere that Chicken was built for many months. What's the problem? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] MSVC turn off RelWithDebInfo and MinSizeRel
Is there anyway to have CMake not generate these two configurations, and just generate the standard release and debug configurations instead? Thanks. Jesse ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] ADD_SUBDIRECTORY
Hi CMakers, I have a simple example. I am curious why CMake doesn't automatically build a psuedo-target when an ADD_SUBDIRECTORY is issued? In the end, I want be able to type 'make libs'. I was able to get it to work by adding ADD_CUSTOM_TARGET(libs DEPENDS A B), but adding it seems somewhat redundant. example/CMakeLists.txt contains, PROJECT(EXAMPLE C) ADD_SUBDIRECTORY(libs) ADD_CUSTOM_TARGET(libs DEPENDS A B) example/libs/CMakeLists.txt contains, PROJECT(LIBS C) ADD_SUBDIRECTORY(A) ADD_SUBDIRECTORY(B) example/libs/A/CMakeLists.txt contains PROJECT(A C) ADD_EXECUTABLE(A A.c) example/libs/B/CMakeLists.txt contains PROJECT(B C) ADD_EXECUTABLE(B B.c) TIA, George. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Calling a dynamically created macro
On Dec 19, 2007 12:47 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote:
Brandon Van Every escreveu:
You could use a macro to generate a CMake script containing a macro,
and then call that script. :-)
Nice... :)
In fact, it turns out you can use an include() to cause it to exist at
the point you create the macro. A downside is the number of escapes
you have to put into your meta-macro, such as \\\${myvar}.
# could figure out whether endline is \n or \r\n for this OS
#set(endline \n)
macro(makemacro macro_name) #macro_args ... macro_body
if(${ARGC} GREATER 2)
set(macro_args ${ARGN})
list(REMOVE_AT macro_args -1)
else(${ARGC} GREATER 2)
set(macro_args)
endif(${ARGC} GREATER 2)
if(${ARGC} GREATER 1)
set(argn_list ${ARGN})
list(GET argn_list -1 macro_body)
#message(macro body)
#message(${macro_body})
else(${ARGC} GREATER 1)
set(macro_body)
endif(${ARGC} GREATER 1)
set(mstart macro(${macro_name} ${macro_args}))
set(mend endmacro(${macro_name}))
set(macro_file ${CMAKE_CURRENT_BINARY_DIR}/macro_${macro_name}.cmake)
#file(REMOVE ${macro_file})
if(EXISTS ${macro_file})
message(can't create ${mstart})
message(FATAL_ERROR ${macro_file} already exists)
endif(EXISTS ${macro_file})
file(WRITE ${macro_file}
${mstart}
${macro_body}
${mend}
)
include(${macro_file})
file(REMOVE ${macro_file})
endmacro(makemacro)
makemacro(meta string_const
message(${string_const}\)
)
meta(I can do what I want)
C:\devel\src\cbugs\makemacrocmake -P makemacro.cmake
I can do what I want
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ADD_SUBDIRECTORY
On Dec 19, 2007 4:44 PM, George Neill [EMAIL PROTECTED] wrote: Hi CMakers, I have a simple example. I am curious why CMake doesn't automatically build a psuedo-target when an ADD_SUBDIRECTORY is issued? Because having a subdirectory doesn't imply that you're going to do anything there. It could just be an intermediate part of your source tree. Perhaps the CMakeLists.txt in that subdirectory merely contains more ADD_SUBDIRECTORY commands. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Calling a dynamically created macro
On Dec 19, 2007 6:04 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
On Dec 19, 2007 12:47 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote:
Brandon Van Every escreveu:
You could use a macro to generate a CMake script containing a macro,
and then call that script. :-)
Nice... :)
In fact, it turns out you can use an include() to cause it to exist at
the point you create the macro. A downside is the number of escapes
you have to put into your meta-macro, such as \\\${myvar}.
If you don't need to invent arbitrarily complicated macros on the fly,
but just want to substitute some hardcoded values like the macro name,
running configure_file on a template macro file might be more
convenient. You wouldn't need funky escapes in a pre-written template
macro file.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Calling a dynamically created macro
Now this thread is just plain cool.
:-)
On 12/19/07, Brandon Van Every [EMAIL PROTECTED] wrote:
On Dec 19, 2007 6:04 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
On Dec 19, 2007 12:47 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED]
wrote:
Brandon Van Every escreveu:
You could use a macro to generate a CMake script containing a macro,
and then call that script. :-)
Nice... :)
In fact, it turns out you can use an include() to cause it to exist at
the point you create the macro. A downside is the number of escapes
you have to put into your meta-macro, such as \\\${myvar}.
If you don't need to invent arbitrarily complicated macros on the fly,
but just want to substitute some hardcoded values like the macro name,
running configure_file on a template macro file might be more
convenient. You wouldn't need funky escapes in a pre-written template
macro file.
Cheers,
Brandon Van Every
___
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] Re: Calling a dynamically created macro
On Dec 19, 2007 7:05 PM, David Cole [EMAIL PROTECTED] wrote: Now this thread is just plain cool. :-) Wait until I start building up a more advanced metaprogramming language from raw regular expressions. That idea occurred to me last night. I know regexes really well... can I keep going with it? If not, at least it'll teach me what regexes can't do, computationally speaking. But who knows, maybe anything that has PCRE could turn into a metaprogramming language translator. It would be really slick from a portability and maintenance standpoint. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MSVC turn off RelWithDebInfo and MinSizeRel
SET(CMAKE_CONFIGURATION_TYPES Debug;Release) in your CMakeLists.txt. (Or just edit that value in CMakeSetup to change it in the cache.) If you do it with a simple set in the CMakeLists.txt then you will not see that reflected in the CMakeSetup GUI, but it will be in effect at generation time and you should end up with sln/vcproj files with just the two types. HTH, David On 12/19/07, Jesse Corrington [EMAIL PROTECTED] wrote: Is there anyway to have CMake not generate these two configurations, and just generate the standard release and debug configurations instead? Thanks. Jesse ___ 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] Multiple executables sharing object files
Where are these 10 lines? Can you post them here or point to the chicken .cmake source file that contains them? On 12/19/07, Brandon Van Every [EMAIL PROTECTED] wrote: On Dec 19, 2007 4:24 PM, David Cole [EMAIL PROTECTED] wrote: On 12/19/07, Brandon Van Every [EMAIL PROTECTED] wrote: ...an easy feature to implement... So easy to implement that the attached patch was 0 bytes...? Bill's comments at http://www.cmake.org/Bug/view.php?id=5155 about the difficulty do not make any sense to me. It sounds like he tried to implement fullblown convenience libraries. I just want to know where object files are turning up. I did it in 10 lines of CMake script and it worked everywhere that Chicken was built for many months. What's the problem? Cheers, Brandon Van Every ___ 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] Multiple executables sharing object files
On Dec 19, 2007 7:32 PM, David Cole [EMAIL PROTECTED] wrote: Where are these 10 lines? In the bug tracker, conspiciously above Bill's comments. They've been there for 6 months. http://www.cmake.org/Bug/view.php?id=5155 On 12/19/07, Brandon Van Every [EMAIL PROTECTED] wrote: On Dec 19, 2007 4:24 PM, David Cole [EMAIL PROTECTED] wrote: On 12/19/07, Brandon Van Every [EMAIL PROTECTED] wrote: ...an easy feature to implement... So easy to implement that the attached patch was 0 bytes...? Bill's comments at http://www.cmake.org/Bug/view.php?id=5155 about the difficulty do not make any sense to me. It sounds like he tried to implement fullblown convenience libraries. I just want to know where object files are turning up. I did it in 10 lines of CMake script and it worked everywhere that Chicken was built for many months. What's the problem? Cheers, Brandon Van Every ___ 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] Re: General modernization facility
Brandon Van Every escreveu: What if you were translating from a legacy build system, you expected regexes to work pretty much like they do in every other language or system, it turns out they don't, and you didn't test for the corner cases because the legacy build system had a truly vast number of option permutations to trundle through? You might not hit the bug for a year. Whereas if the behavior had been fixed in later versions of CMake, you'd never have a problem. Well, maybe you're right in some sense. But let's look at cmake's code, shall we? At Sources/cmFindBase.cxx:213 (cmake-cvs-20071219) we have the following comment: // CMake versions below 2.3 did not search all these extra // locations. Preserve compatibility unless a modern argument is // passed. Then it tests the variable CMAKE_BACKWARDS_COMPATIBILITY, if it is 2.3 or below, a compatibility flag is set. Later (line 413), we have the following comment: // Now that arguments have been parsed check the compatibility // setting. If we need to be compatible with CMake 2.2 and earlier // do not add the CMake system paths. It is safe to add the CMake // environment paths and system environment paths because that // existed in 2.2. It is safe to add the CMake user variable paths // because the user or project has explicitly set them. Isn't this an example of what you've meant? I mean, if I get an old code (which doesn't have the CMAKE_BACKWARDS_COMPATIBILITY flag set) and use it with a new CMake, I might get an unexpected behavior, different from what the author intended. Cmake already treats its compatibility issues like I've proposed. In fact, I came up with this idea after seeing this code, just tried to make a little more robust. Maybe Brad King should comment on this issue since cvs annotate told me he wrote this code. Do you expect me to track all the behavioral differences by version number as CMake evolves? You noticed the number of people asking which version of CMake did behavior X first appear in? People have no clue. People should be coding to the version of cmake available at coding time. And, you know, if a cmake developer decides to change a behavior, this should be documented. He would have to write a proper if clause delimiting some version numbers. This action should be documented stating that a certain feature or behaviour is valid from version X to version Y, etc. This shouldn't be a problem. CMake has broken things before and will break things again. It all depends on how ancient things get. Not to break ancient code is a big plus. Even with autotools is nice to be able to compile an old package. Just trying to sum it up: some backwards compatibility framework is better then none. I've seen features being let down because of lack of it. We have come with two approaches, each one with pros and cons. Now it's up to the cmake developers to decide if this issue deserves consideration or not. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Bug with cmake's `--debug-trycompile' option?
On Dec 19, 2007 12:35 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Clark J. Wang wrote: Anybody has any idea? On Dec 11, 2007 5:07 PM, Clark J. Wang [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I This is fine for `sys/event.h' is not available on my system. But when I run `cmake --debug-trycompile .' it outputed like this: This time it said that `sys/event.h' was found! Anything wrong? I am not surprised. The debug-try compile option does not clean out the build tree. It is meant as a debugging tool only. It should not be expected to work. Usually, if there is trouble with the result of a try compile, you set it up so that only that one try compile will happen and run with debug-trycompile. Then cmake will leave the build/source files in the temp directory, so you can try it by hand, and examine the results. Debugging options are used for debugging, that's right. But I don't agree that CMake can give wrong results when run in debug mode. Take the `--debug-trycompile' option for example, CMake can leave separate build/source files with different filenames in the temp directory for each call of TRY_COMPILE. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
