Re: [CMake] Gyp VS CMake
On 02/19/2011 06:27 PM, Michael Wild wrote: On 02/19/2011 06:16 PM, Jed Brown wrote: On Fri, Feb 18, 2011 at 17:16, Michael Wildthem...@gmail.com wrote: Well, cl.exe for one doesn't do this trick. This means, you'll have to put it in your build system, and once you've done that, why should you use the compiler then? Especially, since you'll want to be consistent across platforms. You can use LD_PRELOAD (DLL injection on Windows) to pick up the dependencies. That has the advantage of automatically working for any compiler or other custom command, for any source language. Tup does this. Tup was already discussed on this list quite some time ago. Using LD_PRELOAD to do those things makes my skin crawl. You need to intercept system calls AND C-library functions and have to hope that the compiler isn't doing some crazy stuff you haven't considered... LD_PRELOAD isn't that bad of a hack, actually. Intercepting open(), read(), and possibly mmap() should cover most cases. -- Jesper Eskilson Developer IAR Systems ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Possible 'brief' output options for UnixMakefileGenerator
On 12/20/2010 01:01 AM, Campbell Barton wrote: Hi, I'm STILL trying to have CMake makefiles replace Blender's hand crafted makefiles. Now the main sticking point with 2 other developers is they don't like CMakes output, as its overly verbose. I realize CMake doesn't need to bend to the whim of all users but wondering if we could have something like RULE_BRIEF_OUTPUT Rather then printing progress and full path for all files it could skip percentage and use a relative path for each C file. I can try submitting a patch but would first like to know if this would be acceptable. I've submitted a bugreport about this: http://www.cmake.org/Bug/view.php?id=7062. It was submitted almost two years ago, so I'm not sure it is getting very much attention by the CMake people. -- Jesper Eskilson Developer IAR Systems ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Is there a tool pretty much like cmake for Java?
On 10/14/2010 10:22 PM, Michał Czuczman wrote: I would be interested in improving Java support in CMake. A source code parser which finds out names of generated output object files, as in the SCons Java support, is a must. That's what the current Java support in CMake lacks the most. I've searched through CMake source code and it looks like the object file name is always obtained just from the source file name. Unfortunately this doesn't work for Java. Would you please give me some more details on how do you see the module implemented? Or some hints from where to start? The most tricky part is how to handle changing dependencies. Should the classes and jar be separate targets, as it is in SCons? I like CMake a lot, but when it comes to Java, I just don't see the benefits. For me, the strength of CMake is the ability to build C/C++ on multiple platforms from a single specification. There is a plethora of different build systems which are tailored to work well with Java. In that world, I don't see what value CMake has. I'm not going to argue against improving CMake support in Java, I'm just curious. -- /Jesper ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] RULE_XXX
I'm trying to use the RULE_XXX properties to customize make output. Is there a way to intercept ALL output from make, including the Build target ..., Building C object..., etc., messages as well? -- /Jesper ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] add_test does not work as documented
Hi,
I cannot get add_test to work as documented.
add_test(mytest MyExe)
correctly runs MyExe. However, if I try to use any of the generator
expressions (such as $CONFIGURATION), it fails:
add_test(mytest ${SOMEVARIABLE}/$CONFIGURATION/MyExe)
fails to locate MyExe correctly, since it isn't expanding
$CONFIGURATION correctly.
Looked in the following places:
/home/jesperes/dev/tooticki/core/ide/../stage/$CONFIGURATION/common/bin/TestIDE
/home/jesperes/dev/tooticki/core/ide/../stage/$CONFIGURATION/common/bin/TestIDE
/home/jesperes/dev/tooticki/core/ide/../stage/$CONFIGURATION/common/bin/Release/TestIDE
/home/jesperes/dev/tooticki/core/ide/../stage/$CONFIGURATION/common/bin/Release/TestIDE
/home/jesperes/dev/tooticki/core/ide/../stage/$CONFIGURATION/common/bin/Debug/TestIDE
/home/jesperes/dev/tooticki/core/ide/../stage/$CONFIGURATION/common/bin/Debug/TestIDE
/home/jesperes/dev/tooticki/core/ide/../stage/$CONFIGURATION/common/bin/MinSizeRel/TestIDE
/home/jesperes/dev/tooticki/core/ide/../stage/$CONFIGURATION/common/bin/MinSizeRel/TestIDE
/home/jesperes/dev/tooticki/core/ide/../stage/$CONFIGURATION/common/bin/RelWithDebInfo/TestIDE
/home/jesperes/dev/tooticki/core/ide/../stage/$CONFIGURATION/common/bin/RelWithDebInfo/TestIDE
/home/jesperes/dev/tooticki/core/ide/../stage/$CONFIGURATION/common/bin/Deployment/TestIDE
/home/jesperes/dev/tooticki/core/ide/../stage/$CONFIGURATION/common/bin/Deployment/TestIDE
/home/jesperes/dev/tooticki/core/ide/../stage/$CONFIGURATION/common/bin/Development/TestIDE
/home/jesperes/dev/tooticki/core/ide/../stage/$CONFIGURATION/common/bin/Development/TestIDE
Also, the form
add_test(NAME mytest COMMAND MyCommand)
doesn't work at all. No tests are generated, and make test complains
that there aren't any tests.
What am I doing wrong?
I'm using CMake 2.8.2.
--
/Jesper
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] add_test does not work as documented
On 09/21/2010 01:30 PM, David Cole wrote: $CONFIGURATION only works with the add_test(NAME mytest COMMAND MyCommand) form of the add_test command. But, when you use that form, you have to run ctest -C Release or ctest -C Debug to choose a configuration when you run the tests. Otherwise, tests added with that form are skipped if ctest is called without a -C argument. Ok, thanks. (I didn't find any mention of this. Maybe the add_test() documentation ought to say something about it.) -- /Jesper ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] vcproj2cmake.rb script: announcing new version / hosting questions
On 06/14/2010 05:00 PM, Andreas Mohr wrote: Frankly the entire distinction between CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE remains one of the more confusing things, as can be witnessed in several confused postings about this topic. (but I'm afraid that's just the way it is - there's nothing to be improved about these mechanisms since they're likely just doing what they should) The biggest annoyment I have with CMake is the fact the the makefile generators don't support building multiple configurations in the same build tree. Not sure if it would be practical to fix, though. -- Jesper Eskilson Developer IAR Systems http://www.iar.com ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Anybody using IAR compiler here ?
On 05/31/2010 10:53 PM, Alexander Neundorf wrote: On Monday 31 May 2010, Jesper Eskilson wrote: On 05/30/2010 02:13 PM, Alexander Neundorf wrote: That's also ok. Could you please post the output of the IAR AVR and ARM assemblers when called without any arguments here ? (or put them into http://public.kitware.com/Bug/view.php?id=10176 ) The first non-empty line is for ARM and Atmel AVR, respectively: IAR Assembler V5.41.2.51793/W32 for ARM IAR Assembler V5.50.0.50277/W32 for Atmel AVR Thanks :-) While we are at it, do the C and C++ compilers behave the same way, i.e. print the version information when called without arguments ? Yes. How does that output look like then ? IAR ANSI C/C++ Compiler V5.41.2.51793/W32 for ARM IAR C/C++ Compiler V5.50.0.50277/W32 for Atmel AVR Does it differ between the AVR and ARM compilers ? They seemed to be quite different in their command lines etc. They do differ a bit in their command lines, mostly depending on the different capabilities. One such difference is that ARM is ELF/Dwarf based, and the AVR-compiler uses the Ubrof object file format. -- Jesper Eskilson Developer IAR Systems http://www.iar.com ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Anybody using IAR compiler here ?
On 05/26/2010 10:08 PM, Alexander Neundorf wrote: Hi, is anybody here using an IAR compiler for AVR or ARM ? If so, how can I execute the assembler so that it just prints its name and version number and exits ? (i.e. the equivalent to as --version, which gives GNU assembler (Linux/GNU Binutils) 2.17.50.0.17.20070615 Copyright 2007 Free Software Foundation, Inc. ...) There is no such option. To extract the version number, you'll have to run the assembler without options and filter the result through some text-processing tool. Same things goes for other IAR tools. -- Jesper Eskilson Developer IAR Systems http://www.iar.com ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Reverse dependencies (Unix Makefiles)
On 05/26/2010 05:17 PM, Michael Hertling wrote:
Will this still work with an executable E wich depends on B - C - B.
Won't C pull in A as well?
OK, I suppose, that means you have targets D *and* E in your project, D
links against A, E against B, A and B both link against C which finally
needs A *or* B, right? ['fetching a cup of coffee... ;) ]
Correct.
Now, indeed, you can not associate C with A in this exclusive manner
anymore, but you can make use of an imported target's decoupling from
its actual file: Introduce two imported library targets CA and CB, both
pointing to libC.a on disk, but associated with either A or B. Look here:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(ABCDE C)
# Generate static libraries A,B,C with circular dependencies:
FILE(WRITE A.c void fA(void){ fC(); } void ident(void){})
FILE(WRITE B.c void fB(void){ fC(); } void ident(void){})
FILE(WRITE C.c void fC(void){ ident(); })
ADD_LIBRARY(A0 STATIC EXCLUDE_FROM_ALL A.c)
ADD_LIBRARY(B0 STATIC EXCLUDE_FROM_ALL B.c)
ADD_LIBRARY(C0 STATIC EXCLUDE_FROM_ALL C.c)
SET_TARGET_PROPERTIES(A0 PROPERTIES ARCHIVE_OUTPUT_NAME A)
SET_TARGET_PROPERTIES(B0 PROPERTIES ARCHIVE_OUTPUT_NAME B)
SET_TARGET_PROPERTIES(C0 PROPERTIES ARCHIVE_OUTPUT_NAME C)
# Incorporate A and B as imported targets:
ADD_LIBRARY(A STATIC IMPORTED)
ADD_LIBRARY(B STATIC IMPORTED)
SET_TARGET_PROPERTIES(A PROPERTIES IMPORTED_LOCATION
${CMAKE_CURRENT_BINARY_DIR}/libA.a)
SET_TARGET_PROPERTIES(B PROPERTIES IMPORTED_LOCATION
${CMAKE_CURRENT_BINARY_DIR}/libB.a)
# Incorporate two imported targets CA and CB for C:
ADD_LIBRARY(CA STATIC IMPORTED)
ADD_LIBRARY(CB STATIC IMPORTED)
SET_TARGET_PROPERTIES(CA PROPERTIES IMPORTED_LOCATION
${CMAKE_CURRENT_BINARY_DIR}/libC.a)
SET_TARGET_PROPERTIES(CB PROPERTIES IMPORTED_LOCATION
${CMAKE_CURRENT_BINARY_DIR}/libC.a)
# Declare circular dependencies:
SET_TARGET_PROPERTIES(A PROPERTIES IMPORTED_LINK_INTERFACE_LIBRARIES CA)
SET_TARGET_PROPERTIES(CA PROPERTIES IMPORTED_LINK_INTERFACE_LIBRARIES A)
SET_TARGET_PROPERTIES(B PROPERTIES IMPORTED_LINK_INTERFACE_LIBRARIES CB)
SET_TARGET_PROPERTIES(CB PROPERTIES IMPORTED_LINK_INTERFACE_LIBRARIES B)
# Generate executable D linking against library A:
FILE(WRITE D.c void main(void){ fA(); })
ADD_EXECUTABLE(D D.c)
TARGET_LINK_LIBRARIES(D A)
# Generate executable E linking against library B:
FILE(WRITE E.c void main(void){ fB(); })
ADD_EXECUTABLE(E E.c)
TARGET_LINK_LIBRARIES(E B)
After cmaking, type make {A,B,C}0 to build lib{A,B,C}.a, and then
make VERBOSE=1 for the executables D and E; the link lines are:
gcc CMakeFiles/D.dir/D.c.o -o D -rdynamic libA.a libC.a libA.a libC.a
gcc CMakeFiles/E.dir/E.c.o -o E -rdynamic libB.a libC.a libB.a libC.a
Thus, the circular dependencies are respected as desired without
repeating A or B in TARGET_LINK_LIBRARIES() for D and E.
Sounds like a somewhat convoluted solution, but thanks anyway. Now at
least I know that it can be done.
--
/Jesper
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Reverse dependencies (Unix Makefiles)
On 05/24/2010 03:40 PM, Michael Hertling wrote: On 05/24/2010 11:20 AM, Jesper Eskilson wrote: Hi, I have two targets, call them A and B. They both link with a third, static library called C. C attempts to invoke a function which is defined by however links with C, i.e. either A or B. This is not a problem as long as A and B are executables or shared libraries, but if A or B is a static library which in turn is linked into a shared object or executable (call it D), then the command becomes something like cc ... -o libD.so -lA -lC since the method C calls in A is unknown by the linker when A is processed, it is discarded. Instead, I would need the command line to look like this: cc ... -o libD.so -lA -lC -lA but how can I do this without explicitly causing A to depend on C? According to your first paragraph, A does depend on C; what you're asking for is a, say, optional dependency of C on A, right? How do you decide whether to use A or B? If this is known at CMake time: TARGET_LINK_LIBRARIES(A C) TARGET_LINK_LIBRARIES(C A) TARGET_LINK_LIBRARIES(D A) should do the job for A, and TARGET_LINK_LIBRARIES(B C) TARGET_LINK_LIBRARIES(C B) TARGET_LINK_LIBRARIES(D B) does it for B, alternatively, since TARGET_LINK_LIBRARIES() attends to circular dependencies w.r.t. static libraries, see its documentation. Furthermore, I suppose you can't use A and B together due to equally named symbols defined in both of them, in fact the ones called by C. The functions in A or B called by C actually *idenfities* which of A or B that C is being linked into. Think of A and B as the compiler and the assembler which links with a utility library C which calls a method in either A or B which identifies which if the compiler and assembler the utility library is being used in. In the last resort, the GNU linker provides options --start-group and --end-group, or the short ones -( and -), respectively, meant to resolve circular dependencies among static libraries, but I don't know if one can have CMake intersperse these options in the link line or if this would be portable regarding the various supported platforms. Perhaps, if possible, you should consider to reorganize your project in order to avoid circular dependencies at all, e.g.: Take those parts of A and B that C refers to and turn them into separate libraries A0 and B0. This results in A, B and C depend on A0 and/or B0, and the link line for libD.so would be: cc ... -o libD.so -lA -lC -lA0 or cc ... -o libD.so -lB -lC -lB0 Thus, the circular dependencies are gone. Yes, that would probably be nice, but it is unfortunately not an option at this time. Rewriting this is not an option due to the sheer size of the code base which would need refactoring. I've solved this for now by doing target_link_libraries(D A C A) which seems to work, although D needs to know that A has to be repeated in the libraries list. -- /Jesper ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Reverse dependencies (Unix Makefiles)
On 05/25/2010 02:41 PM, Michael Hertling wrote: Exactly: The need for A's repetition in the link line is a sole affair of A and C. Therefore, IMO, it should not be brought explicitly to D's link line whereas an approach with two TARGET_LINK_LIBRARIES() for the A'n'C circular dependency and one for D against A would express the actual relations quite accurately. Can CMake express this for IMPORTED libraries as well. Both A, B, and C in this case are (or can be) IMPORTED libraries, and TARGET_LINK_LIBRARIES() fail if the first argument is an IMPORTED library. Until I can figure out how to do that, I'll have to go with repeating A on D's link line. -- /Jesper ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linux In-the-source Build multiple modes without swithing
Bill Hoffman wrote:
Charlie Sun wrote:
Hi,
I'm trying to do a linux build with both release and debug mode. In
stead of builing out of source as indicated on the FAQ 4.15, I really
need to do in the source build. currently, if I do a release build and
then a debug build and then another release build. It will actually
rebuild the release and forgets the previous release build. Is it
because cmake is only generating one set of objective files when doing
in-the-source, either release or debug? Is there a way to have both?
Any help is greatly appreciated!
Regards,
The only way to do what you want is to use out of source builds. Why do
you have to do in-source builds?
I've wanted this as well, for other reasons:
- Be able to do make {Debug|Release|...}.
- Be able to use the same infrastructure for running cmake both on Unix
and Windows. I currently have to maintain two different ways of running
cmake: one for single-config build directories, and another for
multiple-config build directories.
- Be able to build multiple configurations in parallel.
I'd also like a Makefile-generator which fokuses only on GNU make. I get
the feeling that much of the stuff which goes into the makefiles today
are there in order to maintain compatibility with things like Watcom and
Borland.
--
/Jesper
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] MSYS Makefiles + cl.exe
I'm having some trouble in setting up our CMake-system to use MSYS Makefiles together with cl.exe. The environments seems all setup, cl.exe is found, but there is some trouble in detecting the compiler ABI info: $ rm -f CMakeCache.txt cmake ../trunk/ -GMSYS Makefiles -DCMAKE_AR=ar -DCMAKE_BUILD_TYPE=Debug -- The C compiler identification is MSVC -- The CXX compiler identification is MSVC -- Check for CL compiler version -- Check for CL compiler version - 1400 -- Check if this is a free VC compiler -- Check if this is a free VC compiler - no -- Check CL platform -- Check CL platform - 32 bit -- Check for working C compiler: C:/Program Files/Microsoft Visual Studio 8/VC/bin/cl.exe -- Check for working C compiler: C:/Program Files/Microsoft Visual Studio 8/VC/bin/cl.exe -- works -- Detecting C compiler ABI info CMake Error: Could not COPY_FILE. OutputFile: '' copyFile: 'E:/dev/ide-platform/build.cdt/CMakeFiles/CMakeDetermineCompilerABI_C.bin' -- Detecting C compiler ABI info - done CMake Error at C:/Program Files/CMake 2.6/share/cmake-2.6/Modules/CMakeDetermineCompilerABI.cmake:24 (FILE): file STRINGS file E:/dev/ide-platform/build.cdt/CMakeFiles/CMakeDetermineCompilerABI_C.bin cannot be read. Call Stack (most recent call first): C:/Program Files/CMake 2.6/share/cmake-2.6/Modules/CMakeTestCCompiler.cmake:51 (CMAKE_DETERMINE_COMPILER_ABI) CMakeLists.txt:5 (project) -- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio 8/VC/bin/cl.exe -- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio 8/VC/bin/cl.exe -- works -- Detecting CXX compiler ABI info CMake Error: Could not COPY_FILE. OutputFile: '' copyFile: 'E:/dev/ide-platform/build.cdt/CMakeFiles/CMakeDetermineCompilerABI_CXX.bin' -- Detecting CXX compiler ABI info - done CMake Error at C:/Program Files/CMake 2.6/share/cmake-2.6/Modules/CMakeDetermineCompilerABI.cmake:24 (FILE): file STRINGS file E:/dev/ide-platform/build.cdt/CMakeFiles/CMakeDetermineCompilerABI_CXX.bin cannot be read. Call Stack (most recent call first): C:/Program Files/CMake 2.6/share/cmake-2.6/Modules/CMakeTestCXXCompiler.cmake:44 (CMAKE_DETERMINE_COMPILER_ABI) CMakeLists.txt:5 (project) Any clues? -- /Jesper ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Eclipse Generator and Configuration
Pierre-Julien Villoud wrote: Hello everyone, I'm trying to use the Eclipse CDT4 - MinGW Makefiles generator to generate the Eclipse project files. My problem is that it is not possible to choose the configuration (Debug or Release) from the Eclipse platform. Is there any way to make this possible or do I have to specify the configuration when I call cmake with the option -DCMAKE_BUILD_TYPE:STRING=xxx (xxx = Debug or Release). I believe you need to rerun CMake to switch configuration. I'd like to implement a revamped, GNU-make-only, Makefile-generator for CMake with support for selecting configuration at runtime. But day does not have enough hours, I'm afraid. -- /Jesper ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Eclipse CDT generator
I'm giving the CDT backend another shot, following the instructions at http://www.cmake.org/Wiki/Eclipse_CDT4_Generator. I'm using a dual project setup with a build project and source project as described on the wiki. Is there a way to exclude the build project from being indexed? first, my project is fairly large (3000+ source code file), and the indexer is having enough problems indexing the source code once. Secondly, the dual project setup causes each file to appear twice in the Open Resource dialog, which is annoying. (Each resource is actually occurring three times, but the third time is probably my fault.) -- /Jesper ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Visual Studio project file reloading in Vista
Hi, I'm having trouble getting the automatic project file reloading in Visual Studio 2005 to work when running under Vista (Home Premium 64-bit). Reproduce: * Open VS2005 + a solution generated by CMake * Modify one of the CMakeLists.txt files. * Rebuild solution * Observed behavior: ZERO_CHECK reruns CMake, but VS2005 does not detect that the project files has changed until the solution has been completely rebuilt. It looks as if the VS-macros invoked by CMake to interrupt the build aren't working properly. Is this a known problem, or should I report a bug? -- /Jesper ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to set CPACK_SOURCE_IGNORE_FILES to remove all source code?
Eric Noulard wrote: I should stop writing totally wrong advices for this for a while. Let us know when you're going to start giving wrong advice again. Just so we know. ;-) -- /Jesper ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Buggy progress reporting
Bill Hoffman bill.hoff...@kitware.com writes: Gopala Krishna wrote: On Mon, Jan 26, 2009 at 2:29 AM, Bill Hoffman bill.hoff...@kitware.com wrote: The progress reporting only supports one make at a time in the build tree. -Bill Is there any documentation somewhere on how the percentage reporting is implemented ? If not it would really be helpful atleast to get a hint on which source files to look at. :) No, not really, it uses a directory to communicate, and cmake -E cmake_progress_start. If you grep for progress in the source tree and look at the Makefiles you can get the idea. It is going to be very hard to make it work with more than one make in a tree. If the directory used for communication had a pid as part of its name, wouldn't that solve it? Or is it more complicated than that? (I'm just curious.) -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Buggy progress reporting
Michael Wild them...@gmail.com writes: On 26. Jan, 2009, at 15:05, Jesper Eskilson wrote: Bill Hoffman bill.hoff...@kitware.com writes: Gopala Krishna wrote: On Mon, Jan 26, 2009 at 2:29 AM, Bill Hoffman bill.hoff...@kitware.com wrote: The progress reporting only supports one make at a time in the build tree. -Bill Is there any documentation somewhere on how the percentage reporting is implemented ? If not it would really be helpful atleast to get a hint on which source files to look at. :) No, not really, it uses a directory to communicate, and cmake -E cmake_progress_start. If you grep for progress in the source tree and look at the Makefiles you can get the idea. It is going to be very hard to make it work with more than one make in a tree. If the directory used for communication had a pid as part of its name, wouldn't that solve it? Or is it more complicated than that? (I'm just curious.) Lets say with process 1000 is building target A. Process 2000 is building target B at the same time. What happens if both depended on target C (e.g. a library) and tried to build it at the same time without knowing that there is another process trying to do the very same thing. This might lead to very buggy builds... I don't think this is anything CMake could ever possibly handle, as it also very strongly depends on the native build system (Make, VS, Xcode,...) You're right, of course. (Since Bill said that the progress meter only supported one build at a time, my brain started thinking how that could be implemented, without considering the rest of the build system.) -- /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 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] 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
Re: [CMake] Stand alone Visual Studio Solution
Eran Burstain wrote: Hi ! We want to begin working with CMake in a large project, but we want to have a regular Visual's sln-vcproj projects in the source control, for users that cannot use CMake. Can we activate CMake and force in to create all paths relative ? This is a good starting point: set(CMAKE_USE_RELATIVE_PATHS 1) however, some absolute paths still seem appear in the solution files. I'm not sure if that is an issue with my CMakeLists.txt, though. Can we create a solution file without the BUILD_ALL, ZERO_TEST project, and without CMake's-VIsual Studio macros (file change detection) ? AFAIK, no. But you're not alone in wishing for this. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] the switch to subversion?
Esben Mose Hansen wrote: On Tuesday 23 September 2008 18:10:05 Mathieu Malaterre wrote: svn 'external' links to repositories (not tested). Do not know what is the default behavior for branching... I'd stay away from svn:externals. We used those extensively in my company, and they are a bother. E.g, branching doesn't work too well with externals. We have also started using git, and that is much nicer than svn. But as you say, windows support might be an issue. Since the issues are founded in the limitations of windows, I doubt this will be resolved soon. Don't be so sure. There are quite a few people wanting and working on a native Git port for Windows. OTOH, the Cygwin-port of Git works very nice. ( Fortunately for me, windows is something that happens to other people :p ) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Weird output
Alan W. Irwin wrote:
On 2008-09-17 09:10+0200 Jesper Eskilson wrote:
Timenkov Yuri wrote:
Anyway, the printout is inside a if(this-Verbose) { ... }, so
presumable it is something which can be switched on/off.
And it seems not a problem, because CMake just tells why it
regenerates dependencies.
But it clutters my make output. I like my make output to be as clean
as possible. Actually I would like to get rid of the Building CXX
object... messages as well -- when running make with the -s option
there should be no output at all except error messages. But that is
another issue.
Anyway, the culprit is that I ran make like this
$ make -j2 all VERBOSE=
i.e. the VERBOSE variable is set, but to the empty string.
I doubt setting VERBOSE at the end like that after the all target will
work. For that order make probably assumes VERBOSE= is a target which is
not what you want.
I don't think so. VERBOSE seems to be set to an empty string (as far as
I can tell, I haven't checked with $(origin ...)).
Anyway, I've gotten rid of the printouts, so now I'm happy.
--
/Jesper
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Regenerating Visual Studio projects
Hi all, When CMake (2.6) discovers that a CMakeLists.txt file has changed, and that one or more Visual Studio projects/solutions need to be reloaded, it attempts to interrupt the build, force Visual Studio to reload the projects, and then restart the build. This is really good compared to CMake 2.4, where the projects weren't reloaded until the build had completed and you possibly had to build again from scratch. I have a problem, though: CMake does not properly detect if it is being run from inside Visual Studio, and it doesn't check that it interrupting the correct Visual Studio instance. Say that you have a studio instance opened on a solution. If I run CMake to regenerate a completely different solution, CMake will try to interrupt the (unrelated) studio instance. This wouldn't be too bad unless Visual Studio kept throwing up interactive dialogs asking do you really want to interrupt the build and do you want to reload 78 project files. I have users who needs to run my build scripts (which invoke cmake) without the script interfering with any other studio instances they may have running. Either CMake should detect that it is being run under Visual Studio and attempt to stop/interrupt the studio instance which it was started by, or there should be a flag to disable any form of communication with Visual Studio as in CMake 2.4). Which brings me to my second issue: when CMake is rerun from inside Visual Studio, I have to click on at least 3 interactive dialogs in order for the project to be reloaded. Is there anything CMake can do about that? I don't want to click on any dialogs at all, just have the project files recreated and reloaded. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Weird output
Timenkov Yuri wrote:
On Tue, Sep 16, 2008 at 11:08 AM, Jesper Eskilson [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi all,
I get several weird printouts in our build-server logs which I don't get
when I'm building from an (interactive) terminal:
Dependee
/home/jesperes/localmarran/core/ide/cmakebuild/i486-pc-linux-gnu/Debug/Jkc/CMakeFiles/Jkc.dir/DependInfo.cmake
is newer than depender
/home/jesperes/localmarran/core/ide/cmakebuild/i486-pc-linux-gnu/Debug/Jkc/CMakeFiles/Jkc.dir/depend.internal.
I've tried searching for Dependee in both the generated makefiles and
in the CMake source code, but without success.
This output comes from make utility. These problems may occur if you
have problems with time on your server. Check that your VCS server,
developers (who commit to VCS) and build server have same time.
I'm sorry, but this is not correct. CMake prints out the message in
cmDepends.cxx. (Maybe you were thinking about the clock-skew detected
message which is printed when make discovers that newly created files
gets timestamps in the future?)
Anyway, the printout is inside a if(this-Verbose) { ... }, so
presumable it is something which can be switched on/off.
--
/Jesper
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Weird output
Timenkov Yuri wrote:
Anyway, the printout is inside a if(this-Verbose) { ... }, so
presumable it is something which can be switched on/off.
And it seems not a problem, because CMake just tells why it regenerates
dependencies.
But it clutters my make output. I like my make output to be as clean as
possible. Actually I would like to get rid of the Building CXX
object... messages as well -- when running make with the -s option
there should be no output at all except error messages. But that is
another issue.
Anyway, the culprit is that I ran make like this
$ make -j2 all VERBOSE=
i.e. the VERBOSE variable is set, but to the empty string.
--
/Jesper
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] ctest and Visual Studio
I'm trying to add some tests to a project which is mainly built on Windows using Visual Studio. The problem I have is how to locate the binary used to run the test. The path to the binary depends on the Visual Studio macro $(ConfigurationName), so when I run ctest I get: $ vcbuild RUN_TESTS.vcproj Build started: Project: RUN_TESTS, Configuration: Debug|Win32 -- -- Performing Post-Build Event... -- Start processing tests -- Test project H:/dev/marran/trunk/core/ide/cmakebuild/i686-pc-mswin32 -- 1/ 2 Testing jkc_jni ***Failed -- 2/ 2 Testing ide_generic Could not find executable H:/dev/marran/trunk/core/ ide/../stage/$(ConfigurationName)/common/bin/TestIDE -- Looked in the following places: -- H:/dev/marran/trunk/core/ide/../stage/$(ConfigurationName)/common/bin/TestIDE -- H:/dev/marran/trunk/core/ide/../stage/$(ConfigurationName)/common/bin/TestIDE.exe -- H:/dev/marran/trunk/core/ide/../stage/$(ConfigurationName)/common/bin/Debug/TestIDE -- H:/dev/marran/trunk/core/ide/../stage/$(ConfigurationName)/common/bin/Debug/TestIDE.exe -- Debug/H:/dev/marran/trunk/core/ide/../stage/$(ConfigurationName)/common/bin/TestIDE -- Debug/H:/dev/marran/trunk/core/ide/../stage/$(ConfigurationName)/common/bin/TestIDE.exe -- Unable to find executable: H:/dev/marran/trunk/core/ide/../stage/$(ConfigurationName)/common/bin/ TestIDE -- 0% tests passed, 2 tests failed out of 2 -- The following tests FAILED: --1 - jkc_jni (Failed) --2 - ide_generic (Not Run) -- Errors while running CTest *** Project : error PRJ0019: A tool returned an error code from Performing Post-Build Event... I.e. the TestIDE binary can't be found by ctest since ctest doesn't know about $(ConfigurationName). Is there a solution to this? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Disable pretty output
Bill Hoffman wrote: OK, thanks. I am not sure how -j N will be fixed by this, but the other stuff sounds good. I think we are sort of stuck with the jumbled output with parallel make. Unless you got really complicated with some sort of client server setup. I'm not sure how things work today, but typically when you have rules like this foo.o: foo.c @echo Compiling foo $(CC) they aren't jumbled (even if the output won't necessarily come directly together with any subsequent errors or warnings). I guess its because echo flushes the entire line at once. If the progress percentage and the actual message is printed in separate invocations, that would increase the risk of jumbling. Usually the problem with parallell make is that compiler error messages are mixed up. OMake actually solves that by buffering all compiler output until the compiler exits, but that may be overkill in this case, I think. Anyway, having an external program will allow the a large degree of freedom without complicating things too much. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Disable pretty output
Bill Hoffman wrote: David Sveningsson wrote: Hi, more newbie questions. The GNU Makefiles generated CMake has some nice colored output, progress etc. However I would like to disable this and see each command that is run (debugging purpose). There is no way to turn it off. You can do make VERBOSE=1 to see the commands, but they will be mixed with the other stuff as well. The output management for the makefile generator has several problems (IMO). - When using parallell make, the output becomes jumbled. - The -s flag to make is not obeyed. - The pretty/colorized progress messages can't be switched off. - The progress messages are (sometimes) too long. I'd actually like an option to remove all the progress messages from the makefile, alternatively move them out to a separate (replacable) utility. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Disable pretty output
Bill Hoffman wrote: Feel free to create a feature request. Please describe how the replaceable utility would work. Done: http://public.kitware.com/Bug/view.php?id=7062 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] avoid windows link warning: LNK4221
Phil Pellouchoud wrote: I have a *static library* that is giving the following warning: LNK4221 Is there a way to tell cmake to add /IGNORE:4221 Sorry, but there is no /IGNORE option to LIB. Afaik, LIB does not have an option for disabling warnings. If you find one, please let me know. :-( ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Control Object code destination?
Eric Torstenson wrote: Hi All, I'm compiling my application on 4 platforms (linux 32 bit, linux 64 bit, windows and mac) I would like to use my linux source tree for all of them without having to recompile the whole thing each time I change from one platform to the next. Is there a way to do that? I looked at CMAKE_ARCHIVE_OUTPUT_DIRECTORY, but it looks like it is the destination of the end products themselves, and not the intermediate stuff. Use separate build directories. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMAKE_CONFIGURATION_TYPES
I've found a weird behavior which appears when trying to redefine the CMAKE_CONFIGURATION_TYPES variable under the following conditions: - The cmake.exe frontend is used - A Visual Studio generator is used - CMake 2.6 RC5, probably previous versions as well Given the following CMakeLists.txt (with a trivial foo.c): project(foo) set(CMAKE_CONFIGURATION_TYPES Debug;Release;FooBar CACHE STRING FORCE) add_executable(foo foo.c) I would have expected it to generate a solution with a configuration named FooBar, but it doesn't. However, the configuration appears when I rerun cmake. The difference is that the second time the value is in the cache when cmake starts. Running cmake like this also works: cmake -DCMAKE_CONFIGURATION_TYPES=Debug;Release;FooBar I would characterize this as a bug, since it isn't possible to run cmake.exe once and have the CMakeLists.txt set the variable properly. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cyclic DLL dependencies
Michael Wild wrote: Does anyone of you have an idea how to solve the cyclic dependency problem in a more elegant way or how to recycle objects? Yep. Look here: http://msdn2.microsoft.com/en-us/library/kkt2hd12.aspx -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] VMWare on SCons' future
Brandon Van Every wrote: On Mon, Mar 3, 2008 at 6:06 PM, Brandon Van Every [EMAIL PROTECTED] wrote: http://www.nabble.com/SCons-Future-Directions-and-Thoughts-td15176258.html you can learn tons about SCons from that thread. And there's one *really* spectacular public flame, if you need a motive to stay awake reading through it. Care to elaborate for those of use too lazy to read through the whole thing? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] converting VS projects to CMake
Brandon Van Every wrote: Someone asked me the other day why CMake doesn't do this. I thought I gave him a reasonable answer, that it would be painful to do, and that CMake -- native is a much easier problem than native -- CMake. But I said I would ask here for other people's opinions on it. I have experience converting a large Autoconf + GMake project to CMake. At the time I used piles upon piles of regular expressions. I can think of more sophisticated ways to do the parsing and translation. But no matter what technology is chosen, it's a lot of work. I'm sure the same would be true for MSVC, plus MSVC changes its format every few years. Does MSVC pose any other special difficulties, other than sheer mind-numbingness of translation? Having written a naive ruby-script which does little more than just extract the source files for you, there a number of difficulties. For example: - Handling post/pre-build commands. - Handling file-specific options/settings. Getting to 95% is probably doable with a lot of (mind-numbing) work, getting to 100% is probably impossible. There is always another pathological case one wouldn't be able to handle. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] movable (Visual Studio) project files
Hi all, I'm getting repeated questions from other developers at my company about why the project files CMake generates for Visual Studio aren't movable, so I sat down, created a minimal project, switched on the CMAKE_USE_RELATIVE_PATHS flag, and ran cmake. It turns out that there are actually only two places where there still are absolute paths: 1. The description field for custom rule steps. 2. The ProgramDataBaseFileName attribute in the VCCLCompilerTool element. The first issue I can live with, but the second issue shouldn't be too difficult to fix, right? As far as I can see from just studying the source code, its a small matter of changing one method in the cmTarget.cxx file. Are there any other issues which prevent Visual Studio project files from being moved? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] VS makefiles
Steven Van Ingelgem wrote: Hi, I was wondering why there are no VS makefiles? (run like nmake -f project.mak). I know you could run them from the command prompt with something like devenv ..., but that is not exactly the same ;-). Are you just being curious, or do you have a concrete problem you can't solve with devenv? If you want something more lightweight than devenv.com (which actually loads the entire VS IDE) you can try the vcbuild command which is kind of nmake for .vcproj/.sln files, and much faster to start. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
Mike Jackson wrote: http://www.youtube.com/watch?v=4XpnKHJAok8 Git - straight from Linus.. Kinda long but interesting.. as long as you can get past Linus' personality. Here are my two cents: I actually held Linus opinion in rather high regard until he went berzerk on how bad Subversion is. *Please* don't take everything Linus says as The One True Way to version control heaven. Subversion does not fit Linus needs (understandably), but that does not mean the DVCS is suitable for everyone. Those of you who haven't already read Version Control and 'the 80%' should do so (http://blog.red-bean.com/sussman/?p=79) *before* forming your opinion on centralized version control. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] mingw32 linker line exceeds win32 limitations
Felix Obenhuber wrote: On Do, 2007-12-20 at 21:02 +0100, Jesper Eskilson wrote: To be picky, mingw32-make (i.e. GNU make) doesn't mind at all, but cmd.exe might. (Mingw32-make will happily use any bourne-shell it can get its hands on.) You're absolutely right. The problem is, that we're using mingw32 from Code::Blocks. So we would habe to change the default shell to something else than cmd.exe (or patch codeblocks). Unless Code::Blocks has a specially patched GNU make which is hardcoded to cmd.exe there shouldn't be any difficulty to get your make to use sh.exe (Cygwin's, for example). In fact, I've had trouble the other way around; forcing GNU make to use cmd.exe in the presence of Cygwin's sh.exe in PATH. Think other probs will raise due our company workstation setup containins some bat scripts... That is only a problem if you have cmd.exe-specific stuff in your makefile-invocations. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Calling a dynamically created macro
Brandon Van Every wrote: 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. Please let us know when you've implemented a webserver in CMake. ;-) -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] mingw32 linker line exceeds win32 limitations
Felix Obenhuber wrote: Dear CMake developer and users, I've encountered some probs with a an issue whitch already raised last year in the a post [1]. Mingw32-make (5.1.3) minds about a too long linker line. To be picky, mingw32-make (i.e. GNU make) doesn't mind at all, but cmd.exe might. (Mingw32-make will happily use any bourne-shell it can get its hands on.) -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Calling a dynamically created macro
Brandon Van Every wrote: On Dec 20, 2007 2:55 PM, Jesper Eskilson [EMAIL PROTECTED] wrote: Please let us know when you've implemented a webserver in CMake. ;-) It'll never happen. I can't stand the web. I'm a 3D / ASM / AI / game / build system guy. To me, the web has always been the boring stuff that runs slowly. Oh, well. Change webserver to postscript interpreter or real-time raytracer then. ;-) -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compilation speed with CMake/NMake combination, making it faster?
Eric Noulard wrote: 2007/12/11, Jason Stewart [EMAIL PROTECTED]: This is not scientific but I wrote a quick perl script to compile a simple library that we use (GCTPc). It consists of 70 C files with most of the files between 5K and 6K, a few are as large as 70K. The script just uses the time() function to grab the elapsed seconds and runs three tests. The first runs one cl.exe process with all 70 files with the '-c' flag to only compile. The second compiles each C file with it's own invocation of cl.exe. The last repeats the first, but with the new, experimental, '/MP' flag that does multiprocessor builds. I get the following times for these files: all files : 2 seconds single files : 7 seconds mp build : 1 second I repeated this test with a set of 15 C++ files that are larger with template code and that take significantly longer and I got the following times: all files : 60 seconds single files : 78 seconds mp build : 51 seconds So, even on the single processor build the single invocation is almost 25% faster. Take it all with a grain of salt. I'm not a big MS Platform user but I like the idea of compilation speed-up very much. I personnally use ccache (http://ccache.samba.org/) on Linux + gcc and there is x2 up to x4 _SPEEDUP_ (when recompiling since initial compilation is slower) on a C++ project with 50+ files with moderate template usage. Yes, recompiling goes faster, but if you actually have made any changes to the source code (which is often the case when you're compiling ;-)) then ccache won't give you anything. Most people I've seen claim that ccache is useful are people who are stuck with a build system with broken dependencies who need to do make clean a lot. ;-) Actually, ccache comes in its best light when you can use it for sharing build-results. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] question about clock skew detected. Your build may be incomplete
WangPing wrote: The date /time on my local workstation is correct, probably due to NFS system, Do you mean NTP? NFS does not keep your local computer time correct. the work directory is a NFS folder on other server, maybe the date/time on this server is incorrect? I can check it later. NFS is probably the *primary* cause of clock skew, and GNU make can be pretty picky about how close the clocks need to be. (Note that a local clock which is out-of-date won't cause clock skew in itself, since everything will be out-of-date by the same amount.) Also note that if the build succeeds, you probably have nothing to worry about. (Unless you're hacking in the code yourself, then make may have failed to rebuild any out-of-date files.) -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: [Insight-users] question about clock skew detected. Your build may be incomplete
Karthik Krishnan wrote:
Your system time is probably incorrect. One possible reason is that the
timestamp of the files that make is compiling is newer than the current
time.
If the local time is correct and no network filesystems are involved,
then I would guess that there is a file somewhere with a modification
time in the future, but GNU make will notify the user if that is the case:
$ make
cc foo.c -o foo
$ touch --date=tomorrow foo.c
$ make
make: Warning: File `foo.c' has modification time 8.6e+04 s in the future
cc foo.c -o foo
make: warning: Clock skew detected. Your build may be incomplete.
WangPing, can you reproduce this with a trivial makefile?
Makefile:
foo: foo.c
$(CC) $ -o $@
foo.c:
int main() { return 0; }
This does not sound CMake-related to me.
--
/Jesper
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Generating makefile from Visual Studio Project (Migrating to Eclipse)
Olumide wrote: Bill Hoffman wrote: I'm trying to generate a Unix style (or NMake) Makefile that I can use to port my visual studio project to eclipse. I've tried running cmake on the project directory with the -GUnix Makefiles and -GNMake Makefiles option, but its not working -- I'm getting lots of errors. Apparently, I'm missing a number of variables. How can I set these variables? I'd still like to use the Microsoft compiler *but* within the eclipse environment. You need to setup the MS compile to work from the command line. The easy way is to run the visual studio command prompt from the start menu under visual studio tools. Then run cmake from that shell, and it should work. Thanks Bill. Do you mean I should start the command prompt and run devenv or something like that? I dont understand what you mean by run the visual studio command prompt from the start menu under visual studio tools. Am I to launch the command shell from/within visual studio? The command prompt can be found from your start menu: Start Menu - All Programs - Microsoft Visual Studio 2005 - Visual Studio Tools - Visual Studio 2005 Command Prompt. This will give you a regular windows command prompt with all environment variables set up in order for you to be able to run the command-line studio tools (cl, nmake, vcbuild, etc.) -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Generating makefile from Visual Studio Project (Migrating to Eclipse)
Olumide wrote:
Hello -
I'm a CMake newbie and I'd appreciate help creating a makefile *from* a
Visual Studio .NET 2003 project/solution. I'm trying like to migrate my
projects to eclipse and I hope CMake will help make that transition.
Many thanks,
- Olumide
PS: I've already tried creating the config file CMakeLists.txt using
vcproj2cmake.rb ( http://www.eskilson.se/vcproj2cmake.rb ). Below is the
config file generated from a small project -- commenting out the
offending add_locate directives(?). I'm not sure how of what I ought to
do next in order to generate a standard (UNIX) makefile.
I've uploaded a new version of the vcproj2cmake.rb script which does not
emit any add_locale() macros.
#
project( TestTexturePlugin )
set(SOURCES
pluginMain.cpp
)
include_directories(
C:/Program Files/Alias/Maya6.5/include
)
You need double quotes around the path, since it contains spaces.
add_definitions(
-DWIN32,_DEBUG,_WINDOWS,_AFXDLL,_MBCS,NT_PLUGIN,REQUIRE_IOSTREAM
)
No commas between the symbols.
add_library( TestTexturePlugin SHARED ${SOURCES} )
#add_locale( TestTexturePlugin ENU RESFILE )
#add_locale( TestTexturePlugin JPN RESFILE )
target_link_libraries( TestTexturePlugin Foundation OpenMaya )
#
You should be able to run CMake directly on this file. If you're on
Unix, try
$ cd [your project dir]
$ cmake .
--
/Jesper
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug in EXECUTE_PROCESS?
Josef Karthauser wrote: Is this a bug? EXECUTE_PROCESS( COMMAND badcmd_that_doesnt_exist ERROR_VARIABLE ERROR ) IF(ERROR) MESSAGE(FATAL_ERROR Error! Command doesn’t exist.) ENDIF(ERROR) as the fatal_error is never raised. If not, what’s the canonical way of reliably determining whether the process succeeded or failed? Without actually checking the docs, I would guess that ERROR contains the exit code of the process, i.e. non-zero on failure. Try comparing ERROR against 0 instead. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] verbose ADD_CUSTOM_TARGET
James Bigler wrote: Is it possible to force a custom target to be verbose in makefile mode? I know I can turn it on or off for a given project, but I want to do for only a single target (a custom target, in fact). If you're using GNU make you can use target-specific variables: http://www.gnu.org/software/make/manual/make.html#Target_002dspecific I'm not sure exactly how you can inject your own makefile variable assignments into your makefils from within CMake, but I'm sure others on this list can answer that. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake with Lua Experiment
Brandon Van Every wrote: On Nov 28, 2007 2:47 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote: As DSL based on Lua != Lua, assuming Kitware gets rid of documentation and bugs in the language might be too optimistic. Look for example at RHDL (http://rhdl.rubyforge.org/): it's a Ruby-based DSL for hardware description, like Verilog or VHDL, but it's so different from Ruby you need to produce the whole documentation again. So? So far I'm the only person who has proposed changing Lua syntax. I've only listed 2 items: excessive quotes and unpack(table). Nothing would stop anyone from using quotes all over the place or unpack(table), i.e. standard Lua would still work. It may even be possible for these minor tweaks to be transparently corrected as far as 3rd party Lua libraries are concerned. If it's 95% Lua it's still Lua. We're talking about a 1 page addendum to the docs, tops. Talking about Ruby, could someone please paste his wishlist about variable scoping for CMake? (ie what would you like to add: local variables which die when you exit the loop, file-scoped variables, directory-scoped variables, project-scoped variables, what?). It's quite difficult to fix a problem we have not properly defined (at least, I have never seen a proper wishlist about this). I just want scope, i.e. I don't want global variable names crapping all over each other. I don't care about any fancy dancy Computer Science ways of adding extra programmatic features. Other people may see heavy duty OO or tweaky FP constructs as beneficial for their build system. At present I don't. No offense, but you're not really in a position to determine what constructs are benefitial for people in their own build systems. Build systems look very different in different places, and assuming that you know whats best for everybody is a good way to make people want to move away from CMake. Many systems (even the *really* large ones) are actually very simple to their layout; projects are often isomorphic so that each CMakeLists.txt is more or less just a list of files to compile. But other systems (both large and small) are simply to complicated to maintain a build system for without a proper language at your disposal. GCC and the Linux kernel are good examples of the latter (neither of which actually do have a good build system language, but that's another story). But there's clearly a need for more structure than CMake script has got. As far as I'm concerned the fancy dancy stuff is just an artifact of the embedded language that you get for free, whether it's Lua, Ruby, or Python. None of that has been enough to propel SCons into the limelight. No, but having (or being) a real programming language is still one of the main benefits of using SCons (IMO). Still, I went with CMake for our build system, primarily due to the superior support for generating Studio project files, and the fact that SCons has *major* performance issues, especially on Windows. I would like to claim that the input to the build systems (Makefiles, SConsctruct, CMakeLists.txt, etc.) should be considered as source code, with all the implications that has: checked into version control, subject to code quality standards, subject to code review, etc. Given that standpoint, having a real programming language in your build system is very natural. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: setting other compile flag for 1 source file
Cees Wesseling wrote: Hi, It seems that that is frequently requested feature for gcc but alas it is not implemented for gcc. Hence I am looking for another option to disable optimization op a per file level. To specify file-specific compiler flags, use set_source_file_properties: set_source_files_properties(weird-code.c PROPERTIES COMPILE_FLAGS -Wno-funny-opts) -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using gmake with windows CL compiler?
Bill Hoffman wrote: You can also use the GNU make included here: http://unxutils.sourceforge.net/ This is really just a (small) set of unix tools running natively under Windows, using native Windows paths, etc. IMO this is the easiest way to get GNU make for Windows. Don't use the GNU make for Windows at steve.org.uk, this is an old and buggy version (although it is the first result on google). I do this all the time, and use this make: http://www.cmake.org/files/cygwin/make.exe Just replace the cygwin make with the above and it all works. It is actually CVS gnu make with a change that allows the path stuff to work. Just to be complete, there is a nice make installer made available by the GnuWin32 project: http://gnuwin32.sourceforge.net. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Causing cmake to use stderr instead of stdout.
Dizzy wrote: On Monday 19 November 2007 18:37:02 Josef Karthauser wrote: Is it possible (with relative easy) to have cmake send all output to stderr instead of stdout? Well on a bourne shell I think you can do: cmake /path/to/sources 12 And it will run cmake redirecting fd 1 (stdout) to fd 2 (stderr). If you need to further direct the output make sure you write that before 12 part as in: cmake /path/to/sources 2 logfile.txt 12 cmd.exe has limited support for sh-style redirections, so I think you can do things like cmake c:/my/sources log.txt 21 in your regular windows command prompt. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] disabling the cache
Bill Hoffman wrote: So, I did look at how to fix this some. I have a c# program that can force a running visual studio process to close and reload the solution it has. The idea would be to have cmake run this when cmake is run as part of the build. However, visual studio has a neat trick of killing all processes launched as part of a build. So, what happens is the reload c# program closes the solution, and VS kills it before it can reload the project. The only way around this is to run some sort of cmake IDE VS reload server, that cmake can contact and ask it to force a reload. Does this sound worth while? It does to me. I'd love it if the project regeneration worked so that users would not need to build twice for VS to reload the new projects. From that perspective I'd say that it is definitely worthwhile, since it removes a cognitive burden of my users (which ultimately means happier users and less interrupting questions to me). It could also unload/load, and build. However, I am not sure we want to restart the build. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] can't pipe cl.exe in a custom command
Brandon Van Every wrote:
I'm trying to grab the cl.exe banner so I can determine the MSVC
version number. If cl.exe is in the path, then the following works at
a Windows Command Prompt. This gives a short banner with the VC
version number and copyright.
cl /? 2 banner.txt
But when I try to do it in a custom command, I can't get it to pipe to
a file. I see the output go by in the Visual Studio output window,
with 1 prefixed in front of all the lines, and it is saved in
BuildLog.htm, but cbanner.txt has 0 length no matter whether I use
1 2 as the pipe. Does MSVC simply not have a notion of piping or
something? Do I have to do something MSVC-specific to capture the
output or the error?
IF(MSVC)
ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_BINARY_DIR}/cbanner.txt
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
COMMAND ${CMAKE_C_COMPILER} /? 2 cbanner.txt
)
ADD_CUSTOM_TARGET(cbanner ALL
DEPENDS ${CMAKE_BINARY_DIR}/cbanner.txt
)
ENDIF(MSVC)
This is a feature in Visual Studio 8, which drove me nuts before I
realized what was going on. The short story is that cl sends its output
via a backchannel (a pipe, presumable) to the output window when run
from inside Visual Studio, so redirection does not work (there is
nothing to redirect). To get around this, you need to clear the
environment variable VS_UNICODE_OUTPUT before invoking cl.exe.
The longer story (with some useful links):
http://thisisnotaprogrammersblog.blogspot.com/2007/05/redirecting-output-from-compilerlinker.html
--
/Jesper
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] disabling the cache
Andreas Pakulat wrote: On Mittwoch, 31. Oktober 2007, Jesper Eskilson wrote: BTW: Are there any plans of fixing the broken regeneration for Visual Studio? Or at least documenting it as known problem? As it is now, the project files are regenerated but not reloaded, and there is no feedback that the new project files aren't used for the build. How exactly should cmake fix a bug in Visual Studio? As far as I understood this thread the problem is that VS doesn't get that its project files have changed and thus doesn't reload them. I suggest to contact your MS support contact. Visual Studio *does* reload the project files, but not *during* a build. If any project files are modified during a build, they are reloaded *after* the build is complete. I'm not sure if I would call this a bug, even if it conjunction with cmake causes a breakage when cmake tries to regenereate project files. In any case, the automatic regeneration of project files *does* *not* *work*, and my question was simply if there was a plan for either doing something about it (such as disabling it per default, which would be a sensible thing to do, IMHO), and/or documenting that it is broken. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] disabling the cache
Andreas Pakulat wrote: On 01.11.07 10:49:12, Jesper Eskilson wrote: In any case, the automatic regeneration of project files *does* *not* *work*, and my question was simply if there was a plan for either doing something about it (such as disabling it per default, which would be a sensible thing to do, IMHO), and/or documenting that it is broken. So far you're the only one claiming that (in this thread), I suggest to come up with a small sample project where changing the CMakeLists.txt doesn't trigger a cmake run. If you've got that you can file a bugreport against cmake. Did you actually read my post before replying? I'm not claiming that cmake does not regenerate the project files. I'm not claiming that Visual Studio does not reload the projects files. What I'm claiming is that ***the project files aren't reloaded until the build already has completed***, meaning that I need to build ***again*** to make sure that the changes to my CMakeLists.txt actually make it into Visual Studio. This can be demonstrated with the most trivial of CMakeLists.txt files: --- project(foo) add_executable(foo foo.c) --- 1. Run CMake 2. Open solution in Visual Studio 3. Build 4. Add a file, say bar.c, to the CMakeLists.txt file 5. Build (this triggeres a cmake rebuild) 6. Build completes, but bar.c is NOT included in the build. 7. Visual Studio asks if I want to reload the project files I don't think I can make myself clearer than this. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] disabling the cache
Hi people, Is there a way to disable the CMake cache, i.e. prevent CMake from generating or reading CMakeCache.txt? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] disabling the cache
Bill Hoffman wrote: Jesper Eskilson wrote: Hi people, Is there a way to disable the CMake cache, i.e. prevent CMake from generating or reading CMakeCache.txt? No. But, it might help more if you gave an explanation of what you are trying to do? The first problem is that the Visual Studio generator fails to properly rerun CMake when CMakeLists.txt. It reruns CMake, but the modified projects files are not reloaded before continuing with the build. The second problem I have is that my users (the other people in my development team) don't know when they have to rerun CMake and/or remove the CMakeCache.txt file. If rerunning CMake from inside Visual Studio worked, half the problem would be solved, but there is still the problem of knowing when you need to clean out the cache. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] disabling the cache
Bill Hoffman wrote: OK, so you want to disable the rerun of CMake, not the cache. That can be done with the CMAKE_SUPPRESS_REGENERATION variable. (set it to TRUE). Yes, I know how to use this variable. You should never have to clear out the cache. If I make a change in CMakeLists.txt which should cause a (cached) variable to change its value, don't I have to delete the cache for the new value to be calculated? Say that I use FIND_PROGRAM() to locate a program. If the program has moved, how can CMake know that the value in the cache has to be recalculated? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] disabling the cache
Bill Hoffman wrote:
For this case, you could have something like this:
# if SOME_PROGRAM has a value but the program has been moved
# or removed from the system, then clear the cache entry
# so that find_program will try again.
if(SOME_PROGRAM AND NOT EXISTS ${SOME_PROGRAM})
set(SOME_PROGRAM NOTFOUND CACHE FORCE some program)
endif(SOME_PROGRAM AND NOT EXISTS ${SOME_PROGRAM})
find_program(SOME_PROGRAM myprog)
So, if you know that you are changing a cmakelist file in a way that
requires something to be removed from the cache, just remove it, but be
careful not to remove it all the time.
Ouch. My cmake files are unreadable enough without an added 3 lines here
and there checking if the cache entry needs to be replaced or not.
BTW: Are there any plans of fixing the broken regeneration for Visual
Studio? Or at least documenting it as known problem? As it is now, the
project files are regenerated but not reloaded, and there is no feedback
that the new project files aren't used for the build.
--
/Jesper
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] environment variables and visual studio
Sylvain Benner wrote: Is there any way for CMake to set environment variables which can be picked up in Visual Studio's pre/post-build steps? I'm working on a system where I've got a couple of studio project included via the INCLUDE_EXTERNAL_MSPROJECT(), and I would like to be able to refer to things like CMAKE_BINARY_DIR, so that the external msprojects can put their output relative to the CMake build dir. You can still generate the projects you are including with the INCLUDE_EXTERNAL_MSPROJECT. It make sense since they are part of your CMake framework (you want to rely on CMake variables). No, I can't. The reason I don't generate them is that they have to be portable since they are shipped to customers as a part of an SDK, and as I understand it the project files CMake generates are not portable/movable (due to absolute paths, etc). At start, it can be a lot of work to write the CMakeLists.txt for each projects but you need to do it only once. I actually had CMakeLists.txt for the projects, but had to discard them for the reason above. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] environment variables and visual studio
Bill Hoffman wrote: Jesper Eskilson wrote: Is there any way for CMake to set environment variables which can be picked up in Visual Studio's pre/post-build steps? I'm working on a system where I've got a couple of studio project included via the INCLUDE_EXTERNAL_MSPROJECT(), and I would like to be able to refer to things like CMAKE_BINARY_DIR, so that the external msprojects can put their output relative to the CMake build dir. No, this is not possible. CMake is no longer running when the project is built. I do not think there is a way to set variables in the .sln file which is where they would have to be set. I was afraid you might say that. Oh, well, I'll have to think of another solution. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] environment variables and visual studio
Is there any way for CMake to set environment variables which can be picked up in Visual Studio's pre/post-build steps? I'm working on a system where I've got a couple of studio project included via the INCLUDE_EXTERNAL_MSPROJECT(), and I would like to be able to refer to things like CMAKE_BINARY_DIR, so that the external msprojects can put their output relative to the CMake build dir. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Ignoring return codes on ADD_CUSTOM_COMMAND (hhc.exe)
Stefan Buschmann wrote:
Hi all,
I'm currently having a problem using the HTMLHelp Compiler (hhc.exe) in
my CMake-Scripts. I build the doxygen docs, then call hhc.exe and the
.chm file is created correctly.
But hhc.exe seems to return an error code, so the build has failed and
my post-build commands are not invoked.
1) Did anyone have similar problems with hhc.exe?
Yes.
Any ideas why hhc.exe
is returning an error code although the .chm file is generated correctly
and there are no error messages on the output?
No. Afaik, you can't use the error code for anything.
2) Is there a way to tell ADD_CUSTOM_COMMAND to ignore the return value
of the process and consider it as always successfull?
I couldn't find any, so I used a Ruby script wrapper to invoke hhc.exe
and ignore the return value:
if not system((ARGV.collect do |s| \#{s}\ end).join( ))
puts Command failed, ignoring exit code.
end
--
/Jesper
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Weird error message
What does the following error message mean: Re-run cmake no build system arguments -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Visual Studio 8
Hi, If I tell CMake to generate Visual Studio 8 project files, CMake requires that the right cl.exe can be found in PATH. More specifically, if the wrong cl.exe is found in PATH (say from Visual Studio 7), then CMake just pukes with some strange error. This confuses several of my users (who commonly have VS7 first in their path); they expect that CMake should chose the right compiler since they have selected the Visual Studio 8 generator. I can understand how and why this happens, but is there a reason for not fixing CMake such that it finds the correct compiler? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Project being (unnecessarily) relinked
Jesper Eskilson wrote: Mike Jackson wrote: On Sep 11, 2007, at 3:03 AM, Jesper Eskilson wrote: A related question: if I include an external project in my solution using include_external_msproject(Bar ../../Bar/Bar.vcproj) can I later refer to this project using target_link_libraries(Foo Bar) More generally, what is the correct way to specify that a CMake target should be linked with some external library? It is this last question I would like to get an answer to. Say you have another project that produces a library called libBar.dll and that library is located in C:\Libs then you can refer to that library in CMake directly. In other words, the cmake code you have is absolutely correct: Target_link_Libraries(Foo Bar) with the following caveat: libBar.dll MUST be in a known directory that the linker will look in. You can make sure of this by adding the following cmake code above the target_link_libraries code: LINK_DIRECTORIES (C:\Libs) Ah. So if libBar.dll and libBar.lib are in different directories, *both* directories must be added using LINK_DIRECTORIES(), right? That should be documented somewhere (if it is, I've managed to miss it). After testing this, it appears that I still get the same relinking behavior. In this particular case, the import lib and the dll actually have different names: libfoo-1.lib libfoo-1_5_1.dll In case that would make a difference. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Project being (unnecessarily) relinked
Jesper Eskilson wrote:
Jesper Eskilson wrote:
Mike Jackson wrote:
On Sep 11, 2007, at 3:03 AM, Jesper Eskilson wrote:
A related question: if I include an external project in my solution
using
include_external_msproject(Bar ../../Bar/Bar.vcproj)
can I later refer to this project using
target_link_libraries(Foo Bar)
More generally, what is the correct way to specify that a CMake
target should be linked with some external library?
It is this last question I would like to get an answer to.
Say you have another project that produces a library called
libBar.dll and that library is located in C:\Libs then you can refer
to that library in CMake directly. In other words, the cmake code you
have is absolutely correct:
Target_link_Libraries(Foo Bar)
with the following caveat: libBar.dll MUST be in a known directory
that the linker will look in. You can make sure of this by adding the
following cmake code above the target_link_libraries code:
LINK_DIRECTORIES (C:\Libs)
Ah. So if libBar.dll and libBar.lib are in different directories,
*both* directories must be added using LINK_DIRECTORIES(), right?
That should be documented somewhere (if it is, I've managed to miss it).
After testing this, it appears that I still get the same relinking
behavior.
Well, that turned out to be a little hasty conclusion.
In case of linking with a DLL, having paths to both the dll and import
lib in LINK_DIRECTORIES avoids relinking. So far, so good.
However, I still get relinks due to a dependency on a static library. In
this case, I'm unable to add the path using LINK_DIRECTORIES since the
path is different depending on the configuration. I'm currently adding
the path using the LINK_FLAGS_{DEBUG, ...} target property (which
probably is the cause of the relinking).
So, I would like to be able to do something like, given the debug
version of MyStaticLib.lib is in lib/win32/debug:
LINK_DIRECTORIES_DEBUG(lib/win32/debug)
TARGET_LINK_LIBRARIES(Foo MyStaticLib)
To make things more difficult, I cannot do something like:
LINK_DIRECTORIES(lib/win32/$(ConfigurationName))
because the configurations available for the static library
(MyStaticLib.lib) do not map cleanly on the values for $(ConfigurationName).
frustration
Argh! Why can't things every be simple?!
/frustration
Any hints on how to solve this?
--
/Jesper
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Project being (unnecessarily) relinked
Jesper Eskilson wrote: Mathieu Malaterre wrote: On 9/4/07, Jesper Eskilson [EMAIL PROTECTED] wrote: Hi! I've got a Visual Studio 8 solution generated by CMake where one of the projects is always being relinked everytime I build it, even when nothing in it has changed (i.e. if I try to build it twice, it always relinks the project the second time). I've studied the build logs, but they do not make me any wiser. Does anyone recognize this behavior? wild guess Circular dependencie ? /wild guess I am not sure if outputing the depencie graph with graphiz could show that, since it only output high level dep (libs/executable) I think I've located the problem. The project in question uses target_link_library() in a possibly non-kosher way: target_link_library(Foo Bar.lib) That is, the top-level target Foo should include Bar.lib on its command line. This seems to work insofar that it actually performs the link correctly, but for some reason it always relinks as well. A related question: if I include an external project in my solution using include_external_msproject(Bar ../../Bar/Bar.vcproj) can I later refer to this project using target_link_libraries(Foo Bar) More generally, what is the correct way to specify that a CMake target should be linked with some external library? I'm still very much interested in an answer to this question. -- /Jesper -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Project being (unnecessarily) relinked
Mathieu Malaterre wrote: On 9/4/07, Jesper Eskilson [EMAIL PROTECTED] wrote: Hi! I've got a Visual Studio 8 solution generated by CMake where one of the projects is always being relinked everytime I build it, even when nothing in it has changed (i.e. if I try to build it twice, it always relinks the project the second time). I've studied the build logs, but they do not make me any wiser. Does anyone recognize this behavior? wild guess Circular dependencie ? /wild guess I am not sure if outputing the depencie graph with graphiz could show that, since it only output high level dep (libs/executable) I think I've located the problem. The project in question uses target_link_library() in a possibly non-kosher way: target_link_library(Foo Bar.lib) That is, the top-level target Foo should include Bar.lib on its command line. This seems to work insofar that it actually performs the link correctly, but for some reason it always relinks as well. A related question: if I include an external project in my solution using include_external_msproject(Bar ../../Bar/Bar.vcproj) can I later refer to this project using target_link_libraries(Foo Bar) More generally, what is the correct way to specify that a CMake target should be linked with some external library? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Visual Studio reload projects
Torsten Martinsen wrote: gga wrote: KSpam wrote: I agree that this is a Visual Studio issue; however, I am wondering if anyone knows a workaround. I am not a Windows developer, but I figured that someone on this list would have found a reasonable solution. Sure. Don't use Visual Studio. Stick to nmake and a good editor like emacs. You'll be a happier person in the long run. I, too, use Emacs. However, do not be oblivious to the fact that an nmake build can take around five times longer than an IDE build. Performance is one reason, yes -- especially in these multicore times; nmake cannot handle parallell builds -- but the most (or only) compelling reason to use Visual Studio as opposed to Emacs + command line builds is that the Visual Studio debugger is superior to all other debuggers available on Windows. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Project being (unnecessarily) relinked
Hi! I've got a Visual Studio 8 solution generated by CMake where one of the projects is always being relinked everytime I build it, even when nothing in it has changed (i.e. if I try to build it twice, it always relinks the project the second time). I've studied the build logs, but they do not make me any wiser. Does anyone recognize this behavior? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Including .h files in Visual Studio projects
2007/6/25, Jesper Eskilson [EMAIL PROTECTED]: Hi all, I'm trying to get our header files to show up in Visual Studio. I though I could just do add_library(foo foo.cpp foo.h) but Visual Studio tries to compile my header file as if it was a .cpp file. What am I doing wrong? -- /Jesper Since nobody seems to have answered, shall I assume that I there is no way to get header files to appear in a studio project? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] library dependencies
2007/7/2, Alexander Neundorf [EMAIL PROTECTED]: On Monday 02 July 2007 08:05, Jesper Eskilson wrote: Hi all, Is there a way to extract the list of library dependencies specified by target_link_libraries for a target? I would like to be able to pass the list of libraries to an external script at build time. Does export_library_dependencies() help ? You could use it to put the information in a text file which could then be used at buildtime by other tools/scripts. No; export_library_dependencies does not include link dependencies for executables. I've solved it by wrapping target_link_libraries in a macro, and storing the dependencies in a variable which I can pass around as I like. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Improved FindSWIG.cmake
Hi, When can the improvements discussed in bug #4145 be expected to make it into a CMake release? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Including .h files in Visual Studio projects
Hi all, I'm trying to get our header files to show up in Visual Studio. I though I could just do add_library(foo foo.cpp foo.h) but Visual Studio tries to compile my header file as if it was a .cpp file. What am I doing wrong? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] creating static library with references to other .lib files
2007/6/14, David Cole [EMAIL PROTECTED]: It's advanced CMake use, but you might want to have a look at overriding the CMake rule variable CMAKE_CXX_CREATE_STATIC_LIBRARY. (Or _C_ if it's C source code.) You should be able to add some linker flags in there, although they may apply to all static libraries built in the whole project. I'm not 100% clear myself on how these rule variables work... Perhaps somebody else who has used a technique like this can chime in? Setting CMAKE_CXX_CREATE_STATIC_LIBRARY has no effect on the generated vcproj file. In fact, the value set by CMake in CMakeCXXInformation.cmake does not seem to be used in the vcproj file. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] creating static library with references to other .lib files
2007/6/15, kitts [EMAIL PROTECTED]: On Thursday 14 Jun 2007 12:23:07 pm Jesper Eskilson wrote: Is it really impossible to pass an option to the linker when creating a static library? I have not gone through the whole thread but i think the function SET_TARGET_PROPERTIES(TARGET LINK_FLAGS XYZ) can do it. The problem i foresee is that when you pass another library as a source file to a library, cmake may not pass this file as an argument when building your library. Setting the LINK_FLAGS property does not work. CMake keeps track of the dependency, so everything works nice inside CMake, but not when we ship the library to our customers (since they only link with the original library). -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] directory structure on Windows
Hi, In my CMake installation on Windows, there are two directory with seemingly identical contents: c:/Program Files/CMake 2.4/share/CMake c:/Program Files/CMake 2.4/share/cmake-2.4 Could someone care to explain the difference? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] creating static library with references to other .lib files
2007/6/14, Brandon Van Every [EMAIL PROTECTED]: On 6/13/07, Jesper Eskilson [EMAIL PROTECTED] wrote: 2007/6/13, Brandon Van Every [EMAIL PROTECTED]: But why don't you just ship your users a dynamic lib? As far as I know, there are no restrictions on dynamic libs including static libs. That is an alternative, but it requires a non-trivial amount of work, testing, documentation fixes etc., which I'd prefer not to embark on at the moment. I take it you have no infrastructure for dynamic libs at all in your code then? Because if you did, like all your declspecs and so forth, it's pretty easy to add in CMake. The problem isn't CMake in that case, it's updating all the stuff around it which assumes that the lib is static: documentation (the lib is part of a SDK shipped to customers), testing, etc. That's not something I want to do at this time. Is it really impossible to pass an option to the linker when creating a static library? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Fwd: [CMake] creating static library with references to other .lib files
Forgot to cc the list. -- Forwarded message -- From: Jesper Eskilson [EMAIL PROTECTED] Date: 2007-jun-13 19:56 Subject: Re: [CMake] creating static library with references to other .lib files To: Brandon Van Every [EMAIL PROTECTED] 2007/6/13, Brandon Van Every [EMAIL PROTECTED]: Ok, so MSVC can do it, but AR can't. So I guess you only care about MSVC. Yes. Sorry, I forgot to say that. What you're asking for seems kinda weird. What's the motive? foo.obj and bar.obj uses symbols in mydll.dll, and I want to allow users of mystatic.lib to just have to link with mystaticlib.lib, and not with mydll.lib. But why don't you just ship your users a dynamic lib? As far as I know, there are no restrictions on dynamic libs including static libs. That is an alternative, but it requires a non-trivial amount of work, testing, documentation fixes etc., which I'd prefer not to embark on at the moment. I'm actually happy if I just can get hold of a CMake variable where I can put extra flags to pass to lib when creating a static lib. Something like set(CMAKE_STATIC_LINKER_FLAGS ...) -- /Jesper -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] creating static library with references to other .lib files
2007/6/7, Jesper Eskilson [EMAIL PROTECTED]: 2007/6/7, Brandon Van Every [EMAIL PROTECTED]: On 6/7/07, Jesper Eskilson [EMAIL PROTECTED] wrote: Hi all, I would like to be able to create a static library on Windows which includes an import library to a DLL, so that users of the static library do not need to specify the import library. By chance, is your library a C library that is commonly available to the public, i.e. is typically present in Linux or Cygwin distributions and whatnot? If so, you have a problem that will likely sidestep the issue / render it moot. Regardless of the choice of linkage, you could suffer a namespace collision between the version you're maintaining in your own code, and the publically available version. Segfaults etc. Here's the issue in our bug tracker that we haven't resolved yet, it gives a lot of detail as to what kinds of things can go wrong. http://trac.callcc.org/ticket/215 I think we have all our bases covered, but thanks anyway. I'm still interested in a solution to my original problem, though. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] visual studio converter?
2007/6/12, Alexander Neundorf [EMAIL PROTECTED]: Hi Jesper, On Thursday 07 June 2007 08:38, Jesper Eskilson wrote: ... I've written a simple hack in Ruby which extracts the most vital parts of a .vcproj file and generates a corresponding CMakeLists.txt. There are a lot of things it doesn't handle (custom build steps, multiple configurations, etc.), but its a good starting point. Feel free to use it; but I make no guarantees. It shouldn't wipe your harddrive, though. I hope. ;-) can you please put this converter or a link to it in the cmake wiki ? It should go in this section: http://www.cmake.org/Wiki/CMake#Converters_from_other_buildsystems_to_CMake Done. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] creating static library with references to other .lib files
2007/6/12, Brandon Van Every [EMAIL PROTECTED]: On some platforms, I bet the underlying linker AR can't even do it. I know it can't put static libraries inside of static libraries, thats' why everyone wants convenience libraries and I had to work on all that object file fakery. Possibly it can't take a DLL stub .lib either. So, if there is a solution for some platforms, it's not likely to be portable. I don't know what the MSVC linker can accomplish. Would suggest reading the MSVC docs to make sure it can be done. I *know* that it can be done, since our current hand-written .vcproj files do it. I simply want CMake to allow me to create a static library using a command line such as: lib /out:mystaticlib.lib foo.obj bar.obj mydll.lib where mydll.lib is an import lib for mydll.dll. What you're asking for seems kinda weird. What's the motive? http://www.cmake.org/mailman/listinfo/cmake foo.obj and bar.obj uses symbols in mydll.dll, and I want to allow users of mystatic.lib to just have to link with mystaticlib.lib, and not with mydll.lib. Note that an import library on Windows *is* a static library (both having the .lib suffix is not a coincidence). The only special thing with an import library is that it exports symbols with a note that the symbol really should be found at runtime in the given dll. So, lib /out:foo.lib bar.obj fie.lib puts all the contents of bar.obj and fie.lib into foo.lib. This is very practical. Hope that makes it a little clearer. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] visual studio converter?
2007/6/6, Sylvain Benner [EMAIL PROTECTED]: Jon W a écrit : Are there any tools available to convert Visual Studio files to cmakelists.txt? I have hundreds of vcproj files and this would help make the conversion to cmake easier. I don't know if there are some tools to do this. If you don't find any tool and you have some knowledge about jscript you can do a customized wizard for Visual Studio; it's pretty quick to do. In VS2005, to create a new custom wizard: File - New - Project In General section choose Custom Wizard. I've written a simple hack in Ruby which extracts the most vital parts of a .vcproj file and generates a corresponding CMakeLists.txt. There are a lot of things it doesn't handle (custom build steps, multiple configurations, etc.), but its a good starting point. Feel free to use it; but I make no guarantees. It shouldn't wipe your harddrive, though. I hope. ;-) -- /Jesper vcproj2cmake.rb Description: Binary data ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] creating static library with references to other .lib files
Hi all, I would like to be able to create a static library on Windows which includes an import library to a DLL, so that users of the static library do not need to specify the import library. CMake does not allow me to do this. TARGET_LINK_LIBRARIES( FooLib BarLib ) does not work when creating static libraries. SET_TARGET_PROPERTIES( FooLib PROPERTIES LINK_FLAGS_RELEASE BarLib ) does not work either. What to do? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] creating static library with references to other .lib files
2007/6/7, Brandon Van Every [EMAIL PROTECTED]: On 6/7/07, Jesper Eskilson [EMAIL PROTECTED] wrote: Hi all, I would like to be able to create a static library on Windows which includes an import library to a DLL, so that users of the static library do not need to specify the import library. By chance, is your library a C library that is commonly available to the public, i.e. is typically present in Linux or Cygwin distributions and whatnot? If so, you have a problem that will likely sidestep the issue / render it moot. Regardless of the choice of linkage, you could suffer a namespace collision between the version you're maintaining in your own code, and the publically available version. Segfaults etc. Here's the issue in our bug tracker that we haven't resolved yet, it gives a lot of detail as to what kinds of things can go wrong. http://trac.callcc.org/ticket/215 I think we have all our bases covered, but thanks anyway. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] install phase policies
Hi all, I'm wondering about how (large) CMake projects handle the install phase with respect to incremental building and debugging. Do people always install before running/testing/debugging, or is it common to be able to run/test/debug directly from the build output directory? I would ideally like to be able to place executables/dlls etc. in a position such that the can be run directly without having to do the install phase, but CMake does not let me specify the output directory on a per-target basis. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] defining my own build type
Hi all, I tried following the instructions on the wiki on how to define my own build type (configuration), however the new build type (Develop) does not show up as a valid solution configuration in Visual Studio. Why is that? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] defining my own build type
2007/5/18, Joshua Jensen [EMAIL PROTECTED]: Jesper Eskilson wrote: Hi all, I tried following the instructions on the wiki on how to define my own build type (configuration), however the new build type (Develop) does not show up as a valid solution configuration in Visual Studio. Why is that? Custom build types don't work under Visual Studio. The following patches (not really a patch but the best I could do at the moment) gives you custom build types under Visual Studio. These are against latest CVS. This isn't really critical right now, but it will be. Will this make it into the next release, and if so, when will that be? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] failing post-build command
Hi all, If a post-build command fails, the associated target is not rebuilt (This holds at least for the NMake and Visual Studio generators). This is very annoying, as it makes it impossible to be sure that everything is in place unless I do a complete rebuild. Is there any way to fix this? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] makefile generator
2007/4/18, Bill Hoffman [EMAIL PROTECTED]: Jesper Eskilson wrote: Hi all, I'm curious about the design of the current makefile generator, and why it was designed the way it was. I've tried searching the mailing list archive, but without any greater success. One question pops to mind: why invoke use so many levels of recursive make? I counted at least three levels on my project, where the leaf make process only compiles a single file (!), where each make process does the complete phase of parsing, building up a dependency tree, etc. I believe GNU make is smart enough to not start a new process for each recursive make, but NMake is definitely not. A ran a quick and simple benchmark, showing that the overhead for each nmake invokation is at least 0.1-0.2 seconds, which for large projects quickly scales up to minutes. Why use recursive make calls at all? I will let Brad King answer this in full if he has time. But basically, it has to be done this way in order to support correct dependency scanning with generated files. A single pass make can not check for missing files and will error out if a depend file is deleted. There are other issues as well, but to support the features, like generated files, not failing to build when .h files are removed, it has to be this way. gmake can handle some of this stuff, but cmake is meant to work with any make. -Bill Can you (or anyone else) elaborate on this? What features are abscent from other makes which are necessary to avoid recursive make calls? I've got a fair amount of experience of writing complex makefiles for gmake, but very little experience with other makes. I like fast incremental builds over the entire project, i.e. I would like to be able to do make all' and have it completed in under 2-3 seconds. In Visual Studio this is impossible, but my hope was the that Makefile generator could get me somewhere around that mark. (I'm trying to figure out how much effort it would be to write my own generator, but I'm not sure what backend build engine I should target, if I should write it from scratch, or try to adapt one of the existing generators). Anyway, despite some of its quirks, CMake is great. The simple fact that cmake gets me away from visual studio project files is worth alot. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] makefile generator
2007/4/19, Bill Hoffman [EMAIL PROTECTED]: Jesper Eskilson wrote: Can you (or anyone else) elaborate on this? What features are abscent from other makes which are necessary to avoid recursive make calls? I've got a fair amount of experience of writing complex makefiles for gmake, but very little experience with other makes. I like fast incremental builds over the entire project, i.e. I would like to be able to do make all' and have it completed in under 2-3 seconds. In Visual Studio this is impossible, but my hope was the that Makefile generator could get me somewhere around that mark. (I'm trying to figure out how much effort it would be to write my own generator, but I'm not sure what backend build engine I should target, if I should write it from scratch, or try to adapt one of the existing generators). Anyway, despite some of its quirks, CMake is great. The simple fact that cmake gets me away from visual studio project files is worth alot. Here is a simple example: foo: foo.h If you remove foo.h, make will give an error that foo.h does not exist and fail to build. Cmake does the following to get around this: make check_build_system (check for missing files etc, this step could regenerate all makefiles) At this point you have to run another make, because all of the makefiles may have been changed. Gmake will reload changed makefiles, but nmake and other makes will not. Look back at Brad's steps : 1.) Top level invoked by user. Check build system integrity. 2.) Inter-target dependency rules. Build targets in a valid order. 3.) Intra-target dependency rules for a single target. a.) Update generated sources. Update implicit dependencies (do scanning if necessary). b.) Build sources and link target. These steps are unavoidable. I would not waste your time with a new generator, it will not have full functionality. I actually was thinking about not generating makefiles at all, but look into some other backend build engine. Using Ant crossed my mind. We really tried to eliminate recursive make, and have considered writing a paper why recursive make is a necessary evil to counter the popular but misleading why recursive make is bad.The makefiles we have still handle inter-target depends at a high level and do not depend on the order of recursive make to build things correctly. However, do to generated file issues and dependency maintenance you still have to invoke more copies of make. -Bill Ok, thanks. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] makefile generator
Hi all, I'm curious about the design of the current makefile generator, and why it was designed the way it was. I've tried searching the mailing list archive, but without any greater success. One question pops to mind: why invoke use so many levels of recursive make? I counted at least three levels on my project, where the leaf make process only compiles a single file (!), where each make process does the complete phase of parsing, building up a dependency tree, etc. I believe GNU make is smart enough to not start a new process for each recursive make, but NMake is definitely not. A ran a quick and simple benchmark, showing that the overhead for each nmake invokation is at least 0.1-0.2 seconds, which for large projects quickly scales up to minutes. Why use recursive make calls at all? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] using cl.exe with GNU make
What is the easiest way of using cl.exe with one of the GNU make based generators? I've tried cmake -G MinGW Makefiles -DCMAKE_C_COMPILER=cl.exe ... but could never really get it to work. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
