Re: [CMake] find_library and mac os x SDKs
On 28. Mar, 2010, at 3:25 , Simmons, Aaron wrote: What I don't understand is this: Why do you want to force the SDK? Shouldn't this be the worry of the person doing the build? If I download some open-source software and then build it for myself, I don't want to be forced in using the 10.4 SDK, I wan't to build against the greatest and latest! If this were open-source, I'd agree with you. But it's not-- it's the build script for my company's software that needs to run on 10.4. I suppose I could have cmake try for the 10.4 sdk if it's available or use the default otherwise. But since it's a requirement that it work on 10.4, I'd rather have it always build that way. aaron Then I'd suggest you wrap the build-process in a easy-to-use script, where you look for the 10.4 SDK and then call CMake with a cache-initializer script (-C option) to set the required options in the cache. Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using target_link_libraries
On 28. Mar, 2010, at 1:57 , Colin Michael Diesh wrote:
Hey, I was trying to use the TARGET_LINK_LIBRARIES in a CMakeLists.txt file
but the linking doesn't end up working. I am using cygwin and CMake 2.6.4
Currently, I am having trouble with the OpenGL libraries. It links GLUT but
not the OpenGL libraries.
CMakeLists.txt
...
FIND_PACKAGE(OpenGL)
FIND_PACKAGE(GLUT)
...
SET(program_LIBS ${program_LIBS} ${GLUT_LIBRARIES} )
SET(program_LIBS ${program_LIBS} ${OPENGL_LIBRARIES} )
...
ADD_EXECUTABLE(tiney ${program_SRCS})
TARGET_LINK_LIBRARIES(program ${program_LIBS})
...
--
Doing MESSAGE(STATUS ${program_LIBS}) gives
--
/lib/libglut.dll.a;/usr/lib/w32api/libglu32.a;/usr/lib/w32api/libopengl32.a;/usr/X11R6/lib/libGLEW.a
CMakeFiles/program.dir/link.txt says this
/usr/bin/gcc.exe -O3 -DNDEBUG CMakeFiles/tiney.dir/main.c.o -o tiney.exe
-Wl,--out-implib,libtiney.dll.a
-Wl,--major-image-version,0,--minor-image-version,0 -lglut
/usr/lib/w32api/libglu32.a /usr/lib/w32api/libopengl32.a
/usr/X11R6/lib/libGLEW.a
So it links GLUT correctly, but the opengl libraries do not get linked, they
do not have '-l'. Is there any way I can fix this?
Note: it also doesn't work for another library, libGLEW.a.
-Colin
There seems to be nothing wrong here... If possible, CMake prefers to link
using the full path instead of relying on the -l flag. This is mainly because
using -L and -l it is very difficult to ensure which library is linked if there
are more than one library by that name on the linker path. Also, the linker
will usually prefer dynamic libraries over static ones, unless forced with a
special flag, but then that flag acts on all libraries, not just one.
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Is there really any cmake support?
This list seems not to be really active and I did not receive any help since I posted this one week ago. BTW this issue has been open on Mantis more than 3 months ago and seems still to be open! So is there really anybody trying to help on cmake?? From: stan1...@hotmail.fr To: cmake@cmake.org Date: Sat, 20 Mar 2010 17:28:53 +0100 Subject: [CMake] Windows install issue I also face this bug, which seems not to have been fixed. I use Cygwin and MinGV on XP. This thread was posted on the ITK bug list, so should I copy it on the cmake bug list? http://www.itk.org/Bug/view.php?id=8516 Commander un cadeau en ligne discrètement? Voir la solution offerte par Internet Explorer8 _ Hotmail et MSN dans la poche? HOTMAIL et MSN sont dispo gratuitement sur votre téléphone! http://www.messengersurvotremobile.com/?d=Hotmail___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Is there really any cmake support?
2010/3/28 Fred Fred stan1...@hotmail.fr: This list seems not to be really active You are kidding right? Did you check the past 3 years archive ? and I did not receive any help since I posted this one week ago. BTW this issue has been open on Mantis more than 3 months ago and seems still to be open! I'm sure that you may find far older bugs on many project. So is there really anybody trying to help on cmake?? May be you want :-) ? I think you may be wrong about what to expect from an Open Source community and how to ask for help. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Is there really any cmake support?
On 28. Mar, 2010, at 12:37 , Eric Noulard wrote: 2010/3/28 Fred Fred stan1...@hotmail.fr: This list seems not to be really active You are kidding right? Did you check the past 3 years archive ? Two years worth of messages in my mailbox: 16422... and I did not receive any help since I posted this one week ago. BTW this issue has been open on Mantis more than 3 months ago and seems still to be open! I'm sure that you may find far older bugs on many project. And this one is probably one of the harder bugs to fix, and very few people seem to be affected by it (that is, most programmers probably don't even try to use international characters in their path names...) So is there really anybody trying to help on cmake?? May be you want :-) ? That's how it usually works (and quite well at that) in open source projects: Everybody scratches his own itch ;-) I think you may be wrong about what to expect from an Open Source community and how to ask for help. AFAIK Kitware does prioritize paid work, so perhaps the OP should contact the sales department ;-) Back to the original problem: The easy fix? Only use ASCII characters in your path names... The real fix would be to port CMake to fully support UTF-16/32: a huge undertaking, with any software. Especially, since wchar_t is not guaranteed to be large enough to hold unicode characters; it may be as small as 8 bit! On many platforms, most compilers use 32 bit, but you can't rely on that. The upcoming C++ standard (C++0x) does define exact-width character types (char16_t, char32_t) and the corresponding string types (std::u16string and std::u32string), but then I don't know about the whole machinery you need to actually deal with such strings effectively. However, this is a future standard and I'm very sure that the CMake-developers will not rely on any of its features for years to come since they want CMake to build on all kinds of old and weird systems. One option would be to use ICU (http://icu-project.org), but again, this would require a lot of work and is a HUGE dependency... Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] splitting compilation into steps
Hi CMakers,
I am trying to use CMake with llvm-gcc compiler (
http://llvm.org/cmds/llvmgcc.html) and want to split the compilation into
three steps:
1. Compile the C/C++ source code into LLVM bitcode using llvm-gcc with the
command llvm-gcc c-flags -emit-llvm -o bitcode -c source
2. Compile bitcode into assembly language using llc with the command llc -o
assembly bitcode
3. Translate assembly language into object code using GNU assembler with the
command as -o object assembly
The reason for this is that I need both the object files and the bitcode
files be generated.
However I can't figure out how to accomplish this.
So far the only way to invoke llvm-gcc with the correct flags I have found
is to redefine CMAKE_CXX_COMPILE_OBJECT as follows:
string(REPLACE OBJECT OBJECT.bc
generate_bc ${CMAKE_CXX_COMPILE_OBJECT})
set(CMAKE_CXX_COMPILE_OBJECT
${CMAKE_CXX_COMPILE_OBJECT} ${generate_bc} -emit-llvm)
However it invokes the compiler two times: one to generate the object file
(steps 1 - 3 combined) and one to generate the bitcode (step 1).
Is there a better solution to this problem?
Best regards,
Victor
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Is there really any cmake support?
On Sunday 28 March 2010, Eric Noulard wrote: 2010/3/28 Fred Fred stan1...@hotmail.fr: This list seems not to be really active You are kidding right? Did you check the past 3 years archive ? and I did not receive any help since I posted this one week ago. BTW this issue has been open on Mantis more than 3 months ago and seems still to be open! I'm sure that you may find far older bugs on many project. So is there really anybody trying to help on cmake?? May be you want :-) ? I think you may be wrong about what to expect from an Open Source community and how to ask for help. Luckily enough, cmake is not just open source, but also developed by a commercial company, so if you look for commercial support, you can have that too: http://kitware.com/products/support.html Alex ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Is there really any cmake support?
On 3/28/2010 5:14 AM, Fred Fred wrote: This list seems not to be really active and I did not receive any help since I posted this one week ago. BTW this issue has been open on Mantis more than 3 months ago and seems still to be open! So is there really anybody trying to help on cmake?? If the developers were out monitoring every bug-reporting list in the universe (such as ITK), there probably wouldn't be any support. To answer your question: yes you should post it to the CMake bug reporting tool if you want the CMake people to know about it. If the bug is that mission critical to you, there is always the option of downloading the source, fixing the bug, and submitting a patch to the CMake developers. Otherwise - I'd love to know what significantly-cross-platform open source projects you've been working on where bug fixes have such a rapid turnaround. I've seen fairly critical bug tickets for Ubuntu, GDM, Firefox, Thunderbird, OpenOffice and GCC for years. MySQL has had several fatal crash bugs open for 2+ years, and their response to a major bug introduced by Prepared Statements was, after a year of people complaining about it, to remove the default auto-connection behavior to sort of make it go away. Thus far, I've gotten better support out of the CMake developers than I have from several commercial software providers, including Intel. - Oliver ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Is there really any cmake support?
Subject: Re: [CMake] Is there really any cmake support? From: them...@gmail.com Date: Sun, 28 Mar 2010 13:10:17 +0200 CC: stan1...@hotmail.fr; cmake@cmake.org To: eric.noul...@gmail.com On 28. Mar, 2010, at 12:37 , Eric Noulard wrote: 2010/3/28 Fred Fred stan1...@hotmail.fr: This list seems not to be really active You are kidding right? Did you check the past 3 years archive ? Two years worth of messages in my mailbox: 16422... Ok, I just start on this mailing list but since I did not see much activity, I really wonder what is about it, that's all. The oter reason is that, concerning the mentionned bug, any response to the problem. An answer such as ok, we are aware of it but we have more important priorities now would have been clear enough. I understand that cmake developpers cannot solve all of the problems arising with their code. and I did not receive any help since I posted this one week ago. BTW this issue has been open on Mantis more than 3 months ago and seems still to be open! I'm sure that you may find far older bugs on many project. And this one is probably one of the harder bugs to fix, and very few people seem to be affected by it (that is, most programmers probably don't even try to use international characters in their path names...) So is there really anybody trying to help on cmake?? May be you want :-) ? That's how it usually works (and quite well at that) in open source projects: Everybody scratches his own itch ;-) lol I think you may be wrong about what to expect from an Open Source community and how to ask for help. AFAIK Kitware does prioritize paid work, so perhaps the OP should contact the sales department ;-) Back to the original problem: The easy fix? Only use ASCII characters in your path names... As far as I am concerned, I did: I created a specific path, starting from /Development, without any space nor international character, just ASCII ones. But same issue: the test program testCCompiler.c is never created The real fix would be to port CMake to fully support UTF-16/32: a huge undertaking, with any software. Especially, since wchar_t is not guaranteed to be large enough to hold unicode characters; it may be as small as 8 bit! On many platforms, most compilers use 32 bit, but you can't rely on that. The upcoming C++ standard (C++0x) does define exact-width character types (char16_t, char32_t) and the corresponding string types (std::u16string and std::u32string), but then I don't know about the whole machinery you need to actually deal with such strings effectively. However, this is a future standard and I'm very sure that the CMake-developers will not rely on any of its features for years to come since they want CMake to build on all kinds of old and weird systems. What I do not understand is why would cmake use non ASCII characters? Since my path is in ASCII (at least I hope that a mkdir command with non-accentuated characters does not generate non ASCII paths!) and I checked all the paths in the cmake configuration editor, I do not understand where a problem may arise. One option would be to use ICU (http://icu-project.org), but again, this would require a lot of work and is a HUGE dependency... Michael Thx for your answer. _ Découvrez comment SURFER DISCRETEMENT sur un site de rencontres ! http://clk.atdmt.com/FRM/go/206608211/direct/01/___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Is there really any cmake support?
Am Sonntag 28 März 2010 13:10:17 schrieb Michael Wild: The easy fix? Only use ASCII characters in your path names... The real fix would be to port CMake to fully support UTF-16/32: a huge undertaking, with any software. Especially, since wchar_t is not guaranteed to be large enough to hold unicode characters; it may be as small as 8 bit! See http://www.opengroup.org/onlinepubs/7990989775/xsh/stddef.h.html Even when sizeof(wchar_t)==1, you don't have a problem. But since there is no easy and standard way to convert from wchar_t to Unicode (of the locale character set is not UTF-8), whar_t is useless if you need to explicitely convert to non-locale character sets. Else, it is sufficient. This is also a bit dedicated to the strange Windows environment... :-( On many platforms, most compilers use 32 bit, but you can't rely on that. The upcoming C++ standard (C++0x) does define exact-width character types (char16_t, char32_t) and the corresponding string types (std::u16string and std::u32string), but then I don't know about the whole machinery you need to actually deal with such strings effectively. C++0x would definitely be nice but will still need several month. gcc-4.5 and VC++ 2010 wil partly support it but you can add several years before it is widely adopted. HS ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Annoyances with cmake vs qmake
2010/3/28 Ruben Van Boxem vanboxem.ru...@gmail.com: Hi Ruben, 2) A second point, and this has been brought up before on this list, several times even. With qmake: qmake make debug //produces debug binaries make release //produces release binaries make all //produces both make distclean //cleans out *most* of the qmake generated files As you may have read, the multi-config in the same generator is supported by some generator (like the Visual Studio one) which have this builtin and concerning the Makefile generator you can easily reproduce what you want with a simple script which would do mkdir build_debug cd build_debug cmake -DCMAKE_BUILD_TYPE=Debug /path/to/source make cd .. mkdir build_release cd build_release cmake -DCMAKE_BUILD_TYPE=Release /path/to/source cd .. concerning make clean the following is even cleaner: rm -rf build_debug rm -rf build_release Concerning the default value for CFLAGS in Release I didn't realize the default CMake choice was different from other and I let CMake developer explain why. In the meantime you may define your own MyRelease type of build. see http://www.itk.org/Wiki/CMake_Useful_Variables -- CMAKE_BUILD_TYPE. It shouldn't be hard to have each target's build dir have a debug and release folder (even if it's only for windows stuff), and add the de facto standard debug suffix d to the debug binaries. Even easier would be to have all debug object files have the d suffix, eliminating the need for release and debug directory clobber. Having a separate build dir for debug and release doesn't mean you can't mangle the postfix of your lib. In fact you just have to add to your CMakeLists.txt SET(CMAKE_DEBUG_POSTFIX d CACHE STRING debug library postfix, usually d on windows) and library generated for DEBUG build type will have the extra d. Additionally, the distclean target is pretty handy, but I've seen enough argumentation (out-of-source builds) that convinces me it's not the CMake way I think you get that one already. So something like this would be AWESOME: mkdir build cd build cmake .. make debug //produce debug binaries make release //produce release binaries make all //produce both A simple debug suffix will solve most problems with this I believe, and seems to me, extremely handy for the windows platform. Then MinGW or Nmake makefiles will be a standalone thing, like vcproj files, where it is perfectly possible. Now after all what you said, I would be tempted by a multiconfig single build mainly because I'd like for example to package **BOTH** build with CPack in a single package and this is currently not possible out of the box. On a sidenote, CMake is very powerful and solid tool, and I'm really starting to hate the whole configure script and libtool hell. Thanks Welcome to a new Hell :-] ... just kidding. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Annoyances with cmake vs qmake
Am Sonntag 28 März 2010 21:06:10 schrieb Ruben Van Boxem: Since qmake is pretty mouldy (I mean, not probable to be updated anytime soon with new functionality), I decided to try cmake and its colourful build process. But if you ever want to leave the very narrow path of what qmake is supposed to do, you are virtually doomed :-( When experimenting with qmake, I ported libogg, libvorbis and libflac to a qmake build system and it worked pretty easily, without many hiccups. Mind you, I didn't add any assembly stuff to the builds, just source and build options. And that brings me to my first point 1) in qmake and any other configure-based build system, the release build options for gcc/g++ are something like this: -O2 -s. CMake uses -O3. This is neither standard nor recommended (see gcc docs, this option might even produce slower code). It also forgets to strip the binary target, which makes you end up with larger binaries. This should be changed, as -O2 -s for release builds is pretty much the de facto standard. gcc -s is only convenient for e.g. qmake because it only has one install target. In cmake, you have make install and make install/strip, so you can decide at a later point. And even later, you can always use strip directly to achieve exactly the same. Choosing -O2 would really be preferred, but you may as well argue for -Os or anything else. You should always set the preferred thing yourself, see (C|CPP|CXX|LD)FLAGS environment variables. A simple debug suffix will solve most problems with this I believe, and seems to me, extremely handy for the windows platform. Then MinGW or Nmake makefiles will be a standalone thing, like vcproj files, where it is perfectly possible. No, because when compiling differently for Debug and Release, you have all object files twice. Thus you would enforce one more level of subfolders even for those that only want one setup. There may be a new Generator that does that but it still has to be written ;) HS ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using target_link_libraries
Turns out it was win32 versus the native cygwin conflicting, not missing link libraries. I had to modify the Find scripts to find cygwin or win32 with -mnocygwin. Thanks -Colin ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Add .la files to shared lib
I am trying to compile shared lib dynamically linked with one set of libs and statically with anoter. Static libs are provided by third party Probably Ihave to define new target with IMPORTED flag for each .la file, but how to add them to final shared library file? ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
