Re: [CMake] No LANG_FLAGS_CONFIG target property.
Zitat von Óscar Fuentes o...@wanadoo.es: There are target properties such as LINK_FLAGS and LINK_FLAGS_CONFIG, but I don't see properties for setting compiler flags. This makes impossible to build two targets on the same CMakeLists.txt with different compiler flags (I was told that the last value of CMAKE_LANG_FLAGS_CONFIG applies to all targets on that CMakeLists.txt). So why no per-target compile flags? RTFM? The following line is directly derived from the words in your question: set_target_properties(myTarget PROPERTIES COMPILE_FLAGS -foo -bar) Or maybe your question was wrong? 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] No LANG_FLAGS_CONFIG target property.
Am Montag 14 März 2011, 16:35:21 schrieb Óscar Fuentes: Hendrik Sattler p...@hendrik-sattler.de writes: Zitat von Óscar Fuentes o...@wanadoo.es: There are target properties such as LINK_FLAGS and LINK_FLAGS_CONFIG, but I don't see properties for setting compiler flags. This makes impossible to build two targets on the same CMakeLists.txt with different compiler flags (I was told that the last value of CMAKE_LANG_FLAGS_CONFIG applies to all targets on that CMakeLists.txt). So why no per-target compile flags? RTFM? The following line is directly derived from the words in your question: set_target_properties(myTarget PROPERTIES COMPILE_FLAGS -foo -bar) Or maybe your question was wrong? The COMPILE_FLAGS property sets additional compiler flags used to build sources within the target. So it *adds* flags. I want to *set* flags, i.e. replace the existing ones. So you add global compiler flags which are not meant to be global? A usual person would say: then do not set them globally!. It's really that simple... 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] To avoid target_link_libraries magic
Zitat von Valeriy Bykov valery.bic...@gmail.com: So I'll try to describe all my problems: I want to build all the project statically using certain version of glibc, gcc and all other libs I need. They are situated in the folder builddeps which I can simply checkout on any host and pass it's path to CMake. I set compile option -nostdinc and specify all system and user include directories explicitly in toolchain file. By this I can be sure that only headers are used which I want, and no one from host system where may be its own gcc and glibc too. You want the --sysroot gcc option. 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] LINK_FLAGS works incorrectly,
Am Montag 18 April 2011, 15:25:24 schrieb Łukasz Tasz: Hi all, I got a simple question, What is idea behind target property LINK_FLAGS? When I add linker flag e.g --no-undefined then cmake is not alligning it to real linker that will be used during linking. for example --no-undefined is a valid ld switch, but when I specify it LINK_FLAGS it will not reach linker since cmake is deciding to use g++ and is forgeting about adding -Wl, at the begining. However, there are flags for the linking stage of the compiler that do not directly translate to -Wl,--somthing but e.g. instruct gcc what libraries to use (or not) for linking. Just look at Options for Linking in man gcc. 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] Newbie question: Static linking
Am Montag, 23. Mai 2011, 01:36:14 schrieb Sanatan Rai: After cmake, and make all, the libraries build as static archives, ie I get liblib1.a, liblib2.a, libhelper1.a, libhelper2.a and executable myProj in the appropriate locations. However, the executable myProj does not appear to have linked statically to libhelper1.a and libhelper2.a. These libraries contain global initialisers for certain objects: which doesn't happen when I run the executable. Most likely, the linker just drops those global initialisers when linking statically. See the linker options in man ld to prevent that or give the library an initialisation method. 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] Newbie question: Static linking
Zitat von Sanatan Rai sana...@gmail.com:
The `global initialisation' stuff is just the following pattern:
namespace {
helper1 *helper1Creator()
{
return (new helper1());
}
const bool helper1Registered = factory::instance().registerhelper
(helper1, helper1Creator);
}
So when I put the helpers in a separate library, these lines are not
called.
Then you don't understand the implications of static libraries, yet.
Use the following from man ld:
--whole-archive
For each archive mentioned on the command line after the
--whole-archive option, include every object file in the archive in
the link, rather than searching the archive for the required object
files. This is normally used to turn an archive file into a shared
library, forcing every object to be included in the resulting
shared library. This option may be used more than once.
Two notes when using this option from gcc: First, gcc doesn't know
about this option, so you have to use -Wl,-whole-archive. Second,
don't forget to use -Wl,-no-whole-archive after your list of
archives, because gcc will add its own list of archives to your
link and you may not want this flag to affect those as well.
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] [CMAKE] setting list with different directories ?
Zitat von Maxime Lecourt maxime.leco...@gmail.com:
I'm having what is probably a newbie problem, but a problem to me.
I have C source files in two different directories, that I use to build a
dll, that is loaded by another C++ project.
I tried to build C objects and link with C++
set_target_properties(ppc PROPERTIES LINK_FLAGS -Wl,--kill-at
LINKER_LANGUAGE CXX)
but I have linker problem (undefined references) when trying to link my C++
project.
So I decided to build my library as C++ and not C.
Known problem but wrong decision. If your library is C, then compile
it as C, not as C++. Your real problem is that you probably forgot the
extern C {
#include my_c_header.h
}
lines for inclusion of the C header files.
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] GenerateExportHeader macrr for CMake?
Am Samstag, 4. Juni 2011, 21:17:49 schrieb Stephen Kelly: Hi, I came up with an idea to simplify the creation of export headers for hidden visibility by using configure_file. After implementing it I saw that the idea has come up before :) http://www.mail-archive.com/cmake@cmake.org/msg27058.html Please see the attached proof of concept. Could we get something like GenerateExportHeader.cmake and exportheader.cmake.in into CMake 2.8? Alex tells me I'd have to maintain it, respond to bugs, and keep source compatibility, so I guess I can say I'll do that :). I know there are other special cases for other compilers, but I thought I'd put the implementation of the concrete idea here for discussion at this point. Really why? There is _no_ dynamic content in such a header file. 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] GenerateExportHeader macrr for CMake?
Am Sonntag, 5. Juni 2011, 11:45:20 schrieb Stephen Kelly: Hendrik Sattler wrote: Really why? There is no dynamic content in such a header file. I'm not sure what you mean? Could you be more specific? This header file only contains static content. You don't even one definition per library, it's the same for each anyway. I find it strange to create a file that will always contain the same content. The difference of MSVC vs. gcc4 can be fully handled in the export header file. So why do you need CMake for that? 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] GenerateExportHeader macrr for CMake?
Am Sonntag, 5. Juni 2011, 18:16:03 schrieb Michael Wild: On 06/05/2011 05:34 PM, Hendrik Sattler wrote: Am Sonntag, 5. Juni 2011, 11:45:20 schrieb Stephen Kelly: Hendrik Sattler wrote: Really why? There is no dynamic content in such a header file. I'm not sure what you mean? Could you be more specific? This header file only contains static content. You don't even one definition per library, it's the same for each anyway. I find it strange to create a file that will always contain the same content. The difference of MSVC vs. gcc4 can be fully handled in the export header file. So why do you need CMake for that? HS That's not quite true. Each library will have it's own (hopefully unique) XXX_EXPORTS define (the DEFINE_SYMBOL property), otherwise the whole thing won't work. You mean something like: #ifdef FOO_EXPORTS #include export.h #define FOO_DLLEXPORT DLLEXPORT #endif This still makes export.h very static content. As I said in the old thread, CMake is a build system, not a code-generator. If you can do something without CMake easily, why should you use CMake in a more complicated way to do the same thing? 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] Sharing configuration files?
Zitat von Raymond Wan r@aist.go.jp:
Hi all,
I'm having a problem which I can't quite figure out how to solve.
Basically, I have C++ source code in two directories, each for a
different class. Let's say:
src/X
src/Y
Each one makes a different class but ultimately X makes use of Y
(i.e., an instance of Y is a variable within X's definition).
Separating them allows me to test Y independently.
So, Y uses CMake to locate the zlib library and whether or not it is
found is passed to Y's source code via a configuration file. i.e., I
have:
#cmakedefine ZLIB_FOUND 1
in the configuration file which is created like this in CMakeLists.txt:
CONFIGURE_FILE (
${PROJECT_SOURCE_DIR}/Config.hpp.in
${PROJECT_BINARY_DIR}/Config.hpp
)
INCLUDE_DIRECTORIES (${PROJECT_BINARY_DIR})
I think/hope so far things are ok... I can compile Y and run it with
no problems. The problem is that X needs access to this generated
configuration file, too. At the very least, it needs to know the size
of an instance of Y in order to allocate memory for it.
Did you consider alternatives like giving Y a static function that
returns a new instance of Y? That makes your problem void.
If this is all within a project that is not going to be separated
later, just put the common configuration into the parent directory of
both
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] Sharing configuration files?
Zitat von Raymond Wan r@aist.go.jp: Hi Hendrik, Thank you for the suggestions! On Tue, Jun 7, 2011 at 17:02, Hendrik Sattler p...@hendrik-sattler.de wrote: Zitat von Raymond Wan r@aist.go.jp: I think/hope so far things are ok... I can compile Y and run it with no problems. The problem is that X needs access to this generated configuration file, too. At the very least, it needs to know the size of an instance of Y in order to allocate memory for it. Did you consider alternatives like giving Y a static function that returns a new instance of Y? That makes your problem void. If this is all within a project that is not going to be separated later, just put the common configuration into the parent directory of both Hm, I never thought of the first option! So if I am understanding your suggestion correctly, this basically means that in X's class definition, it has an entry like: Y* instance_y; i.e., just a pointer to it. And then X doesn't need to worry about the size of Y. I might consider that... Yes, that's what I meant. As for your second option, yes, they are all within the same project -- it's just one isn't a subdirectory of the other (they're siblings). I honestly thought that it was bad practice to have generated configuration files outside of the build directory. But if it is ok, I might give this second option a try if the first one doesn't work out. I assume you have a toplevel CMakeLists.txt in src/ anyway. Or do you run cmake for each? 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] Enabling C99 in CMake
Am Montag, 27. Juni 2011, 18:40:19 schrieb Todd Gamblin: On Jun 26, 2011, at 7:12 AM, Owen Shepherd wrote: On 25/06/2011 07:30, Michael Hertling mhertl...@online.de wrote: On 06/24/2011 04:16 PM, Owen Shepherd wrote: I think the appropriate solution here is a project-specific dialect flag - perhaps one taking options in the GNU format since it seems most familiar. One could perhaps generalise this further - a file-specific dialect flag which defaults to the value of the project-specific flag If there are individual compilers for C89/C99, and a projects needs a C99 one, any dialect flags - project/directory/target/file specific - would be of no use, wouldn't they? Rather, one must specify the C99 compiler if it isn't found automatically by CMake during the initial configuration, and the project might consider to check the compiler's C99 capabilities. Sorry - I should have said property rather than flag. That is, something along the lines of set_target_properties(the_target PROPERTIES C_DIALECT C99) Or set_source_files_properties(myfile.c PROPERTIES C_DIALECT C99) (I'm not entirely sure here whether the source file property should be C_DIALECT or just DIALECT. The language, after all, should be unambiguous at this point) It would then be the responsibility of the Cmake machinery to choose the right compiler and set it up for building code with the given dialect. I *think* Michael's concern here is that if you have a project that uses C99, it should fail as fast as possible, e.g. when it knows that the detected/provided compiler does not support C99 as it processes the 'project' command at the beginning of the CMakeLists.txt file. Please keep in mind that porjects might use _some_ but not all aspects of C99 because they want to support a compiler like MSVC which is not fully C99 compatible. What do you want to do with those? Also the project might have adding header files (e.g. unofficial versions of inttypes.h and stdint.h for MSVC) to allow usage of C99 although the plain compiler does not support that. 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] Buggy CPack generator behaviour?
Zitat von Eric Noulard eric.noul...@gmail.com: 2011/7/29 Bjørn Forsman bjorn.fors...@gmail.com: As you guessed this is impossible without backward compat' breakage. e.g. be aware that with CPACK_SET_DESTDIR set to ON RPM and DEB behavior changes namely RPM package built with that may not be relocatable. What do you mean with 'not relocatable'? I didn't see any difference in the archive layouts of RPM and DEB when changing CPACK_SET_DESTIR from 'not set' to ON. if you do: rpm -qpi your.rpm you'll see a line like: Relocations : (not relocatable) or Relocations : /usr When an rpm is relocatable you can do rpm -i --prefix=/your/relocation/prefix your.rpm if the rpm is not relocatable you can't. That makes it hard to install stuff that MUST be in specific directories like e.g. udev rules or files that the software expects in /etc (_nobody_ uses /usr/etc). Any package that installs files there are not relocatable? That makes this feature pretty useless... 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] How to installing cmake Config.cmake files under Debian multiarch ?
Am Dienstag, 2. August 2011, 21:55:16 schrieb Alexander Neundorf:
Hi,
until recently, I recommended to install Config.cmake files more or less
like this:
install(FILES FooConfig.cmake DESTINATION lib${LIB_SUFFIX}/cmake/Foo )
with LIB_SUFFIX being 64 on systems where this is required.
How do I do this on a Debian multiarch system ?
How do I know in which directory I should install ?
If you use cmake 2.8.5, you can use GNUInstalldirs.cmake and let the user
specify the multiarch directory to install in (or solve it once in that cmake
module).
At least that was I am going to do for openobex.
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] Does find_library check that a found library does in fact link?
Zitat von Michael Wild them...@gmail.com: Just a few of my thoughts on this: Same for me. - There are several ways to handle dead symlinks: 1. Don't check, let the linker complain (status quo) 2. Check whether the found library is a symlink, and if not valid, remove it silently from the list of candidates. Can be very surprising and will likely result in quite a few bug reports about CMake not finding a certain library that is clearly there. 3. Like 2, but warn about the issue. Possibly very annoying. I don't know which option to prefer (perhaps somebody finds another one that is better?). IMHO bogus symlinks to shared libraries constitute a real problem of the library installation, so CMake shouldn't just paper over it by silently skipping the dead link, proceeding to the next candidate which rules out option 2 for me. Also, option 3 can be troublesome in automated setups where no user actually reads the CMake output. People tend to misunderstand the purpose of build systems like CMake and autotools. They try to make the detection bullet-proof and most likely fail. You can see that this is wrong by looking at those auto* setups that take ages to detect all possible header files and use an ifdef hell to handle that in the code, run lots of link and symbol-finding tests, and still fail on conditions that the author simple didn't consider or know. I prefer option 1. It's not CMake's duty to detect or paper over messed-up systems. That's the administrator's job! BTW: running ldconfig -v on Linux likely tells you about the dangling symlink. What's next? Asking for a syntax check of found header files so that the compiler doesn't complain on broken header files? 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] Does find_library check that a found library does in fact link?
Zitat von Micha Renner micha.ren...@t-online.de: Am Donnerstag, den 29.09.2011, 09:22 +0200 schrieb Hendrik Sattler: Zitat von Michael Wild them...@gmail.com: Just a few of my thoughts on this: Same for me. - There are several ways to handle dead symlinks: 1. Don't check, let the linker complain (status quo) 2. Check whether the found library is a symlink, and if not valid, remove it silently from the list of candidates. Can be very surprising and will likely result in quite a few bug reports about CMake not finding a certain library that is clearly there. 3. Like 2, but warn about the issue. Possibly very annoying. I don't know which option to prefer (perhaps somebody finds another one that is better?). IMHO bogus symlinks to shared libraries constitute a real problem of the library installation, so CMake shouldn't just paper over it by silently skipping the dead link, proceeding to the next candidate which rules out option 2 for me. Also, option 3 can be troublesome in automated setups where no user actually reads the CMake output. People tend to misunderstand the purpose of build systems like CMake and autotools. They try to make the detection bullet-proof and most likely fail. You can see that this is wrong by looking at those auto* setups that take ages to detect all possible header files and use an ifdef hell to handle that in the code, run lots of link and symbol-finding tests, and still fail on conditions that the author simple didn't consider or know. I prefer option 1. It's not CMake's duty to detect or paper over messed-up systems. That's the administrator's job! BTW: running ldconfig -v on Linux likely tells you about the dangling symlink. What's next? Asking for a syntax check of found header files so that the compiler doesn't complain on broken header files? This is exactly what CHECK_INCLUDE_FILES does (via TRY_COMPLIE). It works good as long as the header file has no predecessor. In that case CHECK_INCLUDE_FILES reports FILE-NOT-FOUND. It would save a lot of time, if there would be notice that CHECK_INCLUDE_FILES tests the header file. Check if the files can be included is not enough. And what does it gain you to do this check except wasting time during build configuration? Do you really check that any add_definitions() does not alter the result? After all, you only get the real result during project compilation. 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] install() question
On Thu, 13 Oct 2011 12:09:41 -0500, Robert Dailey wrote: First of all I'm using cmake 2.8.6 and generating Visual Studio 2003 projects with it. There is a particular project that needs to first copy its header files to a specific directory in a specific structure. After that, all other projects need to reference this project's source code from the installed location, not its actual location that it was copied from. The install() command sounded perfect for this but unfortunately it seems that the INSTALL project builds *last*. What I need is for the files to be installed/copied FIRST, so that the other projects will succeed when I build them. Any idea if install() can do this? I'm not really sure of the purpose for install(), so maybe I'm approaching this wrong. Yes. Compilation of a project should always be possible without polluting the system. For other programs or libraries in the same source tree, install() is not the right thing. You have several options: a) Copy the headers in the right structure to the build tree and use as include directory. This also makes your install() command easier: you just have to copy the directory as-is. However, you have to setup dependencies correctly so that changed header files (and only those) get copied again if they changed. If you build in-tree (source dir == build dir, which is not recommended), such a scheme may have problems. b) Is there _any_ reason to no arrange the headers in the source tree in a way that makes it usuable for direct inclusion? 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] Combine GTK with a Cmake Project
On Tue, 18 Oct 2011 14:07:28 +0200, David Boesner wrote: The error is, that gtk/gtk.h is not found Path of that file in Debian: /usr/include/gtk-3.0/gtk/gtk.h So you may want to give CMake a hint to /usr/include/gtk-3.0. But this path can change. So you may want to consider to use pkg-config. 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] Combine GTK with a Cmake Project
On Tue, 18 Oct 2011 14:13:35 +0200, David Boesner wrote: i wanted to use pkg-config, but that is expired Where did you read that? There is still a pkg-config file: /usr/lib/pkgconfig/gtk+-3.0.pc Please keep the discussion on-list. 2011/10/18 Hendrik Sattler p...@hendrik-sattler.de On Tue, 18 Oct 2011 14:07:28 +0200, David Boesner wrote: The error is, that gtk/gtk.h is not found Path of that file in Debian: /usr/include/gtk-3.0/gtk/gtk.h So you may want to give CMake a hint to /usr/include/gtk-3.0. But this path can change. So you may want to consider to use pkg-config. -- 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] Combine GTK with a Cmake Project
Please keep the discussion on-list! On Tue, 18 Oct 2011 14:23:37 +0200, David Boesner wrote: i read that in an errormessage as i was trying make That is quite unclear. Can you be a bit more verbose? 2011/10/18 Hendrik Sattler p...@hendrik-sattler.de On Tue, 18 Oct 2011 14:13:35 +0200, David Boesner wrote: i wanted to use pkg-config, but that is expired Where did you read that? There is still a pkg-config file: /usr/lib/pkgconfig/gtk+-3.0.pc Please keep the discussion on-list. 2011/10/18 Hendrik Sattler p...@hendrik-sattler.de On Tue, 18 Oct 2011 14:07:28 +0200, David Boesner wrote: The error is, that gtk/gtk.h is not found Path of that file in Debian: /usr/include/gtk-3.0/gtk/gtk.h So you may want to give CMake a hint to /usr/include/gtk-3.0. But this path can change. So you may want to consider to use pkg-config. -- 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] CMake still broken post-2.8.1
On Thu, 27 Oct 2011 05:40:24 -0700, Phil Smith wrote: Hmm. My zosport.cmake is now (comments/blank lines removed): SET(CMAKE_SYSTEM_NAME IBM_ZOS) SET(CMAKE_C_COMPILER_ID_RUN 1) SET(CMAKE_C_PLATFORM_ID MyPlatform) SET(CMAKE_C_COMPILER_ID MyCompiler) SET(CMAKE_C_COMPILER regina) SET(CMAKE_C_FLAGS cc.rex dcc.exe) Shouldn't this be SET(CMAKE_C_FLAGS_INIT cc.rex dcc.exe) ? 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] find_library finds same library over and again
Am 03.11.2011 12:26, schrieb John R. Cary:
Feels like I am doing something wrong.
Looking for multiple libraries:
$ cat CMakeLists.txt
set(mylibdir /contrib/netcdf-4.1.2-ser/lib)
foreach (name netcdf_c++ netcdff netcdf)
message(Looking for ${name} in ${mylibdir}.)
find_library(mylib NAMES ${name} PATHS ${mylibdir} NO_DEFAULT_PATH)
if (mylib)
message(Found: ${mylib}.)
list(APPEND mylibs ${mylib})
else ()
message(Not found.)
endif ()
endforeach ()
But continues to find the first each time:
From the documentation:
A cache entry named by VAR is created to store the result of this
command. If the library is found the result is stored in the variable
and the search will not be repeated unless the variable is cleared.
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] find_library finds same library over and again
Am 03.11.2011 12:42, schrieb Hendrik Sattler:
Am 03.11.2011 12:26, schrieb John R. Cary:
Feels like I am doing something wrong.
Looking for multiple libraries:
$ cat CMakeLists.txt
set(mylibdir /contrib/netcdf-4.1.2-ser/lib)
foreach (name netcdf_c++ netcdff netcdf)
message(Looking for ${name} in ${mylibdir}.)
find_library(mylib NAMES ${name} PATHS ${mylibdir}
NO_DEFAULT_PATH)
if (mylib)
message(Found: ${mylib}.)
list(APPEND mylibs ${mylib})
else ()
message(Not found.)
endif ()
endforeach ()
But continues to find the first each time:
From the documentation:
A cache entry named by VAR is created to store the result of this
command. If the library is found the result is stored in the variable
and the search will not be repeated unless the variable is cleared.
Note that clearing the variable is NOT the suggested way, instead use a
name that depends on the loop-item.
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] Undefined reference
Am 03.11.2011 15:51, schrieb Mauricio Klein:
Thank you Raphael, it worked!
One last question: i've tried to compile my code using static
linkage, once
i need my daemon runs in many Linux releases. But, even static, in
many
systems my code crashes because the GLIBC version.
My question is: asking for static linkage in CMake can solve this
problem?
Or maybe another approach in CMake, where i embed all the needed
libraries...
Thanks for your attention!
On Thu, Nov 3, 2011 at 12:19 PM, Raphael Kubo da Costa
rak...@freebsd.orgwrote:
Mauricio Klein
mauricio.klein@gmail.com writes:
I can compile all my codes without problems, but in the linkage
step, i
receive a lot of errors about undefined reference to OpenSSL
functions
(yes, my code uses OpenSSL).
In my own (and ugly :P) Makefile, i use -lssl flag in g++
compile line.
My question is: how can i pass this flag in CMake.
Also, i'm not sure if i'm using CMake correctly. Is correctly use
-lssl
flag in CMake or i need to copy the library to a folder inside my
project
and link to this copy?
You need to find OpenSSL with `find_package(OpenSSL)' and then,
assuming
it is found (ie. OPENSSL_FOUND is true), link to its libraries with
`target_link_libraries(YOUR_APP ${OPENSSL_LIBRARIES})'.
After the issues with glibc were already mentioned, be also aware that
static linking to openssl is really not recommended. Just look at the
history of security updates to openssl. Do you really want to ship a new
executable on every update of any statically linked library? Probably
not.
The only good reason these days to link statically is maybe some
performance hit shared libraries.
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] Setting dependencies between libraries (cmake projects)
Am 04.11.2011 11:44, schrieb Rolf Eike Beer:
Thanks, it solved it.
I thought that using set(a project_a) then using ${a} would be the
same
than using project_a (therefore I could use the same variable
everywhere
and simply change the target name in the set). But it seems it is
not the
same.
It is the same.
Except for the scope of the variable a.
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] Setting dependencies between libraries (cmake projects)
Am 04.11.2011 12:35, schrieb Ludovic Hoyet:
But my variable ${a} was not set in the a project CMakeLists.txt but
in the
root CMakeLists.txt file. If I don't make a mistake the variable
would be
accessible for all the subdirectories then.
Not in the example you posted.
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] find_package(), sources only
Am 07.11.2011 12:04, schrieb Daniel Dekkers: Just a thought. Just a thought on your thought. We are incorporating 3rd party library Bullet in our own library. This can be done on two levels (via an option). Either by sources (which is standard practice with Bullet), or by linking to the built Bullet libraries directly. Now find_package(BULLET) (i.e. the findBullet.cmake script) sets BULLET_FOUND to true only if the include directory *and* the libraries are found. But if we only use the sources, we don't need the libs and we ignore the BULLET_FOUND error if they don't exist but still use the path to the include directories. Wouldn't it be good if you could extend find_package() with some kind of SOURCE-ONLY communication or do you think that is the responsibility of the findpackage.cmake writer? If you are using the sources as internal copy of that library, don't you also have the include files as internal copy? In this case, it would be wrong to use the external headers as they might not match your source copy. 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] find_package(), sources only
Am 07.11.2011 14:49, schrieb Daniel Dekkers:
Hi Hendrik,
Could you write a few more lines. I want to understand,... but I
don't. ;-)
We only have one copy of Bullet as a bundle present on the system.
Let's
say you just downloaded Bullet.
With BULLET_ROOT, we set the root path to that copy and do a
find_package(BULLET), it returns with:
[...]
MESSAGE( STATUS Looking for Bullet... )
SET(BULLET_ROOT ${DEVELOPMENT_ROOT}/bullet CACHE PATH Root directory
for
Bullet)
FIND_PACKAGE( BULLET REQUIRED )
So you link to Bullet libraries but build the libraries yourself? Then
use external_project.
You list the Bullet source files as sources in add_executable or
add_library? Then don't use find_package but instead just check for the
include file yourself using find_path.
The find_package() stuff is mostly targetted for externally built
packages.
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] Adding a new language
Am 09.11.2011 23:00, schrieb Stefan Monnier: I'm trying to use cmake for a project using OCaml, so I'm trying to add support for a new language. Among the many problems I encounter, the most pressing is the following: the rule to build object files (CMAKE_OCaml_COMPILE_OBJECT) seems to want a command that takes SOURCE and generates OBJECT, both of which absolute file names. Problems is, `ocamlc' seems to insist on sending the result to a file name of its own choosing (basically SOURCE with the extension modified). Worse yet: it generates 2 files (a .cmo object file and a .cmi that is similar to a header file). The rule below works: set (CMAKE_OCaml_COMPILE_OBJECT CMAKE_OCaml_COMPILER -c SOURCE \; mv \$$(dirname SOURCE)/$$(basename OBJECT)\ OBJECT) but it's clearly not what we want. - How do I tell Cmake that `ocamlc' generates 2 files? - How do I tell Cmake that `ocamlc' does not let us choose where to put the result? According to http://caml.inria.fr/pub/docs/manual-ocaml/manual022.html, it does: -o exec-file Specify the name of the output file produced by the compiler. The default output name is a.out under Unix and camlprog.exe under Windows. If the -a option is given, specify the name of the library produced. If the -pack option is given, specify the name of the packed object file produced. If the -output-obj option is given, specify the name of the output file produced. If the -c option is given, specify the name of the object file produced for the next source file that appears on the command line. So using set (CMAKE_OCaml_COMPILE_OBJECT CMAKE_OCaml_COMPILER -c -o OBJEJCT SOURCE) does not work? 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] VS2010 Express generator?
Am Freitag, 11. November 2011, 17:41:34 schrieb David Cole: You just need to install a PlatformSDK to go with VS 2010 Express. Search the mailing list for prior discussions of this fact. Last time I tried, VS10Express included the PlatformSDK. 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] Adding a new language
Am Freitag, 11. November 2011, 15:55:12 schrieb Stefan Monnier: According to http://caml.inria.fr/pub/docs/manual-ocaml/manual022.html, it does: -o exec-file Specify the name of the output file produced by the compiler. The default output name is a.out under Unix and camlprog.exe under Windows. If This manpage describes all kinds of uses and in practice the -o only applies to the case whre you use ocamlc to link your program (notice how it says -o exec file rather than -o output-file), but it seems ignored when using it to just compile one file. I guess part of the reason is that in that case there is more than one output (it generates a .cmo and a .cmi file for each input file), so it wouldn't be clear what to do with this single output file name. You did cut the part where it says: If the -c option is given, specify the name of the object file produced for the next source file that appears on the command line. So if the help says that -o is supposed to do something sensible when used with -c but it doesn't, I'd suggest to file a bug. Note that the order of arguments may be important. 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] [RFC] How to use pkg-config under Windows (... and OSX)?
Am Donnerstag, 17. November 2011, 18:26:08 schrieb Alexander Neundorf: Let's say package Foo (unrelated to KDE, and unrelated to cmake) has been ported from UNIX to Windows, and installs a pkgconfig file. This pkgconfig file is generated at the time when the binary package for Foo is generated. Now a user downloads and installs the binary package of Foo, along with the included pkgconfig file, which contains the install path from build time. But the user can now decide where he will install this binary package. This may differ from what is recorded in the pkgconfig file in the binary package of Foo. So the Foo.pc file is installed, and contains e.g. C:/Foo/include, but the user decides to install it to D:/MyStuff/, so the include dir would be D:/MyStuff/include. Now cmake comes into play. Let's say there is a project Bar, which uses Foo, so it does find_package(Foo). Now FindFoo.cmake uses pkgconfig: find_package(PkgConfig) pkg_check_modules(Foo ...) Now this will report C:/Foo/include (because this is what the pkgconfig-file contains), instead of D:/MyStuff/include, where the user decided to install it. No. Pkg-config should derive the prefix variable from the location of the .pc file. According to documentation, it does this on Windows, so it should report D:/MyStuff/include 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] [RFC] How to use pkg-config under Windows (... and OSX)?
Am Donnerstag, 17. November 2011, 21:38:20 schrieb Hendrik Sattler: Am Donnerstag, 17. November 2011, 18:26:08 schrieb Alexander Neundorf: Let's say package Foo (unrelated to KDE, and unrelated to cmake) has been ported from UNIX to Windows, and installs a pkgconfig file. This pkgconfig file is generated at the time when the binary package for Foo is generated. Now a user downloads and installs the binary package of Foo, along with the included pkgconfig file, which contains the install path from build time. But the user can now decide where he will install this binary package. This may differ from what is recorded in the pkgconfig file in the binary package of Foo. So the Foo.pc file is installed, and contains e.g. C:/Foo/include, but the user decides to install it to D:/MyStuff/, so the include dir would be D:/MyStuff/include. Now cmake comes into play. Let's say there is a project Bar, which uses Foo, so it does find_package(Foo). Now FindFoo.cmake uses pkgconfig: find_package(PkgConfig) pkg_check_modules(Foo ...) Now this will report C:/Foo/include (because this is what the pkgconfig-file contains), instead of D:/MyStuff/include, where the user decided to install it. No. Pkg-config should derive the prefix variable from the location of the .pc file. According to documentation, it does this on Windows, so it should report D:/MyStuff/include See http://cgit.freedesktop.org/pkg-config/tree/parse.c#n1136 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] Clen-up pre-built software
Am 22.11.2011 11:42, schrieb t m: Hi Community, In the large project we a having periodic taks which build a couple of projects and store the result of the build in one specific place. Once it's build the rest of the team can use this artifacts becouse those are exported by using of export(TARGETS ...) Since the others refer only to the targets I would like to clean-up the common builds from optional artifacts in order to save some disk space. I guess the objects could be removed. The problem is that make clean will clean also executables and libraries, so it's not an option for me. 1) Is there any way to get all objects files as a list, so I can remove them in the loop ? 2) Is there any other way to cope with this clean-up ? Looking for hints. Make different trees for build and export (aka installation to a specific location to be used by others). Then you can easily delete the build tree. 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] Bad documentation of the LINK_INTERFACE_LIBRARIES property and other transitive linking topics
Am 23.11.2011 22:35, schrieb Michael Hertling: Out of curiosity - I have not worked with RPM for ages: Are these warnings and the related overlinking due to transitive dependencies really an issue or just an inconvenience? Personally, I distinguish between real overlinking, i.e. pulling in libraries not used at all, and formal overlinking by DT_NEEDED tags for mediate prerequisites, or in other words: Real overlinking means the dependency graph has unnecessary nodes, and formal overlinking means is has unnecessary edges. Of course, the former is a real penalty, but is the latter also bad? If an executable X is linked against a shared library B, and B against a shared A, is it really critical if A explicitly appears among the dependencies of X, as A *is* needed for X? Perhaps, you can share some experiences from your practice. Note that Debian also warn about this. The issue is the packaging in distributions. When application A depends on library B (which depends on library C) but links to both B and C, you have to rebuild A and B when the ABI of C changes. If A only links to B, only B has to be rebuilt and the distribution user has to download far less. So it is an optimisation of many ressources which consumes less energy - good :-) BTW: linking plugins against an executable is really not good style. Put the common part into a library and link the executable and the plugin against that library. 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] Adding a reference to a .NET dll in my C++/CLI project
Am Mittwoch, 4. Januar 2012, 23:32:21 schrieb brian:
I've been able to generate VS 2010 solution's via CMake for my C++/CLI
project (.NET project). We've added the log4net.dll to the project by
hand. This is the .NET version of the log4j project. What I'd like to do
is add a reference to this DLL to the solution via cmake using a
Findlog4net.cmake file with a given version number but haven't figured out
how to integrate this since its a dll only.
I've tried,
find_library(LOG4NET_LIB log4net ${PATH_TO_DLL_LOCATION})
but this hasn't worked.
The .dll is the runtime library but for linking with VisualStudio, you need a
.lib import library.
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] list of lists -possible?
Am Mittwoch 02 Juni 2010, 18:34:56 schrieb Clinton Stimpson:
On Wednesday, June 02, 2010 10:24:44 am Doug Reiland wrote:
Is it possible to implement a list of lists. The following example
shows cmake ending up with a list with 6 elements instead of
a list with 2 elements with each element being a list with 3 elements
set(fooa 1 2 3)
set(foob a b c)
message(${fooa})
message(${fooa})
message(${foob})
list(APPEND foos ${fooa})
list(APPEND foos ${foob})
message(${foos})
foreach (a ${foos})
message(${a})
endforeach()
You can put the name of the list in another list, instead of its contents.
And use a nested foreach to extract all of the contents.
I couldn't find a non-hackish way to include a variable into a cmake list,
e.g. a java classpath argument into a cmake list of command line options.
IMHO, escaping the ';' would allow this but I couldn't find out how :-(
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] Problems with linking on MinGW?
Am Dienstag 15 Juni 2010, 16:54:28 schrieb Jesse Perla:
I am using CMake 2.8.1 on Windows 7. I have MinGW installed with GCC 4.5
I have successfully compiled a library with a MinGW and cmake. The full
path to the library is: c:\working\etk_binaries\libetk-mgw45.a
However, when I want to link this file into an executable (no need to have
the CMake dependencies, etc. in projects) it can't seem to find this file.
My cmakelists.txt is:
cmake_minimum_required(VERSION 2.6)
set(PROJECT_NAME test )
set(SRCS test.cpp )
project(${PROJECT_NAME})
add_executable(${PROJECT_NAME} ${SRCS})
link_directories( c:/working/etk_binaries)
target_link_libraries(${PROJECT_NAME} libetk-mgw45)
The error I get is:
c:\MinGW\bin/ld.exe: cannot find -llibetk-mgw45
Your library name is NOT libetk-mgw45. Try etk-mgw45 instead and read
about library file names.
Also, do not use link_directories() but use find_library() and the value you
get from it.
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] The find_xxx family and VS
Am Dienstag 15 Juni 2010, 14:12:38 schrieb Micha Renner: It seems, that CMake can detect the MSVC specific headers and libraries only, if it runs within Visual Studio. For example: FIND_FILE(STD_FILE stdio.h), FIND_PATH(STD_PATH stdio.h) or FIND_LIBRARY(LIB_PATH comctl32) results in NOT-FOUND, if CMake is run outside the IDE with an empty Build-Directory. This means the first run of the compiler/linker always fails, since CMake regenerates the solution-/config-files only if there is a change in the script/config files inside VS. This always leads to complex instructions for third-party users who just want to build the programs/libraries, like this. After you have build the solution files with cmake-gui: - open VS, - open the project - open the Top-level-CMakeList.txt file - Hit a space in an empty line - Rebuild the project. Is there a better foolproof method to solve this. Yes. You must call cmake from the Visual Studio Command Prompt (either in the Windows start menu or from the IDE). Additional, there is no gain in trying to find libraries that come with the compiler or system when they are always there. Additionally, the compiler itself knows where to find them. 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] Problems with linking on MinGW?
Am Dienstag 15 Juni 2010, 18:25:20 schrieb Jesse Perla: On Tue, Jun 15, 2010 at 12:01 PM, Hendrik Sattler p...@hendrik-sattler.dewrote: Your library name is NOT libetk-mgw45. Try etk-mgw45 instead and read about library file names. Thanks for your help. Alas, on MSVC10 and Intel11.1 windows, the link_directories and target_link_libraries approach I used above (with the full filename) worked fine and hence never tried other methods I had tried the etk-mgw45 without the lib and it didn't seem to work. gcc and msvc differ in their library naming. While gcc uses libfoo.a, msvc uses foo.lib. So your library must have the right naming according to the compiler you are going to use. To avoid other problems, you should have used the same compiler for the library. Also, do not use link_directories() but use find_library() and the value you get from it. I have tried a few permutations with find_library, but not having a lot of luck. Here is the current section of code I am testing with. link_directories( c:/working/etk_binaries) find_library(LIB_NAME etk-mgw45-d c:/working/etk_binaries) You are not using find_library() correctly!: find_library(LIB_NAME etk-mgw45-d HINTS c:/working/etk_binaries) And omit the link_directories() call. Any ideas? You _really_ need to read about the proper library naming for your compilers! That's why you got confused. 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] CMake - overriding shared linker flags
Am Mittwoch 23 Juni 2010, 15:38:40 schrieb K Lakshman: I didn't really think of that (why no library does it). Can you tell me what the issues are? I suggest looking at the libc source code, e.g. the entry point for libpthread is in nptl/version.c Seperating that as libfoo.so and foo-config makes it easier and much more portable. 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] Finding WS2 library on Windows Vista
Am Freitag 02 Juli 2010, 19:56:02 schrieb Di Zou: I am trying to use CMake to find WS2_32.dll on Windows Vista. For me, the dll is located in C:/Program Files/Microsoft SDKs/Windows/v6.0A/Lib. So I use the command: FIND_LIBRARY(WS2 NAMES WS2_32 PATHS C:/Program Files/Microsoft SDKs/Windows/* C:/Program Files/Microsoft SDKs/Windows/*/*) This command works on my computer, but I would like to make it more generic. I tried FIND_PACKAGE(WS2 REQUIRED) but that did not find anything. Is there a module available to find the WS2_32.dll? Also, is there a default or common location for WS2_32.dll? ws2_32 (note: lower-case) is a system library. You do not need to use find_library for those. 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] CPack DEB: default to standard Debian package file names
Zitat von Olaf van der Spek olafvds...@gmail.com: Hi, At the moment the default package file name is like xbt-tracker-0.1.1-Linux.deb. Could this be changed to xbt-tracker_0.1.1_i386.deb? Note the underscore instead of minus as field separator and the architecture. Last time I looked at CPack, the cpack core chose the base name, not the generator. So either you choose the name from outside (via variables) which is rather clumsy, or you patch cpack to give more control to the generators. 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] [VS gen] Multiple configurations code
Zitat von David Cole david.c...@kitware.com: On Tue, Jul 27, 2010 at 5:45 AM, Verweij, Arjen I hear what you are saying, but a lot of legacy Makefile based system support make and make debug alongside each other. I'm still looking for the cmake way to easily mark a small part of a project to be built with debug flags. For instance, if you have functionality in a static archive, you just link the new debug enabled object file against the main.o and the archive and you end up with some debugging symbols in no time. Replicating that with CMake should be possible, too, but it's not the typical everyday use case. If the cmake source scanner can detect (not sure) the usage of #ifdef MY_DEBUG then that's all that is needed to achieve that: cmake -DENABLE_MY_DEBUG=ON . make Not everything that looks like debug stuff must be coupled with a debug build type. It can as well only define the default for MY_DEBUG. If it cannot detect this, use a config.h. That it certainly can. 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] Visual Studio Generator: different Link paths for Debug and Release
Zitat von aaron.mead...@thomsonreuters.com:
I need to use different link paths for Debug and Release builds of my
software. I'm building with the Visual Studio Generator (2005, 2008,
etc). I had put this in my CMakeLists.txt, but as it turns out, this
doesn't do what I need (likely because of the single pass to generate
the project files):
if(DEBUG)
link_directories($ENV{RDFD3RDPARTYDIR}/lib/Debug)
else()
link_directories($ENV{RDFD3RDPARTYDIR}/lib/Release)
endif()
So, my question: is there a way to have different link directory paths
for each configuration in visual studio without generating multiple
build directories for VS?
I could tell you to use lib/${CMAKE_CFG_INTDIR} instead of lib/Debug
and lib/Release. However, the names may not match what VS uses. The
solution is to use full path to libraries with debug . optimized
syntax and completely forget about the existence of
link_directories().
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] add_custom_target dependency list issue
Am Montag 27 September 2010, 01:48:38 schrieb Szilárd Páll:
No black magic, just cmake's rules about variable contents.
Basically CMake has only 1 type of variable value, thats a string. What
you created above is a string variable DEPS with the value dep1 dep2
dep3, i.e. a single string consisting of 3 words separated by spaces.
Some strings are considered to be a list if you use a cmake command that
expects a list, these strings need to separate each list entry with a
semicolon.If you use
Actually I knew about the rules on variable contents as well as the
structure and generation on lists. However I didn't realize that
set(DEPS dep1 dep2 dep3)
add_dependencies(foo bar
${DEPS})
is not pretty much the same as:
add_dependencies(target-name depend-target1
depend-target2 ...),
That's because you got the quotes wrong, must be
set(DEPS dep1 dep2 dep3)
and _NOT_
set(DEPS dep1 dep2 dep3)
for this to work.
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] Fwd: Removing overkill linking
Am Sonntag 03 Oktober 2010, 14:15:41 schrieb Paul McEnery: The solution was to set CMAKE_EXE_LINKER_FLAGS using -Wl,--as-needed. That is actually only a work-around. Pkg-config can handle the difference between static linking and dynamic linking but you have to tell it what is what. However, not all upstream developers that emit pkg-config files make proper use of that. OTOH, some APIs import types from other libraries so that linking to those is necessary to avoid problems when upgrading. That's where -Wl,--as-needed is not the proper solution (as the linker cannot know this). 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] Merge two static libraries
Zitat von Marcel Loose lo...@astron.nl: Even if you opt for the one static library option, you already gain in build speed. Suppose you've modified foo.c, then CMake will only rebuild foo.o. Of course, it will rebuild foo.o twice, once for libconsole, once for libwindows. But that's already much better than recompiling all 50 sources twice. Such requests come up regularly. The solution would be easy: something like VIRTUAL as alternative to the STATIC flags of add_library(). Cmake could just omit the link step (it already knows all object files) and linking such a virtual library to a static one just includes the already compiled object files. That would exactly achieve the requested features (compiling those files only once), is hack-free and totally straight-forward. Just not done... 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] How to rename the resulting Makefile.
Am Dienstag 12 Oktober 2010, 17:52:31 schrieb william.croc...@analog.com: I will use cmake to build the app on my various platforms (Linux/Windows...). Most of my convenience targets are only used during development (Linux) so it is typically okay that they are not cross platform. That you may consider seperating development stuff and build stuff, anyway. That way, you do not accidently pollute the source tree. OTOH, that way you could as well use shell scripts directly rather than using shell code in a makefile. 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] cmake for cygwin
Am Sonntag 24 Oktober 2010, 08:37:30 schrieb Marco Atzeri:
It should be changed. That will be the cleanest way for porting and
most of the time we will not need any IF (CYGWIN) to complete our job
as package maintainer.
Othewise we should patch any sources to replace IF (WIN32) with
IF(WIN32 AND NOT CYGWIN) and these means that this wrong policy
is forcing unneeded workload on our backs.
Also cmake and vtk sources are full of IF(WIN32 AND NOT CYGWIN)
because WIN32 and CYGWIN are in strong contrast.
No, they are not. There are certain things in cygwin that are so WIN32 like.
I have the following in my CMakeLists for OpenOBEX:
if ( CMAKE_COMPILER_IS_GNUCC )
if ( UNIX AND NOT WIN32 )
set ( COMPILER_FLAG_VISIBILITY -fvisibility=hidden )
check_c_compiler_flag ( ${COMPILER_FLAG_VISIBILITY}
COMPILER_SUPPORT_VISIBILITY )
endif ( UNIX AND NOT WIN32 )
[...]
because on WIN32, the DLLEXPORT is used instead. So your proposal really
breaks working setups while trying to fix it for those upstreams that cannot
read documentation? That sucks.
And: believe it or not, WIN32 and CYGWIN are _not_ in strong contrast. They've
got so much in common, starting from the binary file format to all low level
stuff that cygwin is never going to change. Live with it.
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] cmake, latex docbook
Zitat von luxInteg lux-in...@btconnect.com: I am learning cmake I downloaded CMakeUseLatex from http://www.cmake.org/Wiki/CMakeUserUseLATEX and I scanned through the pdf file but I did not see any references to TEX binaries such docbook2html, dblatex etc. So lets say I have a couple a docbook_xml files xyxy.docbook abab.docbook You can use this module: http://gitorious.org/openobex/mainline/blobs/master/CMakeModules/FindDocbook.cmake http://gitorious.org/openobex/mainline/blobs/master/CMakeModules/UseDocbook.cmake which need (Find|Use)Xslt.cmake. It needs some improvements but works pretty well for manpage and HTML generation. PDF generation can be added with fop. You need a XSLT1.1 program (xsltproc, saxon6.5.x or xalan2.x). 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] cmake, latex docbook
Zitat von Cliff Yapp cliffy...@gmail.com: On 11/19/2010 03:31 AM, Hendrik Sattler wrote: Zitat von luxInteg lux-in...@btconnect.com: I am learning cmake I downloaded CMakeUseLatex from http://www.cmake.org/Wiki/CMakeUserUseLATEX and I scanned through the pdf file but I did not see any references to TEX binaries such docbook2html, dblatex etc. So lets say I have a couple a docbook_xml files xyxy.docbook abab.docbook You can use this module: http://gitorious.org/openobex/mainline/blobs/master/CMakeModules/FindDocbook.cmake http://gitorious.org/openobex/mainline/blobs/master/CMakeModules/UseDocbook.cmake which need (Find|Use)Xslt.cmake. It needs some improvements but works pretty well for manpage and HTML generation. PDF generation can be added with fop. You need a XSLT1.1 program (xsltproc, saxon6.5.x or xalan2.x). HS Those look quite interesting. Looking at the toplevel project, it appears to be GPL - is there any chance you could license those specific files under the same license as CMake? Perhaps they could be polished into Docbook modules that we could propose for inclusion in CMake proper, if that is of interest to the Kitware guys. I am the only author of those modules and you can put them under the same license as cmake if you wish to do so. Following things can be improved: The list of generated files is currently determined at cmake time, thus you must re-run cmake when that list possibly changes (which is not on every edit). Additionally, that list generation only works with reference and refentry tags, so even fails with the docbook that cmake generates. However, generating the list of file is independent from all of the other functionality. 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] Specify as in the toolchain
Am Freitag, 3. Dezember 2010, 13:06:41 schrieb Andrea Galeazzi: How can I specify the as command like I do for gcc or g++ compiler in a toolchain? SET(CMAKE_C_COMPILER C:/Programmi/development/GCCARM/bin/gcc.exe) http://www.cmake.org/Wiki/CMake/Assembler 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] add_subdirectory and link_directories
Zitat von Thomas Petazzoni thomas.petazz...@free-electrons.com: On Tue, 11 Jan 2011 01:42:47 +0100 Michael Hertling mhertl...@online.de wrote: Since CMake prefers to specify libraries by path instead of using -l/-L or the like, there's usually no need for the LINK_DIRECTORIES() command, IMO. Sorry to jump into the discussion, but I'm having a problem that I think is related to that. I have an application that links against Qt and another library which is found using pkg-config (and the PkgConfig CMake module). Due to the fact that I'm cross-compiling, the library is in a non-standard location (i.e: $HOME/something/usr/lib instead of /usr/lib). Unfortunately, the xxx_LIBRARIES variable filled by the PkgConfig module only contains -lfoobar. So I'd like to either : *) Tell the PkgConfig module to add the full path to the library, which it seems is the CMake way of doing things. *) Tell CMake about this $HOME/something/usr/lib path for which a -L flag should be added. I've tried changing LINK_DIRECTORIES, but it then completely breaks the build. Any clue ? Ask the pkg-config guys to fix pkg-config to make it suitable for such a case? It's already done in pkg-config but only on Windows. As a work-around, use the undocumented pcfiledir variable (see http://cgit.freedesktop.org/pkg-config/tree/pkg.c#n1235), go two directory levels up (strip lib/pkg-config from the end) and call pkg-config with this as prefix variable. Now, it magically does it almost right (depending pkg-config modules may not be right). Someone just needs to change the cmake module to do just that when cross-compiling :-/ OR: don't use or rely on pkg-config when cross-compiling. 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] cross g++ linking shared instead of static libgcc
Am Donnerstag, 13. Januar 2011, 02:10:12 schrieb Darren Hollenbeck: I am using CMake to cross compile with an arm toolchain and getting a linker error: undefined reference to `__sync_fetch_and_add_4' the toolchain has both a shared and static libgcc: ./lib/gcc/arm-linux-gnueabi/4.5.2/libgcc.a ./lib/gcc/arm-linux-gnueabi/4.5.2/libgcc_eh.a ./arm-linux-gnueabi/lib/libgcc_s.so.1 ./arm-linux-gnueabi/lib/libgcc_s.so the path for both is in the linker directories (from CMakeCXXCompiler.cmake generated in the build directory/CMakeFiles), but the path for the static is first: SET(CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES /opt/gatecraft/arm/lib/gcc/arm-linux-gnueabi/4.5.2;/opt/gatecraft/arm/arm- linux-gnueabi/lib;/opt/gatecraft/arm/arm-linux-gnueabi/usr/lib) Does this matter? No, the libraries have differen names! The libraries are not the same, the .so does not have the symbol the linker is complaining about but the .a does (I inspected this with nm). What I can't figure out is why I can switch the CMAKE_CXX_COMPILER defined in my toolchain file to another toolchain (with the same shared/static and linker path order) - keeping everything else the same - and the build succeeds. I can't find any significant difference in anything in the build directory between the two, yet one will link libgcc.a (and therefore works) and the other won't (and gives the error above). I found that I have a work-around by forcing -static-libgcc in the linker flags, but this doesn't explain why it works without this change when I switch the compiler to the other toolchain. Anyone able to explain the discrepancy here and offer a fix? You probably have different defaults (by gcc configure flags) for code generation. Anyway, this is a problem either with gcc itself, how you configured it or a problem with use a atomic operations in your code. Totally unrelated to cmake. 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] CMake Java Support
Am Freitag, 14. Januar 2011, 16:48:44 schrieb Andreas Schneider:
On Friday 14 January 2011 16:32:16 you wrote:
Andreas,
Hi Allen,
Thanks, I do have most everything working, setting the version was
the
key!
Concerning the '.' at the beginning of my proposed patch, I added that
because the CMAKE_JAVA_INCLUDE_PATH_FINAL started with a seperator and I
didn't look into why. I find this 'set' command very useful and I suggest
you consider adding it (with or without the leading '.'). Note that I
discovered a bug with Windows and the Visual Studio generator. The use of
CMAKE_JAVA_INCLUDE_PATH_FINAL in the add_custom_command changes the ';'
seperator into spaces - I think it needs to be escaped somehow - maybe
the CMake gurus have a suggestion?
I'm not a java programmer and I haven't tested this stuff on Windows.
Please tell which variables have the wrong ; or : or whatever and what it
should look like. I already did some things to get it working on Windows
but never tested.
The more details you give the easier it is to fix. If you could print out
the variables I could try to fix it and add what you need.
I had the same problem for my XSLT modules that can make use of saxon and
xalan (both java program including some jar files). If you do calls to java,
the classpath must be it's own list and can then be run like:
add_custom_command (
OUTPUT foo
COMMAND ${JAVA_RUNTIME} -cp ${FOO_CLASSPATH} bar
)
If you import a classpath from the environment, use
string ( REPLACE : ; .)
but only on Windows.
This solution works on Linux and Windows.
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] MSVC 2010
Am Dienstag 18 Januar 2011, 18:05:50 schrieb Mateusz Loskot: On 18/01/11 16:15, David Cole wrote: Your confusion is that you are looking for a 2010 -- there isn't one -- there is Visual Studio 10 David, This is indeed a mess in CMake. There is no such product as Visual Studio 10. Also, there is no Microsoft product named Visual Studio .NET 2005. 10.4 million google hits, some on microsoft.com (although I wouldn't take that page as proper history indication), tell something different. I don' think all those authors invented the same name by accident. 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] MSVC 2010
Am Dienstag 18 Januar 2011, 19:02:15 schrieb Hendrik Sattler: Am Dienstag 18 Januar 2011, 18:05:50 schrieb Mateusz Loskot: On 18/01/11 16:15, David Cole wrote: Your confusion is that you are looking for a 2010 -- there isn't one -- there is Visual Studio 10 David, This is indeed a mess in CMake. There is no such product as Visual Studio 10. Also, there is no Microsoft product named Visual Studio .NET 2005. 10.4 million google hits, some on microsoft.com (although I wouldn't take that page as proper history indication), tell something different. I don' think all those authors invented the same name by accident. What I meant to say: the .NET in the name is not important, being it the official product name or not. 7/8/9/10 or [.NET] 2003/2005/2008/2010, who cares. I find it more strange that everyone of those needs its own generator. After all, cmake could perfectly auto-detect this from the version of cl.exe. 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] CMake performs search for includes/libs in non-default compiler search paths.
Zitat von Michael Wild them...@gmail.com: Now, if you want to mix-and-match, by having this include-path: -I/usr/include -I/usr/local/include (i.e. use /usr/include/foo.h and /usr/local/include/bar.h) you're in trouble, because CMake will filter out the /usr/include directory, leaving you with /usr/local/include/foo.h being found. Rats. Note that some compilers, e.g. gcc, ignore system include path that are given with -I. Citing from its manpage: If you really need to change the search order for system directories, use the -nostdinc and/or -isystem options. 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] Is there an elegant way to get list of object files participating into a library?
Zitat von Vladislav Vaintroub vvaintr...@googlemail.com: For the Windows platform I am generating the .DEF files with all defined symbols to be exported. For this I need to get the list of all object files (.obj) participating into a library. Are you trying to export all symbols from a shared library, something that emulates Unix linkers behavior (Microsoft linker has no option for it=? If it is so, then you can create a static library first. Then add custom command that e.g runs dumpbin with you static library to extract symbols and produces .DEF (for example using a script like this one http://kenai.com/projects/mysql-jvm/sources/source/content/win/create_def_fi le.js?rev=25 ). Finally, to produce DLL, use a dummy source file , and your generated .DEF and link the DLL to the static library, like ADD_LIBRARY(mydll SHARED dummy.c generated.def) TARGET_LINK_LIBRARIES(mydll staticlib) It's better to have a well-defined API, so you should know what symbols to export... Additionally, since gcc can also be selective about the symbols to export, maybe adding the proper export flags in the code would also be a solution. 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] Finding MinGW compiler libraries?
Am Sonntag, 27. Juli 2008 02:27:40 schrieb Alan W. Irwin: On 2008-07-26 16:06-0400 Bob Paddock wrote: find_library( MinGW_libuuid uuid ole32 shell32 C:/MinGW/lib ) find_library( MinGW_libole32 ole32 C:/MinGW/lib ) find_library( MinGW_libshell32 shell32 C:/MinGW/lib ) # Is there a better way to do the above? What happens when you have dozens of # libraries?' Look up the find_library command in the documentation. Especially the part that starts The reason the paths listed in the call to the command are searched last And what is the reason to find .dll files on Windows when searching for a library file, most likely to link to? HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Finding MinGW compiler libraries?
Am Sonntag, 27. Juli 2008 13:58:06 schrieb Werner Smekal: And what is the reason to find .dll files on Windows when searching for a library file, most likely to link to? Well, the MinGW compiler doesn't need a foo.a file to link against a foo.dll file - if foo.dll was created with MinGW itself. Therefore it makes sense. If the foo.dll was compiled with a different compiler (e.g. system libraries) this will most likely not work. But how should CMake know? It shouldn't. But doing this is _most_ _likely_ to fail, as most .dll files are not created using MinGW. That's fact. So why doing something by default that has a success rate of less than 50%? Make it optional and disabled by default... HS PS: Please to not send replies to me _and_ the list, just to the list is completely sufficient. An MUA that understands mailing lists can help here. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating libraries (DLL) in windows
Am Samstag, 2. August 2008 00:41:11 schrieb Leopold Palomo Avellaneda: I understand that you have to add: class MYLIB_EXPORT MyClass for all the classes, but also for the structs , and functions? If a class is exported, its member functions also get exported. For non-member function, this must also be added. Structs and classes are roughly the same in C++ (different initialisation) but unless they include functions (not function pointers), the do not need to be exported (you don't link to it). BTW: With gcc = 4 on linux, you may also want to use #define MYLIB_EXPORT __attribute__((visibility(default))) and compile with -fvisibility=hidden. That allows to not export symbols for internal classes and it's faster at runtime. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating libraries (DLL) in windows
Am Samstag, 2. August 2008 01:21:01 schrieb Leopold Palomo Avellaneda: A Dissabte 02 Agost 2008, Hendrik Sattler va escriure: Am Samstag, 2. August 2008 00:41:11 schrieb Leopold Palomo Avellaneda: I understand that you have to add: class MYLIB_EXPORT MyClass for all the classes, but also for the structs , and functions? If a class is exported, its member functions also get exported. For non-member function, this must also be added. Structs and classes are roughly the same in C++ (different initialisation) but unless they include functions (not function pointers), the do not need to be exported (you don't link to it). BTW: With gcc = 4 on linux, you may also want to use #define MYLIB_EXPORT __attribute__((visibility(default))) and compile with -fvisibility=hidden. That allows to not export symbols for internal classes and it's faster at runtime. faster in terms of? Time to link the library at application start. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.1 available for download
Am Montag, 4. August 2008 17:48:28 schrieb Mathieu Malaterre: That was not really my main concern anyway, instead I am more concerned with the patch done for debian people (admittedly I dont understand what they are trying to do): http://ftp.de.debian.org/debian/pool/main/c/cmake/cmake_2.6.0-5.diff.gz The have /lib /lib32 - /emul/ia32-linux/lib /lib64 - /lib So adding the /lib64 to the library search will gain nothing as everything is at /lib already. The /lib64 link is only a compatibility thing for other distros that interpret the FHS in strange ways... HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.1 available for download
Am Montag, 4. August 2008 18:02:15 schrieb Bill Hoffman: Hendrik Sattler wrote: Am Montag, 4. August 2008 17:48:28 schrieb Mathieu Malaterre: That was not really my main concern anyway, instead I am more concerned with the patch done for debian people (admittedly I dont understand what they are trying to do): http://ftp.de.debian.org/debian/pool/main/c/cmake/cmake_2.6.0-5.diff.gz The have /lib /lib32 - /emul/ia32-linux/lib /lib64 - /lib So adding the /lib64 to the library search will gain nothing as everything is at /lib already. The /lib64 link is only a compatibility thing for other distros that interpret the FHS in strange ways... But, does it hurt? I don't see us moving that into the main tree with the if 0 as the lib64 actually does do something on other machines. I guess we could have an if _DEBIAN_ or something like that. Or maybe we could check to see if /lib == /lib64 as other distros might do the same thing. On a second look, the patch does not select /lib64 even when compiling 64bit binaries on 32bit system as cmSystemTools:FileIsDirectory() will return false on a symlink. Well that is broken in itself as having /lib64 as symlink is valid. Debian could also solve this by seeing the compilation of 64bit binaries on 32bit systems as kind of cross-compiling. Not sure how the layout is on i386. Why aren't the same checks done when compiling 32bit binaries on 64bit system, meaning using /lib32 instead of /lib in this case? If those stuff is not meant for 32-64 bit cross-compiling but for some other directory layouts, everything is fine and the patch does essentially nothing (except saving a few cpu cycles). You might want to speak to the Debian Maintainer in this case, see http://packages.debian.org/sid/cmake (right side). Cmake-2.6 is not going to be in Debian Lenny, so no real time pressure on this. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.1 available for download
Zitat von Alberto Luaces [EMAIL PROTECTED]: El Lunes 04 Agosto 2008ES 19:06:07 Hendrik Sattler escribió: Cmake-2.6 is not going to be in Debian Lenny, so no real time pressure on this. cmake 2.6 is already on lenny, see it at Hmm, bad timing then. They must have requested an exception to the freeze, then. cmake-2.4.8 would have been fine, too, though. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Permissions for new folders and files
Zitat von Брюков Юрий [EMAIL PROTECTED]: Thanks Yuri and Alan. But I develop cross-platform application (for Linux and Windows now) and it would be better if directory layout for my application will be the same on both platform. Actually better is a layout that can be adopted to the specific platform. DLL and .so files are in totally different locations relative to the application binary. Or in this case I also should try to follow the FHS for Linux platform? That's non-sense. By the way, my application consists of some shared libraries and executables files. And shared libraries should be placed in some directory from the PATH. Not on Linux, neither /lib/ nor /usr/lib are in PATH. And it is not strictly necessary to put libraries there. Sometime, rpath is actually useful, you know! I suggest it require root privileges in Linux. In result, `make install` command should be executed with root access. If there any way to avoid this issue? Because in this case I have the troubles described above. man ld.so is your friend, look for LD_LIBRARY_PATH if you don't want to use rpath with $ORIGIN. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Qt-Sources and non Qt-Source
Am Dienstag, 12. August 2008 17:49:46 schrieb Jan Dinger: Thats right. So, I ignore this. Can I disable this warning in my release version? This warning looks not so good. Then don't run it through the moc... HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE_TOOLCHAIN_FILE / testing with 'wine'
Am Dienstag, 19. August 2008 22:24:12 schrieb Mathieu Malaterre: Did you figure out a way to install 32bits debian package in the /emul/ia32 subdirectory ? How did you install your target system environment. On my debian box, the ia32-libs package works somewhat ok, but it only provide the runtime 32bits libs (not the include file for instance). The include files do not differ (they are architecture-independent) for normal projects. Why would you want to install a second set? HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE_TOOLCHAIN_FILE / testing with 'wine'
Am Dienstag, 19. August 2008 23:17:18 schrieb Alexander Neundorf: On Tuesday 19 August 2008, Hendrik Sattler wrote: Am Dienstag, 19. August 2008 22:24:12 schrieb Mathieu Malaterre: Did you figure out a way to install 32bits debian package in the /emul/ia32 subdirectory ? How did you install your target system environment. On my debian box, the ia32-libs package works somewhat ok, but it only provide the runtime 32bits libs (not the include file for instance). The include files do not differ (they are architecture-independent) for normal projects. Why would you want to install a second set? Because they could differ, e.g. different versions or whatever. Not in a distribution like Debian. Well unless you are using unstable as it has a reason to be called like that. For other cases, the e.g ia32- packaes on amd64 have the same version. And in this case, they do not differ. On other systems where you have 32bit and 64bit libraries mixed (e.g. Solaris), you also only have _one_ include directory. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE_TOOLCHAIN_FILE / testing with 'wine'
Am Dienstag, 19. August 2008 23:08:56 schrieb Mathieu Malaterre: On Tue, Aug 19, 2008 at 10:57 PM, Hendrik Sattler [EMAIL PROTECTED] wrote: Am Dienstag, 19. August 2008 22:24:12 schrieb Mathieu Malaterre: Did you figure out a way to install 32bits debian package in the /emul/ia32 subdirectory ? How did you install your target system environment. On my debian box, the ia32-libs package works somewhat ok, but it only provide the runtime 32bits libs (not the include file for instance). The include files do not differ (they are architecture-independent) for normal projects. Why would you want to install a second set? uh ? I see two issues: 1. Related to how cmake internally works: The way cmake toolchain work is you simply set some kind of root, for instance /emul/ia32-linux and within this root, will search for /usr/lib/libz.so and /usr/include/zlib.h. I'll have to double check but hopefully order is is respected so that I can say search first in '/emul/ia32-linux' and then in '/' Or /emul/ia32-linux, /include and /usr/include. You don't need to take 'root' literally. anyway that's not really a problem. 2. The real problem that I am seeing is that include file are not arch independant AFAIK. What if a project would store the result of sizeof(long) within one of its header. You mean something like glibconfig.h. But that's why they put that under /lib/glib-2.0/include and not under /include. That's also why pkgconfig file go under /lib/pkgconfig for libraries and not under /share/pkgconfig . I naively assumed that for doing cross compilation I would simply have to install the 32bits version of a particular package (zlib, uuid, expat) within a specific root (/emul/ia32-linux for instance). Sure, you can always do that. That doesn't mean you always have to if you want to save some disk space and inodes :) HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE_TOOLCHAIN_FILE / testing with 'wine'
Am Dienstag, 19. August 2008 23:55:30 schrieb Mathieu Malaterre: On Tue, Aug 19, 2008 at 11:46 PM, Hendrik Sattler [EMAIL PROTECTED] wrote: Am Dienstag, 19. August 2008 23:17:18 schrieb Alexander Neundorf: On Tuesday 19 August 2008, Hendrik Sattler wrote: Am Dienstag, 19. August 2008 22:24:12 schrieb Mathieu Malaterre: Did you figure out a way to install 32bits debian package in the /emul/ia32 subdirectory ? How did you install your target system environment. On my debian box, the ia32-libs package works somewhat ok, but it only provide the runtime 32bits libs (not the include file for instance). The include files do not differ (they are architecture-independent) for normal projects. Why would you want to install a second set? Because they could differ, e.g. different versions or whatever. Not in a distribution like Debian. Well unless you are using unstable as it has a reason to be called like that. For other cases, the e.g ia32- packaes on amd64 have the same version. And in this case, they do not differ. On other systems where you have 32bit and 64bit libraries mixed (e.g. Solaris), you also only have _one_ include directory. Very impressive... this means that at any level of inclusion none of the include files has any system specific declaration (even gcc header!). gcc is not normal software. It actually needs to be specially ported to architectures and thus is always special. But the compiler knows where to find its include files, so you rarely need to worry about that, do you? Unless headers are generated at build time of the software that you depend on, how could they possibly be different? libz doesn't, just to use your example... HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE_TOOLCHAIN_FILE / testing with 'wine'
Am Mittwoch, 20. August 2008 00:19:32 schrieb Mathieu Malaterre: On Wed, Aug 20, 2008 at 12:16 AM, Hendrik Sattler [EMAIL PROTECTED] wrote: Am Dienstag, 19. August 2008 23:55:30 schrieb Mathieu Malaterre: On Tue, Aug 19, 2008 at 11:46 PM, Hendrik Sattler [EMAIL PROTECTED] wrote: Am Dienstag, 19. August 2008 23:17:18 schrieb Alexander Neundorf: On Tuesday 19 August 2008, Hendrik Sattler wrote: Am Dienstag, 19. August 2008 22:24:12 schrieb Mathieu Malaterre: Did you figure out a way to install 32bits debian package in the /emul/ia32 subdirectory ? How did you install your target system environment. On my debian box, the ia32-libs package works somewhat ok, but it only provide the runtime 32bits libs (not the include file for instance). The include files do not differ (they are architecture-independent) for normal projects. Why would you want to install a second set? Because they could differ, e.g. different versions or whatever. Not in a distribution like Debian. Well unless you are using unstable as it has a reason to be called like that. For other cases, the e.g ia32- packaes on amd64 have the same version. And in this case, they do not differ. On other systems where you have 32bit and 64bit libraries mixed (e.g. Solaris), you also only have _one_ include directory. Very impressive... this means that at any level of inclusion none of the include files has any system specific declaration (even gcc header!). gcc is not normal software. It actually needs to be specially ported to architectures and thus is always special. But the compiler knows where to find its include files, so you rarely need to worry about that, do you? Unless headers are generated at build time of the software that you depend on, how could they possibly be different? libz doesn't, just to use your example... Ok I have two questions then for you: 1. what is the flag for gcc to generate byte code for powerpc (-mcpu=powerpc is deprecated) You have a gcc that was compiled with that as target? Gcc-4.3 manpage mentions nothing about this option being deprecated. 2. what is the difference between the gcc package and gcc-multilib. If gcc package still exist and has not been replaced by gcc-multilib, there must be a reason... gcc-multilib is an addition to the gcc package, that allows you to actually link the 32bit binaries on your 64bit installation (or the other way round). HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 64bit programming
Am Samstag, 23. August 2008 02:34:35 schrieb Matthew Woehlke: Darren Weber wrote: What are the traps and tricks for 64bit programming with CMake and other kitware libraries? Don't make assumptions about sizeof(long) or sizeof(void*)... not even that they are the same (Microsoft, in their infinite wisdom, decided - as usual - to be different from everyone else and adopt a P64 model, rather than LP64 used by *everyone* else). That's the big thing. I don't know about kitware libraries, but I wouldn't expect much in the way of gotchas regarding 64-bit builds and cmake... at least, not on non-Windows platforms :-). Usually, that should never be a problem as casting from long to a pointer and back is really good coding style in modern C (about the same as not differing between function/code pointer and data pointers). Since google code has a project that gives msvc the C99 inttypes.h and stdint.h, those types should be used when a specific size is assumed. And when using int64_t, you don't have the problem of long only being 32bit and not 64bit. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] set_property and SOVERSION==0
Hi, I just changes a project from set_target_properties() to set_property() and found a bug, I assume: - a SOVERSION of 0 gets ignored. This worked for set_target_properties(). I am using cmake-2.6.0, is this maybe already fixed in CVS? HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] set_property and SOVERSION==0
Am Samstag, 23. August 2008 19:53:46 schrieb Hendrik Sattler: I just changes a project from set_target_properties() to set_property() and found a bug, I assume: - a SOVERSION of 0 gets ignored. This worked for set_target_properties(). I am using cmake-2.6.0, is this maybe already fixed in CVS? Nevermind, my fault :-( HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ADD_CUSTOM_TARGET behavior 2.4 vs 2.6?
Zitat von Roland Philippsen [EMAIL PROTECTED]: It is quite possible that the following problem arises because I misunderstant custom targets, but it worked under cmake-2.4 (various patch levels, various UNIX-ish operating systems). Attached is a mini-project which triggers an error due to the way that COMMANDs are parsed by ADD_CUSTOM_TARGET(). My custom command is essentially saying if there is no symlink, create it, like this: $ test -L foobar || ln -s /Users/rolo/soft/check foobar ln already does this check, the option -f is required to overwrite an existing symlink. Under cmake-2.6 at make time, this gets translated to $ test -L foobar || ln -s /Users/rolo/soft/check foobar Where the quotes around the or-operator break the command and make bails out with /bin/sh: line 1: test: too many arguments. Not all environment have shell bahaviour and accept an ||. Usually those should be normal commands with arguments, not something that needs to be interpreted by a shell. Or is there an altogether better way to create symlinks? cmake -E may help you. However note, that not all filesystems can actually have symlinks. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug? Broken header files in Visual C++ 2008 project
Am Donnerstag, 4. September 2008 21:50:03 schrieb Alexander Neundorf: On Thursday 04 September 2008, Andreas Pakulat wrote: On 03.09.08 23:45:56, Alexander Neundorf wrote: On Wednesday 03 September 2008, Andreas Pakulat wrote: ... Ah, yes. What would be cool would be if I could force kdevelop to reread its project files (... after they have been regenerated by cmake). Is this possible maybe via DCOP ? Let me check... The openProject() call is in fact available via dcop. Of course this is not a silent operation, i.e. the user will get asked if he wants to re-open the current project. I could add the needed functionality, but this won't show up in a stable release for quite some time. I think I already thought about this some time ago. So: how does cmake find the correct kdevelop instance ? Well, it must be a parent of your own PID (or the parent of the PPID, etc.). The 4745 in your example is the PID of the kdevelop process. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't find crypt
Am Saturday 13 September 2008 18:36:32 schrieb Razaj:
__CMakeLists.txt snippet__
# Check for crypt, if not found check for crypt in libcrypt
CHECK_FUNCTION_EXISTS(crypt CRYPT_EXISTS)
IF(NOT ${CRYPT_EXISTS})
CHECK_LIBRARY_EXISTS(crypt crypt CRYPT_LIB_EXISTS)
ENDIF(NOT ${CRYPT_EXISTS})
Does
CHECK_FUNCTION_EXISTS(crypt CRYPT_EXISTS)
IF(NOT CRYPT_EXISTS)
CHECK_LIBRARY_EXISTS(crypt crypt CRYPT_LIB_EXISTS)
ENDIF(NOT CRYPT_EXISTS)
work for you?
HS
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake + cygwin + NSIS Cpack generators
Zitat von David Coeurjolly [EMAIL PROTECTED]: I'd like to use the NSIS CPack Genertor on cygwin systems but I'm having a lot of troubles: by default, cpack wants to use the Cygwin-binary generator and if I customize myself the CPackConfig script, I have many errors due to unix style filepaths. Here are my questions: - is the command SET(CPACK_GENERATOR NSIS) in my CMakeLists.txt is supposed to work ? - has somebody experienced this kind of package generation ? NSIS can also be run under Linux and thus works with unix-style path. However, you probably need to use an nsis binary that was compiled with cygwin, _not_ a generic Win32 binary. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] multi-line definitions
Am Thursday 18 September 2008 15:18:46 schrieb Bill Hoffman: cyril_wobow wrote: Have you tried the following SET (CMAKE_C_FLAGS_RELEASE -mcpu=arm7tdmi -std=gnu99 -fgnu89-inline ... -DNDEBUG) Cyril That won't work. It will create a list of items and it needs to be a big string. Exactly why is it not possible to give a cmake list of options to property like COMPILE_FLAGS and LINK_FLAGS? CMake kindof should know that those flags cannot be given as e.g. -Wall;-W. Or is there any known case where this would make sense? HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Updated WinCE CMakefiles
Am Thursday 18 September 2008 14:08:05 schrieb Andreas Pokorny: * If I am not mistaken there is yet no clean facility to specify the libpath and include path from the toolchain file The lib path can normally be derived from the root path by specifying the proper PATH_SUFFIXES when using find_library. The include paths can be set by adding include_libraries(SYSTEM .) in the toolchain file. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindFreetype wrong?
Am Friday 19 September 2008 22:57:03 schrieb E. Wing:
Interesting. I was expecting the PATH_SUFFIXES to work on Windows. I
thought I had tested this general technique, though maybe not with the
Freetype module and maybe not 2.6.0. I think this may be a CMake bug,
but I'm not an authority on the matter.
You might want to try a more generalized example (not freetype
specific) and either repost the question for others to see, or file a
bug report.
-Eric
On 9/17/08, klaas.holwerda [EMAIL PROTECTED] wrote:
Hi,
I want to use FIND_PACKAGE( FREETYPE ) on windows. But it looks like it
does not work.
If i change in FindFreetype.cmake:
FIND_PATH(FREETYPE_INCLUDE_DIR_ft2build ft2build.h
$ENV{FREETYPE_DIR}
NO_DEFAULT_PATH
PATH_SUFFIXES include
)
to this:
FIND_PATH(FREETYPE_INCLUDE_DIR_ft2build ft2build.h
$ENV{FREETYPE_DIR}/include
NO_DEFAULT_PATH
)
It starts working. I tried setting FREETYPE_DIR environment variable
with and without a / at the end, but that is not solving it.
Even setting this:
FIND_PATH(FREETYPE_INCLUDE_DIR_ft2build ft2build.h
c:/soft/freetype/GnuWin32
NO_DEFAULT_PATH
PATH_SUFFIXES include
)
Maybe it should be
FIND_PATH(FREETYPE_INCLUDE_DIR_ft2build ft2build.h
$ENV{FREETYPE_DIR}
PATH_SUFFIXES include
NO_DEFAULT_PATH
)
?
HS
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] how to link with a system library ?
Am Sunday 21 September 2008 17:20:19 schrieb Eric Noulard: There is bug report about this http://www.vtk.org/Bug/view.php?id=6042 pointing to this CMake module http://code.google.com/p/cmake-modules/source/browse/trunk/Modules/GTK2/Fin dGTK2.cmake I haven't tested it though. Looks not too good (it doesn't even use foreach for this endless list of doing the same thing again and again). It also needs support for component selection and missing finding the programs that come with gtk. It mixes several things although they are not even from the same source package upstream (glib / gtk / pango / ...). It also doesn't make sure that the *config.h matches the library found (if you ever have two versions installed). HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Assembler and C++ for the same target
Am Thursday 25 September 2008 17:45:54 schrieb Stefan Weber: I am working on a C++ project which is using a single assembler file (among all the C++ files). In the mailinglist archives I found some hints on how to use the experimental ASM mode. However, as I only have a single ASM file, I'm not sure how to handle that: Ideally, I would like to pass it to add_library with all the other source files (in the same way I can pass it to C++ which automatically forwards it to the assembler). This is not working, Stop. The next step is no logical one. If it doesn't work for one target, why should it for another? cmake_minimum_required(VERSION 2.6) project(TEST) enable_language(ASM) add_library(asmtest MyAsm.S) That looks fine. And just adding the assembler file works here. Are you cross-compiling? If yes, did you define CMAKE_ASM_COMPILER? What is the compilation output? (make VERBOSE=1) Does that file actually appear there? HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Assembler and C++ for the same target
Am Thursday 25 September 2008 23:50:33 schrieb Stefan Weber: I think I was not clear enough here: it is not working when I combine ASM source files and CXX source files and as I found out by now, this is probably not supported anways. (Mixing ASM and C++ source files would be the ideal scenario because I can do it with g++ directly, too) Maybe I wasn't clear either: I use it on a mixed C/C++/ASM binary. Cross-compiling though but that shouldn't matter. Note the capital S in the file extension of the ASM file. It seems this is crucial: when I rename to a small s and manually pass it to g++ it does not work anymore. When I leave the cap S, it works. Looking a bit deeper shows that the ASM file has preprocessor macros in it, so it needs to go through g++ (and obviously g++ only looks at it if the S is capital)... now I'm totally confused... Then tell CMake that this needs to go to the C++ compiler, not the assembler: set_property (SOURCE myfile.S PROPERTY LANGUAGE CXX) Else you should make you .S file work with as and not silently assume that g++ or gcc is used for it. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Assembler and C++ for the same target
Am Thursday 25 September 2008 19:42:34 schrieb Hendrik Sattler: Am Thursday 25 September 2008 17:45:54 schrieb Stefan Weber: I am working on a C++ project which is using a single assembler file (among all the C++ files). In the mailinglist archives I found some hints on how to use the experimental ASM mode. However, as I only have a single ASM file, I'm not sure how to handle that: Ideally, I would like to pass it to add_library with all the other source files (in the same way I can pass it to C++ which automatically forwards it to the assembler). This is not working, Stop. The next step is no logical one. If it doesn't work for one target, why should it for another? cmake_minimum_required(VERSION 2.6) project(TEST) enable_language(ASM) add_library(asmtest MyAsm.S) That looks fine. I have to correct myself. Probably due to different incompatible ASM compilers, you have to set the LANGUAGE property of each ASM file with e.g. set_property ( SOURCE MyAsm.S PROPERTY LANGUAGE ASM ) It does _not_ work without that. I found a bug with CMake-2.6.1 with this: a -Dasmtest_EXPORTS is given to as and my as from gcc-4.1.2 doesn't like that at all (aborts with an error). Strangely, all other defines from the COMPILE_DEFINITIONS property are _NOT_ given in the as call (another bug, I assume). HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link_libraries
Ioan Calin Borcoman schrieb:
Hi,
I have a dir with a lot of small example apps that all link with the
same libs. The link_libraries is much more convenient in this case
than writing a target_link_libraries line for each example target.
Why is the link_libraries deprecated? Will it be removed in the future?
In this case, you usually use a foreach anyway, don't you?
set (exampleapps
ex1
ex2
ex3
)
foreach ( ex ${exampleapps} )
add_executable( ${ex} ${ex}.c )
target_link_libraries( ${ex} mylib)
endforeach ( ex )
Easy enough?
HS
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] install CMake on Win 64-bit
Stéphane CALANDE schrieb: but I still don't understand how to install CMake on Win 64-bit Can you help me please ? Download the source and compile it? I don't have Win64 but AFAIK, Visual Studio Express also works there and can be used to compile cmake. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compiling assembler files with C code
Gerhard Gappmeier schrieb: Hi all, I want to compile an assembler file with my C sources. A simple example how to compile this on the command line looks like that: gcc cas32test.c cas32.s -o cas32test --- project(cas C) enable_language(ASM) set_property(SOURCE cas32.s PROPERTY LANGUAGE ASM) add_executable(cas32test cas32test.c cas32.s) --- That should be it. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Changing CMake default directories.
Paweł Żak schrieb: Hi, I have a problem with changing CMake default directories and I need your help. The usual layout of projects we develop in my company presents like this: project --- src (sources and headers) |-- lib (libraries and archives) |-- bin (binaries) \-- tmp (temporary files) I'm unable to set it in this way using CMake, because it always creates `CMakeFiles' directory in `project' and `src' dirs. I tried to change this behaviour by setting CMAKE_FILES_DIRECTORY to `tmp' but it doesn't work for me. The directory is being created but some of generated files (mostly from other modules) are still put into `CMakeFiles'. I was wondering if running CMake with -C option and a script with `CMAKE_BINARY_DIR' set to `tmp' might do the trick but since it is rather inelegant solution I'm asking you first. cd tmp cmake .. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake problem on Solaris with suncc
Bill Hoffman schrieb: You have to start with an empty cache. Re-run cmake with no CMakeCache.txt. Then make sure the CMAKE_C_FLAGS are correct. Shouldn't that be CMAKE_ASM_FLAGS if the .s file has the language property set to ASM? HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE_MAKE_PROGRAM is not set
Stephen Collyer schrieb: I have some code that I've delivered to a 3rd party who is now trying to build it. They're using Vista and a Visual Studio 2008 environment, with cmake 2.6.1 They're getting the following errors when trying to run cmake. It looks to me like an environment problem of some kind, but I've never seen it before: C:\mdp_qt\builds\win32cmake /DBUILD_SHARED_LIBS=ON ..\.. CMake Error: CMake was unable to find a build program corresponding to Visual Studio 6. CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. If you want nmake, you should give cmake the correct generator value using -G HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to link against a static lib under windows/minGW
Joachim Ziegler schrieb:
if(CMAKE_HOST_WIN32)
INCLUDE_DIRECTORIES(D:/nspr-4.6/include)
LINK_DIRECTORIES(D:/nspr-4.6/lib)
ADD_EXECUTABLE(testPR PRifdefd.cpp ${BASEFILES})
TARGET_LINK_LIBRARIES(testPR nspr4 Ws2_32)
...
To run the executable, I have to copy the lib files libnspr4.dll and
libnspr4.lib into the build directory (where the executable testPR is
built). (Can I avoid this somehow?)
I am pretty sure you do not have to copy them, at least no the .dll
file. Read the FIND_LIBRARY command help but LINK_DIRECTORIES as about
should work as well.
But now, what if I want to compile statically against NSPR (and maybe
Winsock2), so that I can give away my executable to a customer?
ws2_32 is a system library, there's no sense in wanting to link that
statically.
If you put the libnspr4.dll (you do not need to ship the .lib file) into
the same directory as the executable, it will get used.
Additionally, if the .lib file is a static library, then you link
statically. If it is not, then you do not link statically. It is as easy
as this.
HS
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack DEB Packaging: Automate dependency resolution
Am Saturday 01 November 2008 12:44:39 schrieb David Graf: Currently in my project, I provide all dependencies for DEB packaging in CPack by setting the variable CPACK_DEBIAN_PACKAGE_DEPENDS. Is there a possibility to automate this process (similar to the behavior of the CPack RPM packaging mechanism)? As far as I understood it correctly, such a mechanism must be implemented with the Linux tool 'objdump' to get the dependencies of shared libraries. I already thought about implementing my own script to get these dependencies of my shared libraries automatically. But first, I wanted to make sure that I do not reinvent the wheel. Especially because I found the following entry in 'CPackDeb.cmake' next to the dependency section: ' TODO: automate 'objdump -p | grep NEEDED'. No, you would get libraries but on Debian you should use dpkg-shlibdeps instead (or read its manpage and do it the same). HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] pkgconfig and cross compiling
Alexander Neundorf schrieb: -Once it found the correct pc-file, it returns the result. Problem: the results don't contain the target architecture prefix, e.g. here incdir gives /usr/include while it should be /opt/eldk-4.1/ppc_4xxFP/ppc_4xxFP/usr/include . So what to do ? Try to automatically adjust it by adding some appropriate path in the beginning ? Ignore it and use the wrong include dir ? Sounds even worse. $export PKGCONFIG_LIB_DIR=/opt/eldk-4.1/ppc_4xxFP/ppc_4xxFP $pkg-config \ --define-variable=prefix=/opt/eldk-4.1/ppc_4xxFP/ppc_4xxFP/usr/ \ some_package should give you the correct result as the other paths should be defined relative to prefix. BTW: cross-pkg-config as proposed here should indeed be used if present. However(!) and like the one above, it will also fail if you have more than one root prefix. The right fix would be to do the same as on Windows and automatically define prefix relative to the location of the .pc file that is currently in use (and remove the prefix variable from all those files). And then, the cross-pkg-config is just useful for the case that the build host does not have pkg-config itself. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack DEB Packaging: Automate dependency resolution
Mathieu Malaterre schrieb: On Tue, Nov 4, 2008 at 12:43 PM, Mike Arthur [EMAIL PROTECTED] wrote: On Tuesday 04 November 2008 11:36:12 David Graf wrote: How exactly to you use dpkg-shlibdeps? Because I get the following bug: dpkg-shlibdeps: failure: cannot read debian/control: No such file or directory You really should be using Debian utilities. Not unless you are on a debian machine. Technically nothing should prevent your from creating a deb package on redhat/slackware/... Except one thing: since you have to specify actual package names, the result very much depends on the release that you want to run it on. The result can be different between stable, testing and unstable or the different Ubuntu releases or whatever you want to install it on. So either you give the binary package dependencies manually, or you build with a debian root. For the source dependencies: how do you specify alternative source packages like a | b | c automatically? CMake doesn't know about them, it only could know what is currently installed. And giving those manually kind of currently conflicts with your desire to put them in automatically. Currently because that could be solved with a database that gets checked when source package dependencies get resolved (would even be better than the current state). In fact: I agree with you. However, some things need to change before that it possible. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack DEB Packaging: Automate dependency resolution
Mathieu Malaterre schrieb: I quickly browse thought the page you sent and indeed this is the way to retrieve the shared lib deps. However, debian references packages name (not lib name). So we are still missing the inverse lookup of what package provide a particular shared libs. I can't remember which file list all those (package - libs reference). I guess one could do a: $ dpkg -S libname.so Did you read my message? Citing from dpkg-shlibdeps: dpkg-shlibdeps has two possible sources of information to generate dependency information. Either symbols files or shlibs files. For each binary that dpkg-shlibdeps analyzes, it finds out the list of libraries that it's linked with. Then, for each library, it looks up either the symbols file, or the shlibs file (if the former doesn't exist). Both files are supposed to be provided by the library package and should thus be available as /var/lib/dpkg/info/package.symbols or /var/lib/dpkg/info/package.shlibs. The package name is identified in two steps: find the library file on the system (looking in the same directories that ld.so would use), then use dpkg -S library-file to lookup the package providing the library. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
