[CMake] cmake . -DCMAKE_INSTALL_PREFIX=/foo broken on solaris and hpux
(apoligies if this goes through twice - have had mailer issues) Hi, Having polluted /lib on a couple of machines I noticed that setting CMAKE_INSTALL_PREFIX on the command line with -D does not work on solaris or HP-UX. Using the solaris sparc download from cmake.org, I can reproduce quite simply: mkdir ctest; cd ctest echo Hello Hello.h echo 'INSTALL_FILES(/include Hello.h)' CMakeLists.txt cmake . -DCMAKE_INSTALL_PREFIX=/tmp/install_test gmake gmake install The problem is that although CMAKE_INSTALL_PREFIX is correctly set in CMakeCache.txt in the install file, cmake_install.cmake, we have: # Set the install prefix IF(NOT DEFINED CMAKE_INSTALL_PREFIX) SET(CMAKE_INSTALL_PREFIX ) ENDIF(NOT DEFINED CMAKE_INSTALL_PREFIX) This should, of course be: # Set the install prefix IF(NOT DEFINED CMAKE_INSTALL_PREFIX) SET(CMAKE_INSTALL_PREFIX /tmp/install_test) ENDIF(NOT DEFINED CMAKE_INSTALL_PREFIX) The odd thing is that using ccmake to set the install prefix works fine. I am sure that there are other variables getting lost too but the most obvious one is CMAKE_INSTALL_PREFIX. If we build cmake with gcc/g++ instead of the native Sun and HP compilers then we get a cmake that behaves as expected. Peter ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compiling fortran
Juan Sanchez wrote: Anyone know what are the valid comment lines in all the Fortran variants? I know of lines beginning with c, C, or * in the first column. Those are valid only in the fixed-form type of source code. The exclamation mark (!) is valid in both free-form and fixed-form code (from Fortran 90 onwards, but perhaps there are FORTRAN 77 compilers out there that accepted that as well). The exclamation mark, appearing anywhere _outside_ a literary string, marks the beginning of a comment. I do not think it would cause any problems to assume any exclamation mark (even inside a string) is the start of a comment - for this particular task: you can not have a valid USE statement follow a literary string. Another problem is, however, the D (and d) conditional comment (only for fixed form). It is regarded a comment during normal compilation, but may be turned into valid code with a compile option. Probably the safest bet here is to assume that it is always valid code: C C Only use this module if we are debugging ... D use my_debugging_stuff C C C D call debug_msg( 'Now in routine such-and-such' ) Regards, Arjen ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake . -DCMAKE_INSTALL_PREFIX=/foo broken on solaris and hpux
On Thu, Sep 27, 2007 at 01:11:56AM -0500, Peter O'Gorman wrote: cmake . -DCMAKE_INSTALL_PREFIX=/tmp/install_test gmake gmake install If we build cmake with gcc/g++ instead of the native Sun and HP compilers then we get a cmake that behaves as expected. Also -DCMAKE_INSTALL_PREFIX:PATH=/tmp/install_test works. I was sure I had tried this, but I guess not. So, user error, I guess. However, I would expect the same behavior with cmake built with g++ and SUN CC/aCC. Peter ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to call make program
Hi,
CMake searches for make program while configuring and stores its path
in CMAKE_MAKE_PROGRAM variable but I need to call it myself to build
the project. There are no problems if my PATH environment contains
make's path but in some cases it doesn't.
For example, MinGW programs are searched via Windows registry so CMake
knows where the are. But to compile my project I have to specify full
path to make to build project:
E:\Temp\bin C:\MinGW\bin\mingw32-make
In other workd _I_ need to know where MinGW's make resides despite of
CMake knows it already.
Is there any way to call the make program found by cmake indirectly by
calling cmake? Something like 'cmake -E exec ${CMAKE_MAKE_PROGRAM}'?
Regard,
--
Nikita V. Borodikhin, NIKB-RIPN BNV7-RIPE
Registered Linux user #256562 with the Linux Counter
uniqueics.com.ru
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] include directories variable?
How do I get the INCLUDE_DIRECTORIES path? I need to feed into into the search path for the swig command line. Documentation taken from a man cmake command: GET_DIRECTORY_PROPERTY Get a property of the directory. GET_DIRECTORY_PROPERTY(VAR [DIRECTORY dir] property) Get a property from the Directory. The value of the property is stored in the variable VAR. If the property is not found, CMake will report an error. The properties include: VARIABLES, CACHE_VARIABLES,COMMANDS,MACROS,INCLUDE_DIRECTORIES, LINK_DIRECTORIES, DEFINITIONS, INCLUDE_REGULAR_EXPRESSION, LIST- FILE_STACK, PARENT_DIRECTORY, and DEFINITION varname. If the DIRECTORY argument is provided then the property of the provided directory will be retrieved instead of the current directory. You can only get properties of a directory during or after it has been traversed by cmake. --Sylvain ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Project Grouping in a solution
Is there a way to group projects in a solution? Something like this would be handy CMakeProject -- ALL_BUILD -- ZERO_CHECK etc lib -- lib1 -- lib2 Possibly something that follows the file system setup. -Neal This topic has been addressed few days ago, a quick search in the mailing list archive would do the trick ( http://www.cmake.org/pipermail/cmake/ ) And here is the topic: http://www.cmake.org/pipermail/cmake/2007-September/016504.html --Sylvain ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Nonstandard architectures.
Hi, I have problems with nonstandard architectures. cmakes mechanism to see if some package is installed usually just looks if some files are present. That is good as long as you just compile for the standard architecture on a specific operating system. But if I build for some non default architecture (for example for 64 bit pa risc instead of the 32 bit default one). Most configury checks will not find the truth. For example, In my amd64 linux system we have a /usr/local/lib/libglut.so. so the FIND_PACKAGE(GLUT) will see: 'ah we have glut available!'. But when I build for emt64, this is just wrong, because I do not have the equivalent /usr/local/lib64/libglut.so installed ... Old autoconf used to check existence of libraries by compiling a small test example with the configured compiler and link against that library in question. In contrast to cmake that just looks for the existence of files. This way one could be sure that this fits together. This would be for sure one solution to that problem. An other one would be to use the 'correct' standard librarie paths for different architectures. But that means that cmake will need to know more about the ABI in use. Currently this is not required to know. What to do here? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Confikgurations and Platforms in Visual Studio 8
I'm looking at cmake as a potential solution to some build problems I'm having. Am I right in thinking that cmake only allows for four hard-coded configuration labels, DEBUG/RELEASE/etc? Where should I look to add to these, as we've got more configurations than this. Also, does cmake have an idea of platforms, or does it assume Win32? Thanks, Joe ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Confikgurations and Platforms in Visual Studio 8
Josef Karthauser wrote: I'm looking at cmake as a potential solution to some build problems I'm having. Am I right in thinking that cmake only allows for four hard-coded configuration labels, DEBUG/RELEASE/etc? Where should I look to add to these, as we've got more configurations than this. http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_extend_the_build_modes_wit h_a_custom_made_one_.3F Also, does cmake have an idea of platforms, or does it assume Win32? CMake does not assume anything about Win32 or any other platform. -Torsten ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Confikgurations and Platforms in Visual Studio 8
I'm looking at cmake as a potential solution to some build problems I'm having. Am I right in thinking that cmake only allows for four hard-coded configuration labels, DEBUG/RELEASE/etc? Where should I look to add to these, as we've got more configurations than this. http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_extend_the_build_modes_wit h_a_custom_made_one_.3F Brilliant, that looks good. Also, does cmake have an idea of platforms, or does it assume Win32? CMake does not assume anything about Win32 or any other platform. What I mean is, in vcproj files combine the configuration and the platform labels to form a compilation target, i.e Release|Win32, Debug|x64. How do I go about specifying the platform parts of these with cmake? For example, I say I have 'Release', 'Debug', and 'Special' configurations, and Win32 and x64 platforms. Now suppose that I only support the following configurations: Release|Win32 Release|x64 Debug|Win32 Debug|x64 Special|x64 How do I go about specifying that to cmake? Much appreciated, Joe ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Nonstandard architectures.
On Thursday 27 September 2007 12:12:56 Mathias Froehlich wrote: Hi, Hello I have problems with nonstandard architectures. cmakes mechanism to see if some package is installed usually just looks if some files are present. That is good as long as you just compile for the standard architecture on a specific operating system. But if I build for some non default architecture (for example for 64 bit pa risc instead of the 32 bit default one). Most configury checks will not find the truth. For example, In my amd64 linux system we have a /usr/local/lib/libglut.so. so the FIND_PACKAGE(GLUT) will see: 'ah we have glut available!'. But when I build for emt64, this is just wrong, because I do not have the equivalent /usr/local/lib64/libglut.so installed ... FIND_PACKAGE(GLUT) will use FindGLUT.cmake as it's made and it does not have to fit every need, you can provide your own FindGLUT.cmake in a local project cmake modules directory to override the default one (I do that with ZLIB). Also generally, FIND_LIBRARY(), FIND_FILE() (which are generally used in FindPackage scripts) are both configurable setting some variables for the paths (see the cmake man page on them). Old autoconf used to check existence of libraries by compiling a small test example with the configured compiler and link against that library in question. In contrast to cmake that just looks for the existence of files. Yes (but cmake has that too). This way one could be sure that this fits together. This would be for sure one solution to that problem. So then use such a check instead of FIND_LIBRARY() (that locates files only). CMake comes with many modules that can be used to test-compile, but there is one specifically for your case, namely CHECK_LIBRARY_EXISTS(). An other one would be to use the 'correct' standard librarie paths for different architectures. But that means that cmake will need to know more about the ABI in use. Currently this is not required to know. In your example, the native arch it's x86-64 or x86? And then you are compiling for a target x86 or x86-64? I would not like to have cmake do very strict checks such as autoconf by default, because then we will get the same speed as with autoconf (which was very slow) and you generally don't need those strict checks. I would like to have it both, so you can do both fast checks (checking for existence of files) and compile-test checks (checking if it actually compiles) in a configurable way. So maybe there should be a new attribute to FIND_PACKAGE() (as we have the REQUIRED attribute) say named STRICT and have code in FindPackage modules that when STRICT is present there will also be a test-compile check done (using CHECK_LIBRARY_EXISTS and such) on the found library. -- Mihai RUSU Email: [EMAIL PROTECTED] Linux is obsolete -- AST ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Confikgurations and Platforms in Visual Studio 8
Also, does cmake have an idea of platforms, or does it assume Win32? CMake does not assume anything about Win32 or any other platform. What I mean is, in vcproj files combine the configuration and the platform labels to form a compilation target, i.e Release|Win32, Debug|x64. How do I go about specifying the platform parts of these with cmake? For example, I say I have 'Release', 'Debug', and 'Special' configurations, and Win32 and x64 platforms. Now suppose that I only support the following configurations: Release|Win32 Release|x64 Debug|Win32 Debug|x64 Special|x64 How do I go about specifying that to cmake? Looking at the source, it appears (from cmLocalVisualStudio7Generator.cxx) that cmake assumes that visual studio only supports 'x64', 'ia64' and 'win32' as target platforms, and that this can only be changed in code. Is this right? Three questions then, if I may: * How do I go about specifying a particular platform in the CMakeList.txt file? * What is the easiest way to add additional platform support; can this only happen through modifying the code, or is there some other magic that can be done. (Other embedded platforms exist in VC8, which we're targeting). * Are these issues dealt with in the book? Or is there some other on-line documentation that I'm missing? Thanks, Joe ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Nonstandard architectures.
If you want to check without actually compiling. There is the file command which can tell you about a shared library or any other file on your filesystem. ~ file /opt/firefox/libfreebl3.so /opt/firefox/libfreebl3.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped ~ file /usr/lib64/nss/libfreebl3.so /usr/lib64/nss/libfreebl3.so: symbolic link to `libfreebl3.so.11' ~ file /usr/lib64/nss/libfreebl3.so.11 /usr/lib64/nss/libfreebl3.so.11: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), stripped Barring that, I've seen people use chroot jails to contain their 32 bit compile environments. Juan -Original Message- From: [EMAIL PROTECTED] on behalf of Mathias Froehlich Sent: Thu 9/27/2007 4:12 AM To: cmake@cmake.org Subject: [CMake] Nonstandard architectures. Hi, I have problems with nonstandard architectures. cmakes mechanism to see if some package is installed usually just looks if some files are present. That is good as long as you just compile for the standard architecture on a specific operating system. But if I build for some non default architecture (for example for 64 bit pa risc instead of the 32 bit default one). Most configury checks will not find the truth. For example, In my amd64 linux system we have a /usr/local/lib/libglut.so. so the FIND_PACKAGE(GLUT) will see: 'ah we have glut available!'. But when I build for emt64, this is just wrong, because I do not have the equivalent /usr/local/lib64/libglut.so installed ... Old autoconf used to check existence of libraries by compiling a small test example with the configured compiler and link against that library in question. In contrast to cmake that just looks for the existence of files. This way one could be sure that this fits together. This would be for sure one solution to that problem. An other one would be to use the 'correct' standard librarie paths for different architectures. But that means that cmake will need to know more about the ABI in use. Currently this is not required to know. What to do here? Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Changing CMAKE_OSX_ARCHITECTURES and rebuilding...
Hi all, If I set CMAKE_OSX_ARCHITECTURES to, for example, i386 ppc, then configure, generate, and make, everything works great. However, if I then go back into ccmake and append a new architecture, say change it to i386 ppc ppc64 then configure, generate, and make again, the make step just proceeds to 100% very quickly. It does not intelligently only do a ppc64 build. Is this a bug? Is there a workaround other than 'make clean'? Thanks, -- Sean McBride, B. Eng [EMAIL PROTECTED] Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Interresting dependency problem
Hi, Thank you for anwsering so fast. 1. What solution do you think is the best: A main master script that knows every dependencies of every projects VS Completly indenpendant build script that we could simply include if we need them and their dependencies ? Please justify. If these are independent solutions, then there is no real choice. If there is such one, then they are not really independent and you could use the simplest approach of a master script. Actually, I would like to be able to build A and B independantly. If I decide to build B, then B and only B is built. If I decide to build A, then B and A are built. This is the actual definition of independance. 2. How can I achieve the first solution with CMake ? (Is it possible ?) You can let cmake write another cmake script with SET statements that you include in yet another cmake script. It sounds like a big configuration file. But how could this solve the src/file1.cpp problem ? Do you have any little practical example ? 3: Is there any better solution that I don't see ? Yes. Every solution comes down to a classic common thing: a development kit for C (used by B) and B (used by A). An automatically written cmake script is one solution (somewhat limiting the dependent build environments to cmake) or something else like pkgconfig, or shell scripts that set environment variables, or whatever. Very much depends on the target audience and personal preferences. Could you please elaborate on an automatically written cmake script. I would like to know more about it and how it can be acheived. The use of pkgconfig is prohibited, just like shell scripts and env. variables. The solution has to be as portable as it can be (win32, linux, macosx, etc.) Thank you again, Félix C. Morency -- Message: 3 Date: Thu, 27 Sep 2007 04:26:32 +0200 From: Hendrik Sattler [EMAIL PROTECTED] Subject: Re: [CMake] Interresting dependency problem To: cmake@cmake.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=utf-8 Am Donnerstag 27 September 2007 schrieb Félix C. Morency: 1. What solution do you think is the best: A main master script that knows every dependencies of every projects VS Completly indenpendant build script that we could simply include if we need them and their dependencies ? Please justify. If these are independent solutions, then there is no real choice. If there is such one, then they are not really independent and you could use the simplest approach of a master script. 2. How can I achieve the first solution with CMake ? (Is it possible ?) You can let cmake write another cmake script with SET statements that you include in yet another cmake script. 3: Is there any better solution that I don't see ? Yes. Every solution comes down to a classic common thing: a development kit for C (used by B) and B (used by A). An automatically written cmake script is one solution (somewhat limiting the dependent build environments to cmake) or something else like pkgconfig, or shell scripts that set environment variables, or whatever. Very much depends on the target audience and personal preferences. HS -- ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Nonstandard architectures.
Hi, On Thursday 27 September 2007 11:33, Dizzy wrote: Also generally, FIND_LIBRARY(), FIND_FILE() (which are generally used in FindPackage scripts) are both configurable setting some variables for the paths (see the cmake man page on them). So you can avoid that cmake will look into /lib and /usr/lib for example? What to do then with the OpenGL test for example? It adds its own knowledge about the standard paths where OpenGL is usually installed. But That paths only include the standard abi variants of those paths. I need to make sure that the ones with the correct abi are found. Sure I can do that with CMAKE_LIBRARY_PATH. But I also need to make sure that libs that are present in */lib paths are not found if they do not match the required abi. That is cmake should not just look into */lib paths. Or it must have a way to check if the abi will match. In your example, the native arch it's x86-64 or x86? And then you are compiling for a target x86 or x86-64? The native arch is x86-64. And I compile for x86-64. The native archs libs will be in */lib64 instead of the usual */lib paths. But cmake looks in */lib directories where some x86 libs are present that are not present for the x86-64 case. The question here is even worse - which one is the native one?? lib or lib64?? And which ones should cmake accept? I would not like to have cmake do very strict checks such as autoconf by default, because then we will get the same speed as with autoconf (which was very slow) and you generally don't need those strict checks. I would like to have it both, so you can do both fast checks (checking for existence of files) and compile-test checks (checking if it actually compiles) in a configurable way. So maybe there should be a new attribute to FIND_PACKAGE() (as we have the REQUIRED attribute) say named STRICT and have code in FindPackage modules that when STRICT is present there will also be a test-compile check done (using CHECK_LIBRARY_EXISTS and such) on the found library. Having that STRICT flag should not be a per target flag. It would help me if there is a switch to make that the global default. Better correctness then speed. CHECK_LIBRARY_EXISTS is a C implementaiton? May be you want to fiddle with the output of the file command? Well, you need to know what abis are available and compatible and which one is compiled with the configured compiler. Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Nonstandard architectures.
Hi, On Thursday 27 September 2007 15:21, Sanchez, Juan wrote: If you want to check without actually compiling. There is the file command which can tell you about a shared library or any other file on your filesystem. ~ file /opt/firefox/libfreebl3.so /opt/firefox/libfreebl3.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped ~ file /usr/lib64/nss/libfreebl3.so /usr/lib64/nss/libfreebl3.so: symbolic link to `libfreebl3.so.11' ~ file /usr/lib64/nss/libfreebl3.so.11 /usr/lib64/nss/libfreebl3.so.11: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), stripped Ok, but: On hpux for example: $ file /lib/pa*/libc.* /lib/libc.* /lib/pa11_32/libc.2:PA-RISC1.1 shared library -not stripped /lib/pa20_32/libc.2:PA-RISC2.0 shared library -not stripped /lib/pa20_64/libc.2:ELF-64 shared object file - PA-RISC 2.0 (LP64) /lib/pa20_64/libc.a:archive file /lib/pa20_64/libc.sl: ELF-64 shared object file - PA-RISC 2.0 (LP64) /lib/libc.0:PA-RISC1.1 shared library -not stripped /lib/libc.1:PA-RISC1.1 shared library -not stripped /lib/libc.2:PA-RISC2.0 shared library -not stripped /lib/libc.a:archive file -PA-RISC1.1 relocatable library /lib/libc.sl: PA-RISC2.0 shared library -not stripped Which one would you choose? Especially that: /lib/pa20_64/libc.a:archive file You need to recognise that it is an archive you need to unpack one of the files and do a file commmand on such an object. Or that one as seen on opensuse 10.2: $ file /usr/lib*/libc.* /usr/lib64/libc.a: current ar archive /usr/lib64/libc.so: ASCII C program text /usr/lib/libc.a:current ar archive /usr/lib/libc.so: ASCII C program text Ooops, C program text aka gnu ld linker script :) Or think of AIX and its way to pack different so versions of the same library into an archive file ... Greetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Nonstandard architectures.
On 27.09.07 15:36:11, Mathias Froehlich wrote: On Thursday 27 September 2007 11:33, Dizzy wrote: In your example, the native arch it's x86-64 or x86? And then you are compiling for a target x86 or x86-64? The native arch is x86-64. And I compile for x86-64. The native archs libs will be in */lib64 instead of the usual */lib paths. Just to state the obvious: Thats backwards compared to what distro's have these days. */lib is always the native libs and then you have either lib64 or lib32 (at least AFAIK, don't have any 64-bit system) But cmake looks in */lib directories where some x86 libs are present that are not present for the x86-64 case. The question here is even worse - which one is the native one?? lib or lib64?? And which ones should cmake accept? I think there's a way to tell CMake to either use lib or lib64, something like LIB_SUFFIX. Andreas -- What happened last night can happen again. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Building both make and vcproj files.
This may be common knowledge already, but I was wondering what the best way to get cmake to build both unix make files and visual studio files for the same project is. I'd like to use makefiles for building my project, but I still need vcproj files so that the developers can use visual studio for writing and debugging the code. The vcproj files would be Make projects, shelling out to call the command line make. Does anyone here already do something like this? Joe ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Nonstandard architectures.
Andreas Pakulat wrote: But cmake looks in */lib directories where some x86 libs are present that are not present for the x86-64 case. The question here is even worse - which one is the native one?? lib or lib64?? And which ones should cmake accept? I think there's a way to tell CMake to either use lib or lib64, something like LIB_SUFFIX. CMake does a test for sizeof void* if it is 8 bytes then lib64 is searched before lib in all FIND_* stuff. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] removing invalid output
I am using ADD_CUSTOM_COMMAND to produce an output. Unfortunately, if the commands in it fail, the OUTPUT. Hence the OUTPUT is up to date, even though it is invalid. Is there a way to tell ADD_CUSTOM_COMMAND to remove its output when it fails? Thanks, Juan ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Jam generator for CMake
I was wondering if there is a Jamfile generator for CMake for either Perforce Jam or Boost Jam? I'm doing build system experiments, and I'd like to export the CMakeLists.txt contents to alternative build systems. Thanks. Josh ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Error using cygwin with Matlab2007a installed
I got a new XP computer at work so I installed some of my standard tools (including cygwin and a new copy of MATLAB 2007a). When I try to compile one of my cmake projects in cygwin, I get an new error (see end of message for error printout). It seems that cmake is incorrectly associating an executable (gmake.exe) in my MATLAB R2007a directory as the make program. Fortunately, there is an easy fix, all I need to do is redirect cmake to the correct file: $ cmake ../ThreeDID/ -DCMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/make However, it seems odd to me that cmake would identify the MATLAB program as the proper make program. Can someone explain the method cmake uses to identify the make program, and why it would pick the MATLAB program? This would help me determine if the error I got is a bug or a feature of cmake. Thank you, Dirk $ cmake ../ThreeDID/ -- Check for working C compiler: /usr/bin/gcc.exe -- Check for working C compiler: /usr/bin/gcc.exe -- broken CMake Error: The C compiler /usr/bin/gcc.exe is not able to compile a simple t est program. It fails with the following output: c:/Program Files/Matlab/R2007a/bin/win32/gmake.exe -f CMakeFiles/cmTryCompileEx ec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build gmake.exe[1]: Entering directory `C:/cygwin/home/Dirk Colbry/cyg2/CMakeFiles/CMa keTmp' /usr/bin/cmake.exe -E cmake_progress_report /home/Dirk\ Colbry/cyg2/CMakeFiles/C MakeTmp/CMakeFiles 1 process_begin: CreateProcess((null), /usr/bin/cmake.exe -E cmake_progress_report /home/Dirk Colbry/cyg2/CMakeFiles/CMakeTmp/CMakeFiles 1, ...) failed. make (e=3): The system cannot find the path specified. gmake.exe[1]: *** [CMakeFiles/cmTryCompileExec.dir/testCCompiler.o] Error 3 gmake.exe[1]: Leaving directory `C:/cygwin/home/Dirk Colbry/cyg2/CMakeFiles/CMak eTmp' c:\Program Files\Matlab\R2007a\bin\win32\gmake.exe: *** [cmTryCompileExec/fast] Error 2 CMake will not be able to correctly generate this project. -- Configuring done -- Dr. Dirk Colbry Assistant Research Professor Center for Cognitive Ubiquitous Computing School of Computing and Informatics Arizona State University http://www.dirk.colbry.com/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Error using cygwin with Matlab2007a installed
What happens if you type gmake --help or which gmake from the same prompt...? CMake should just use the PATH env variable to find the right gmake first. If not there, it may look in some other well known places, but if there is one in your PATH, it will use it... Most likely considered a feature. :-) On 9/27/07, Dirk Colbry [EMAIL PROTECTED] wrote: I got a new XP computer at work so I installed some of my standard tools (including cygwin and a new copy of MATLAB 2007a). When I try to compile one of my cmake projects in cygwin, I get an new error (see end of message for error printout). It seems that cmake is incorrectly associating an executable ( gmake.exe) in my MATLAB R2007a directory as the make program. Fortunately, there is an easy fix, all I need to do is redirect cmake to the correct file: $ cmake ../ThreeDID/ -DCMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/make However, it seems odd to me that cmake would identify the MATLAB program as the proper make program. Can someone explain the method cmake uses to identify the make program, and why it would pick the MATLAB program? This would help me determine if the error I got is a bug or a feature of cmake. Thank you, Dirk $ cmake ../ThreeDID/ -- Check for working C compiler: /usr/bin/gcc.exe -- Check for working C compiler: /usr/bin/gcc.exe -- broken CMake Error: The C compiler /usr/bin/gcc.exe is not able to compile a simple t est program. It fails with the following output: c:/Program Files/Matlab/R2007a/bin/win32/gmake.exe -f CMakeFiles/cmTryCompileEx ec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build gmake.exe[1]: Entering directory `C:/cygwin/home/Dirk Colbry/cyg2/CMakeFiles/CMa keTmp' /usr/bin/cmake.exe -E cmake_progress_report /home/Dirk\ Colbry/cyg2/CMakeFiles/C MakeTmp/CMakeFiles 1 process_begin: CreateProcess((null), /usr/bin/cmake.exe -E cmake_progress_report /home/Dirk Colbry/cyg2/CMakeFiles/CMakeTmp/CMakeFiles 1, ...) failed. make (e=3): The system cannot find the path specified. gmake.exe[1]: *** [CMakeFiles/cmTryCompileExec.dir/testCCompiler.o] Error 3 gmake.exe[1]: Leaving directory `C:/cygwin/home/Dirk Colbry/cyg2/CMakeFiles/CMak eTmp' c:\Program Files\Matlab\R2007a\bin\win32\gmake.exe: *** [cmTryCompileExec/fast] Error 2 CMake will not be able to correctly generate this project. -- Configuring done -- Dr. Dirk Colbry Assistant Research Professor Center for Cognitive Ubiquitous Computing School of Computing and Informatics Arizona State University http://www.dirk.colbry.com/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Error using cygwin with Matlab2007a installed
Both which and gmake commands point to the gmake file in MATLAB as the first in my path directory. However, when I look at my PATH directory the /usr/bin folder is first in the path list (see print outs at the end of this message). I check the /usr/bin directory and it does not contain the gmake file. Instead it contains only the make file. From this, I assume that cmake is first searching for gmake and if it does not find it, it looks for make. I tested this assumption by adding a symbolic link to the /usr/bin directory ($ ln -s /usr/bin/make /usr/bin/gmake) and the build worked fine again without the need to redefine my make filepath in cmake. Now I am still scratching my head over a few questions: 1. Why didn't the MATLAB version of gmake work? My guess is that since the MATLAB version of gmake is built for windows, it is having difficulty with the cygwin directory structure. 2. What is the difference between gmake and make? I Googled this one and found that gmake stands for GNU make and it is basically the same as make although different versions do exist and it can depend on the platform you are using. 3. The version of make in my install of cygwin is GNU Make 3.81 so why didn't cygwin have links to both gmake and make? (this is obviously a cygwin question and not a cmake question). 3. Why does cmake search for gmake before make? I am sure there is a historical or logical reason for this, I just could not find it. Thanks for your help, Dirk $ which gmake /cygdrive/c/Program Files/Matlab/R2007a/bin/win32/gmake $ gmake --help Usage: c:\Program Files\Matlab\R2007a\bin\win32\gmake.exe [options] [target] ... Options: -b, -m Ignored for compatibility. -B, --always-make Unconditionally make all targets. -C DIRECTORY, --directory=DIRECTORY Change to DIRECTORY before doing anything. -d Print lots of debugging information. --debug[=FLAGS] Print various types of debugging information. -e, --environment-overrides Environment variables override makefiles. -f FILE, --file=FILE, --makefile=FILE Read FILE as a makefile. -h, --help Print this message and exit. -i, --ignore-errors Ignore errors from commands. -I DIRECTORY, --include-dir=DIRECTORY Search DIRECTORY for included makefiles. -j [N], --jobs[=N] Allow N jobs at once; infinite jobs with no arg. -k, --keep-goingKeep going when some targets can't be made. -l [N], --load-average[=N], --max-load[=N] Don't start multiple jobs unless load is below N. -n, --just-print, --dry-run, --recon Don't actually run any commands; just print them. -o FILE, --old-file=FILE, --assume-old=FILE Consider FILE to be very old and don't remake it. -p, --print-data-base Print make's internal database. -q, --question Run no commands; exit status says if up to date. -r, --no-builtin-rules Disable the built-in implicit rules. -R, --no-builtin-variables Disable the built-in variable settings. -s, --silent, --quiet Don't echo commands. -S, --no-keep-going, --stop Turns off -k. -t, --touch Touch targets instead of remaking them. -v, --version Print the version number of make and exit. -w, --print-directory Print the current directory. --no-print-directoryTurn off -w, even if it was turned on implicitly. -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE Consider FILE to be infinitely new. --warn-undefined-variables Warn when an undefined variable is referenced. This program built for Windows32 Report bugs to [EMAIL PROTECTED] $ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOWS/system32:/cygdri ve/c/WINDOWS:/cygdrive/c/WINDOWS/system32/wbem:/cygdrive/c/program files/common files/roxio shared/dllshared/:/cygdrive/c/Program Files/Matlab/R2007a/bin:/cygdr ive/c/Program Files/Matlab/R2007a/bin/win32:/cygdrive/c/Program Files/SSH Commun ications Security/SSH Secure Shell -- Dr. Dirk Colbry Assistant Research Professor Center for Cognitive Ubiquitous Computing School of Computing and Informatics Arizona State University http://www.dirk.colbry.com/ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Error using cygwin with Matlab2007a installed
On 9/27/07, Dirk Colbry [EMAIL PROTECTED] wrote: 1. Why didn't the MATLAB version of gmake work? My guess is that since the MATLAB version of gmake is built for windows, it is having difficulty with the cygwin directory structure. Not sure about this one -- your guess sounds reasonable, though. The cygwin tools work well under cygwin, but maybe or maybe not so well when used directly from a windows cmd prompt. (Vice versa, too : windows tools work well under windows cmd prompt, but maybe not so well under a cygwin shell... many reasons for this... but the lesson is usually : use cygwin tools when in a cygwin shell, use other tools in other shells. :-) 2. What is the difference between gmake and make? I Googled this one and found that gmake stands for GNU make and it is basically the same as make although different versions do exist and it can depend on the platform you are using. 3. The version of make in my install of cygwin is GNU Make 3.81 so why didn't cygwin have links to both gmake and make? (this is obviously a cygwin question and not a cmake question). I'm not sure about these two questions either. Cygwin does not appear to have a gmake, unless it is buried inside some other package that is non-obvious simply from scanning through the list of available cygwin packages 3. Why does cmake search for gmake before make? I am sure there is a historical or logical reason for this, I just could not find it. I'm not sure what the reason behind it is (other than perhaps most Unix/Linux developers prefer gmake over make...?) but the implementation is clear from CMake's Modules/CMakeUnixFindMake.cmake : FIND_PROGRAM(CMAKE_MAKE_PROGRAM NAMES gmake make smake) MARK_AS_ADVANCED(CMAKE_MAKE_PROGRAM) Directing cmake to the right make with -D is a good solution for you if you want to keep your PATH set as it is... HTH, David ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Interresting dependency problem
Am Donnerstag 27 September 2007 schrieb Félix C. Morency: Could you please elaborate on an automatically written cmake script. I would like to know more about it and how it can be acheived. See http://www.cmake.org/HTML/Documentation.html and search for EXPORT_LIBRARY_DEPENDENCIES. The FILE command below that is a possibility to combine this with other commands. The use of pkgconfig is prohibited, just like shell scripts and env. variables. The solution has to be as portable as it can be (win32, linux, macosx, etc.) pkgconfig _is_ portable. It works on all the mentioned platforms, AFAIK. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] ctest question
I've ran into similar problem.
Instead of keeping the original files as golden results, I
wanted to keep MD5 checksums of these files. There are two reasons
for it: disk space constraints and different file format
support. The generated files can take up a lot of disk space. If
a MD5 checksum difference is detected, I can roll back a revision
and generate the original file. Also, I wanted to perform similar
test on software that generates images (jpeg, etc.).
Because these scheme has to work on Linux and Windows, I've
wrote python script that computes file's MD5 checksum and compares
it to given golden result. This is something that I've done (CheckMD5.py
is the script mentioned before):
FIND_PACKAGE(PytonInterp)
IF(PYTHONINTERP_FOUND)
ADD_TEST(test1 my_program ${CMAKE_BINARY_DIR}/test.txt)
ADD_TEST(test2 ${PYTHON_EXECUTABLE}
${PROJECT_SOURCE_DIR}/CheckMD5.py ${CMAKE_BINARY_DIR}/test.txt
1a3fdcea)
ENDIF(PYTHONINTERP_FOUND)
That did the trick. However, now Dart2 shows reports about
possible memory leaks inside of python interpreter. Has anybody
else did something similar? It would be if CMake contained
macro like this:
ADD_MD5_TEST(testname generatedfile md5checksum)
--
Artur Kedzierski
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Juan Sanchez
Sent: Sunday, September 23, 2007 12:49
To: CMake ML
Subject: [CMake] ctest question
I want run a test program and pipe its results to a file. I
then want to compare this file to the golden results using diff.
Does anyone have a macro or cookbook example for doing this?
Thank you,
Juan
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] problem creating a library on mac
Hi,
I have a project which in which I create a library and then I use
this library with my executable. The way I set it up seem to be working on
linux (fedora) but it does not work on mac ox10.
Could someone tell me what I am doing wrong,
Thanks,
Marie
Project tree
*Projectdir
**mdi
**skinmesh
in my project directory I have the following cmake file :
--
project(mdi C Fortran CXX)
cmake_minimum_required(VERSION 2.4.0)
SET(PROJECT_BINARY_DIR
${CMAKE_SOURCE_DIR}/bin)
SET(LIBRARY_OUTPUT_PATH
${CMAKE_SOURCE_DIR}/lib)
# tell cmake to process CMakeLists.txt in these subdirectory
#they have to be added separately for it to work
#this subdirectory will create a lib so I put the lib in the lib folder
add_subdirectory(
skinmesh
${PROJECT_BINARY_DIR}
)
#this add the executable in the bin directory
add_subdirectory (
mdi
${PROJECT_BINARY_DIR}
)
--
In the mdi directory I have the following cmake file (part of it anyay) :
--
[..]
SET(SKINMESH_LIBRARIES
${LIBRARY_OUTPUT_PATH}/libskinmesh.a
)
SET(SKINMESH_INCLUDE_DIR
${CMAKE_SOURCE_DIR}/skinmesh
)
SET(INCLUDE_DIR
${INCLUDE_DIR}
${SKINMESH_INCLUDE_DIR}
)
SET(LIBRARIES
${LIBRARIES}
${SKINMESH_LIBRARIES})
[..]
# Mac configuration
IF ( CMAKE_SYSTEM_NAME MATCHES Darwin )
#setting flags
SET(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -O3 -mp1 -Kc++ -Dintel)
SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -O3 -mp1 -Kc++ -Dintel)
#equivalent to ldflag
SET( CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS}
-bind_at_load)
ENDIF ( CMAKE_SYSTEM_NAME MATCHES Darwin )
#VARIABLE INITIALISATION
# set source files
[..]
SET(mdi_EXECUTABLE
${mdi_SRCS}
${mdi_UIS_H}
${mdi_MOC_SRCS}
${mdi_RCC_SRCS}
)
INCLUDE_DIRECTORIES(${INCLUDE_DIR})
link_directories (${PROJECT_BINARY_DIR}/skinmesh)
# create an executable file named mdi from the source files in the
variable mdi_SRCS.
ADD_EXECUTABLE ( mdi
${mdi_EXECUTABLE}
)
TARGET_LINK_LIBRARIES ( mdi
${LIBRARIES}
)
-
In the skinmesh directory I have the following cmake file (part of it anyay) :
-
# create an executable file named skinmesh from the source files in the
variable skinmesh_SRCS.
ADD_LIBRARY ( skinmesh STATIC
${skinmesh_SRCS}
)
#set the linker language
SET_TARGET_PROPERTIES(skinmesh
PROPERTIES
LINKER_LANGUAGE CXX
)
[..]
# Mac configuration
IF ( CMAKE_SYSTEM_NAME MATCHES Darwin )
#setting flags
SET(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -c -O3 -mp1 -Kc++ -Dintel)
SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -c -O3 -mp1 -Kc++
-Dintel)
SET(CMAKE_Fortran_FLAGS ${CMAKE_Fortran_FLAGS} -c -u -O3 -mp1
-w90 -w95
-cpp )
#equivalent to ldflag
SET( CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} -O3
-Kc++ -mp1
-bind_at_load)
ENDIF ( CMAKE_SYSTEM_NAME MATCHES Darwin )
INCLUDE_DIRECTORIES (${INCLUDE_DIR})
TARGET_LINK_LIBRARIES (skinmesh
${PROJECT_LIBRARIES}
)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Project Grouping in a solution
Richard,
This project organization is much better, Kudos. However, most of our
directories include only a single project file so there seems to be a lot of
redundant folders in this type of layout, so maybe a little additional
feature that if there is only a single project in the directory don't add
it's directory to the list as well (the project name is usually pretty close
to the directory names). Also I'd like to see the CMake generated projects
in their own folder to seperate them from the rest of the projects.
A nice addition to this type of functionality might be to add functionality
similar to SOURCE_GROUP() (i.e. PROJECT_GROUP), so that I can design the
whacky project groupings that make sense for my project.
-Neal
On 9/27/07, Richard Moreland [EMAIL PROTECTED] wrote:
Attached is an updated patch that works with 2.4.7.
-Richard
Sylvain Benner wrote:
Is there a way to group projects in a solution? Something like this
would be handy
CMakeProject
-- ALL_BUILD
-- ZERO_CHECK
etc
lib
-- lib1
-- lib2
Possibly something that follows the file system setup.
-Neal
This topic has been addressed few days ago, a quick search in the
mailing list archive would do the trick (
http://www.cmake.org/pipermail/cmake/ )
And here is the topic:
http://www.cmake.org/pipermail/cmake/2007-September/016504.html
--Sylvain
--- cmGlobalVisualStudio71Generator.cxx Mon Jul 16 17:16:42 2007
+++ cmGlobalVisualStudio71Generator.cxx Thu Aug 16 09:15:04 2007
@@ -228,6 +228,9 @@
}
}
}
+
+ WriteAdditionalProjectSections(fout, root, generators);
+
fout Global\n;
this-WriteSolutionConfigurations(fout);
fout \tGlobalSection( this-ProjectConfigurationSectionName
@@ -271,6 +274,8 @@
}
fout \tEndGlobalSection\n;
+ WriteAdditionalGlobalSections(fout, root, generators);
+
// Write the footer for the SLN file
this-WriteSLNFooter(fout);
}
--- cmGlobalVisualStudio71Generator.h Mon Jul 16 17:16:42 2007
+++ cmGlobalVisualStudio71Generator.h Thu Aug 16 09:15:13 2007
@@ -62,6 +62,12 @@
virtual void WriteSLNFooter(std::ostream fout);
virtual void WriteSLNHeader(std::ostream fout);
+ virtual void WriteAdditionalGlobalSections(std::ostream fout,
cmLocalGenerator* root,
+ std::vectorcmLocalGenerator* generators) {}
+
+ virtual void WriteAdditionalProjectSections(std::ostream fout,
cmLocalGenerator* root,
+ std::vectorcmLocalGenerator* generators) {}
+
std::string ProjectConfigurationSectionName;
};
#endif
--- cmGlobalVisualStudio8Generator.cxx Mon Jul 16 17:16:42 2007
+++ cmGlobalVisualStudio8Generator.cxx Thu Aug 16 10:25:07 2007
@@ -170,10 +170,269 @@
}
//
+std::vectorstd::string buildPathAndSubPathVector(const std::string
path)
+{
+ std::vectorstd::string ret;
+ ret.push_back(path);
+
+ int slashPos;
+ std::string workingPath = path;
+ while ((slashPos = workingPath.find_last_of(/)) != std::string::npos)
+{
+workingPath = workingPath.substr(0, slashPos);
+ret.push_back(workingPath);
+}
+
+ return ret;
+}
+
+//
+std::string lastPathComponent(const std::string path)
+{
+ int slashPos = path.find_last_of(/);
+ if (slashPos != std::string::npos)
+{
+return path.substr(slashPos+1, path.length() - slashPos);
+}
+ return path;
+}
+
+//
+std::string allButLastPathComponent(const std::string path)
+{
+ int slashPos = path.find_last_of(/);
+ if (slashPos != std::string::npos)
+{
+return path.substr(0, slashPos);
+}
+ return path;
+}
+
+//
+std::string foobarPath(const std::string path)
+{
+ return std::string(SOLUTION FOLDER: ) + path;
+}
+
+//
+void cmGlobalVisualStudio8Generator::WriteAdditionalProjectSections(
+std::ostream fout, cmLocalGenerator* root,
+std::vectorcmLocalGenerator* generators)
+{
+ std::mapstd::string, std::string dspPathMap;
+ bool nestSolutionFolders =
+
cmSystemTools::IsOn(root-GetMakefile()-GetDefinition(NEST_SOLUTION_FOLDERS));
+ nestSolutionFolders = true;
+
+ // Get the start directory with the trailing slash
+ std::string rootdir = root-GetMakefile()-GetStartOutputDirectory();
+ rootdir += /;
+
+ // For each cmMakefile, create a VCProj for it, and
+ // add it to this SLN file
+ unsigned int i;
+ for(i = 0; i generators.size(); ++i)
+{
+if(this-IsExcluded(root, generators[i]))
+ {
+ continue;
+ }
+cmMakefile* mf = generators[i]-GetMakefile();
+
+// Get the source directory from the makefile
+
Re: [CMake] Interresting dependency problem
On 2007-09-27 20:10+0200 Hendrik Sattler wrote: Am Donnerstag 27 September 2007 schrieb Félix C. Morency: The use of pkgconfig is prohibited, just like shell scripts and env. variables. The solution has to be as portable as it can be (win32, linux, macosx, etc.) pkgconfig _is_ portable. It works on all the mentioned platforms, AFAIK. To reinforce Hendrik's point, http://pkg-config.freedesktop.org/wiki/ has the following to say: pkg-config works on multiple platforms: Linux and other UNIX-like operating systems, Mac OS X and Windows. It does not require anything but a reasonably well working C compiler and a C library, but can use an installed glib if that is present. (A copy of glib 1.2.8 is shipped together with pkg-config and this is sufficient for pkg-config to compile and work properly.) Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] problem creating a library on mac
What are the errors you are getting on OS X?
Also, at least one comment, I am not sure you want to be setting the
PROJECT_BINARY_DIR Variable?
What are you trying to do with this statement:
SET(PROJECT_BINARY_DIR
${CMAKE_SOURCE_DIR}/bin)
--
Mike Jackson Senior Research Engineer
Innovative Management Technology Services
On Sep 27, 2007, at 2:50 PM, Marie-Christine Vallet wrote:
Hi,
I have a project which in which I create a library and then
I use
this library with my executable. The way I set it up seem to be
working on
linux (fedora) but it does not work on mac ox10.
Could someone tell me what I am doing wrong,
Thanks,
Marie
Project tree
*Projectdir
**mdi
**skinmesh
in my project directory I have the following cmake file :
--
project(mdi C Fortran CXX)
cmake_minimum_required(VERSION 2.4.0)
SET(PROJECT_BINARY_DIR
${CMAKE_SOURCE_DIR}/bin)
SET(LIBRARY_OUTPUT_PATH
${CMAKE_SOURCE_DIR}/lib)
# tell cmake to process CMakeLists.txt in these subdirectory
#they have to be added separately for it to work
#this subdirectory will create a lib so I put the lib in the lib
folder
add_subdirectory(
skinmesh
${PROJECT_BINARY_DIR}
)
#this add the executable in the bin directory
add_subdirectory (
mdi
${PROJECT_BINARY_DIR}
)
--
In the mdi directory I have the following cmake file (part of it
anyay) :
--
[..]
SET(SKINMESH_LIBRARIES
${LIBRARY_OUTPUT_PATH}/libskinmesh.a
)
SET(SKINMESH_INCLUDE_DIR
${CMAKE_SOURCE_DIR}/skinmesh
)
SET(INCLUDE_DIR
${INCLUDE_DIR}
${SKINMESH_INCLUDE_DIR}
)
SET(LIBRARIES
${LIBRARIES}
${SKINMESH_LIBRARIES})
[..]
# Mac configuration
IF ( CMAKE_SYSTEM_NAME MATCHES Darwin )
#setting flags
SET(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -O3 -mp1 -Kc++ -Dintel)
SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -O3 -mp1 -Kc++ -Dintel)
#equivalent to ldflag
SET( CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} -
bind_at_load)
ENDIF ( CMAKE_SYSTEM_NAME MATCHES Darwin )
#VARIABLE INITIALISATION
# set source files
[..]
SET(mdi_EXECUTABLE
${mdi_SRCS}
${mdi_UIS_H}
${mdi_MOC_SRCS}
${mdi_RCC_SRCS}
)
INCLUDE_DIRECTORIES(${INCLUDE_DIR})
link_directories (${PROJECT_BINARY_DIR}/skinmesh)
# create an executable file named mdi from the source files in the
variable mdi_SRCS.
ADD_EXECUTABLE ( mdi
${mdi_EXECUTABLE}
)
TARGET_LINK_LIBRARIES ( mdi
${LIBRARIES}
)
-
In the skinmesh directory I have the following cmake file (part of
it anyay) :
-
# create an executable file named skinmesh from the source files
in the
variable skinmesh_SRCS.
ADD_LIBRARY ( skinmesh STATIC
${skinmesh_SRCS}
)
#set the linker language
SET_TARGET_PROPERTIES(skinmesh
PROPERTIES
LINKER_LANGUAGE CXX
)
[..]
# Mac configuration
IF ( CMAKE_SYSTEM_NAME MATCHES Darwin )
#setting flags
SET(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -c -O3 -mp1 -Kc++ -Dintel)
SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -c -O3 -mp1 -Kc++
-Dintel)
SET(CMAKE_Fortran_FLAGS ${CMAKE_Fortran_FLAGS} -c -u -O3 -mp1 -
w90 -w95
-cpp )
#equivalent to ldflag
SET( CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} -O3 -Kc++ -
mp1
-bind_at_load)
ENDIF ( CMAKE_SYSTEM_NAME MATCHES Darwin )
INCLUDE_DIRECTORIES (${INCLUDE_DIR})
TARGET_LINK_LIBRARIES (skinmesh
${PROJECT_LIBRARIES}
)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] problem creating a library on mac
Mike Jackson wrote:
What are the errors you are getting on OS X?
I get an undefined symbol error for several of my variables.
If I do the linking manually, leaving out the library, and putting the
.o of the library and use the same flags, it works.
Also, at least one comment, I am not sure you want to be setting the
PROJECT_BINARY_DIR Variable?
What are you trying to do with this statement:
SET(PROJECT_BINARY_DIR
${CMAKE_SOURCE_DIR}/bin)
I just wanted the binary to be in this folder (and all the files
created by cmake to be in this directory so I could clean up my
directory more easily )
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Interresting dependency problem
On 27.09.07 12:31:31, Alan W. Irwin wrote: On 2007-09-27 20:10+0200 Hendrik Sattler wrote: Am Donnerstag 27 September 2007 schrieb Félix C. Morency: The use of pkgconfig is prohibited, just like shell scripts and env. variables. The solution has to be as portable as it can be (win32, linux, macosx, etc.) pkgconfig _is_ portable. It works on all the mentioned platforms, AFAIK. To reinforce Hendrik's point, http://pkg-config.freedesktop.org/wiki/ has the following to say: pkg-config works on multiple platforms: Linux and other UNIX-like operating systems, Mac OS X and Windows. It does not require anything but a reasonably well working C compiler and a C library, but can use an installed glib if that is present. (A copy of glib 1.2.8 is shipped together with pkg-config and this is sufficient for pkg-config to compile and work properly.) No it doesn't work properly on win32 - AFAIK. Thats the reason why all cmake FindXXX modules for KDE4/win32 don't use pkgconfig. I'm not sure wether it was about the paths in the .pc files or something else, but fact is that pkconfig is unusable in _plain_ win32 (without msys, which I think creates problems when using cmake). And a link from the pkgconfig website claiming it works properly is not really a proof ;) Andreas -- Things will be bright in P.M. A cop will shine a light in your face. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] problem creating a library on mac
Could this be an issue with linker order? Most linkers are one pass.
The library containing the undefined references should be on the linker
line before the library containing the symbols, or vice-versa (I keep
forgetting).
Do the libraries contain the symbols that they should? Use whatever the
nm equivalent on mac os is to check.
Regards,
Juan
Marie-Christine Vallet wrote:
Mike Jackson wrote:
What are the errors you are getting on OS X?
I get an undefined symbol error for several of my variables.
If I do the linking manually, leaving out the library, and putting the
.o of the library and use the same flags, it works.
Also, at least one comment, I am not sure you want to be setting the
PROJECT_BINARY_DIR Variable?
What are you trying to do with this statement:
SET(PROJECT_BINARY_DIR
${CMAKE_SOURCE_DIR}/bin)
I just wanted the binary to be in this folder (and all the files
created by cmake to be in this directory so I could clean up my
directory more easily )
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
--
Juan Sanchez
[EMAIL PROTECTED]
800-538-8450 Ext. 54395
512-602-4395
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] problem creating a library on mac
Marie,
Use the following in your CMakeLists.txt file, generally near the
top just after you define the PROJECT (... )
SET (LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/Bin CACHE INTERNAL
For libraries.)
SET (EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/Bin CACHE
INTERNAL For executables.)
This will put all the compiled libraries and executables into the
same bin directory.
Also, I think you may be missing a key philosophy of CMake which is
Out of Source builds. In your project folder create a new folder
called Build. Then from the a terminal run the following commands:
cd Build
cmake ../
make
What this does is create the Build directory, moves into that
directory, then runs cmake from within the Build directory. This will
encapsulate all the cmake files, intermediate files, and compiled
libraries/executables in ONE sub directory within your project. If
you ever need to clean to do a CVS update/Checkout/Distribution or
clean build so can safely remove EVERYTHING within the Build
directory and rerun cmake again. Others in the cmake community will
put the build directory at the same level as the ProjectDir. So the
commands look like:
mkdir Build
cmake ../ProjectDir
make
Also, on to the actual problem, can you post the actual linker
command? Run make VERBOSE=1 and post the output.
--
Mike Jackson Senior Research Engineer
Innovative Management Technology Services
On Sep 27, 2007, at 3:46 PM, Marie-Christine Vallet wrote:
Mike Jackson wrote:
What are the errors you are getting on OS X?
I get an undefined symbol error for several of my variables.
If I do the linking manually, leaving out the library, and putting
the .o of the library and use the same flags, it works.
Also, at least one comment, I am not sure you want to be setting
the PROJECT_BINARY_DIR Variable?
What are you trying to do with this statement:
SET(PROJECT_BINARY_DIR
${CMAKE_SOURCE_DIR}/bin)
I just wanted the binary to be in this folder (and all the files
created by cmake to be in this directory so I could clean up my
directory more easily )
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] pkg-config at Windows Command Prompt
On 9/27/07, Alan W. Irwin [EMAIL PROTECTED] wrote: On 2007-09-27 20:10+0200 Hendrik Sattler wrote: Am Donnerstag 27 September 2007 schrieb Félix C. Morency: The use of pkgconfig is prohibited, just like shell scripts and env. variables. The solution has to be as portable as it can be (win32, linux, macosx, etc.) pkgconfig _is_ portable. It works on all the mentioned platforms, AFAIK. To reinforce Hendrik's point, http://pkg-config.freedesktop.org/wiki/ has the following to say: pkg-config works on multiple platforms: Linux and other UNIX-like operating systems, Mac OS X and Windows. It does not require anything but a reasonably well working C compiler and a C library, but can use an installed glib if that is present. (A copy of glib 1.2.8 is shipped together with pkg-config and this is sufficient for pkg-config to compile and work properly.) If you look at the current source release, you will see that it is an Autoconf build. There is no other build available. On Windows that presupposes the use of a Cygwin or MSYS shell to build pkgconfig. README.win32 implies that if you build with MSYS, it's supposed to work with MSVC also. But how strong is this guarantee that it's supposed to work? There are no Windows binaries of pkg-config available on the website. Googling around, I don't see any kind of self-contained pkg-config.exe for use on the Windows Command Prompt. I do see some .exe's that are part of Cygwin or MSYS toolchains. Questions: 1) does pkg-config.exe work from the Windows Command Prompt, independent of any MSYS shell environment that was used to build it? i.e. is it really native ? 2) given the build constraints and the lack of obvious deployed binaries, is anyone actually making production use of it in conjunction with MSVC? from the Command Prompt? To a Windows native developer this tool smells bad. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] problem creating a library on mac
Juan Sanchez wrote: Could this be an issue with linker order? Most linkers are one pass. The library containing the undefined references should be on the linker line before the library containing the symbols, or vice-versa (I keep forgetting). The symbols are part of the newly created library, and they are only reference in the executable Do the libraries contain the symbols that they should? Use whatever the nm equivalent on mac os is to check. what is nm? Regards, Juan ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] problem creating a library on mac
Marie-Christine Vallet wrote: Juan Sanchez wrote: Could this be an issue with linker order? Most linkers are one pass. The library containing the undefined references should be on the linker line before the library containing the symbols, or vice-versa (I keep forgetting). The symbols are part of the newly created library, and they are only reference in the executable Do the libraries contain the symbols that they should? Use whatever the nm equivalent on mac os is to check. nm is a unix tool, which google claims to exist on the mac, which tells you the name of any symbols that are referenced (but undefined), or are defined somewhere in the objects of an archive file or binary. If you have a C++ project, you can do: nm foo.a | c++ filt to see the human readable version of the symbols in your archive. If your linker complains about an undefined symbol, you can go looking for the symbol in the archive you think it belongs to. For example: ~ nm ctest/hello | grep main U __libc_start_main@@GLIBC_2.0 08048424 T main Says that main is defined in my binary, but the symbol __libc_start_main@@GLIBC_2.0 is referenced and undefined. If it is in the appropriate place, you then need to look at the linker order on the link line. Regards, Juan what is nm? Regards, Juan ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- Juan Sanchez [EMAIL PROTECTED] 800-538-8450 Ext. 54395 512-602-4395 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] pkg-config at Windows Command Prompt
On 27.09.07 16:12:19, Brandon Van Every wrote: On 9/27/07, Alan W. Irwin [EMAIL PROTECTED] wrote: On 2007-09-27 20:10+0200 Hendrik Sattler wrote: Am Donnerstag 27 September 2007 schrieb Félix C. Morency: The use of pkgconfig is prohibited, just like shell scripts and env. variables. The solution has to be as portable as it can be (win32, linux, macosx, etc.) pkgconfig _is_ portable. It works on all the mentioned platforms, AFAIK. To reinforce Hendrik's point, http://pkg-config.freedesktop.org/wiki/ has the following to say: pkg-config works on multiple platforms: Linux and other UNIX-like operating systems, Mac OS X and Windows. It does not require anything but a reasonably well working C compiler and a C library, but can use an installed glib if that is present. (A copy of glib 1.2.8 is shipped together with pkg-config and this is sufficient for pkg-config to compile and work properly.) If you look at the current source release, you will see that it is an Autoconf build. There is no other build available. On Windows that presupposes the use of a Cygwin or MSYS shell to build pkgconfig. README.win32 implies that if you build with MSYS, it's supposed to work with MSVC also. But how strong is this guarantee that it's supposed to work? There are no Windows binaries of pkg-config available on the website. Googling around, I don't see any kind of self-contained pkg-config.exe for use on the Windows Command Prompt. I do see some .exe's that are part of Cygwin or MSYS toolchains. Questions: 1) does pkg-config.exe work from the Windows Command Prompt, independent of any MSYS shell environment that was used to build it? i.e. is it really native ? AFAIK no, especially (AFAIK) it uses the same paths as under unix (including unix path separators). 2) given the build constraints and the lack of obvious deployed binaries, is anyone actually making production use of it in conjunction with MSVC? from the Command Prompt? No, in fact the other way around. KDE4/win32 completely ignores pkgconfig on win32 in its CMake FindXXX modules (its used extensively on *nix and also MacOS) To a Windows native developer this tool smells bad. I'm not a real win32 developer (just doing my part in porting a kde4 app to win32) and it smells to me as bad as it smells to you ;) Andreas -- Are you making all this up as you go along? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack option naming and deb generator
2007/9/26, Fredrik Hultin [EMAIL PROTECTED]: You're describing my problem all over again, if I'm not overlooking something important. If I write: SET(DEBIAN_PACKAGE_ARCHITECTURE whatever) INCLUDE(CPack) OK right. Sorry for the delayed answer I was too busy to give this a try. in my CMakeList.txt, it will be completly ignored since INCLUDE(CPack) only transfers variables with the CPACK_-prefix to the CPackList.cmake. So CPack will never see the DEBIAN_PACKAGE_ARCHITECTURE-variable. That's why I proposed of naming it CPACK_DEBIAN_PACKAGE_ARCHITECTURE, since then I can actually use it at all. What CPackDeb.cmake says doesn't matter since it will never see anything but the variables INCLUDE(CPack) has copied to CPackList.cmake (ie. the ones starting with CPACK_). Or perhaps I've got it all wrong? No you get it damn right. I have just the same behavior. The only way set a var value that can be seen by CPack (besides patching CMake code) is to provide it on a command line like this: cpack -G DEB -D DEBIAN_PACKAGE_ARCHITECTURE=your_arch CPackConfig.cmake then dpkg-deb -I generated-package.deb should show you Architecture: your_arch It works for me on a Debian/Etch+SID with CMake 2.5-20070927 (current CVS) This will work, but not as useful as the way I thought it was working, in the first place. I think the work on CPack Generator is not fully satisfactory, I pointed out some deisgn issue while writing the RPM generator. http://www.cmake.org/Wiki/CMakeUserUseRPMTools#CPack_Built-in_RPM_support_design_issues I think you may add your remark concerning CPack design issue, The first CMake volunteer who have time to propose patches for those issue would certainly be welcomed :=) -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] problem creating a library on mac
Mike Jackson wrote:
Comments are in-line. (Note, this is one particular style of using
CMake, other variations are perfectly valid)
--Mike Jackson Senior Research Engineer
Innovative Management Technology Services
On Sep 27, 2007, at 2:50 PM, Marie-Christine Vallet wrote:
Hi,
I have a project which in which I create a library and then I
use
this library with my executable. The way I set it up seem to be
working on
linux (fedora) but it does not work on mac ox10.
Could someone tell me what I am doing wrong,
Thanks,
Marie
Project tree
*Projectdir
**mdi
**skinmesh
in my project directory I have the following cmake file :
--
project(mdi C Fortran CXX)
cmake_minimum_required(VERSION 2.4.0)
# Set a variable to point to our top level project directory
SET (MDI_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
SET(PROJECT_BINARY_DIR
${CMAKE_SOURCE_DIR}/bin)
SET(LIBRARY_OUTPUT_PATH
${CMAKE_SOURCE_DIR}/lib)
# Add some include paths to the subdirectories
INCLUDE_DIRECTORIES ( ${MDI_SOURCE_DIR}/mdi
${MDI_SOURCE_DIR}/skinmesh )
# tell cmake to process CMakeLists.txt in these subdirectory
#they have to be added separately for it to work
#this subdirectory will create a lib so I put the lib in the lib folder
add_subdirectory(
skinmesh
${PROJECT_BINARY_DIR}
)
add_subdirectory( skinmesh ${PROJECT_BINARY_DIR}/skinmesh )
add_subdirectory( mdi ${PROJECT_BINARY_DIR}/mdi )
#this add the executable in the bin directory
add_subdirectory (
mdi
${PROJECT_BINARY_DIR}
)
--
In the mdi directory I have the following cmake file (part of it
anyay) :
--
[..]
SET(SKINMESH_LIBRARIES
${LIBRARY_OUTPUT_PATH}/libskinmesh.a
)
This is NOT needed because CMake will know about the library
libSkinMesh.a
SET(SKINMESH_INCLUDE_DIR
${CMAKE_SOURCE_DIR}/skinmesh
)
This was taken care of in the top level CMakeLists.txt file and is NOT
needed
SET(INCLUDE_DIR
${INCLUDE_DIR}
${SKINMESH_INCLUDE_DIR}
)
NOT NEEDED...
SET(LIBRARIES
${LIBRARIES}
${SKINMESH_LIBRARIES})
NOT needed. Use the name of the library directly in the
TARGET_LINK_LIBRARIES function:
SET (SKINMESH_LIB_NAME skinmesh )
[..]
# Mac configuration
IF ( CMAKE_SYSTEM_NAME MATCHES Darwin )
#setting flags
SET(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -O3 -mp1 -Kc++ -Dintel)
SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -O3 -mp1 -Kc++ -Dintel)
#equivalent to ldflag
SET( CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS}
-bind_at_load)
ENDIF ( CMAKE_SYSTEM_NAME MATCHES Darwin )
#VARIABLE INITIALISATION
# set source files
[..]
SET(mdi_EXECUTABLE
${mdi_SRCS}
${mdi_UIS_H}
${mdi_MOC_SRCS}
${mdi_RCC_SRCS}
)
This
INCLUDE_DIRECTORIES(${INCLUDE_DIR})
link_directories (${PROJECT_BINARY_DIR}/skinmesh)
CMAKE will KNOW where to look for the library. Not needed.
# create an executable file named mdi from the source files in the
variable mdi_SRCS.
ADD_EXECUTABLE ( mdi ${mdi_EXECUTABLE} )
TARGET_LINK_LIBRARIES ( mdi
${LIBRARIES}
)
TARGET_LINK_LIBRARIES (mdi ${SKINMESH_LIB_NAME})
-
In the skinmesh directory I have the following cmake file (part of it
anyay) :
-
# create an executable file named skinmesh from the source files in
the
variable skinmesh_SRCS.
ADD_LIBRARY ( skinmesh STATIC
${skinmesh_SRCS}
)
#set the linker language
SET_TARGET_PROPERTIES(skinmesh
PROPERTIES
LINKER_LANGUAGE CXX
)
[..]
# Mac configuration
IF ( CMAKE_SYSTEM_NAME MATCHES Darwin )
#setting flags
SET(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -c -O3 -mp1 -Kc++ -Dintel)
SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -c -O3 -mp1 -Kc++
-Dintel)
SET(CMAKE_Fortran_FLAGS ${CMAKE_Fortran_FLAGS} -c -u -O3
-mp1 -w90 -w95
-cpp )
#equivalent to ldflag
SET( CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} -O3
-Kc++ -mp1
-bind_at_load)
ENDIF ( CMAKE_SYSTEM_NAME MATCHES Darwin )
This...
INCLUDE_DIRECTORIES (${INCLUDE_DIR})
Most likely not needed because we set the include directories in the
top level CMakeLists.txt file
TARGET_LINK_LIBRARIES (skinmesh
${PROJECT_LIBRARIES}
)
I will assume that PROJECT_LIBRARIES was set somewhere above and has
all your 3rd party libraries that you need listed.
hope some of this helps.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Interresting dependency problem
On 2007-09-27 21:53+0200 Andreas Pakulat wrote: On 27.09.07 12:31:31, Alan W. Irwin wrote: On 2007-09-27 20:10+0200 Hendrik Sattler wrote: Am Donnerstag 27 September 2007 schrieb Félix C. Morency: The use of pkgconfig is prohibited, just like shell scripts and env. variables. The solution has to be as portable as it can be (win32, linux, macosx, etc.) pkgconfig _is_ portable. It works on all the mentioned platforms, AFAIK. To reinforce Hendrik's point, http://pkg-config.freedesktop.org/wiki/ has the following to say: pkg-config works on multiple platforms: Linux and other UNIX-like operating systems, Mac OS X and Windows. It does not require anything but a reasonably well working C compiler and a C library, but can use an installed glib if that is present. (A copy of glib 1.2.8 is shipped together with pkg-config and this is sufficient for pkg-config to compile and work properly.) No it doesn't work properly on win32 - AFAIK. Thats the reason why all cmake FindXXX modules for KDE4/win32 don't use pkgconfig. I'm not sure wether it was about the paths in the .pc files or something else, but fact is that pkconfig is unusable in _plain_ win32 (without msys, which I think creates problems when using cmake). And a link from the pkgconfig website claiming it works properly is not really a proof ;) I absolutely agree. :-) Also, I certainly have no positive proof that pkg-config works on windows (of any kind) because I don't use that platform, which is why I quoted the website. That said, the pkg-config people did make that claim on their website (why claim it if not true?), and pkg-config is really quite simple (a C programme + glib library) so I would be very surprised if it didn't work for some combination of windows with or without MinGW and with or without MSYS. So just out of curiosity are you reporting your own first-hand results for the latest version of pkg-config or something that might have been historically true? If others here have tried modern pkg-config for the various windows flavours (with or without MinGW, with or without MSYS) I would also be curious about your results as well. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] problem creating a library on mac
Are there actual implementations for the undefined functions? If there are implementations, are they being skipped because of some #define? Just some simple mistakes that I have made in the past. also, is there an actual libskinmesh.a in the following location: /Users/program/qtskinmesh/build/skinmesh or /Users/program/qtskinmesh/build/bin -- Mike Jackson Senior Research Engineer Innovative Management Technology Services On Sep 27, 2007, at 6:52 PM, Marie-Christine Vallet wrote: Linking CXX executable ../bin/mdi cd /Users/program/qtskinmesh/build/mdi /usr/local/bin/cmake -P CMakeFiles/mdi.dir/cmake_clean_target.cmake cd /Users/program/qtskinmesh/build/mdi /opt/intel/cc/10.0.016/bin/icpc -O3 -mp1 -Kc++ -Dintel -headerpad_max_install_names -bind_at_load CMakeFiles/mdi.dir/ main.o CMakeFiles/mdi.dir/csbdmainwindow.o CMakeFiles/mdi.dir/ csbdmdichild.o CMakeFiles/mdi.dir/moc_csbdmainwindow.o CMakeFiles/mdi.dir/moc_csbdmdichild.o CMakeFiles/mdi.dir/qrc_qt4skinmesh.o -o ../bin/mdi -L/Users/ program/qtskinmesh/build/skinmesh -L/Users/program/qtskinmesh/build/bin -L/usr/local/lib -L/usr/X11R6/lib -L/opt/intel/fc/10.0.016/lib -F/Library/Frameworks -framework QtGui -framework Carbon -framework QuickTime -framework QtXml -framework QtCore -lz -framework ApplicationServices -framework QtOpenGL -lQGLViewer -lgmp -lm -lGL -lGLU -lirc -limf -lifcore -lskinmesh - lgmp -lm -lGL -lGLU -lirc -limf -lifcore ld: warning multiple definitions of symbol _modf /opt/intel/cc/10.0.016/lib/libimf.a(modf_stub.o) definition of _modf in section (__TEXT,__text) /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../..//libm.dylib (xmm_floor.o) definition of _modf ld: Undefined symbols: _tetra_zone_copy_ _xyz_vertex_copy_ and my Undefined symbols are all part of my newly created library skinmesh. What suprrisses me the most is that all that works on fedora core 6 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] problem creating a library on mac
Mike Jackson wrote:
Marie,
Use the following in your CMakeLists.txt file, generally near the
top just after you define the PROJECT (... )
SET (LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/Bin CACHE INTERNAL
For libraries.)
SET (EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/Bin CACHE INTERNAL
For executables.)
done
This will put all the compiled libraries and executables into the same
bin directory.
Also, I think you may be missing a key philosophy of CMake which is
Out of Source builds. In your project folder create a new folder
called Build. Then from the a terminal run the following commands:
cd Build
cmake ../
make
thanks, I did not know that
Also, on to the actual problem, can you post the actual linker
command? Run make VERBOSE=1 and post the output.
I did the modifications you suggested, but it still does not work. For
the include directory, I had to keep
these lines :
*--
SET(SKINMESH_INCLUDE_DIR
${CMAKE_SOURCE_DIR}/skinmesh
)
SET(INCLUDE_DIR
${INCLUDE_DIR}
${SKINMESH_INCLUDE_DIR}
)
SET(INCLUDE_DIR
${INCLUDE_DIR}
${SKINMESH_INCLUDE_DIR}
)
*--
even though I did made the modification suggested in cmake file the
source directory otherwise, it was not working
Here is my linker command:
Linking CXX executable ../bin/mdi
cd /Users/program/qtskinmesh/build/mdi /usr/local/bin/cmake -P
CMakeFiles/mdi.dir/cmake_clean_target.cmake
cd /Users/program/qtskinmesh/build/mdi
/opt/intel/cc/10.0.016/bin/icpc -O3 -mp1 -Kc++ -Dintel
-headerpad_max_install_names -bind_at_load CMakeFiles/mdi.dir/main.o
CMakeFiles/mdi.dir/csbdmainwindow.o CMakeFiles/mdi.dir/csbdmdichild.o
CMakeFiles/mdi.dir/moc_csbdmainwindow.o
CMakeFiles/mdi.dir/moc_csbdmdichild.o
CMakeFiles/mdi.dir/qrc_qt4skinmesh.o -o ../bin/mdi
-L/Users/program/qtskinmesh/build/skinmesh
-L/Users/program/qtskinmesh/build/bin -L/usr/local/lib
-L/usr/X11R6/lib -L/opt/intel/fc/10.0.016/lib -F/Library/Frameworks
-framework QtGui -framework Carbon -framework QuickTime -framework QtXml
-framework QtCore -lz -framework ApplicationServices -framework QtOpenGL
-lQGLViewer -lgmp -lm -lGL -lGLU -lirc -limf -lifcore -lskinmesh -lgmp -lm
-lGL -lGLU -lirc -limf -lifcore
ld: warning multiple definitions of symbol _modf
/opt/intel/cc/10.0.016/lib/libimf.a(modf_stub.o) definition of _modf in
section (__TEXT,__text)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../..//libm.dylib(xmm_floor.o)
definition of _modf
ld: Undefined symbols:
_tetra_zone_copy_
_xyz_vertex_copy_
and my Undefined symbols are all part of my newly created library
skinmesh. What suprrisses me the most is that all that works on fedora
core 6
Thanks again,
Marie
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Confikgurations and Platforms in Visual Studio 8
Also, does cmake have an idea of platforms, or does it assume Win32? CMake does not assume anything about Win32 or any other platform. What I mean is, in vcproj files combine the configuration and the platform labels to form a compilation target, i.e Release|Win32, Debug|x64. How do I go about specifying the platform parts of these with cmake? For example, I say I have 'Release', 'Debug', and 'Special' configurations, and Win32 and x64 platforms. Now suppose that I only support the following configurations: Release|Win32 Release|x64 Debug|Win32 Debug|x64 Special|x64 How do I go about specifying that to cmake? Answering my own question, after a bit of research, it appears that cmake doesn't natively deal with cross-platform building for Visual Studio Projects. Instead it tests to see whether to generate Win32 or x64 project file configurations. In the environment we've got, we want to build Win32, Xbox 360 and Playstation 3 binaries, all from a Win32 box. I wonder what the best way to tweak cmake to do this is. My first thoughts are to do away with Visual Studio altogether, as its vcproj files are pretty hard coded into cmake. Instead I'm playing with using a traditional make, but I still need vcproj external make files, as the developers are using visual studio. I've ordered the book - perhaps I'll get some hints from there. I'd be interested in hearing from anyone who is already doing this kind of thing. Joe ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] problem creating a library on mac
Did you run nm on the library containing these symbols to verify they exist?
_tetra_zone_copy_
_xyz_vertex_copy_
The trailing underscore is reminiscent of a Fortran compiler. Are you using
the write convention when calling these functions from C code? On Linux,
you would call the Fortran function foo as foo_.
Should you be linking against libm, if you are getting the same symbols from
libimf.a?
ld: warning multiple definitions of symbol _modf
/opt/intel/cc/10.0.016/lib/libimf.a(modf_stub.o) definition of _modf in
section (__TEXT,__text)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../..//libm.dylib(xmm_floor.o)
definition of _modf
Regards,
Juan
On 9/27/07, Marie-Christine Vallet [EMAIL PROTECTED] wrote:
Mike Jackson wrote:
Marie,
Use the following in your CMakeLists.txt file, generally near the
top just after you define the PROJECT (... )
SET (LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/Bin CACHE INTERNAL
For libraries.)
SET (EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/Bin CACHE INTERNAL
For executables.)
done
This will put all the compiled libraries and executables into the same
bin directory.
Also, I think you may be missing a key philosophy of CMake which is
Out of Source builds. In your project folder create a new folder
called Build. Then from the a terminal run the following commands:
cd Build
cmake ../
make
thanks, I did not know that
Also, on to the actual problem, can you post the actual linker
command? Run make VERBOSE=1 and post the output.
I did the modifications you suggested, but it still does not work. For
the include directory, I had to keep
these lines :
*--
SET(SKINMESH_INCLUDE_DIR
${CMAKE_SOURCE_DIR}/skinmesh
)
SET(INCLUDE_DIR
${INCLUDE_DIR}
${SKINMESH_INCLUDE_DIR}
)
SET(INCLUDE_DIR
${INCLUDE_DIR}
${SKINMESH_INCLUDE_DIR}
)
*--
even though I did made the modification suggested in cmake file the
source directory otherwise, it was not working
Here is my linker command:
Linking CXX executable ../bin/mdi
cd /Users/program/qtskinmesh/build/mdi /usr/local/bin/cmake -P
CMakeFiles/mdi.dir/cmake_clean_target.cmake
cd /Users/program/qtskinmesh/build/mdi
/opt/intel/cc/10.0.016/bin/icpc -O3 -mp1 -Kc++ -Dintel
-headerpad_max_install_names -bind_at_load CMakeFiles/mdi.dir/main.o
CMakeFiles/mdi.dir/csbdmainwindow.o CMakeFiles/mdi.dir/csbdmdichild.o
CMakeFiles/mdi.dir/moc_csbdmainwindow.o
CMakeFiles/mdi.dir/moc_csbdmdichild.o
CMakeFiles/mdi.dir/qrc_qt4skinmesh.o -o ../bin/mdi
-L/Users/program/qtskinmesh/build/skinmesh
-L/Users/program/qtskinmesh/build/bin -L/usr/local/lib
-L/usr/X11R6/lib -L/opt/intel/fc/10.0.016/lib -F/Library/Frameworks
-framework QtGui -framework Carbon -framework QuickTime -framework QtXml
-framework QtCore -lz -framework ApplicationServices -framework QtOpenGL
-lQGLViewer -lgmp -lm -lGL -lGLU -lirc -limf -lifcore -lskinmesh -lgmp -lm
-lGL -lGLU -lirc -limf -lifcore
ld: warning multiple definitions of symbol _modf
/opt/intel/cc/10.0.016/lib/libimf.a(modf_stub.o) definition of _modf in
section (__TEXT,__text)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../..//libm.dylib(xmm_floor.o)
definition of _modf
ld: Undefined symbols:
_tetra_zone_copy_
_xyz_vertex_copy_
and my Undefined symbols are all part of my newly created library
skinmesh. What suprrisses me the most is that all that works on fedora
core 6
Thanks again,
Marie
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Interresting dependency problem
Am Freitag 28 September 2007 schrieb Andreas Pakulat: On 27.09.07 16:07:46, Alan W. Irwin wrote: On 2007-09-27 21:53+0200 Andreas Pakulat wrote: No it doesn't work properly on win32 - AFAIK. Thats the reason why all cmake FindXXX modules for KDE4/win32 don't use pkgconfig. I'm not sure wether it was about the paths in the .pc files or something else, but fact is that pkconfig is unusable in _plain_ win32 (without msys, which I think creates problems when using cmake). And a link from the pkgconfig website claiming it works properly is not really a proof ;) I absolutely agree. :-) Also, I certainly have no positive proof that pkg-config works on windows (of any kind) because I don't use that platform, which is why I quoted the website. That said, the pkg-config people did make that claim on their website (why claim it if not true?), Well, because portability is a big plus? Just guessing here, I never used pkg-config (why install something of which I've been told by long-time-win32 developers that its just broken) It's open, fix it instead of complaining. and pkg-config is really quite simple (a C programme + glib library) so I would be very surprised if it didn't work for some combination of windows with or without MinGW and with or without MSYS. Well, it might run and eventually it might even return something when you ask it for. Nevertheless there's at least one problem with it: The paths are hardcoded into the .pc files, which means a) an installer for a lib has to change this file during installation - its quite usual to install a program into a different location than its defaulting to At least the pkgconfig documentation mentions this case and how it (is supposed to) deal with it. b) you can't move the lib afterwards without changing the .pc files. Same case. CMake creates the same problem by using rpath by default, doesn't it? So just out of curiosity are you reporting your own first-hand results for the latest version of pkg-config or something that might have been historically true? I'm reporting 2nd hand information from people that have long-time experience with pkg-config. Unfortunately I can't find the thread on the kde lists where Christian Ehrlicher pointed out the other issues with pkg-config, maybe I'll have a try with it tomorrow... I only used it with msys so far and it's working, there, using the GLIB dll and the provided pre-compiled pkgconfig binary. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] pkg-config at Windows Command Prompt
On 2007-09-27 16:12-0400 Brandon Van Every wrote: [...]There are no Windows binaries of pkg-config available on the website. Googling around, I don't see any kind of self-contained pkg-config.exe for use on the Windows Command Prompt. I do see some .exe's that are part of Cygwin or MSYS toolchains. Hi Brandon: http://www.gimp.org/~tml/gimp/win32/downloads.html is a site that contains windows binaries for the libgtk+ dependencies (which include glib and pkg-config). I have been made aware of this site because it apparently works for our PLplot windows developers when building one of our libgtk+ related device drivers on windows. I just downloaded pkg-config-0.20.zip from there, and there is indeed a bin/pkg-config.exe inside that zip. Questions: 1) does pkg-config.exe work from the Windows Command Prompt, independent of any MSYS shell environment that was used to build it? i.e. is it really native ? That's an important question. Please try the pkg-config.exe that I found above (I have no access to windows so I cannot try it myself) and let us know the answer. I assume you have to download the glib windows binary package from that same site as well. [out of order]If you look at the current source release, you will see that it is an Autoconf build. I agree that the current autoconf build requirement is a real turnoff for windows users (and everybody else here :-) ). However, if the binary version of pkg-config that I found passes the above test, then that might motivate somebody to port the build system for it and glib to CMake. BTW, the reason I have been doing some pkg-config advocacy here is I have had good experiences with it as a Linux/Unix developer. It's a straightforward tool that is easy to use from the command line or from CMake to derive needed compilation and linking information for a given package. Also, it is extremely easy to export compiler and linking information for a given software package in pkg-config form (that is what we do with PLplot, for example, to make it easy to build applications that use the various PLplot libraries). Thus, when I saw the pkg-config website assertion today that it worked on windows, that seemed important to me. Thus, I really do hope for the sake of windows developers and PLplot windows users that your test of the above binary version of pkg-config works out. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Interresting dependency problem
On 27.09.07 16:07:46, Alan W. Irwin wrote: On 2007-09-27 21:53+0200 Andreas Pakulat wrote: No it doesn't work properly on win32 - AFAIK. Thats the reason why all cmake FindXXX modules for KDE4/win32 don't use pkgconfig. I'm not sure wether it was about the paths in the .pc files or something else, but fact is that pkconfig is unusable in _plain_ win32 (without msys, which I think creates problems when using cmake). And a link from the pkgconfig website claiming it works properly is not really a proof ;) I absolutely agree. :-) Also, I certainly have no positive proof that pkg-config works on windows (of any kind) because I don't use that platform, which is why I quoted the website. That said, the pkg-config people did make that claim on their website (why claim it if not true?), Well, because portability is a big plus? Just guessing here, I never used pkg-config (why install something of which I've been told by long-time-win32 developers that its just broken) and pkg-config is really quite simple (a C programme + glib library) so I would be very surprised if it didn't work for some combination of windows with or without MinGW and with or without MSYS. Well, it might run and eventually it might even return something when you ask it for. Nevertheless there's at least one problem with it: The paths are hardcoded into the .pc files, which means a) an installer for a lib has to change this file during installation - its quite usual to install a program into a different location than its defaulting to b) you can't move the lib afterwards without changing the .pc files. Luckily they're plain text. Wether or not they contain win32-paths or unix-like paths and wether or not one can adjust pkg-config to create information for VS I don't know. So just out of curiosity are you reporting your own first-hand results for the latest version of pkg-config or something that might have been historically true? I'm reporting 2nd hand information from people that have long-time experience with pkg-config. Unfortunately I can't find the thread on the kde lists where Christian Ehrlicher pointed out the other issues with pkg-config, maybe I'll have a try with it tomorrow... Andreas -- You will always get the greatest recognition for the job you least like. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Visual Studio 8 and warning levels
I'm having some trouble getting a clean way to set the warning level
in my projects with Visual Studio 2005.
When I try this
SET(CMAKE_C_WARNING_LEVEL 4)
SET(CMAKE_CXX_WARNING_LEVEL 4)
It seems to be ignored because the project files still have the
warning level set to 3. I only want to turn up (or down) the warning
level for particular projects so I don't want to mess with the cache
variable.
I found this searching through old posts and it works, but it seems a
bit sloppy to have to do this when there is a simply way to just set
the Warning Level.
IF(CMAKE_CXX_FLAGS MATCHES /W[0-4])
STRING(REGEX REPLACE /W[0-4] /W4 CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
ELSE(CMAKE_CXX_FLAGS MATCHES /W[0-4])
SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /W4)
ENDIF(CMAKE_CXX_FLAGS MATCHES /W[0-4])
-Neal
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] problem creating a library on mac
Mike Jackson wrote: Are there actual implementations for the undefined functions? If there are implementations, are they being skipped because of some #define? Just some simple mistakes that I have made in the past. The thing is the code is the same for linux and for mac, and it works well with linux. If I manually generate the linking part without using the library, explicitly using the .o file, the linking works and generates a working executable. also, is there an actual libskinmesh.a in the following location: /Users/program/qtskinmesh/build/skinmesh or /Users/program/qtskinmesh/build/bin it's in /Users/program/qtskinmesh/build/bin --Mike Jackson Senior Research Engineer Innovative Management Technology Services as suggested previously, I also tried to change the linker order (by hand) by putting the newly generated library at the end (since non of the other libraries are independent on my newly created one) but that does not work either. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Interresting dependency problem
On 9/27/07, Andreas Pakulat [EMAIL PROTECTED] wrote: I'm reporting 2nd hand information from people that have long-time experience with pkg-config. Unfortunately I can't find the thread on the kde lists where Christian Ehrlicher pointed out the other issues with pkg-config, maybe I'll have a try with it tomorrow... Kudos to you for your diligence, but this is a waste of time. I looked at the sources today, and it's obvious from the READMEs and Googling what the level of MSVC support really is. It's designed around gcc toolchains and Unix shells. Have fun coaxing it to work with MSVC and no Unix shell. It may be doable, it may not be doable, but it is certainly not widespread production practice so you're going to take lumps. I can't see why any CMake-oriented person would recommend pkg-config unless they're stuck with it as a legacy concern. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Interresting dependency problem
Hi, Thank you all for answering. First, I would like to mention that the pkg-config alternative isn't very portable. Like other already said, it does not work well under Microsoft Windows nor MSVC. Also, all paths are wrote in .pc files which aren't very portable. I think I might have found a solution to this problem today. Here are the basics of the idea: You first need a main configuration file which contains a WORKING_DIR for the executable to be build as well as a PROJECT_INCLUDE_DIR and a PROJECT_LIBRARY_DIR (which are in the WORKING_DIR. For each library, you need two files: - A CMake script that tells the CMake engine how to build the library; - A configuration file that tells the CMake engine who the library is and where to get it dependencies. The trick is in how the CMake engine process the CMake scripts. A feature of CMake's engine is that it can propagate dependencies up-bottom. This is nice if you want to use a master-script approach but isn't usable if you want to be able to build every part of the chain independantly. To acheive such goal, you may want to propagate dependencies bottom-up. As far as I know, this is not doable natively with the CMake engine but can be acheive with the basics I've told earlier. Here's a small example: The project A which contains the A_BuildScript and A_ConfigScript. The project A needs the project B to build. The project B which contains the B_BuildScript and B_ConfigScript. The project B need the third party library C to build. The library C is built by another build system independantly. The B_ConfigScript contains the B project's settings as well as where to find C includes and libraries. Let call the include path PROJECT_B_INCLUDE_DIR. The B_BuildScript contains the instructions on how to build the project Bwith the source files list and what directories to include (refer to PROJECT_B_INClUDE_DIR). The A_ConfigScript contains the A project's settings as well as where to find the B_ConfigScript. Let's call the include path PROJECT_A_INCLUDE_DIR. The A_BuildScript contains the instructions on how to build the project A with the source files life and what directory to include (refer to PROJECT_A_INClUDE_DIR and PROJECT_B_INClUDE_DIR). Depending on how your code has been written, you might need to copy project B's libraries and include to the PROJECT_LIBRARY_DIR and the PROJECT_INCLUDE_DIR. This can be done in the A_BuildScript and B_BuildScriptand processed by calling the CMake's SUBDIRS command. As far as I know, with all the testing I did, this works very well. By including the B_ConfigScript into the A_ConfigScript, you also include the Clibrary w/o having to know whatever about C itself because de dependencies propagate bottom-up. Another good thing is that now every single part of the chain can be build independantly (by processing the A_BuildScript or the B_BuildScript directly). I might write some practical example if I have time or if someone asks for it. Please give me your feedback about it. Thank you for reading me, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Nonstandard architectures.
Hi, On Thursday 27 September 2007 15:53, Andreas Pakulat wrote: Just to state the obvious: Thats backwards compared to what distro's have these days. */lib is always the native libs and then you have either lib64 or lib32 (at least AFAIK, don't have any 64-bit system) No. On a redhat or suse linux - probably that Linux distros with most installations on this blue marble - 32 bit i386 libs are in 'lib' and emt64 libs in 'lib64'. Well debian does it 'right' from that point of view, but But cmake looks in */lib directories where some x86 libs are present that are not present for the x86-64 case. The question here is even worse - which one is the native one?? lib or lib64?? And which ones should cmake accept? I think there's a way to tell CMake to either use lib or lib64, something like LIB_SUFFIX. I could not find such a thing. Can you give me a more concrete hint? But yes, for most of the platforms (I believe AIX will still fall through), such a path suffix that can be globally configurable would help much. Ok, the problem with AIX: They have archive files that can even einclude object or shared object files for different abis. The linker cares for selecting the correct ones. At least we observed that with some libraries ... Strange, but the real existing world ... Greertings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
