Re: [CMake] lexical comparison of cmake version numbers

2006-09-21 Thread Alexander Neundorf
Original-Nachricht Datum: Thu, 21 Sep 2006 23:15:36 -0700 Von: "Brandon J. Van Every" <[EMAIL PROTECTED]> An: cmake Betreff: [CMake] lexical comparison of cmake version numbers > I would like more direct access to the CMake version number, and the > ability to make easy lexica

[CMake] lexical comparison of cmake version numbers

2006-09-21 Thread Brandon J. Van Every
I would like more direct access to the CMake version number, and the ability to make easy lexical comparisons between version numbers. Typically, this is so I can test the current release version of CMake, and CMake CVS, using the same CMakeLists.txt. I have workarounds for various bugs in CM

Re: [CMake] The input line is too long (MinGW)

2006-09-21 Thread Martin Dobias
On 9/21/06, Brad King <[EMAIL PROTECTED]> wrote: Martin Dobias wrote: > I try to build executable in my project (using about 150 source files) > with CMake and MinGW. When it comes to linking I get an error message > from system saying: > > The input line is too long. What version of CMake are y

[CMake] Escaping $

2006-09-21 Thread Kedzierski, Artur CIV NAVSURFWARCENDIV CORONA
Hi, I am trying to create FooConfig.cmake by having FooConfig.cmake.in and running CONFIGURE_FILE(FooConfig.cmake.in FooConfig.cmake) on it. In FooConfig.cmake.in, I have something like: SET(MY_LOCAL ${CMAKE_INSTALL_PREFIX}/include/foo) IF (WIN32) SET(MY_LOCAL \$(M

Re: [CMake] Extensionless Headers, and Non-compiled SOURCE_GROUP files

2006-09-21 Thread Jacob Foshee
That fixed it.  Well done!  The vcproj looks much cleaner now.(-=On 9/21/06, Brad King <[EMAIL PROTECTED] > wrote:Jacob Foshee wrote:> Howdy,> I'm helping out with the CMake build for OpenSceneGraph.  OSG follows > the standard practice of using extensionless headers for common> interfaces.  We wou

[CMake] Xcode and library search paths

2006-09-21 Thread Anders Sundman
Hi all! Xcode and CMake works fine for me with one (minor) exception. When I build my Xcode project with CMake and then compile i get the following warning: Tool:0: warning -L: directory name (/usr/local/lib/Debug) does not exist It looks like CMake adds the entry: /usr/local/lib/$(CONFIGURATIO

Re: [CMake] 3rd party modules

2006-09-21 Thread David Cole
They could be installed anywhere they want to be as long as the corresponding FindFoo and FindBar look for them there. :-) Also consider this: Foo 1.0 Foo 1.2 Foo 1.4 All installed on the same machine... Ideally, each one should have a FooConfig -- then FindFoo has to choose the "latest on

RE: [CMake] 3rd party modules

2006-09-21 Thread Kedzierski, Artur CIV NAVSURFWARCENDIV CORONA
Thanks Brad. Let's say for project Foo and project Bar, I've created a FooConfig.cmake and BarConfig.cmake. Project Foo uses Cmake but Bar doesn't. During the installation, where should Foo and Bar place the Config.cmake so that another project's CMake can easily find it? Consider t

Re: [CMake] Dependencies check failure

2006-09-21 Thread Alexander Neundorf
Original-Nachricht Datum: Thu, 21 Sep 2006 14:39:27 +0200 Von: "Ebersold André" <[EMAIL PROTECTED]> An: Alexander Neundorf <[EMAIL PROTECTED]> Betreff: Re: [CMake] Dependencies check failure > Thanks a lot it works fine. > So is it necessary to have a dependency to the source f

Re: [CMake] [MISC] CMake support for enscript

2006-09-21 Thread Brad King
Tristan Carel wrote: > Enscript highlightning system does not support CMake source files in > the last version and Google told me anyone has written the required > file `cmake.st'. > > So I made a very naive one Cool! > Maybe this could be added to the CMake wiki. You're welcome to create a Wik

Re: [CMake] Extensionless Headers, and Non-compiled SOURCE_GROUP files

2006-09-21 Thread Brad King
Jacob Foshee wrote: > Howdy, > I'm helping out with the CMake build for OpenSceneGraph. OSG follows > the standard practice of using extensionless headers for common > interfaces. We would like all headers to show up in the project files > (e.g. vcproj). For the SOURCE_GROUP command to work, the

[CMake] Extensionless Headers, and Non-compiled SOURCE_GROUP files

2006-09-21 Thread Jacob Foshee
Howdy,I'm helping out with the CMake build for OpenSceneGraph.  OSG follows the standard practice of using extensionless headers for common interfaces.  We would like all headers to show up in the project files (e.g. vcproj).  For the SOURCE_GROUP command to work, the files must be listed in the AD

[CMake] [MISC] CMake support for enscript

2006-09-21 Thread Tristan Carel
Hi CMake users, Enscript (http://www.codento.com/people/mtr/genscript) is, I guess, one of the most powerful pretty printing tool for code. It's used by many other programs which need syntax highlightning. It can generate nice documents in several format (ps, html, rtf...) Enscript highlightning

Re: [CMake] Re: TRY_COMPILE painful for tool testing

2006-09-21 Thread Arjen Markus
Like I promised, here is the information I have on this bug: A simple Fortran program: ! Program to test the CMake utility ! - support for CVF? ! program hello write(*,*) 'Hello' end program And an equally simple CMakeLists.txt: project (HELLO) enable_language(Fortran) add_ex

Re: [CMake] Re: TRY_COMPILE painful for tool testing

2006-09-21 Thread Arjen Markus
Brad King wrote: Arjen Markus wrote: I am running into very similar problems with the Compaq Visual Fortran compiler on Windows: When CMake tests if this is an acceptable compiler, the generated makefile contains partly Windows-style paths (c:\...) and partly UNIX-style (c:/

Re: [CMake] Re: TRY_COMPILE painful for tool testing

2006-09-21 Thread Brad King
Arjen Markus wrote: > I am running into very similar problems with the Compaq Visual Fortran > compiler on Windows: > > When CMake tests if this is an acceptable compiler, the > generated makefile contains partly Windows-style paths (c:\...) and > partly UNIX-style (c:/). Are you saying tha

Re: [CMake] A cmake-2.4.3 segfault that is caused by a circular chain of library dependencies

2006-09-21 Thread Brad King
Alan W. Irwin wrote: > Today I inadvertently formed an unwanted circular chain of library > dependencies with the target_link_libraries command, and as a result CMake > segfaulted. [snip] > [EMAIL PROTECTED]> cmake ../test_cmake > -- Check for working C compiler: gcc > -- Check for working C compil

Re: [CMake] The input line is too long (MinGW)

2006-09-21 Thread Brad King
Martin Dobias wrote: > I try to build executable in my project (using about 150 source files) > with CMake and MinGW. When it comes to linking I get an error message > from system saying: > > The input line is too long. What version of CMake are you using? This has been fixed in CVS CMake and wi

Re: [CMake] Does CMake have any known problems with C and C++ code mixed together in the same library?

2006-09-21 Thread Matt Rogers
On Thursday 21 September 2006 03:19, Alan W. Irwin wrote: > Years ago I somehow got the impression it was not a good idea to mix C and > C++ object code in the same library, but now I cannot find the reference > (or I misinterpreted it in the first place). > > This really boils down to two question

Re: [CMake] Dependencies check failure

2006-09-21 Thread Alexander Neundorf
Original-Nachricht Datum: Thu, 21 Sep 2006 12:34:46 +0200 Von: "Ebersold André" <[EMAIL PROTECTED]> An: cmake@cmake.org Betreff: [CMake] Dependencies check failure > Hello, > > I am working with cmake 2.4.2 and have the macro bellow in a projet. > I uses the macro two times. T

[CMake] The input line is too long (MinGW)

2006-09-21 Thread Martin Dobias
Hi, I try to build executable in my project (using about 150 source files) with CMake and MinGW. When it comes to linking I get an error message from system saying: The input line is too long. It seems that Windows has too short maximal allowed command line - on Linux it's OK. Is it possible to

[CMake] Dependencies check failure

2006-09-21 Thread Ebersold André
Hello, I am working with cmake 2.4.2 and have the macro bellow in a projet. I uses the macro two times. The code works fine with 2.4.2. I tried the same macro with cmake 2.4.3 and I have an error in dependencies check. cmake says that there is no rule to build src2.aac but it create src1.acc ? I

[CMake] Does CMake have any known problems with C and C++ code mixed together in the same library?

2006-09-21 Thread Alan W. Irwin
Years ago I somehow got the impression it was not a good idea to mix C and C++ object code in the same library, but now I cannot find the reference (or I misinterpreted it in the first place). This really boils down to two questions: (1) Are there any known CMake issues with mixing C and C++ cod