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] > > > wrote: > > > > I > > This is fine for `sys/event.h' is not available on my sy

[CMake] Re: General modernization facility

ook 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_BA

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 D

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

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 an

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 w

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: > > > > >

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. :-) >

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 ther

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 exis

Re: [CMake] Re: General modernization facility

On Dec 19, 2007 1:44 PM, Rodolfo Schulz de Lima <[EMAIL PROTECTED]> wrote: > > 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. What if you wer

[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 r

[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

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

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

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: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

Re: [CMake] Multiple executables sharing object files

On Dec 19, 2007, at 1:44 PM, Joël Schaerer 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 fil

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 cor

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

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

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

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 h

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

[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: h

[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

[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:/

[CMake] Re: Calling a dynamically created macro

Brandon Van Every escreveu: You could use a macro to generate a CMake script containing a macro, and then call that script. :-) Nice... :) ___ 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://ww

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 >

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, dy

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.

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 se

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

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

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 __

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

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] 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.cmak

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 peopl

[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

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

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

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-Se

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

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 comp

[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] Re: Parsing cmake command line parameters

Rodolfo Schulz de Lima wrote: 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 n

[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 someon

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=520790&view=markup Beside that,

[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 --enab

[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

[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 reg

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