Re: [CMake] Cross-compilation linking against host libc
On Tue, Mar 31, 2009 at 10:11 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
On Tuesday 31 March 2009, Adolfo Rodríguez wrote:
2009/3/30 Alexander Neundorf a.neundorf-w...@gmx.net
...
[1] In case you think it helps, these are my rpath settings:
# Use, i.e. don't skip the full RPATH for the build tree
set(CMAKE_SKIP_BUILD_RPATH FALSE)
# When building, don't use the install RPATH already
# (but later on when installing)
set(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
# The RPATH to be used when installing
set(CMAKE_INSTALL_RPATH ${CMAKE_INSTALL_PREFIX}/lib)
# Add the automatically determined parts of the RPATH
# which point to directories outside the build tree to the install RPATH
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
I'm not sure these two settings are good for cross compiling.
At least when I did cross compiling for really different targets, I usually
installed the executables e.g. to ~/arm/inst/, but on the target platform
this would be a different location, e.g. /opt or /usr/local (which could be
NFS-mounted just from the local directory).
So while the files where installed, but on the host system the RPATH
was wrong, but once they were moved to their final location the RPATH was
then the correct one.
This is also the case for you with the libc here. The executable doesn't
have
the RPATH set for the libc, so while it is on the build host system, ldd
will
show you the build host libc. Once you move it to the target system, ldd
will
automatically find the system libc there.
If this is not what you want, I would suggest to
1) not use CMAKE_INSTALL_RPATH_USE_LINK_PATH when cross compiling
2) set CMAKE_INSTALL_RPATH explicitely to the directories you want on the
target platform
What you're saying really makes sense. I'll give it a try. Thanks again for
all your help.
Adolfo
Alex
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Adolfo Rodríguez Tsouroukdissian
Robotics engineer
PAL ROBOTICS S.L
http://www.pal-robotics.com
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09
___
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] fortran flags in a c++ linked executable
Elena, Try to compile and link by hand. For example - write one CPP, one F90, then compile them with flags you want and link them with flags you want. After you find out, what you need, you may start experimenting with CMake flags. gmake VERBOSE=1 can help you alot to see what is happening during compilation and linking. Denis Thank you for your patience. I now have this set via set( CMAKE_EXE_LINKER_FLAGS -mbig-endian ) However, this does not seem to affect the reading of the big-endian binary file (which is in read in fortran). Perhaps I am still not setting it properly? James ___ 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] fortran flags in a c++ linked executable
Isn't that a compiler flag? You would have to specify that
at compile time, not link time.
Regards,
Arjen
On 2009-04-01 01:33, James C. Sutherland wrote:
Alin,
Thank you for your patience. I now have this set via
set( CMAKE_EXE_LINKER_FLAGS -mbig-endian )
However, this does not seem to affect the reading of the big-endian
binary file (which is in read in fortran). Perhaps I am still not
setting it properly?
James
On Mar 31, 2009, at 1:30 PM, Alin M Elena wrote:
man g++
add_definition is a preprocessor directive not linking flag
Alin
--
__
If the Universities will not study useless subjects, who will?
G. F. FitzGerald, Nature, 45/46, 392 (1892)
__
Mr Alin M ELENA
Irish Centre for High-End Computing -- www.ichec.ie http://www.ichec.ie
The Design Tower, Trinity Technology Enterprise Campus
Grand Canal Quay, Dublin 2, Ireland
Tel: +353 (0) 1 5241608 ext 29
Fax: +353 (0) 1 7645845
http://alin.elenaworld.net
alin.el...@ichec.ie mailto:alin.el...@ichec.ie
alinm.el...@gmail.com mailto:alinm.el...@gmail.com
__
On Tuesday 31 March 2009 17:27:39 you wrote:
Should not the flag be passed to the linker? So in this case the
linker flags are read from the c++ compiler flags?
I tried adding
add_definitions( ${CMAKE_Fortran_FLAGS} )
But the g++ linker complained about an unrecognized option (the -
fconvert=big-endian option).
When linking, I pull in the gfortran library,
target_link_libraries( readx gfortran )
When creating the fortran object files the appropriate flags are
passed, but the g++ compiler has no notion of endian-ness...
Any other ideas?
___
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
Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable.
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The
Netherlands, Commercial Registration Number 41146461, is not liable in any way
whatsoever for consequences and/or damages resulting from the improper,
incomplete and untimely dispatch, receipt and/or content of this e-mail.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Xcode generator
Hi All,
I have a problem with compiled CUDA source code and the Xcode
generator. The behavior can be demonstrated using this simple example:
I have a file called main.template:
#include iostream
int main()
{
std::cout Hello world!\n;
return 0;
}
my CMakeLists.txt looks like this:
project( XcodeTest )
cmake_minimum_required( VERSION 2.6 )
get_filename_component( TEMPLATE main.template ABSOLUTE )
add_custom_command( OUTPUT main.cpp
COMMAND cp
ARGS ${TEMPLATE} main.cpp
DEPENDS main.template
)
set_source_files_properties( main.cpp PROPERTIES GENERATED TRUE )
add_executable( program main.cpp main.template )
As you can see, when a rebuild is done, the template gets copied to
main.cpp which in turn is compiled and linked. This works great in
Xcode. But, whenever I change the template, i.e. my CUDA sources, I
have to run the build twice to make the changes appear in the test
program. It looks like the custom command is executed during the first
run and the generated file gets compiled in the second.
Has anyone ever seen this?
cheers,
Tobias
___
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] fortran flags in a c++ linked executable
James C. Sutherland wrote: Let me try this again. I have a f90 subroutine that performs file IO. I would like to link that with a C++ driver. If I use a fortran driver, I am able to set the binary format via set( CMAKE_Fortran_FLAGS -fconvert=big-endian ) This results in file IO in big-endian format. When using the C++ driver, (linking with g++), I cannot get things working properly. I have tried various compiler settings: add_definitions( -Xlinker -fconvert=big-endian ) # links, but does not affect endian-ness add_definitions( -Wl,-fconvert=big-endian ) # links, but does not affect endian-ness add_definitions( -mbig-endian ) # does not work - link fails with unrecognized flag None of these result in an executable that properly handles big-endian file formats. The system I am compiling on is a little-endian system (intel Mac) with gfortran 4.4.0 and g++ 4.0.1. Hi James, In general you can set linker options for your executable as follows: SET_TARGET_PROPERTIES(ProgramName PROPERTIES LINK_FLAGS -Wl,--fconvert=big-endian) As far as I know, --fconvert=big-endian is a compiler option not a linker option, so this will not work. But I don't think that this will succeed, because the man page of gfortran contains the following comment: -fconvert=conversion This option has an effect only when used in the main program. The CONVERT specifier and the GFORTRAN_CONVERT_UNIT environment variable override the default specified by -fconvert. As you probably don't have a Fortran main program, setting this option will have no effect. In the end, you will have to find out, how to set the conversion mode to use, if you don't have a Fortran main program. I assume that you will have to explicitly select a library to link to your program. Anyway, this is not a CMake issue. Hope this helps, Martin Virus checked by G DATA AntiVirus Version: AVB 19.282 from 31.03.2009 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] make make test make all
I couldn't resist the subject - my question is whether given some number of executables that are produced during a build, and some tests that later run using those, is there a straightforward way to have cmake (globally) always run make all before make test? Right now, with my current setup, if someone does make test without doing make all, the executables aren't found and they complain that things are broken (ie. not like they are used to). I'd rather prefer to not add custom targets or add_dependencies for all the individual tests if at all possible. thanks b. ___ 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] make make test make all
On Wed, Apr 1, 2009 at 12:47 PM, Bill O'Hara billtoh...@gmail.com wrote: I couldn't resist the subject - my question is whether given some number of executables that are produced during a build, and some tests that later run using those, is there a straightforward way to have cmake (globally) always run make all before make test? Right now, with my current setup, if someone does make test without doing make all, the executables aren't found and they complain that things are broken (ie. not like they are used to). I'd rather prefer to not add custom targets or add_dependencies for all the individual tests if at all possible. There was a discussion of this last week on the mailing list. http://www.cmake.org/pipermail/cmake/2009-March/thread.html#27887 John ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Fwd: make make test make all
There was a discussion of this last week on the mailing list. http://www.cmake.org/pipermail/cmake/2009-March/thread.html#27887 Also a bug report http://www.vtk.org/Bug/view.php?id=8774 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] solution folder
Is it possible in cmake to add solution folder in the generated visual studio solution thaks ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Fwd: solution folder
On Wed, Apr 1, 2009 at 1:34 PM, Nicolas Slythe (Intern)
nicolas.sly...@autodesk.com wrote:
Is it possible in cmake to add solution folder in the generated visual
studio solution
Isn't that ${PROJECT_BINARY_DIR}
--
John M. Drescher
___
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] autoheader
On Tue, Mar 31, 2009 at 3:27 PM, BRM bm_witn...@yahoo.com wrote:
Notice my original API suggestion - the project controls its own header - just
not the list of available items.
So essentially:
1) Cmake runs, finds packages, builds list
2) user add extra items to list
3) header generated
Noting from my original API example:
cmake_autoheader(C, path/to/cmake/autoheader_output1.h some_other_package )
cmake_autoheader(C, path/to/cmake/autoheader_output2.h some_other_package )
cmake_autoheader(C, path/to/cmake/autoheader_output3.h some_other_package )
Adding in the filtering as I suggested:
cmake_autoheader(C, path/to/cmake/autoheader_output1.h some_other_package
[filter 1])
cmake_autoheader(C, path/to/cmake/autoheader_output2.h some_other_package
[filter 2])
cmake_autoheader(C, path/to/cmake/autoheader_output3.h some_other_package
[filter 3])
Each project could easily define its own header (or headers) - there would be
no limit. And it should probably generate the header immediately based on when
the cmake_autoheader() is called, based on the state of the list at that point.
(I think it would be too complex to push it until the end of the file; but that
might be possible too.)
As to resolving between sub-projects, it would likely be good to internally
register a scope for the variables - the scope being the path from the root
CMakeLists.txt to the present one. If a parent, sibling, or child node wanted
to access a different node's variables, it would have to do so using the
filters and explicitly name the path. This would be easy to do in the filters
as the project designer would know the paths between the projects. The output
in the header would be no different - just the #define HAS_VARIABLE no matter
what node it was in.
So take the following:
src/CMakeLists.txt
src/subdir1/CMakeLists.txt
src/subdir1/subdir1a/CMakeLists.txt
src/subdir2/CMakeLists.txt
src/subdir1/CMakeLists.txt would be able to access its variables with no
scoping whatsoever. But to access a variable in src/CMakeLists.txt, it would
have to provide explicit scoping to it via a filter when generating the
autoheader via cmake_autoheader(). It would need to do the same to access
variables in either src/subdir1/subdir1a/CMakeLists.txt and
src/subdir2/CMakeLists.txt.
However, I would only guarantee that the cmake_autoheader() would be able to
get what is in the global list at the time it is run. So
src/subdir1/CMakeLists.txt would likely not be able to see
src/subdir2/CMakeLists.txt's variables, or all of the variables in
src/CMakeLists.txt (as some may be defined after src/subdir1/CMakeLists.txt is
run). It could control what it or its child nodes know though - based on when
it makes the call, but that can be left to the project designer.
Quote Philip Lowman phi...@yhbt.com:
===
Why not simply make cmake_autoheader() reentrant (and I assume a command) and
have it process last? This would solve one of your critiques of not having to
pass lists around. You could also eliminate the need to specify the filename
everywhere and a logical name could be used. It would presumably call the
functionality provided by configure_file() internally per logical name.
cmake_autoheader(INIT myconfig ${CMAKE_CURRENT_BINARY_DIR}/config.h)
cmake_autoheader(CONFIG myconfig
... stuff like we already have ...)
add_subdirectory(foo)
foo/ = cmake_autoheader(CONFIG myconfig
... add additional stuff)
Ben's Reply:
=
Only issue I can see with it being re-entrant (good idea overall) is that you
would be limited to having one file. Otherwise love it.
Quote Philip Lowman phi...@yhbt.com:
===
I hear you on trying to automatically add #cmakedefine variables to a list.
Ultimately I think Bill and co. are right that trying to retrofit
find_package() and any other place where you may (or may not) want to add a
#cmakedefine like check_function_exists, etc. is simply going to be too
complex. Also as for find_package() someone out there will certainly want
HAVE_OPENSCENEGRAPH to work instead of HAVE_OSG or HAVE_OSG2 or whatever. You
seem to like HAS_FOO, others probably prefer USE_FOO or HAVE_FOO_H. Clearly
we're never all going to agree.
Even if it was easy to do this there is another risk. Users won't care to
really define which variables they want #cmakedefined or not so they'll simply
define everything. Then you'll end up with what GNU autotools seems to do now
which is to create a ginormous config.h.in file for pretty much anything you
type in configure.ac. Trying to wade through which of these #defines are
actually necessary or not is an annoying exercise in the use of grep. Also
many of these #defines are superfluous on modern compilers/platforms.
Ben's Reply:
=
If you noticed my original API example, I had the Find function use its own
variable for defining the variable. I honestly could care less what
[CMake] continuous builds best practices?
Is there a best practices for kicking off Continuous builds using ctest? What do most people do for this? I know about svn hooks but I don't want multiple builds spawned for each commit, just the latest commit when the machines are idle. Also, I have multiple build machines on various operating systems. -- Philip Lowman ___ 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 get cmake command line after running ccmake
Yes, this is the feature that I'm looking for. I want to use ccmake for the initial configuration and then automatically translate that configuration into an equivalent command line for cmake (all on *nix system), which I can then put into an automated build script (sh or bash) that I can run on other systems (via ssh, macports, etc.). I'll try your diff suggestion James. Thanks, Darren On Mon, Mar 30, 2009 at 9:23 PM, James Bigler jamesbig...@gmail.com wrote: On Mon, Mar 30, 2009 at 9:27 PM, Philip Lowman phi...@yhbt.com wrote: On Mon, Mar 30, 2009 at 4:09 PM, Darren Weber darren.weber.li...@gmail.com wrote: Can we automatically extract an equivalent cmake command line after running ccmake? Take care, Darren If you're using the Makefile generator you can simply type make edit_cache in your build tree after you've initially generated. If this doesn't solve your problem you likely can look towards finding the source directory in the CMakeCache.txt file. I think he wants to run ccmake and configure things how he likes and then get a command line that would produce the equivalent configuration without ccmake (i.e. cmake -DSOMEVAR:BOOL=ON -DPATH_TO_SOME_EXE:PATH=/path/to/some.exe). This way, he can configure a new build in one easy step. I don't believe this feature exists, though you could get something close by doing the following. 1. Create a build directory and run cmake path to source. This is your default configuration. 2. Copy CMakeCache.txt some where safe. 3. Configure you system with ccmake. 4. Diff the old CMakeCache.txt and the new CMakeCache.txt. The differences should show you a superset of the options you will need (depending on if some options are automatically generated when you turn others on). James ___ 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 ___ 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 get cmake command line after running ccmake
Yes, this is the feature that I'm looking for. I want to use ccmake for the initial configuration and then automatically translate that configuration into an equivalent command line for cmake (all on *nix system), which I can then put into an automated build script (sh or bash) that I can run on other systems (via ssh or whatever). I'll try your diff suggestion James. Thanks, Darren On Mon, Mar 30, 2009 at 9:23 PM, James Bigler jamesbig...@gmail.com wrote: On Mon, Mar 30, 2009 at 9:27 PM, Philip Lowman phi...@yhbt.com wrote: On Mon, Mar 30, 2009 at 4:09 PM, Darren Weber darren.weber.li...@gmail.com wrote: Can we automatically extract an equivalent cmake command line after running ccmake? Take care, Darren If you're using the Makefile generator you can simply type make edit_cache in your build tree after you've initially generated. If this doesn't solve your problem you likely can look towards finding the source directory in the CMakeCache.txt file. I think he wants to run ccmake and configure things how he likes and then get a command line that would produce the equivalent configuration without ccmake (i.e. cmake -DSOMEVAR:BOOL=ON -DPATH_TO_SOME_EXE:PATH=/path/to/some.exe). This way, he can configure a new build in one easy step. I don't believe this feature exists, though you could get something close by doing the following. 1. Create a build directory and run cmake path to source. This is your default configuration. 2. Copy CMakeCache.txt some where safe. 3. Configure you system with ccmake. 4. Diff the old CMakeCache.txt and the new CMakeCache.txt. The differences should show you a superset of the options you will need (depending on if some options are automatically generated when you turn others on). James ___ 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 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] link_libraries() deprecated. Why?
Hi all, I was wondering why the link_libraries() command has been deprecated. Commands like include_directories() and link_directories() which have the same scope have not been deprecated. I think that link_libraries() has its virtues too. My reason for asking this, is that I wonder what's the proper way to add a library to *all* targets in a project; for example, a logging library or a threads library. Here, link_libraries() provides IMHO a much cleaner solution, than target_link_libraries(). The latter requires me to keep track of the globally used library in a variable that must be passed around; and for each target I must explicitly specify its dependency on this library by using target_link_libraries(). Or, am I missing something, and is there a cleaner way to do this, without using a deprecated feature? Best regards, Marcel Loose. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Seeing CMakeLists.txt in IDEs (Visual Studio, Xcode)
I have a minor problem, though maybe this is a CMake bug. I wanted to see my CMakeLists.txt in Xcode so I could try to edit them in the IDE. So I've been manually adding CMakeLists.txt to my targets (ADD_LIBRARY, etc). I tend to miss things like top level CMakeLists.txt when lists are common to multiple targets. I then moved over to Visual Studio testing and discovered that CMakeLists.txt were automatically being added for me. So instead, all my targets seemed to have 2 CMakeLists.txt links right next to each other, both pointing to the same file which looks weird. So I'm wondering what the correct thing to do is and if I need to file a bug. Thanks, Eric ___ 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] Xcode generator
As you can see, when a rebuild is done, the template gets copied to main.cpp which in turn is compiled and linked. This works great in Xcode. But, whenever I change the template, i.e. my CUDA sources, I have to run the build twice to make the changes appear in the test program. It looks like the custom command is executed during the first run and the generated file gets compiled in the second. Has anyone ever seen this? I haven't had your exact problem, but I think I have encountered something similar which required me to build twice to capture changes. I think there is a bug in the CMake bootstrap. Since you have a good reproducible test case, would, I would encourage you to file a bug report on this in the CMake bug tracker. Thanks, Eric ___ 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_libraries() deprecated. Why?
On Wed, Apr 1, 2009 at 5:35 PM, Marcel Loose lo...@astron.nl wrote:
Hi all,
I was wondering why the link_libraries() command has been deprecated.
Commands like include_directories() and link_directories() which have the
same scope have not been deprecated. I think that link_libraries() has its
virtues too.
My reason for asking this, is that I wonder what's the proper way to add a
library to *all* targets in a project; for example, a logging library or a
threads library. Here, link_libraries() provides IMHO a much cleaner
solution, than target_link_libraries(). The latter requires me to keep track
of the globally used library in a variable that must be passed around; and
for each target I must explicitly specify its dependency on this library by
using target_link_libraries().
Or, am I missing something, and is there a cleaner way to do this, without
using a deprecated feature?
Often I have seen people write functions to help with this especially if you
have more than one common library.
function(link_target_against_common_libs _target)
target_link_libraries(${_target} ${WHATEVER_LIBRARY})
endfunction()
Another approach is if you have a low level library as part of your codebase
that everyone depends upon you can simply make it dependent on your
threading or logging libraries and anyone that is dependent against it will
automatically link against the threading or logging library.
--
Philip Lowman
___
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 Can I compile the following code on Windows with CMake?
On Mon, Mar 30, 2009 at 7:48 PM, Kermit Mei kermit@gmail.com wrote:
I want to add the following program as a part of my project, but I don't
konw how to manage it in CMake.
I worte the following in my CMakeLists.txt:
FIND_LIBRARY(LIBWMM winmm)
ADD_EXECUTABLE(aplay WIN32 aplay.c)
TARGET_LINK_LIBRARIES(aplay ${LIBWMM})
But it always told me that undefined reference to 'playsou...@12' .
How can I solve it?
Double check to make sure that winmm (and the MinGW implementation of this
library) has that function in it. You might also consider asking for help
on a MinGW forum?
By the way, what's the meaning of -mwindows? Can I also use strip in
CMake for optimization?
This sounds like a MinGW thing. If Google doesn't yield the answer you
should check with the MinGW mailing lists. Also double check with make
VERBOSE=1 to make sure that you're actually passing -lwinmm and it's finding
the library.
It looks like CPack has an option to strip binaries.
http://www.cmake.org/Wiki/CMake:Packaging_With_CPack
--
Philip Lowman
___
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] autoheader
On Wed, Apr 1, 2009 at 2:13 PM, BRM bm_witn...@yahoo.com wrote:
Simplicity is best, and I think the simplest solution means not having
user's bloat their CMakeFiles.txt - it should be part of the system provided
by CMake.
Let me list the reasons I'm opposed to your proposal of *automatically*
having find modules list preprocessor definitions.
1. Just because you call find_package() on a package doesn't mean that you
need a preprocessor definition in your code in order to use it. The same is
true of checking to see if a function or header file exists (perhaps just to
throw an error if it doesn't).
It is very often these days that one intends merely to build a plugin by
using a 3rd party package in which case adding a global #define via a
config.h file is not wanted at all.
2. There is no guarantee that the find module will pick the proper
preprocessor definitions to define if a package is present. The reason why
is that these vary from project to project. Some people may use:
#ifdef HAVE_CURL
while others use
#ifdef USE_CURL
See Google, this is a very common phenomenon. There often is no consistent
agreement on preprocessor definitions to include/exclude additional source
code from being built.
3. It would seem that laying the responsibility of calling
cmake_autoheader() on the find module would limit you to one config.h header
file without really complicating the API.
So basically, it might not always be right and it might not always be
wanted. Not to mention the work involved in retrofitting the find modules
so that they #define the proper stuff.
1) Do we want to have a reliable naming convention for variables in the API?
2) Do we want to have reliable, cross-project names for the same project in
the API?
3) Do we want to make it easy for users to use the API?
Ultimately I think letting people add whatever preprocessor definitions they
want is the easiest way to solve the problem. The alternative is making
them remove automatically created preprocessor definitions from config.h
they don't want which seems very backwards to me.
Perhaps find_package(), check_library_exists(), etc. could be augmented to
optionally support the autoheader api? Regardless of whether or not this
happens, as Bill pointed out a user could always use a wrapper function
themselves where it makes sense to.
function(find_package_add_define _pkg)
find_package(${_pkg} ${ARGN})
cmake_autodefine(... HAVE_${_pkg}) # or what-have-you
endfunction()
--
Philip Lowman
___
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
