Re: [CMake] CMake and MinGW on Windows
Von: Shriramana Sharma Hello. I would like to use CMake to build some CMake-ready Qt-based applications on Windows using MinGW. I get an error saying Make was not found. I used -DCMAKE_MAKE_PROGRAM=path to mingw. But then I got an error saying C compiler could not compile the test program. I tried on the CMake wiki but both the MinGW-related pages I found: http://www.cmake.org/Wiki/CMake_MinGW_Compiler_Issues http://www.cmake.org/Wiki/CmakeMingw did not solve my problem. Please can anyone give clear instructions as to how to use CMake with MinGW, especially for compiling Qt programs on Windows? Thanks in advance. There are no special things to do. Looks like your PATH environment variable is missing the path to 'bin' directory from MinGW. Otherwise mingw32-make and gcc would be found by cmake without any additional parameters. Christian -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compiling for 64 bit Vista with Windows SDK for Windows Server 2008
Am Mittwoch 21 Mai 2008 04:59:37 schrieb Roger Martin: Hi, See related thread on OpenSceneGraph http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008 -May/011600.html I did as Philip suggested and made a small test project. and still got the same j option issue with a 64 bit project with the 'Windows SDK for Windows Server 2008' Any way to track this j option down? My impression is you invoked nmake with -j2 or similar to build parallel. If this is the case, don't do it. NMake cannot build parallel due to the lack of a job server of the windows command shell. If you didn't, please spend a .bat which includes the commands you use to configure and start the build process. -- Maik ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 and find_library with MinGW generator
Christian Ehrlicher schrieb:
during your new warning when mixing libs in target_link_libraries
(CMP0003) I changed target_link_libraries(foo ws2_32) to
find_library(WS2_32_LIBRARY ws2_32)
target_link_libraries(foo ${WS2_32_LIBRARY})
but now cmake finds ws2_32.dll in system32 instead the correct one
(ws2_32.dll.a / ws2_32.a) in mingw dir.
Set the LIB environment variable to the MinGW lib dir. While you are at
it, do the same for INCLUDE.
This is comparable to the setup for cl.
HS
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 and find_library with MinGW generator
Von: Hendrik Sattler
Christian Ehrlicher schrieb:
during your new warning when mixing libs in target_link_libraries
(CMP0003) I changed target_link_libraries(foo ws2_32) to
find_library(WS2_32_LIBRARY ws2_32)
target_link_libraries(foo ${WS2_32_LIBRARY})
but now cmake finds ws2_32.dll in system32 instead the correct one
(ws2_32.dll.a / ws2_32.a) in mingw dir.
Set the LIB environment variable to the MinGW lib dir. While you are at
it, do the same for INCLUDE.
This is comparable to the setup for cl.
Also they solution is clear I don't like it. MinGW doesn't care about LIB
(otherwise it wouldn't link against ws2_32.a) so why should cmake do in this
case?
The problem is the new warning - it suggest that a simple find_library would do
the job but it doesn't - it breaks compilation. Looks like this warning is the
first one which I'll disable by default. Maybe also in kde4/win because it's
imho useless when linking against system libs (on windows).
Christian
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED]
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 and find_library with MinGW generator
Christian Ehrlicher schrieb:
Von: Hendrik Sattler
Christian Ehrlicher schrieb:
during your new warning when mixing libs in target_link_libraries
(CMP0003) I changed target_link_libraries(foo ws2_32) to
find_library(WS2_32_LIBRARY ws2_32)
target_link_libraries(foo ${WS2_32_LIBRARY})
but now cmake finds ws2_32.dll in system32 instead the correct one
(ws2_32.dll.a / ws2_32.a) in mingw dir.
Set the LIB environment variable to the MinGW lib dir. While you are at
it, do the same for INCLUDE.
This is comparable to the setup for cl.
Also they solution is clear I don't like it. MinGW doesn't care about LIB
(otherwise it wouldn't link against ws2_32.a) so why should cmake do in this
case?
The problem is the new warning - it suggest that a simple find_library would do
the job but it doesn't - it breaks compilation. Looks like this warning is the
first one which I'll disable by default. Maybe also in kde4/win because it's
imho useless when linking against system libs (on windows).
Did find_library in CMake 2.4 find he correct one?
I also think that this could be improved: for MinGW Makefiles
generator, cmake could get the base MinGW directory and add
the lib/ and include/ subdirs to the front of default paths. Then,
find_library() would magically work again.
Do you want to create a bug tracker entry for that issue?
HS
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Disable pretty output
Bill Hoffman wrote: OK, thanks. I am not sure how -j N will be fixed by this, but the other stuff sounds good. I think we are sort of stuck with the jumbled output with parallel make. Unless you got really complicated with some sort of client server setup. I'm not sure how things work today, but typically when you have rules like this foo.o: foo.c @echo Compiling foo $(CC) they aren't jumbled (even if the output won't necessarily come directly together with any subsequent errors or warnings). I guess its because echo flushes the entire line at once. If the progress percentage and the actual message is printed in separate invocations, that would increase the risk of jumbling. Usually the problem with parallell make is that compiler error messages are mixed up. OMake actually solves that by buffering all compiler output until the compiler exits, but that may be overkill in this case, I think. Anyway, having an external program will allow the a large degree of freedom without complicating things too much. -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 and find_library with MinGW generator
Von: Hendrik Sattler
Christian Ehrlicher schrieb:
Von: Hendrik Sattler
Christian Ehrlicher schrieb:
during your new warning when mixing libs in target_link_libraries
(CMP0003) I changed target_link_libraries(foo ws2_32) to
find_library(WS2_32_LIBRARY ws2_32)
target_link_libraries(foo ${WS2_32_LIBRARY})
but now cmake finds ws2_32.dll in system32 instead the correct one
(ws2_32.dll.a / ws2_32.a) in mingw dir.
Set the LIB environment variable to the MinGW lib dir. While you are at
it, do the same for INCLUDE.
This is comparable to the setup for cl.
Also they solution is clear I don't like it. MinGW doesn't care about
LIB (otherwise it wouldn't link against ws2_32.a) so why should cmake do in
this case?
The problem is the new warning - it suggest that a simple find_library
would do the job but it doesn't - it breaks compilation. Looks like this
warning is the first one which I'll disable by default. Maybe also in kde4/win
because it's imho useless when linking against system libs (on windows).
Did find_library in CMake 2.4 find he correct one?
Don't know but don't think so - I completly switched to 2.6 a while ago.
I also think that this could be improved: for MinGW Makefiles
generator, cmake could get the base MinGW directory and add
the lib/ and include/ subdirs to the front of default paths. Then,
find_library() would magically work again.
Do you want to create a bug tracker entry for that issue?
I will - just wanted to discuss it here to see if you maybe can convince me
that's the correct behaviour for mingw :)
Christian
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Issue with CMAKE 2.6 and Windows.
Phil Pellouchoud wrote: I noticed that the TARGET_LINK_LIBRARIES seems to add .obj instead of .lib to link libraries without an extension. I went back to 2.4 and everything works fine... When it adds the .obj, obviously the build fails because it can't find the .obj (it should be looking for .lib). Anyone else seeing this? CMake is not adding the .obj extension. It generates the path to the library exactly as you provided it on the generated link line in the VS project. It's the VS linker that decides to add .obj instead of .lib. The difference in link line generation from CMake 2.4 is documented here: http://www.cmake.org/Wiki/CMake_2.6_Notes#Link_Line_Generation Basically, CMake 2.4 would turn c:/path/to/foo into /LIBPATH:c:\path\to foo.lib while CMake 2.6 is preserving user-provided full paths. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Issue with CMAKE 2.6 and Windows.
Brad King wrote: The difference in link line generation from CMake 2.4 is documented here: http://www.cmake.org/Wiki/CMake_2.6_Notes#Link_Line_Generation This documentation is helpful, but it also mentions that there are side effects and these are not described (as far as I can tell) Regards, Arjen ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Issue with CMAKE 2.6 and Windows.
Arjen Markus wrote: Brad King wrote: The difference in link line generation from CMake 2.4 is documented here: http://www.cmake.org/Wiki/CMake_2.6_Notes#Link_Line_Generation This documentation is helpful, but it also mentions that there are side effects and these are not described (as far as I can tell) The subsections immediately following that sentence describe them. I've added an explicit note to this effect. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] linking to .so's
Hi, I have a question about how to link (via CMake) to specific .so's. I know I need to use target_link_libraries. But what happens then is that the so is linked against the directory where it's in. Is there a possibility (i know rpath does exist, but I don't know exactly how to use it) to have the .so's loaded from the local directory before it starts looking in the default library directories? An example: MyPlugin.so == target_link_libraries(MyPlugin /src/MyPlugin/libbz2.so). When I deploy this on a target system, the target system cannot use the libbz2 unless it's in exact that directory... What I would like is that it's in the directory of MyPlugin and also loaded from there... Thanks! ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Issue with CMAKE 2.6 and Windows.
Brad King wrote: Arjen Markus wrote: Brad King wrote: The difference in link line generation from CMake 2.4 is documented here: http://www.cmake.org/Wiki/CMake_2.6_Notes#Link_Line_Generation This documentation is helpful, but it also mentions that there are side effects and these are not described (as far as I can tell) The subsections immediately following that sentence describe them. I've added an explicit note to this effect. -Brad Hi Brad, thanks, I suspected as much, but could not be sure. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 and find_library with MinGW generator
Christian Ehrlicher wrote:
Hi,
during your new warning when mixing libs in target_link_libraries
(CMP0003) I changed target_link_libraries(foo ws2_32) to
find_library(WS2_32_LIBRARY ws2_32)
target_link_libraries(foo ${WS2_32_LIBRARY})
but now cmake finds ws2_32.dll in system32 instead the correct one
(ws2_32.dll.a / ws2_32.a) in mingw dir.
A!!!
This is the most misunderstood warning of all times :)
You do not have to use full paths for all libraries now.
You do not have to use full paths for all libraries now.
For system libraries like this one it is much safer to just list them.
If you set the policy to NEW, it will just work with no warnings. The
warning says that it maybe a problem, but to try it as NEW, and if it is
not a problem, then you are good.
For this case I would recommend changing ws2_32 to not being found. It
is a standard library that the compiler should be able to find the
appropriate version of.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Can't unset suffix
Using Cmake 2.4.7 on Ubuntu. My project produces a shared library on Unix which is a plugin. Therefore, it does not need the standard libxxx.so naming. I want the name to be xsb_vatsim.xpl I've changed the suffix to what I want, but now I'm trying to eliminate the prefix and finding it impossible. If I use: SET_TARGET_PROPERTIES(xsb_vatsim PROPERTIES PREFIX ) I get: xsb_vatsim.xpl as an output file. If I use: SET_TARGET_PROPERTIES(xsb_vatsim PROPERTIES PREFIX) I get: SET_TARGET_PROPERTIES called with incorrect number of arguments any thoughts on how I can correct this? Thanks, Wade ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 and find_library with MinGW generator
Von: Bill Hoffman
Christian Ehrlicher wrote:
Hi,
during your new warning when mixing libs in target_link_libraries
(CMP0003) I changed target_link_libraries(foo ws2_32) to
find_library(WS2_32_LIBRARY ws2_32)
target_link_libraries(foo ${WS2_32_LIBRARY})
but now cmake finds ws2_32.dll in system32 instead the correct one
(ws2_32.dll.a / ws2_32.a) in mingw dir.
A!!!
This is the most misunderstood warning of all times :)
You do not have to use full paths for all libraries now.
You do not have to use full paths for all libraries now.
For system libraries like this one it is much safer to just list them.
If you set the policy to NEW, it will just work with no warnings. The
warning says that it maybe a problem, but to try it as NEW, and if it is
not a problem, then you are good.
For this case I would recommend changing ws2_32 to not being found. It
is a standard library that the compiler should be able to find the
appropriate version of.
I understood the warning - I know that it is not mandatory. But how useful is a
warning when the only way to get rid of them is to disable it? I either have to
fix all places (including the system libs) or disable it and don't care at all.
That's stupid.
Christian
--
Desperate Housewives - das Spiel!
Pikante Skandale, schockierende Details unter: http://flat.games.gmx.de
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 and find_library with MinGW generator
Christian Ehrlicher wrote: I understood the warning - I know that it is not mandatory. But how useful is a warning when the only way to get rid of them is to disable it? I either have to fix all places (including the system libs) or disable it and don't care at all. That's stupid. Adding the code the warning suggests does *not* disable it. It is actually a *fix* for the condition that produces the warning. CMake is telling you that it is enabling some old (bad) behavior for compatibility because it has not been told that it is safe to use the new behavior and is unable to detect whether it is safe. The suggested code cmake_policy(SET CMP0003 NEW) tells CMake to use the new behavior...it will actually produce a *different link line* for the target. If the project was not depending on the old behavior it will just work. However, if the project was depending on the old behavior it will not link and then the offending code will have to be fixed (add a link directory or use a full path for the lib that cannot be found). In that case the author that is adding the line above can update the code too. The key to the policy design is that in either case joe user doesn't have to do anything to get the project to build without modification. Another way to tell CMake to use the new behavior is to require CMake 2.6 (which will get rid of this problem completely in the future): cmake_minimum_required(VERSION 2.6) This is all explained by documentation: http://www.cmake.org/Wiki/CMake_Policies http://www.cmake.org/HTML/cmake-2.6.html#policy:CMP0003 http://www.cmake.org/Wiki/CMake_2.6_Notes#Missing_Linker_Search_Directories cmake --help-policy CMP0003 cmake --help-command cmake_policy cmake --help-command cmake_minimum_required -Brad BTW, the code cmake_policy(SET CMP0003 OLD) # note OLD, not NEW or the command line option -Wno-dev would be disabling the warning without changing behavior. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 and find_library with MinGW generator
Christian Ehrlicher wrote: I understood the warning - I know that it is not mandatory. But how useful is a warning when the only way to get rid of them is to disable it? I either have to fix all places (including the system libs ) or disable it and don't care at all. That's stupid. OK, so you don't understand the warning. Not your fault it is just hard to write as many others do not understand it. Here is the problem: We changed from -L/path/to -lA to /path/to/library. In some rare cases projects have something like this: target_link_libraries(foo /path/to/libA.a B) And B is actually in /path/to/libB.a We have no easy way of telling the difference between the above and target_link_libraries(foo /path/to/libA.a somesystemlib) Where somesystemlib library can be found by the compiler. So, we had two choices for 2.6: 1. Always add -L/path if there is at least one non-full path library linked in. This makes extra long link lines. 2. Do not add -L/path and give no warning - we will break some projects with no warning, and the break will happen with a linker error during the build step. So, what we did was do 1 by default, but give a warning. So, to make a long story short, setting the policy to NEW is not disabling the warning, it is asking CMake to link libraries in the new better 2.6 way. So, the correct fix is to set the policy to NEW, and if your stuff links then the warning was in error. If a project has 2.6 as the minimum require version there is no warning and things are always linked full path. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Pure Python project
Emmanuel Blot wrote: Hi, I'm using CMake (2.6) to build several C and C++ projects. I'd like to add another project which would be a pure Python project: CMake would simply have to invoke Python script (which in turn generates an output file based on two input files). What would be the rules to do so ? I've tried ADD_CUSTOM_COMMAND and ADD_CUSTOM_TARGET with no luck: CMake does create the Makefile files, but running make simply does nothing (no error, simply does nothing) http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_generate_a_source_file_during_the_build.3F The command add_custom_command(OUTPUT myout.txt COMMAND ...) tells CMake how to generate myout.txt. Then you have to tell CMake you want to generate it by depending on the output from a target. The target can either be an executable you're already building: add_executable(myexe myexe.c myout.txt) or a custom target: add_custom_target(MyDriverTarget ALL DEPENDS myout.txt) The ALL option makes the custom target build by default. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 and find_library with MinGW generator
Bill Hoffman schrieb: Christian Ehrlicher wrote: I understood the warning - I know that it is not mandatory. But how useful is a warning when the only way to get rid of them is to disable it? I either have to fix all places (including the system libs ) or disable it and don't care at all. That's stupid. OK, so you don't understand the warning. Not your fault it is just hard to write as many others do not understand it. Here is the problem: We changed from -L/path/to -lA to /path/to/library. In some rare cases projects have something like this: target_link_libraries(foo /path/to/libA.a B) And B is actually in /path/to/libB.a We have no easy way of telling the difference between the above and target_link_libraries(foo /path/to/libA.a somesystemlib) Where somesystemlib library can be found by the compiler. So, we had two choices for 2.6: 1. Always add -L/path if there is at least one non-full path library linked in. This makes extra long link lines. 2. Do not add -L/path and give no warning - we will break some projects with no warning, and the break will happen with a linker error during the build step. So, what we did was do 1 by default, but give a warning. So, to make a long story short, setting the policy to NEW is not disabling the warning, it is asking CMake to link libraries in the new better 2.6 way. So, the correct fix is to set the policy to NEW, and if your stuff links then the warning was in error. If a project has 2.6 as the minimum require version there is no warning and things are always linked full path. Thx for the explanation. Christian signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Inter-project dependencies
Emmanuel Blot wrote: Hi, I'm using CMake to build two C-based projects The first CMake project builds several static libraries (ARM elf / eCos) The second CMake project builds several application which do link against the static libraries produced within the first project. However, both CMake projects are unrelated from CMake perspective. I've not been able to find a CMake rule to tell CMake to force relinking an application of the second project when a library generated in the first project has been updated. I always need to touch a source file of the second project so that Make rebuilds the file and is forced to relink the application with the static libraries of the first project. Which CMake rule should/could I use to add a dependency from the 2nd project onto an external static library (of the 1st project) ? In the second project make sure you specify the libraries to link from the first project by full path. Then the dependencies will be hooked up. Without a full path CMake does not know how to add a build-time dependency on a library. You can get a full path in the second project by using find_library. Even better, use export/import capabilities: http://www.cmake.org/Wiki/CMake_2.6_Notes#Exporting_and_Importing_Targets -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.6 and find_library with MinGW generator
Christian Ehrlicher wrote: Thx for the explanation. No problem, how do you think we could reword the warning to avoid future confusion? You are certainly not alone here. :) -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Can't unset suffix
On 2008-05-21 09:03-0500 Wade Williams wrote:
Using Cmake 2.4.7 on Ubuntu.
My project produces a shared library on Unix which is a plugin. Therefore,
it does not need the standard libxxx.so naming. I want the name to be
xsb_vatsim.xpl
I've changed the suffix to what I want, but now I'm trying to eliminate the
prefix and finding it impossible.
If I use:
SET_TARGET_PROPERTIES(xsb_vatsim PROPERTIES PREFIX )
I get:
xsb_vatsim.xpl
as an output file.
If I use:
SET_TARGET_PROPERTIES(xsb_vatsim PROPERTIES PREFIX)
I get:
SET_TARGET_PROPERTIES called with incorrect number of arguments
any thoughts on how I can correct this?
The PLplot project uses the following construct all the time without
problems for exactly this situation (building plugin shared objects) on
Unix systems.
set_target_properties(targetname PROPERTIES PREFIX SUFFIX ${DYNAMIC_SUFFIX})
where $DYNAMIC_SUFFIX is platform-dependent (.dll on CYGWIN and .so for
Mac OS X and Linux). (Note, these suffixes are demanded by the libltdl
library and should probably be something else if you are using some other
alternative for your dynamic loading.)
The only real difference with what you have done above, is both PREFIX and
SUFFIX are set at the same time, but that shouldn't matter. Since I don't
observe the behaviour you have found, I suggest you put together an
extremely simple but complete example (hello-world plugin build). If the
problem occurs in that context, then that simple example could be used by
others to verify/fix the problem. OTOH, on a number of occasions I have
prepared a simple but complete example of a CMake problem only to find the
problem disappeared in the simple context, i.e., I had introduced some CMake
logic bug in the more complex context.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Issues with VS2005 Pro, CMake 2.4.8, Win XP, ParaView
Not sure which list to ask on first so I'll try this one. My Setup is Visual Studio 2005 Pro, CMake 2.4.8 on windows XP. I have NO admin privs (USAF computer) and NO write access to the C: drive. VS is installed on C: but everything else user related is on the D: drive including CMake (Downloaded from cmake), Qt and everything else. The error I get is saying the the TestBigEndian failed but the output is actually saying it passed. After that I start getting errors about 32 and 64 bit floats can't be found. I also have VS 2003.Net installed and using that with CMake and ParaView, cmake runs successfully. If someone might be able to shed some light on what is going wrong it would be great. I also have the error logs from the run if that will help figure out what is going on. Also, my VS2005 Pro has never has a service pack installed. Might that be the problem? -- Mike Jackson imikejackson _at_ gee-mail dot com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Compiler flags for Obj-C++ files only
I need to set a compiler flag for Obj-C++ files (-fobjc-call-cxx- cdtors). Setting it for C++ will give a warning from gcc when the source file type is C++ (instead of Obj-C++). Is there any way to set flags for only Obj-C++ files? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compiler flags for Obj-C++ files only
On Wednesday 21 May 2008 1:08:40 pm Allan Odgaard wrote:
I need to set a compiler flag for Obj-C++ files (-fobjc-call-cxx-
cdtors).
Setting it for C++ will give a warning from gcc when the source file
type is C++ (instead of Obj-C++).
Is there any way to set flags for only Obj-C++ files?
Does
set_source_files_properties( ${obj_Cpp_files} PROPERTIES
COMPILE_FLAGS -fobjc-call-cxx-cdtors)
work?
I've done that kind of thing with mixed fortran C projects before.
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compiler flags for Obj-C++ files only
E. Wing wrote: I believe the answer is no. I think Sean McBride and I brought this up before and agree with you that we need a case like this. The bug is filed here: http://public.kitware.com/Bug/view.php?id=4756 Please feel free to add additional information (or submit a patch :)) On 5/21/08, Allan Odgaard [EMAIL PROTECTED] wrote: I need to set a compiler flag for Obj-C++ files (-fobjc-call-cxx- cdtors). Setting it for C++ will give a warning from gcc when the source file type is C++ (instead of Obj-C++). Is there any way to set flags for only Obj-C++ files? You could use a source file property compile flag as a work around. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compiler flags for Obj-C++ files only
On 21 May 2008, at 21:52, Bill Hoffman bill.hoffman-at-kitware.com |
CMake| wrote:
E. Wing wrote:
I believe the answer is no. I think Sean McBride and I brought this
up
before and agree with you that we need a case like this. The bug is
filed here:
http://public.kitware.com/Bug/view.php?id=4756
Please feel free to add additional information (or submit a patch :))
On 5/21/08, Allan Odgaard [EMAIL PROTECTED] wrote:
I need to set a compiler flag for Obj-C++ files (-fobjc-call-cxx-
cdtors).
Setting it for C++ will give a warning from gcc when the source file
type is C++ (instead of Obj-C++).
Is there any way to set flags for only Obj-C++ files?
You could use a source file property compile flag as a work around.
Yes, though I have 15+ targets so I ended up replacing all uses of
ADD_LIBRARY/EXECUTABLE with MY_ADD_LIBRARY/EXECUTABLE and have it do
the following before calling the real function:
FOREACH(SRC ${ARGN})
IF(${SRC} MATCHES \\.mm$)
SET_SOURCE_FILES_PROPERTIES(${SRC} PROPERTIES COMPILE_FLAGS -
fobjc-call-cxx-cdtors)
ENDIF()
ENDFOREACH()
Thanks all for the prompt replies.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Inter-project dependencies
In the second project make sure you specify the libraries to link from the first project by full path. Then the dependencies will be hooked up. Without a full path CMake does not know how to add a build-time dependency on a library. You can get a full path in the second project by using find_library. Even better, use export/import capabilities: http://www.cmake.org/Wiki/CMake_2.6_Notes#Exporting_and_Importing_Targets Hi, I tried the importing target feature, but unfortunately, it does not seem to work as (I ?) expected. The executable of the second CMake project does not get relinked when a library of the first project is updated (i.e. more recent than the executable). I've tried to change the rule set_property(TARGET foo PROPERTY IMPORTED_LOCATION /path/to/libfoo.a) with a non-existing file, i.e. set_property(TARGET foo PROPERTY IMPORTED_LOCATION /path/to/libfoo2.a) GCC fails to link the executable against the libfoo2.a library, as expected. Note that the missing file as reported from GCC is a full path, which demonstrates that full path to the library are actually generated by CMake (I also run make VERBOSE=1 to cross check: full path name to the libraries are definitely used) Then, I reverted the invalid change to the proper library file path: set_property(TARGET foo PROPERTY IMPORTED_LOCATION /path/to/libfoo.a) and re-run make. At this point the executable DID get relinked (not rebuild, as expected). So it seems that it gets closer to what I'd like to achieve, but there's still some issue with the dependency processing. touching the libfoo.a never leads to relink the executable file. I'm using CMake 2.6: $ cmake --version cmake version 2.6-patch 0 As a side note, http://www.cmake.org/Wiki/CMake_2.6_Notes#Exporting_and_Importing_Targets uses the following example: add_library(foo IMPORTED) but it seems that this statement is not valid: the type of the library is required (STATIC, SHARED, etc) such as in add_library(foo STATIC IMPORTED) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] What is the proper way to handle additional non-object files generated by compilation?
I am finally working again on the CMake language support for Ada (currently implemented just for the gcc gnatmake compiler). One of the issues is the gnatmake compiler not only produces *.o object files but also *.ali (Ada library information) files, and I haven't figured out how to get the *.ali files automatically removed by make clean using my Ada language support files. Currently, I am using SET_DIRECTORY_PROPERTIES(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES ...) to get make clean to work for the generated *.ali files, but I am concerned this is just a workaround for some limitation in my current Ada language support files. A similar situation appears for Fortran 90 compilers which generate both module files and standard object files. I have just proved to my satisfaction that make clean works for those generated module files (at least for cmake-2.6.0 and gfortran module files with the extension .mod that are generated by the PLplot build). If that correct make clean result for Fortran module files is set up in the CMake Fortran language support files, please point me to the area, and I can probably do the rest for the Ada case. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
