[cmake-developers] [CMake 0012110]: CodeBlocks project with full paths
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12110 == Reported By:oreja80 Assigned To: == Project:CMake Issue ID: 12110 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-04-20 06:28 EDT Last Modified: 2011-04-20 06:28 EDT == Summary:CodeBlocks project with full paths Description: I noticed that when switching from cmake 2.8.2 to 2.8.4, C::B projects show the full tree (from / on Linux) instead of starting from the project base. Steps to Reproduce: run cmake with -GCodeBlocks - Unix Makefiles with 2.8.2, open the project to see how it looked. Then replace 2.8.2 - 2.8.4, run the cmake again, and compare the results. Additional Information: I have posted this question first to the C::B forum. They replied that the fact that the paths in the xml file .cbp that is generated should be relative paths. After opening the project and clicking save, some of the paths do change to relative, but not all. == Issue History Date ModifiedUsername FieldChange == 2011-04-20 06:28 oreja80New Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Qt Bundle Utilities/Packaging
On Wednesday, April 20, 2011 05:18:41 am Mike McQuaid wrote: On 7 April 2011 18:17, Clinton Stimpson clin...@elemtech.com wrote: I think you should *always* write out a qt.conf file. The Qt libraries have hardcoded paths (used if there is no qt.conf file) and if the target machine has a Qt installation at the same location as the build machine, it could get the target machines plugins instead. These plugins are tied to a specific version and configuration of Qt, so they cannot be mixed. On Mac, the problem of a missing qt.conf is immediate on the build machine. In my experience this isn't needed on Mac and can/should instead be set by calling QApplication::setLibraryPaths or embedding qt.conf as a resource on Windows or Linux. I think on both of those platforms it's fairly unpleasant to just have a plain-text qt.conf file sitting in your binary directory. But not everyone does it that way. And from these docs: http://doc.qt.nokia.com/latest/qt-conf.html it seems possible to embed a qt.conf on Mac as well. I don't think it is correct to switch the behavior with an if(APPLE). How about letting the user pass in a flag? I think we should add QT_LIBRARY_DIR to fixup_bundle()'s dirs all the time. This isn't always necessary and is hard to get at install time. My solution still allows this to be done optionally if it can't be found. Sure, it may not always be necessary, but we don't know the Qt setups on the users machines, and the script should be robust. For example, we have a windows machine that does multiple nightly builds from scripts (both 32 and 64 bit). The developer on that machine can use a different Qt version. Also, it has both 32 and 64 bit Qt dlls in the path, and one of them is first in the path. If QT_LIBRARY_DIR/QT_BINARY_DIR isn't used with BundleUtilities, it doesn't get done right. Have you thought about letting the user supply a list of their own plugins and having the function add the default Qt plugins to that list (or a set of plugins based on the QT_USE_* variables)? I'd rather install only the minimal amount of plugins rather than automatically install them all. Most applications using e.g. QtSQL will only use a single plugin, not multiple. Yeah, for QtSQL, that is usually the case. How does the user call install_qt4_app() with a list of plugins? BTW, I was asking about users's *own* plugins that they built, which could have their own non-Qt dependencies. But it looks like install_qt4_app() can handle that. Also, one frequent complaint with using these functions is the user having to do install(CODE ) and worry about escaping quotes and dollar signs. Do you think this would be a good time to address that? Have added a install_qt4_app which should deal with this. Thanks. Patch attached for something actually tested and working for two internal projects. And what's the SET( BU_CHMOD_BUNDLE_ITEMS TRUE ) for? Also, you said something before about using the install plugins macros, but this patch doesn't use them. I'm curious why that didn't work out. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Better Eclipse CDT support
On Wednesday 20 April 2011, Oliver Buchtala wrote: Hi Alex, ... What would you expect there ? Some structure that gives me acces to the sources of the targets. I suppose, you try to achieve this with sub-projects, but it does not work properly in my case. How does it work not properly ? Don't you have project() calls or are they not created ? Is your build dir a subdir of the source dir ? Yes. In this case the link to CMAKE_SOURCE_DIR is not generated, otherwise there should be a link [Source directory]. It's a pity that Eclipse has such problems with out-of-source builds. Ok - that is the problem with my setting then. It's really Eclipse which would need some fixing here. It would just have to accept that the base source directory is not always the directory where the project file is located, but can be a directory specified in the project file. This would help a lot. See attachment: 2.4.8 CDT4 MinGW generator on CMake/Example, Eclipse Helios, CDT 7.0.2 All in all, this is not what a developer used to CDT wants to see ;) What I want to do: - generate projects for each target (like in VC generators) Can you please explain ? Do you want a separate build tree for each project ? Or just separate Eclipse project files for each target ? For each target. Like in MSVC. Are you sure people will want to import that many projects or can they be grouped in some way in a superproject ? Eclipse users are used to a flat multi-project layout. They use working sets to group projects. Actually, I am personally not the greatest friend of complete flat hierarchies - but this is actually the eclipse way. You may have a look at large Eclipse java projects, e.g. Eclipse itself. Importing all projects in a directory is a one-clicker. Though, they should not be nested for that feature to work. Hmm. So this would be one build tree (i.e. one CMakeCache.txt with a global Makefile-structure), and Eclipse-projects for each target, and a working set which groups these projects together ? Yep. One Make tree. And 'light-weight' eclipse projects as views on targets. Don't know. Maybe. Can you provide a screenshot of how this looks like ? Or maybe create a clone of the cmake git tree on gitorious or github and try to implement it there ? I have a working impl will push it on github tommorrow :) Cool :-) Or, how about instead of creating one project per target one project per project() call ? Hmm. Is it typical to have many project calls? I don't know whether it's typical. It also depends what you consider many ;-) I usually use project() for a somehow self-contained part of the build tree. I'll ping you tomorrow (after work). I won't be back before Monday. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Post-Build commands on custom targets are always executed?
Am 19.04.2011 16:10, schrieb David Cole:
On Mon, Apr 18, 2011 at 11:22 PM, Michael Hertling
mhertl...@online.de mailto:mhertl...@online.de wrote:
On 04/19/2011 02:17 AM, Oliver Buchtala wrote:
Am 18.04.2011 06:58, schrieb Michael Hertling:
On 04/16/2011 12:05 AM, Oliver Buchtala wrote:
Am 15.04.2011 23:48, schrieb Michael Hertling:
On 04/15/2011 11:22 PM, Oliver Buchtala wrote:
Hi,
I observe that a custom command attached to a custom target as
POST-BUILD is launched on every build.
Is that true? or is it a misconfiguration on my side?
Bye,
Oliver
A custom target is always out of date, i.e. it is always
rebuilt when
it is visited - as a prerequisite of another target or due to
the ALL
clause, e.g., and since the target has been rebuilt, each
associated
POST_BUILD custom command is rerun. Thus, the behaviour you
observed
is correct, expected and reasonable, IMO.
Regards,
Michael
Yep. That's reasonable.
Do have a suggestion how to get around a rerun of the post-build?
Prevent the custom target from being visited, i.e. from being
checked
if it's up to date since it will be found to be out of date, so the
immediately associated commands - if any - are run as well as the
associated POST_BUILD custom commands.
Or how would you do a post-build after custom-target without
being run
when custom-target actually did nothing,
What do you mean with a custom target that actually did
nothing? Not
visited or no own commands? In the former case, the associated
custom
commands are not run, of course, but in the latter case, it
does not
matter if there are immediately associated commands or not
since the
target will be considered as out of date and
rebuilt-without-op, and
its POST_BUILD custom commands will be run. In other words: A
custom
target - even without own commands - is not good for preventing its
custom commands from being run when the custom target is visited.
i.e., custom target depends on custom command that did nothing?
The same holds for this kind of dependency, i.e. the visited custom
target will be rebuilt regardless whether the prerequisite custom
command did do something or not, or do you still talk about the
custom-command-associated-with-custom-target dependency?
Alright. Then, no way to get what i want with custom targets.
I am asking, as I try to improve behavior with
UseJave.cmake::add_jar
(on stage::next) which creates a custom target.
E.g., after building the jar I want to copy the java archive into
another destination (not install).
OK, I see; in fact, this would be a good job for a POST_BUILD custom
command associated with the custom target. Thus, as you can't prevent
the custom command from being run on behalf of the custom target, you
should set up the command to do nothing if there's actually nothing to
do. E.g., you might use ${CMAKE_COMMAND} -E copy_if_different ... to
copy the updated-or-not-updated jar file, so the custom command is as
cheap as possible, although it always runs when the custom target is
examined. Moreover, ${CMAKE_COMMAND} -P ... and the IF() command's
EXISTS and IS_NEWER_THAN clauses possibly provide further approaches
w.r.t. your concern.
Regards,
Michael
As long as java support is on a weak basis (i.e., not built-in),
this
won't change...
Thank you for your help!
Bye,
Oliver
___
Powered by www.kitware.com http://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
This is how I would do it:
Why wouldn't you simply add *another* custom target that depends on
the output of a custom command, and then make that custom command's
output be your copy of the jar file, and then make the custom command
depend on the real jar file?
Then, the custom target would run always -- but it has no command,
so there's never anything to do, but when the custom command's depends
are out of date, it will execute, and the jar file will be copied...
If you have something that depends on a file, then it should nearly
always be a custom command.
Custom targets are best at simply collecting related custom commands
in. I've never found them that useful with commands associated
directly in the add_custom_target call.
HTH,
David
Re: [CMake] RPATH on Mac
Hi,
Yes I have used the references you send me i.e. the link to the QtTest project.
This project is nevertheless simpler than mine since only an
executable is generated - no libraries (excepted those taken from Qt).
If my understanding is correct - FIXUP_BUNDLE shall be used after the
bundle is created. Shall it be called for each artifacts i.e each
library and executable or only for the main executable.
My problem is that I got an fixup_bundle: not a valid bundle error
message when using FIXUP_BUNDLE.
I have created a very simplified project here if one wants to have a
look to my problem: https://github.com/galleon/CMakeOSX
Best Regards
Guillaume
On Tue, Apr 19, 2011 at 9:10 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
Use the SHARED library type for your shared library and MODULE for your
plugin.
Have you downloaded the Qt example from the Wiki? It shows what you need to
do. The terse summary of how some of us do it is this:
Write a configurable *.cmake.in file that gets configured at cmake time. An
install rule is also added that executes the .cmake file at install time.
inside this file is cmake code to over ride some CMake functions for your use
and then include the BundleUtilities. And then call fixup_bundle. The tail
end of my own file looks like this:
# -- Run the BundleUtilities cmake code
include(BundleUtilities)
fixup_bundle(${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app
# Plugins to Install
${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/imageformats/libqgif.dylib;${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/imageformats/libqjpeg.dylib;${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/imageformats/libqtiff.dylib;${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/libEMMPMPlugin_debug.plugin;${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/libCrossCorrelationPlugin_debug.plugin
# Directories to Search for Libraries
/Users/mjackson/Workspace/IPHelper/Build/Bin;/Users/mjackson/Workspace/IPHelper/Build/Bin
)
This is for a Qt based project where I need some of the Qt plugins for image
loading and I have produced my own plugins that need to get copied into the
application bundle. Note that this will get called at INSTALL time NOT at
build time. You should have code in your main executable that looks for the
plugins in a few locations so your executable will work from both the build
directory and the installed location. Again, if you happen to be working with
Qt I can share some code that I use.
If you take a look at
http://scm.bluequartz.net/support-libraries/cmp/trees/master there are some
Macros (cmpCMakeMacros.cmake) that I use in my project. There is also the
example configured file in the OSX_Tools directory (CompleteBundle.cmake.in).
The cmp project is just a collection of CMake code that I use over and over
in all my projects so I just made a Git module out of it and I use it as a
git submodule in all my projects.
___
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
On Apr 19, 2011, at 11:21 AM, tog wrote:
Hi Mike
Thanks for this very helpful answer.
I am nevertheless still facing few problems. My project contains:
- a shared library
- an executable using the shared lib
- a plugin lib (loaded using dylib)
I have modified my exec target to be
ADD_EXECUTABLE(main MACOSX_BUNDLE main.cpp sub.cpp)
then I have something like
INSTALL(TARGETS main BUNDLE DESTINATION Applications RUNTIME)
the make install does create Application.app and add the main exec.
Fir the lib I am facing 2 problems:
1- I don't understand how to add them to the bundle. They are both
created using:
ADD_LIBRARY(foo ${EXAMPLE_LIBRARY_TYPE} foo.cpp)
EXAMPLE_LIBRARY_TYPE=SHARED
INSTALL(TARGETS foo
RUNTIME DESTINATION ${EXAMPLE_INSTALL_LIB_DIR} COMPONENT
RuntimeLibraries
LIBRARY DESTINATION ${EXAMPLE_INSTALL_LIB_DIR} COMPONENT
RuntimeLibraries
ARCHIVE DESTINATION ${EXAMPLE_INSTALL_LIB_DIR} COMPONENT
Development
nothing is added to the app.
2- According to the doc. For a library loaded at runtime the doc
suggests to use MODULE but I end up having this error. Is that
supported on Mac
Linking CXX shared module libplugin.so
cd /Users/alleon/PROJECTS/example_build/plugin /Applications/CMake
2.8-4.app/Contents/bin/cmake -E cmake_link_script
CMakeFiles/plugin.dir/link.txt --verbose=1
/usr/bin/c++ -bundle -Wl,-headerpad_max_install_names
-compatibility_version 1.0.0 -current_version 1.2.3 -o
libplugin.1.2.3.so CMakeFiles/plugin.dir/plugin.cpp.o
i686-apple-darwin10-g++-4.2.1: -compatibility_version only allowed
with -dynamiclib
make[2]: ***
Re: [CMake] BundleUtilities (was RPATH on Mac)
Some small progress after using INSTALL(CODE ...) but still an error.
(Small) code is still there https://github.com/galleon/CMakeOSX for
those interested.
Any idea what is going wrong ?
Best Regards
Guillaume
-- 4/8: copying '/Users/alleon/PROJECTS/CMakeOSX_build/foo/libfoo.1.dylib'
-- fixup_bundle: fixing...
-- 5/8: fixing up '/Users/alleon/PROJECTS/CMakeOSX_build/plugin/libplugin.so'
exe_dotapp_dir/='/tmp/example/main.app/'
item_substring='/Users/alleon/PROJECTS'
resolved_embedded_item='/Users/alleon/PROJECTS/CMakeOSX_build/plugin/libplugin.so'
Install or copy the item into the bundle before calling fixup_bundle
CMake Error at /Applications/CMake
2.8-4.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:557
(message):
cannot fixup an item that is not in the bundle...
Call Stack (most recent call first):
/Applications/CMake
2.8-4.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:645
(fixup_bundle_item)
example/cmake_install.cmake:44 (fixup_bundle)
cmake_install.cmake:35 (INCLUDE)
make: *** [install] Error 1
On Wed, Apr 20, 2011 at 12:03 PM, tog guillaume.all...@gmail.com wrote:
Hi,
Yes I have used the references you send me i.e. the link to the QtTest
project.
This project is nevertheless simpler than mine since only an
executable is generated - no libraries (excepted those taken from Qt).
If my understanding is correct - FIXUP_BUNDLE shall be used after the
bundle is created. Shall it be called for each artifacts i.e each
library and executable or only for the main executable.
My problem is that I got an fixup_bundle: not a valid bundle error
message when using FIXUP_BUNDLE.
I have created a very simplified project here if one wants to have a
look to my problem: https://github.com/galleon/CMakeOSX
Best Regards
Guillaume
On Tue, Apr 19, 2011 at 9:10 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
Use the SHARED library type for your shared library and MODULE for your
plugin.
Have you downloaded the Qt example from the Wiki? It shows what you need to
do. The terse summary of how some of us do it is this:
Write a configurable *.cmake.in file that gets configured at cmake time. An
install rule is also added that executes the .cmake file at install time.
inside this file is cmake code to over ride some CMake functions for your
use and then include the BundleUtilities. And then call fixup_bundle. The
tail end of my own file looks like this:
# -- Run the BundleUtilities cmake code
include(BundleUtilities)
fixup_bundle(${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app
# Plugins to Install
${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/imageformats/libqgif.dylib;${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/imageformats/libqjpeg.dylib;${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/imageformats/libqtiff.dylib;${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/libEMMPMPlugin_debug.plugin;${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/libCrossCorrelationPlugin_debug.plugin
# Directories to Search for Libraries
/Users/mjackson/Workspace/IPHelper/Build/Bin;/Users/mjackson/Workspace/IPHelper/Build/Bin
)
This is for a Qt based project where I need some of the Qt plugins for image
loading and I have produced my own plugins that need to get copied into the
application bundle. Note that this will get called at INSTALL time NOT at
build time. You should have code in your main executable that looks for the
plugins in a few locations so your executable will work from both the build
directory and the installed location. Again, if you happen to be working
with Qt I can share some code that I use.
If you take a look at
http://scm.bluequartz.net/support-libraries/cmp/trees/master there are some
Macros (cmpCMakeMacros.cmake) that I use in my project. There is also the
example configured file in the OSX_Tools directory (CompleteBundle.cmake.in).
The cmp project is just a collection of CMake code that I use over and
over in all my projects so I just made a Git module out of it and I use it
as a git submodule in all my projects.
___
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
On Apr 19, 2011, at 11:21 AM, tog wrote:
Hi Mike
Thanks for this very helpful answer.
I am nevertheless still facing few problems. My project contains:
- a shared library
- an executable using the shared lib
- a plugin lib (loaded using dylib)
I have modified my exec target to be
ADD_EXECUTABLE(main MACOSX_BUNDLE main.cpp sub.cpp)
then I have something like
INSTALL(TARGETS main BUNDLE DESTINATION Applications RUNTIME)
the make install does create Application.app and add the main exec.
Fir the lib I am
[CMake] Changing compiler
I am trying to build ITK with a non-system-standard compiler. I did so by running: ccmake ../../src/ITK/ -DCMAKE_CXX_COMPILER=/home/doriad/src/gcc-4.5.2/bin/gcc/g++ However, I get: --- CMake Error at /usr/share/cmake/Modules/CMakeTestCXXCompiler.cmake:45 (MESSAGE): The C++ compiler /home/doriad/src/gcc-4.5.2/bin/gcc/g++ is not able to compile a simple test program. It fails with the following output: Change Dir: /home/doriad/bin/ITK/CMakeFiles/CMakeTmp Run Build Command:/usr/bin/gmake cmTryCompileExec/fast /usr/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build gmake[1]: Entering directory `/home/doriad/bin/ITK/CMakeFiles/CMakeTmp' --- This is indeed the correct path for the compiler: [doriad@daviddesktop ~]$ ~/src/gcc-4.5.2/bin/gcc/g++ g++: no input files I tried creating a fresh build directory and nothing changed. Any suggestions of what else to do to use this compiler? Thanks, David ___ 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] Properly Detecting Win64
On Tue, Apr 19, 2011 at 5:44 PM, James Bigler jamesbig...@gmail.com wrote:
On Tue, Apr 12, 2011 at 2:24 PM, Bill Hoffman bill.hoff...@kitware.comwrote:
On 4/12/2011 4:13 PM, David Cole wrote:
Does somebody have reproducible steps to get to the point where
CMAKE_SIZEOF_VOID_P disappears??
I've never seen that...
How many times do you have to re-configure before you start seeing this
behavior? That sounds like something is just really wrong somewhere, and
it would be a good thing to track down exactly what that is.
This variable is stored in this file:
CMakeFiles/CMakeCCompiler.cmake
It should not go away.
-Bill
I just had this happen to one of my colleagues with a fresh build
directory. When I looked into CMakeCCompiler.cmake this is what I found:
# Save compiler ABI information.
SET(CMAKE_C_SIZEOF_DATA_PTR )
SET(CMAKE_C_COMPILER_ABI )
IF(CMAKE_C_SIZEOF_DATA_PTR)
SET(CMAKE_SIZEOF_VOID_P ${CMAKE_C_SIZEOF_DATA_PTR})
ENDIF(CMAKE_C_SIZEOF_DATA_PTR)
For whatever reason CMAKE_C_SIZEOF_DATA_PTR is empty.
What could cause this to happen? Is there perhaps a race condition or some
other failure when CMake detects this value?
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
If it is a race condition that simply occurs sometimes, sproadically then
we should be able to reproduce this by writing a script that tries to
configure a project over and over again into a clean directory.
But I'm not convinced it's as simple as that. There must be something
happening (or some condition on certain machines/platforms/compilers) that
triggers it... otherwise, we'd see this on the CMake dashboard results
sometimes, wouldn't we?
What compiler/generator are you using in this instance?
Does it repeat with a fresh build directory on this project in this
environment? Or does it go away with a new fresh build?
Is the project that demonstrates this behavior public? (Can I try it
here...?)
Thanks,
David
___
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] BundleUtilities (was RPATH on Mac)
The error message tells you what to do:
* Install or copy the item into the bundle before calling fixup_bundle*
That means that libplugin.so must be underneath /tmp/example/main.app
before you call fixup_bundle. (Because it's a plugin, it will not appear in
any file's otool -L output, so it has to be installed first in the bundle
before it can be fixed up...)
On Wed, Apr 20, 2011 at 6:54 AM, tog guillaume.all...@gmail.com wrote:
Some small progress after using INSTALL(CODE ...) but still an error.
(Small) code is still there https://github.com/galleon/CMakeOSX for
those interested.
Any idea what is going wrong ?
Best Regards
Guillaume
-- 4/8: copying '/Users/alleon/PROJECTS/CMakeOSX_build/foo/libfoo.1.dylib'
-- fixup_bundle: fixing...
-- 5/8: fixing up
'/Users/alleon/PROJECTS/CMakeOSX_build/plugin/libplugin.so'
exe_dotapp_dir/='/tmp/example/main.app/'
item_substring='/Users/alleon/PROJECTS'
resolved_embedded_item='/Users/alleon/PROJECTS/CMakeOSX_build/plugin/libplugin.so'
Install or copy the item into the bundle before calling fixup_bundle
CMake Error at /Applications/CMake
2.8-4.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:557
(message):
cannot fixup an item that is not in the bundle...
Call Stack (most recent call first):
/Applications/CMake
2.8-4.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:645
(fixup_bundle_item)
example/cmake_install.cmake:44 (fixup_bundle)
cmake_install.cmake:35 (INCLUDE)
make: *** [install] Error 1
On Wed, Apr 20, 2011 at 12:03 PM, tog guillaume.all...@gmail.com wrote:
Hi,
Yes I have used the references you send me i.e. the link to the QtTest
project.
This project is nevertheless simpler than mine since only an
executable is generated - no libraries (excepted those taken from Qt).
If my understanding is correct - FIXUP_BUNDLE shall be used after the
bundle is created. Shall it be called for each artifacts i.e each
library and executable or only for the main executable.
My problem is that I got an fixup_bundle: not a valid bundle error
message when using FIXUP_BUNDLE.
I have created a very simplified project here if one wants to have a
look to my problem: https://github.com/galleon/CMakeOSX
Best Regards
Guillaume
On Tue, Apr 19, 2011 at 9:10 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
Use the SHARED library type for your shared library and MODULE for
your plugin.
Have you downloaded the Qt example from the Wiki? It shows what you need
to do. The terse summary of how some of us do it is this:
Write a configurable *.cmake.in file that gets configured at cmake
time. An install rule is also added that executes the .cmake file at install
time. inside this file is cmake code to over ride some CMake functions for
your use and then include the BundleUtilities. And then call fixup_bundle.
The tail end of my own file looks like this:
# -- Run the BundleUtilities cmake code
include(BundleUtilities)
fixup_bundle(${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app
# Plugins to Install
${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/imageformats/libqgif.dylib;${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/imageformats/libqjpeg.dylib;${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/imageformats/libqtiff.dylib;${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/libEMMPMPlugin_debug.plugin;${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/libCrossCorrelationPlugin_debug.plugin
# Directories to Search for Libraries
/Users/mjackson/Workspace/IPHelper/Build/Bin;/Users/mjackson/Workspace/IPHelper/Build/Bin
)
This is for a Qt based project where I need some of the Qt plugins for
image loading and I have produced my own plugins that need to get copied
into the application bundle. Note that this will get called at INSTALL time
NOT at build time. You should have code in your main executable that looks
for the plugins in a few locations so your executable will work from both
the build directory and the installed location. Again, if you happen to be
working with Qt I can share some code that I use.
If you take a look at
http://scm.bluequartz.net/support-libraries/cmp/trees/master there are
some Macros (cmpCMakeMacros.cmake) that I use in my project. There is also
the example configured file in the OSX_Tools directory (
CompleteBundle.cmake.in).
The cmp project is just a collection of CMake code that I use over and
over in all my projects so I just made a Git module out of it and I use it
as a git submodule in all my projects.
___
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
On Apr 19, 2011, at 11:21 AM, tog wrote:
Hi Mike
Thanks
Re: [CMake] Changing compiler
If you are setting the CXX compiler, you should also probably be setting the C compiler. I always use environment variables to do this: export CC=/home/doriad/src/gcc-4.5.2/bin/gcc/gcc export CXX=/home/doriad/src/gcc-4.5.2/bin/gcc/g++ ccmake ../../src/ITK If that still doesn't work, then inspect the contents of the file CMakeFiles/CMakeError.log to see what the actual errors are, and post them here. (CMakeFiles/CMakeOutput.log may also have relevant results in it...) HTH, David C. On Wed, Apr 20, 2011 at 7:39 AM, David Doria daviddo...@gmail.com wrote: I am trying to build ITK with a non-system-standard compiler. I did so by running: ccmake ../../src/ITK/ -DCMAKE_CXX_COMPILER=/home/doriad/src/gcc-4.5.2/bin/gcc/g++ However, I get: --- CMake Error at /usr/share/cmake/Modules/CMakeTestCXXCompiler.cmake:45 (MESSAGE): The C++ compiler /home/doriad/src/gcc-4.5.2/bin/gcc/g++ is not able to compile a simple test program. It fails with the following output: Change Dir: /home/doriad/bin/ITK/CMakeFiles/CMakeTmp Run Build Command:/usr/bin/gmake cmTryCompileExec/fast /usr/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryCompileExec.dir/build gmake[1]: Entering directory `/home/doriad/bin/ITK/CMakeFiles/CMakeTmp' --- This is indeed the correct path for the compiler: [doriad@daviddesktop ~]$ ~/src/gcc-4.5.2/bin/gcc/g++ g++: no input files I tried creating a fresh build directory and nothing changed. Any suggestions of what else to do to use this compiler? Thanks, David ___ 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] Changing compiler
On Wed, Apr 20, 2011 at 9:04 AM, David Cole david.c...@kitware.com wrote: If you are setting the CXX compiler, you should also probably be setting the C compiler. I always use environment variables to do this: export CC=/home/doriad/src/gcc-4.5.2/bin/gcc/gcc export CXX=/home/doriad/src/gcc-4.5.2/bin/gcc/g++ ccmake ../../src/ITK If that still doesn't work, then inspect the contents of the file CMakeFiles/CMakeError.log to see what the actual errors are, and post them here. (CMakeFiles/CMakeOutput.log may also have relevant results in it...) HTH, David C. Hm, so there is no 'gcc' executable after I built gcc. Gcc's configure says: The following languages will be built: c,c++,fortran,java,objc. So I'm assuming it should be there? I tried setting the ITK C compiler to g++ as well, but no dice. In CMakeFiles/CMakeError.log of course it says: CMakeCCompilerId.c:2:3: error: #error A C++ compiler has been selected for C. The executables that were built are: [doriad@daviddesktop gcc]$ find . -executable -type f ./as ./cc1-dummy ./jcf-dump ./cc1 ./jvgenmain ./gcj ./config.status ./lto-wrapper ./cc1plus-dummy ./cc1plus ./cc1obj-dummy ./gcov ./nm ./cpp ./f951 ./xgcc ./cc1obj ./gfortran ./collect2 ./collect-ld ./jc1 ./g++ ./gcov-dump Any thoughts? Thanks, David ___ 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] Changing compiler
On Wed, Apr 20, 2011 at 9:43 AM, David Doria daviddo...@gmail.com wrote: On Wed, Apr 20, 2011 at 9:04 AM, David Cole david.c...@kitware.com wrote: If you are setting the CXX compiler, you should also probably be setting the C compiler. I always use environment variables to do this: export CC=/home/doriad/src/gcc-4.5.2/bin/gcc/gcc export CXX=/home/doriad/src/gcc-4.5.2/bin/gcc/g++ ccmake ../../src/ITK If that still doesn't work, then inspect the contents of the file CMakeFiles/CMakeError.log to see what the actual errors are, and post them here. (CMakeFiles/CMakeOutput.log may also have relevant results in it...) HTH, David C. Hm, so there is no 'gcc' executable after I built gcc. Gcc's configure says: The following languages will be built: c,c++,fortran,java,objc. So I'm assuming it should be there? I tried setting the ITK C compiler to g++ as well, but no dice. In CMakeFiles/CMakeError.log of course it says: CMakeCCompilerId.c:2:3: error: #error A C++ compiler has been selected for C. The executables that were built are: [doriad@daviddesktop gcc]$ find . -executable -type f ./as ./cc1-dummy ./jcf-dump ./cc1 ./jvgenmain ./gcj ./config.status ./lto-wrapper ./cc1plus-dummy ./cc1plus ./cc1obj-dummy ./gcov ./nm ./cpp ./f951 ./xgcc ./cc1obj ./gfortran ./collect2 ./collect-ld ./jc1 ./g++ ./gcov-dump Any thoughts? Thanks, David Sounds like you must have gotten errors when you built gcc... Pore through the log of what happened during the gcc build maybe? Are you building gcc from source, or using some package manager to build it for you? (MacPorts, something else?) ___ 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] Properly Detecting Win64
On Apr 20, 2011, at 8:55 AM, David Cole wrote:
On Tue, Apr 19, 2011 at 5:44 PM, James Bigler jamesbig...@gmail.com wrote:
On Tue, Apr 12, 2011 at 2:24 PM, Bill Hoffman bill.hoff...@kitware.com
wrote:
On 4/12/2011 4:13 PM, David Cole wrote:
Does somebody have reproducible steps to get to the point where
CMAKE_SIZEOF_VOID_P disappears??
I've never seen that...
How many times do you have to re-configure before you start seeing this
behavior? That sounds like something is just really wrong somewhere, and
it would be a good thing to track down exactly what that is.
This variable is stored in this file:
CMakeFiles/CMakeCCompiler.cmake
It should not go away.
-Bill
I just had this happen to one of my colleagues with a fresh build directory.
When I looked into CMakeCCompiler.cmake this is what I found:
# Save compiler ABI information.
SET(CMAKE_C_SIZEOF_DATA_PTR )
SET(CMAKE_C_COMPILER_ABI )
IF(CMAKE_C_SIZEOF_DATA_PTR)
SET(CMAKE_SIZEOF_VOID_P ${CMAKE_C_SIZEOF_DATA_PTR})
ENDIF(CMAKE_C_SIZEOF_DATA_PTR)
For whatever reason CMAKE_C_SIZEOF_DATA_PTR is empty.
What could cause this to happen? Is there perhaps a race condition or some
other failure when CMake detects this value?
James
If it is a race condition that simply occurs sometimes, sproadically then
we should be able to reproduce this by writing a script that tries to
configure a project over and over again into a clean directory.
But I'm not convinced it's as simple as that. There must be something
happening (or some condition on certain machines/platforms/compilers) that
triggers it... otherwise, we'd see this on the CMake dashboard results
sometimes, wouldn't we?
What compiler/generator are you using in this instance?
Does it repeat with a fresh build directory on this project in this
environment? Or does it go away with a new fresh build?
Is the project that demonstrates this behavior public? (Can I try it here...?)
Thanks,
David
I have a small project (http://scm.bluequartz.net/eim/emmpm) that I can
reproduce on. If you do a checkout you will need to do a git clone --recursive
due to the use of git submodules. It also depends on libTiff. This is what I do
to reproduce the issue.
On Windows 7 x64 (Ultimate in my case) running from a MSVC Command Prompt x64 I
invoke cmake-gui.exe and configure the project for Visual Studio 9 2008 x64.
Configure and then generate. Close CMake-GUi.exe. Out in Windows explorer
navigate to the build directory and delete EVERYTHING except CMakeCache.txt. I
then run cmake.exe from the build directory from the same command prompt as I
invoked cmake-gui.exe from. I now get the following error:
-- Generating Copy Rule for Debug DLL Library C:/Developer/x64/tiff/bin/tif
-- Generating Copy Rule for Release DLL Library C:/Developer/x64/tiff/bin/t
-- Generating Install Rule for DLL Library C:/Developer/x64/tiff/bin/tiffdl
-- Generating Install Rule for DLL Library C:/Developer/x64/tiff/bin/tiffdl
-- CMAKE_SIZEOF_VOID_P:
CMake Warning at Resources/CPack/PackageProject.cmake:53 (if):
given arguments:
EQUAL 8
Unknown arguments specified
Call Stack (most recent call first):
CMakeLists.txt:149 (include)
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/mjackson/Workspace/emmpm/x64
And here is the cmake code that causes the issues:
if ( ${CMAKE_SIZEOF_VOID_P} EQUAL 8)
set(CPACK_PACKAGE_FILE_NAME
${PROJECT_NAME}-${${CMP_PROJECT_NAME}_VERSION}-Win64)
else()
set(CPACK_PACKAGE_FILE_NAME
${PROJECT_NAME}-${${CMP_PROJECT_NAME}_VERSION}-Win32)
endif()
Hope that helps
___
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
___
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] BundleUtilities (was RPATH on Mac)
Well I thought that the BUNDLE line in my INSTALL command would take
care of that. Actually it is the case for the other 2 libs.
What is wrong with that one ?
I guess I am missing something with those plugin libraries ...
ADD_LIBRARY(plugin MODULE plugin.cpp)
INSTALL(TARGETS plugin
BUNDLE DESTINATION . COMPONENT Runtime
RUNTIME DESTINATION ${EXAMPLE_INSTALL_PLUGIN_LIB_DIR}
COMPONENT RuntimeLibraries
LIBRARY DESTINATION ${EXAMPLE_INSTALL_PLUGIN_LIB_DIR}
COMPONENT RuntimeLibraries
ARCHIVE DESTINATION ${EXAMPLE_INSTALL_PLUGIN_LIB_DIR}
COMPONENT Development
)
On Wed, Apr 20, 2011 at 6:30 PM, David Cole david.c...@kitware.com wrote:
The error message tells you what to do:
Install or copy the item into the bundle before calling fixup_bundle
That means that libplugin.so must be underneath /tmp/example/main.app
before you call fixup_bundle. (Because it's a plugin, it will not appear in
any file's otool -L output, so it has to be installed first in the bundle
before it can be fixed up...)
On Wed, Apr 20, 2011 at 6:54 AM, tog guillaume.all...@gmail.com wrote:
Some small progress after using INSTALL(CODE ...) but still an error.
(Small) code is still there https://github.com/galleon/CMakeOSX for
those interested.
Any idea what is going wrong ?
Best Regards
Guillaume
-- 4/8: copying '/Users/alleon/PROJECTS/CMakeOSX_build/foo/libfoo.1.dylib'
-- fixup_bundle: fixing...
-- 5/8: fixing up
'/Users/alleon/PROJECTS/CMakeOSX_build/plugin/libplugin.so'
exe_dotapp_dir/='/tmp/example/main.app/'
item_substring='/Users/alleon/PROJECTS'
resolved_embedded_item='/Users/alleon/PROJECTS/CMakeOSX_build/plugin/libplugin.so'
Install or copy the item into the bundle before calling fixup_bundle
CMake Error at /Applications/CMake
2.8-4.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:557
(message):
cannot fixup an item that is not in the bundle...
Call Stack (most recent call first):
/Applications/CMake
2.8-4.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:645
(fixup_bundle_item)
example/cmake_install.cmake:44 (fixup_bundle)
cmake_install.cmake:35 (INCLUDE)
make: *** [install] Error 1
On Wed, Apr 20, 2011 at 12:03 PM, tog guillaume.all...@gmail.com wrote:
Hi,
Yes I have used the references you send me i.e. the link to the QtTest
project.
This project is nevertheless simpler than mine since only an
executable is generated - no libraries (excepted those taken from Qt).
If my understanding is correct - FIXUP_BUNDLE shall be used after the
bundle is created. Shall it be called for each artifacts i.e each
library and executable or only for the main executable.
My problem is that I got an fixup_bundle: not a valid bundle error
message when using FIXUP_BUNDLE.
I have created a very simplified project here if one wants to have a
look to my problem: https://github.com/galleon/CMakeOSX
Best Regards
Guillaume
On Tue, Apr 19, 2011 at 9:10 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
Use the SHARED library type for your shared library and MODULE for
your plugin.
Have you downloaded the Qt example from the Wiki? It shows what you
need to do. The terse summary of how some of us do it is this:
Write a configurable *.cmake.in file that gets configured at cmake
time. An install rule is also added that executes the .cmake file at
install
time. inside this file is cmake code to over ride some CMake functions for
your use and then include the BundleUtilities. And then call
fixup_bundle.
The tail end of my own file looks like this:
# -- Run the BundleUtilities cmake code
include(BundleUtilities)
fixup_bundle(${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app
# Plugins to Install
${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/imageformats/libqgif.dylib;${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/imageformats/libqjpeg.dylib;${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/imageformats/libqtiff.dylib;${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/libEMMPMPlugin_debug.plugin;${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app/Contents/plugins/libCrossCorrelationPlugin_debug.plugin
# Directories to Search for Libraries
/Users/mjackson/Workspace/IPHelper/Build/Bin;/Users/mjackson/Workspace/IPHelper/Build/Bin
)
This is for a Qt based project where I need some of the Qt plugins for
image loading and I have produced my own plugins that need to get copied
into the application bundle. Note that this will get called at INSTALL
time
NOT at build time. You should have code in your main executable that looks
for the plugins in a few locations so your executable will work from both
the build directory and the installed location. Again, if you happen to be
working with Qt I can share some code that I use.
If you take a look at
Re: [CMake] Post-Build commands on custom targets are always executed?
On 04/20/2011 08:16 AM, Oliver Buchtala wrote:
Am 19.04.2011 16:10, schrieb David Cole:
On Mon, Apr 18, 2011 at 11:22 PM, Michael Hertling
mhertl...@online.de mailto:mhertl...@online.de wrote:
On 04/19/2011 02:17 AM, Oliver Buchtala wrote:
Am 18.04.2011 06:58, schrieb Michael Hertling:
On 04/16/2011 12:05 AM, Oliver Buchtala wrote:
Am 15.04.2011 23:48, schrieb Michael Hertling:
On 04/15/2011 11:22 PM, Oliver Buchtala wrote:
Hi,
I observe that a custom command attached to a custom target as
POST-BUILD is launched on every build.
Is that true? or is it a misconfiguration on my side?
Bye,
Oliver
A custom target is always out of date, i.e. it is always
rebuilt when
it is visited - as a prerequisite of another target or due to
the ALL
clause, e.g., and since the target has been rebuilt, each
associated
POST_BUILD custom command is rerun. Thus, the behaviour you
observed
is correct, expected and reasonable, IMO.
Regards,
Michael
Yep. That's reasonable.
Do have a suggestion how to get around a rerun of the post-build?
Prevent the custom target from being visited, i.e. from being
checked
if it's up to date since it will be found to be out of date, so the
immediately associated commands - if any - are run as well as the
associated POST_BUILD custom commands.
Or how would you do a post-build after custom-target without
being run
when custom-target actually did nothing,
What do you mean with a custom target that actually did
nothing? Not
visited or no own commands? In the former case, the associated
custom
commands are not run, of course, but in the latter case, it
does not
matter if there are immediately associated commands or not
since the
target will be considered as out of date and
rebuilt-without-op, and
its POST_BUILD custom commands will be run. In other words: A
custom
target - even without own commands - is not good for preventing its
custom commands from being run when the custom target is visited.
i.e., custom target depends on custom command that did nothing?
The same holds for this kind of dependency, i.e. the visited custom
target will be rebuilt regardless whether the prerequisite custom
command did do something or not, or do you still talk about the
custom-command-associated-with-custom-target dependency?
Alright. Then, no way to get what i want with custom targets.
I am asking, as I try to improve behavior with
UseJave.cmake::add_jar
(on stage::next) which creates a custom target.
E.g., after building the jar I want to copy the java archive into
another destination (not install).
OK, I see; in fact, this would be a good job for a POST_BUILD custom
command associated with the custom target. Thus, as you can't prevent
the custom command from being run on behalf of the custom target, you
should set up the command to do nothing if there's actually nothing to
do. E.g., you might use ${CMAKE_COMMAND} -E copy_if_different ... to
copy the updated-or-not-updated jar file, so the custom command is as
cheap as possible, although it always runs when the custom target is
examined. Moreover, ${CMAKE_COMMAND} -P ... and the IF() command's
EXISTS and IS_NEWER_THAN clauses possibly provide further approaches
w.r.t. your concern.
Regards,
Michael
As long as java support is on a weak basis (i.e., not built-in),
this
won't change...
Thank you for your help!
Bye,
Oliver
This is how I would do it:
Why wouldn't you simply add *another* custom target that depends on
the output of a custom command, and then make that custom command's
output be your copy of the jar file, and then make the custom command
depend on the real jar file?
Then, the custom target would run always -- but it has no command,
so there's never anything to do, but when the custom command's depends
are out of date, it will execute, and the jar file will be copied...
If you have something that depends on a file, then it should nearly
always be a custom command.
Custom targets are best at simply collecting related custom commands
in. I've never found them that useful with commands associated
directly in the add_custom_target call.
HTH,
David
Hi David,
I will go for your suggested solution in that particular case.
AFAICS, this solution is not bullet-proof. To make it work, you must
ensure that the, say, CopyJarFiles target is examined after the, say,
UpdateJarFiles target. Otherwise, the former possibly runs first, the
associated custom commands find the jar files up to date and will do
nothing, and subsequently, the UpdateJarFiles target
Re: [CMake] BundleUtilities (was RPATH on Mac)
On Wed, Apr 20, 2011 at 10:40 AM, tog guillaume.all...@gmail.com wrote:
Well I thought that the BUNDLE line in my INSTALL command would take
care of that. Actually it is the case for the other 2 libs.
The other 2 libs show up in the following output:
otool -L your_main_executable
The plugin does not.
What is wrong with that one ?
Nothing is wrong with it, but there is no link from the app to the plugin,
so fixup_bundle cannot determine that it's necessary and automatically pull
it in. The plugin, from the app's point of view, is something that may or
may not exist, and if it does, it's dynamically loaded. So you need to
install it into the bundle first, and then you need to tell fixup_bundle
about it so that it gets included in the set of fixed up libraries.
Hope this helps,
David
I guess I am missing something with those plugin libraries ...
ADD_LIBRARY(plugin MODULE plugin.cpp)
INSTALL(TARGETS plugin
BUNDLE DESTINATION . COMPONENT Runtime
RUNTIME DESTINATION ${EXAMPLE_INSTALL_PLUGIN_LIB_DIR}
COMPONENT RuntimeLibraries
LIBRARY DESTINATION ${EXAMPLE_INSTALL_PLUGIN_LIB_DIR}
COMPONENT RuntimeLibraries
ARCHIVE DESTINATION ${EXAMPLE_INSTALL_PLUGIN_LIB_DIR}
COMPONENT Development
)
On Wed, Apr 20, 2011 at 6:30 PM, David Cole david.c...@kitware.com
wrote:
The error message tells you what to do:
Install or copy the item into the bundle before calling fixup_bundle
That means that libplugin.so must be underneath /tmp/example/main.app
before you call fixup_bundle. (Because it's a plugin, it will not appear
in
any file's otool -L output, so it has to be installed first in the bundle
before it can be fixed up...)
On Wed, Apr 20, 2011 at 6:54 AM, tog guillaume.all...@gmail.com wrote:
Some small progress after using INSTALL(CODE ...) but still an error.
(Small) code is still there https://github.com/galleon/CMakeOSX for
those interested.
Any idea what is going wrong ?
Best Regards
Guillaume
-- 4/8: copying
'/Users/alleon/PROJECTS/CMakeOSX_build/foo/libfoo.1.dylib'
-- fixup_bundle: fixing...
-- 5/8: fixing up
'/Users/alleon/PROJECTS/CMakeOSX_build/plugin/libplugin.so'
exe_dotapp_dir/='/tmp/example/main.app/'
item_substring='/Users/alleon/PROJECTS'
resolved_embedded_item='/Users/alleon/PROJECTS/CMakeOSX_build/plugin/libplugin.so'
Install or copy the item into the bundle before calling fixup_bundle
CMake Error at /Applications/CMake
2.8-4.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:557
(message):
cannot fixup an item that is not in the bundle...
Call Stack (most recent call first):
/Applications/CMake
2.8-4.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:645
(fixup_bundle_item)
example/cmake_install.cmake:44 (fixup_bundle)
cmake_install.cmake:35 (INCLUDE)
make: *** [install] Error 1
On Wed, Apr 20, 2011 at 12:03 PM, tog guillaume.all...@gmail.com
wrote:
Hi,
Yes I have used the references you send me i.e. the link to the QtTest
project.
This project is nevertheless simpler than mine since only an
executable is generated - no libraries (excepted those taken from Qt).
If my understanding is correct - FIXUP_BUNDLE shall be used after the
bundle is created. Shall it be called for each artifacts i.e each
library and executable or only for the main executable.
My problem is that I got an fixup_bundle: not a valid bundle error
message when using FIXUP_BUNDLE.
I have created a very simplified project here if one wants to have a
look to my problem: https://github.com/galleon/CMakeOSX
Best Regards
Guillaume
On Tue, Apr 19, 2011 at 9:10 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
Use the SHARED library type for your shared library and MODULE
for
your plugin.
Have you downloaded the Qt example from the Wiki? It shows what you
need to do. The terse summary of how some of us do it is this:
Write a configurable *.cmake.in file that gets configured at cmake
time. An install rule is also added that executes the .cmake file at
install
time. inside this file is cmake code to over ride some CMake
functions for
your use and then include the BundleUtilities. And then call
fixup_bundle.
The tail end of my own file looks like this:
# -- Run the BundleUtilities cmake code
include(BundleUtilities)
fixup_bundle(${CMAKE_INSTALL_PREFIX}/IPHelperApp_debug.app
# Plugins to Install
Re: [CMake] BundleUtilities (was RPATH on Mac)
Yes David I fully agree with you
I am not arguing on the fact that the lib cannot be retrieved from the
exe - obviously it cannot and this is why the lib is a parameter of
fixbundle
I am just arguing that I would expect this block:
INSTALL(TARGETS plugin
BUNDLE DESTINATION . COMPONENT Runtime
to copy the lib inside the bundle directory.
Best Regards
Guillaume
On Wed, Apr 20, 2011 at 8:25 PM, David Cole david.c...@kitware.com wrote:
On Wed, Apr 20, 2011 at 10:40 AM, tog guillaume.all...@gmail.com wrote:
Well I thought that the BUNDLE line in my INSTALL command would take
care of that. Actually it is the case for the other 2 libs.
The other 2 libs show up in the following output:
otool -L your_main_executable
The plugin does not.
What is wrong with that one ?
Nothing is wrong with it, but there is no link from the app to the plugin,
so fixup_bundle cannot determine that it's necessary and automatically pull
it in. The plugin, from the app's point of view, is something that may or
may not exist, and if it does, it's dynamically loaded. So you need to
install it into the bundle first, and then you need to tell fixup_bundle
about it so that it gets included in the set of fixed up libraries.
Hope this helps,
David
I guess I am missing something with those plugin libraries ...
ADD_LIBRARY(plugin MODULE plugin.cpp)
INSTALL(TARGETS plugin
BUNDLE DESTINATION . COMPONENT Runtime
RUNTIME DESTINATION ${EXAMPLE_INSTALL_PLUGIN_LIB_DIR}
COMPONENT RuntimeLibraries
LIBRARY DESTINATION ${EXAMPLE_INSTALL_PLUGIN_LIB_DIR}
COMPONENT RuntimeLibraries
ARCHIVE DESTINATION ${EXAMPLE_INSTALL_PLUGIN_LIB_DIR}
COMPONENT Development
)
On Wed, Apr 20, 2011 at 6:30 PM, David Cole david.c...@kitware.com
wrote:
The error message tells you what to do:
Install or copy the item into the bundle before calling fixup_bundle
That means that libplugin.so must be underneath /tmp/example/main.app
before you call fixup_bundle. (Because it's a plugin, it will not appear
in
any file's otool -L output, so it has to be installed first in the
bundle
before it can be fixed up...)
On Wed, Apr 20, 2011 at 6:54 AM, tog guillaume.all...@gmail.com wrote:
Some small progress after using INSTALL(CODE ...) but still an error.
(Small) code is still there https://github.com/galleon/CMakeOSX for
those interested.
Any idea what is going wrong ?
Best Regards
Guillaume
-- 4/8: copying
'/Users/alleon/PROJECTS/CMakeOSX_build/foo/libfoo.1.dylib'
-- fixup_bundle: fixing...
-- 5/8: fixing up
'/Users/alleon/PROJECTS/CMakeOSX_build/plugin/libplugin.so'
exe_dotapp_dir/='/tmp/example/main.app/'
item_substring='/Users/alleon/PROJECTS'
resolved_embedded_item='/Users/alleon/PROJECTS/CMakeOSX_build/plugin/libplugin.so'
Install or copy the item into the bundle before calling fixup_bundle
CMake Error at /Applications/CMake
2.8-4.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:557
(message):
cannot fixup an item that is not in the bundle...
Call Stack (most recent call first):
/Applications/CMake
2.8-4.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:645
(fixup_bundle_item)
example/cmake_install.cmake:44 (fixup_bundle)
cmake_install.cmake:35 (INCLUDE)
make: *** [install] Error 1
On Wed, Apr 20, 2011 at 12:03 PM, tog guillaume.all...@gmail.com
wrote:
Hi,
Yes I have used the references you send me i.e. the link to the
QtTest
project.
This project is nevertheless simpler than mine since only an
executable is generated - no libraries (excepted those taken from
Qt).
If my understanding is correct - FIXUP_BUNDLE shall be used after the
bundle is created. Shall it be called for each artifacts i.e each
library and executable or only for the main executable.
My problem is that I got an fixup_bundle: not a valid bundle error
message when using FIXUP_BUNDLE.
I have created a very simplified project here if one wants to have a
look to my problem: https://github.com/galleon/CMakeOSX
Best Regards
Guillaume
On Tue, Apr 19, 2011 at 9:10 PM, Michael Jackson
mike.jack...@bluequartz.net wrote:
Use the SHARED library type for your shared library and MODULE
for
your plugin.
Have you downloaded the Qt example from the Wiki? It shows what you
need to do. The terse summary of how some of us do it is this:
Write a configurable *.cmake.in file that gets configured at cmake
time. An install rule is also added that executes the .cmake file at
install
time. inside this file is cmake code to over ride some CMake
functions for
your use and then include the BundleUtilities. And then call
fixup_bundle.
The tail end of my own file looks like this:
# -- Run the BundleUtilities cmake code
include(BundleUtilities)
Re: [CMake] BundleUtilities (was RPATH on Mac)
On Apr 20, 2011, at 10:55 AM, David Cole wrote: What is wrong with that one ? Nothing is wrong with it, but there is no link from the app to the plugin, so fixup_bundle cannot determine that it's necessary and automatically pull it in. The plugin, from the app's point of view, is something that may or may not exist, and if it does, it's dynamically loaded. So you need to install it into the bundle first, and then you need to tell fixup_bundle about it so that it gets included in the set of fixed up libraries. Hope this helps, David Is that the part that changed from CMake 2.8.3 to 2.8.4? I am using CMake 2.8.3 and all my code works fine but I don't think I explicitly install the plugin but rather list it (the absolute path to the built plugin) as an argument to the fixup_bundle function. Will that scheme still work under CMake 2.8.4? There are some other issues with CMake 2.8.4 with BundleUtilities and my code which is why I have not updated from 2.8.3 Mike Jackson www.bluequartz.net ___ 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] Use of ADD_CUSTOM_COMMAND
On 04/20/2011 05:40 AM, Fraser Hutchison wrote:
Hi Gib,
Try the following:
GET_TARGET_PROPERTY(FUBAR_EXE fubar LOCATION)
ADD_CUSTOM_COMMAND(TARGET fubar POST_BUILD COMMAND ${CMAKE_COMMAND} -E
copy ${FUBAR_EXE} somepath)
Cheers,
Fraser.
Don't use the obsolete LOCATION property since it might have subtle
side effects, see [1]. Instead, use the new generator expressions
ADD_CUSTOM_COMMAND(TARGET fubar POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy $TARGET_FILE:fubar somepath)
or follow the advice Michael W. has provided in the meantime.
Regards,
Michael H.
[1] http://www.mail-archive.com/cmake@cmake.org/msg33675.html
On 20/04/2011 03:31, Gib Bogle wrote:
I'm a real cmake novice, and I find the cmake documentation hard to
follow, because it assumes that you know what you're doing (and I
obviously don't) and doesn't provide examples. I simply want to add
to CMakeLists.txt an instruction to copy the executable created to
another directory. I gather that I want to use ADD_CUSTOM_COMMAND,
and naively I thought this might do it:
ADD_CUSTOM_COMMAND( TARGET fubar POST_BUILD COMMAND copy fubar.exe
somepath/fubar.exe)
but although this doesn't trigger a cmake error, it doesn't do
anything either, and doesn't even seem to change Makefile. Can
someone point me in the right direction? I'm using MinGW tools on
Windows.
Thanks
Gib
___
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] BundleUtilities (was RPATH on Mac)
On Wed, Apr 20, 2011 at 11:17 AM, Michael Jackson mike.jack...@bluequartz.net wrote: On Apr 20, 2011, at 10:55 AM, David Cole wrote: What is wrong with that one ? Nothing is wrong with it, but there is no link from the app to the plugin, so fixup_bundle cannot determine that it's necessary and automatically pull it in. The plugin, from the app's point of view, is something that may or may not exist, and if it does, it's dynamically loaded. So you need to install it into the bundle first, and then you need to tell fixup_bundle about it so that it gets included in the set of fixed up libraries. Hope this helps, David Is that the part that changed from CMake 2.8.3 to 2.8.4? I am using CMake 2.8.3 and all my code works fine but I don't think I explicitly install the plugin but rather list it (the absolute path to the built plugin) as an argument to the fixup_bundle function. Will that scheme still work under CMake 2.8.4? There are some other issues with CMake 2.8.4 with BundleUtilities and my code which is why I have not updated from 2.8.3 Mike Jackson www.bluequartz.net ___ 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 In CMake 2.8.3 and earlier, libs listed in the 2nd arg to fixup_bundle were copied into the bundle. Half the people using it considered that behavior a bug, half liked it just fine. In 2.8.4, we fixed the bug (really, transferred it to the other half of the people)... In retrospect, I never should have allowed that change to go into CMake, but there you have it: 2.8.3 and earlier copy the plugins, 2.8.4 and later do not. So: if you want a plugin inside your bundle, with CMake 2.8.4 and later, you have to copy/install the plugin into the bundle yourself before calling fixup_bundle. Sorry for the persisting confusion, David ___ 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] BundleUtilities (was RPATH on Mac)
___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio On Apr 20, 2011, at 11:25 AM, David Cole wrote: On Wed, Apr 20, 2011 at 11:17 AM, Michael Jackson mike.jack...@bluequartz.net wrote: On Apr 20, 2011, at 10:55 AM, David Cole wrote: What is wrong with that one ? Nothing is wrong with it, but there is no link from the app to the plugin, so fixup_bundle cannot determine that it's necessary and automatically pull it in. The plugin, from the app's point of view, is something that may or may not exist, and if it does, it's dynamically loaded. So you need to install it into the bundle first, and then you need to tell fixup_bundle about it so that it gets included in the set of fixed up libraries. Hope this helps, David Is that the part that changed from CMake 2.8.3 to 2.8.4? I am using CMake 2.8.3 and all my code works fine but I don't think I explicitly install the plugin but rather list it (the absolute path to the built plugin) as an argument to the fixup_bundle function. Will that scheme still work under CMake 2.8.4? There are some other issues with CMake 2.8.4 with BundleUtilities and my code which is why I have not updated from 2.8.3 Mike Jackson www.bluequartz.net In CMake 2.8.3 and earlier, libs listed in the 2nd arg to fixup_bundle were copied into the bundle. Half the people using it considered that behavior a bug, half liked it just fine. In 2.8.4, we fixed the bug (really, transferred it to the other half of the people)... In retrospect, I never should have allowed that change to go into CMake, but there you have it: 2.8.3 and earlier copy the plugins, 2.8.4 and later do not. So: if you want a plugin inside your bundle, with CMake 2.8.4 and later, you have to copy/install the plugin into the bundle yourself before calling fixup_bundle. Sorry for the persisting confusion, David So I should probably put the copy step into my configured cmake file that runs the 'fixup_bundle'? I guess an install rule with the proper path inside the app bundle should work. Isn't there an easier way? BUNDLE DESTINATION argument to the INSTALL(target.. ) should do it also correct? Thanks Mike Jackson ___ 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] Properly Detecting Win64
If it helps, I always configure from a clean directory. This script
is written in bash for cygwin, but I'm sure it would be easy enough to
do from some other script:
CMAKE=/cygdrive/C/Program\ Files\ \(x86\)/CMake\ 2.8/bin/cmake.exe
mkdir win32
(cd win32; $CMAKE -G Visual Studio 10 ..)
mkdir win64
(cd win64; $CMAKE -G Visual Studio 10 Win64 ..)
where .. is my top level directory containing a CMakelists.txt. I
have no problems then with:
IF (WIN32)
IF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
ELSE (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
ENDIF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
ENDIF (WIN32)
in my files.
Juan
On Wed, Apr 20, 2011 at 9:24 AM, Michael Jackson
mike.jack...@bluequartz.net wrote:
On Apr 20, 2011, at 8:55 AM, David Cole wrote:
On Tue, Apr 19, 2011 at 5:44 PM, James Bigler jamesbig...@gmail.com wrote:
On Tue, Apr 12, 2011 at 2:24 PM, Bill Hoffman bill.hoff...@kitware.com
wrote:
On 4/12/2011 4:13 PM, David Cole wrote:
Does somebody have reproducible steps to get to the point where
CMAKE_SIZEOF_VOID_P disappears??
I've never seen that...
How many times do you have to re-configure before you start seeing this
behavior? That sounds like something is just really wrong somewhere, and
it would be a good thing to track down exactly what that is.
This variable is stored in this file:
CMakeFiles/CMakeCCompiler.cmake
It should not go away.
-Bill
I just had this happen to one of my colleagues with a fresh build
directory. When I looked into CMakeCCompiler.cmake this is what I found:
# Save compiler ABI information.
SET(CMAKE_C_SIZEOF_DATA_PTR )
SET(CMAKE_C_COMPILER_ABI )
IF(CMAKE_C_SIZEOF_DATA_PTR)
SET(CMAKE_SIZEOF_VOID_P ${CMAKE_C_SIZEOF_DATA_PTR})
ENDIF(CMAKE_C_SIZEOF_DATA_PTR)
For whatever reason CMAKE_C_SIZEOF_DATA_PTR is empty.
What could cause this to happen? Is there perhaps a race condition or some
other failure when CMake detects this value?
James
If it is a race condition that simply occurs sometimes, sproadically then
we should be able to reproduce this by writing a script that tries to
configure a project over and over again into a clean directory.
But I'm not convinced it's as simple as that. There must be something
happening (or some condition on certain machines/platforms/compilers) that
triggers it... otherwise, we'd see this on the CMake dashboard results
sometimes, wouldn't we?
What compiler/generator are you using in this instance?
Does it repeat with a fresh build directory on this project in this
environment? Or does it go away with a new fresh build?
Is the project that demonstrates this behavior public? (Can I try it
here...?)
Thanks,
David
I have a small project (http://scm.bluequartz.net/eim/emmpm) that I can
reproduce on. If you do a checkout you will need to do a git clone
--recursive due to the use of git submodules. It also depends on libTiff.
This is what I do to reproduce the issue.
On Windows 7 x64 (Ultimate in my case) running from a MSVC Command Prompt x64
I invoke cmake-gui.exe and configure the project for Visual Studio 9 2008
x64. Configure and then generate. Close CMake-GUi.exe. Out in Windows
explorer navigate to the build directory and delete EVERYTHING except
CMakeCache.txt. I then run cmake.exe from the build directory from the same
command prompt as I invoked cmake-gui.exe from. I now get the following error:
-- Generating Copy Rule for Debug DLL Library C:/Developer/x64/tiff/bin/tif
-- Generating Copy Rule for Release DLL Library C:/Developer/x64/tiff/bin/t
-- Generating Install Rule for DLL Library C:/Developer/x64/tiff/bin/tiffdl
-- Generating Install Rule for DLL Library C:/Developer/x64/tiff/bin/tiffdl
-- CMAKE_SIZEOF_VOID_P:
CMake Warning at Resources/CPack/PackageProject.cmake:53 (if):
given arguments:
EQUAL 8
Unknown arguments specified
Call Stack (most recent call first):
CMakeLists.txt:149 (include)
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/mjackson/Workspace/emmpm/x64
And here is the cmake code that causes the issues:
if ( ${CMAKE_SIZEOF_VOID_P} EQUAL 8)
set(CPACK_PACKAGE_FILE_NAME
${PROJECT_NAME}-${${CMP_PROJECT_NAME}_VERSION}-Win64)
else()
set(CPACK_PACKAGE_FILE_NAME
${PROJECT_NAME}-${${CMP_PROJECT_NAME}_VERSION}-Win32)
endif()
Hope that helps
___
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
___
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:
Re: [CMake] Properly Detecting Win64
I normally do this also BUT sometimes I try to short circuit the process
because I just want to regenerate the Solution/Projects and not have to wait
for a complete CMake configuration which takes a really long time on some
project due to the number of tests that need to be performed. At the time this
seems like a reasonable approach, just blow away everything except the cache
and let cmake regenerate everything else. Now I know this really isn't a good
idea. So maybe a bug maybe an operator error.
___
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
On Apr 20, 2011, at 11:52 AM, j s wrote:
If it helps, I always configure from a clean directory. This script
is written in bash for cygwin, but I'm sure it would be easy enough to
do from some other script:
CMAKE=/cygdrive/C/Program\ Files\ \(x86\)/CMake\ 2.8/bin/cmake.exe
mkdir win32
(cd win32; $CMAKE -G Visual Studio 10 ..)
mkdir win64
(cd win64; $CMAKE -G Visual Studio 10 Win64 ..)
where .. is my top level directory containing a CMakelists.txt. I
have no problems then with:
IF (WIN32)
IF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
ELSE (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
ENDIF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
ENDIF (WIN32)
in my files.
Juan
On Wed, Apr 20, 2011 at 9:24 AM, Michael Jackson
mike.jack...@bluequartz.net wrote:
On Apr 20, 2011, at 8:55 AM, David Cole wrote:
On Tue, Apr 19, 2011 at 5:44 PM, James Bigler jamesbig...@gmail.com wrote:
On Tue, Apr 12, 2011 at 2:24 PM, Bill Hoffman bill.hoff...@kitware.com
wrote:
On 4/12/2011 4:13 PM, David Cole wrote:
Does somebody have reproducible steps to get to the point where
CMAKE_SIZEOF_VOID_P disappears??
I've never seen that...
How many times do you have to re-configure before you start seeing this
behavior? That sounds like something is just really wrong somewhere, and
it would be a good thing to track down exactly what that is.
This variable is stored in this file:
CMakeFiles/CMakeCCompiler.cmake
It should not go away.
-Bill
I just had this happen to one of my colleagues with a fresh build
directory. When I looked into CMakeCCompiler.cmake this is what I found:
# Save compiler ABI information.
SET(CMAKE_C_SIZEOF_DATA_PTR )
SET(CMAKE_C_COMPILER_ABI )
IF(CMAKE_C_SIZEOF_DATA_PTR)
SET(CMAKE_SIZEOF_VOID_P ${CMAKE_C_SIZEOF_DATA_PTR})
ENDIF(CMAKE_C_SIZEOF_DATA_PTR)
For whatever reason CMAKE_C_SIZEOF_DATA_PTR is empty.
What could cause this to happen? Is there perhaps a race condition or some
other failure when CMake detects this value?
James
If it is a race condition that simply occurs sometimes, sproadically then
we should be able to reproduce this by writing a script that tries to
configure a project over and over again into a clean directory.
But I'm not convinced it's as simple as that. There must be something
happening (or some condition on certain machines/platforms/compilers) that
triggers it... otherwise, we'd see this on the CMake dashboard results
sometimes, wouldn't we?
What compiler/generator are you using in this instance?
Does it repeat with a fresh build directory on this project in this
environment? Or does it go away with a new fresh build?
Is the project that demonstrates this behavior public? (Can I try it
here...?)
Thanks,
David
I have a small project (http://scm.bluequartz.net/eim/emmpm) that I can
reproduce on. If you do a checkout you will need to do a git clone
--recursive due to the use of git submodules. It also depends on libTiff.
This is what I do to reproduce the issue.
On Windows 7 x64 (Ultimate in my case) running from a MSVC Command Prompt
x64 I invoke cmake-gui.exe and configure the project for Visual Studio 9
2008 x64. Configure and then generate. Close CMake-GUi.exe. Out in Windows
explorer navigate to the build directory and delete EVERYTHING except
CMakeCache.txt. I then run cmake.exe from the build directory from the same
command prompt as I invoked cmake-gui.exe from. I now get the following
error:
-- Generating Copy Rule for Debug DLL Library C:/Developer/x64/tiff/bin/tif
-- Generating Copy Rule for Release DLL Library C:/Developer/x64/tiff/bin/t
-- Generating Install Rule for DLL Library C:/Developer/x64/tiff/bin/tiffdl
-- Generating Install Rule for DLL Library C:/Developer/x64/tiff/bin/tiffdl
-- CMAKE_SIZEOF_VOID_P:
CMake Warning at Resources/CPack/PackageProject.cmake:53 (if):
given arguments:
EQUAL 8
Unknown arguments specified
Call Stack (most recent call first):
CMakeLists.txt:149 (include)
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/mjackson/Workspace/emmpm/x64
And here is the cmake code that causes the issues:
if ( ${CMAKE_SIZEOF_VOID_P} EQUAL 8)
Re: [CMake] Properly Detecting Win64
On Wed, Apr 20, 2011 at 10:55 AM, Michael Jackson
mike.jack...@bluequartz.net wrote:
I normally do this also BUT sometimes I try to short circuit the process
because I just want to regenerate the Solution/Projects and not have to wait
for a complete CMake configuration which takes a really long time on some
project due to the number of tests that need to be performed. At the time
this seems like a reasonable approach, just blow away everything except the
cache and let cmake regenerate everything else. Now I know this really isn't
a good idea. So maybe a bug maybe an operator error.
I've always had very bad luck with the Visual Studio projects
generator, and always start from a clean directory when something in
the configuration changes. I only run the default configuration tests
and I set the paths manually for all of my dependencies, so that saves
some time.
If I am just adding a source file, I can usually get away with not
blowing everything away. However, I do close Visual Studio first,
because of issues with the cmake scripts being run by the visual
studio project. The cmake gui is typically sufficient for updating
the build directory.
Regards,
Juan
___
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
On Apr 20, 2011, at 11:52 AM, j s wrote:
If it helps, I always configure from a clean directory. This script
is written in bash for cygwin, but I'm sure it would be easy enough to
do from some other script:
CMAKE=/cygdrive/C/Program\ Files\ \(x86\)/CMake\ 2.8/bin/cmake.exe
mkdir win32
(cd win32; $CMAKE -G Visual Studio 10 ..)
mkdir win64
(cd win64; $CMAKE -G Visual Studio 10 Win64 ..)
where .. is my top level directory containing a CMakelists.txt. I
have no problems then with:
IF (WIN32)
IF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
ELSE (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
ENDIF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
ENDIF (WIN32)
in my files.
Juan
On Wed, Apr 20, 2011 at 9:24 AM, Michael Jackson
mike.jack...@bluequartz.net wrote:
On Apr 20, 2011, at 8:55 AM, David Cole wrote:
On Tue, Apr 19, 2011 at 5:44 PM, James Bigler jamesbig...@gmail.com
wrote:
On Tue, Apr 12, 2011 at 2:24 PM, Bill Hoffman bill.hoff...@kitware.com
wrote:
On 4/12/2011 4:13 PM, David Cole wrote:
Does somebody have reproducible steps to get to the point where
CMAKE_SIZEOF_VOID_P disappears??
I've never seen that...
How many times do you have to re-configure before you start seeing this
behavior? That sounds like something is just really wrong somewhere, and
it would be a good thing to track down exactly what that is.
This variable is stored in this file:
CMakeFiles/CMakeCCompiler.cmake
It should not go away.
-Bill
I just had this happen to one of my colleagues with a fresh build
directory. When I looked into CMakeCCompiler.cmake this is what I found:
# Save compiler ABI information.
SET(CMAKE_C_SIZEOF_DATA_PTR )
SET(CMAKE_C_COMPILER_ABI )
IF(CMAKE_C_SIZEOF_DATA_PTR)
SET(CMAKE_SIZEOF_VOID_P ${CMAKE_C_SIZEOF_DATA_PTR})
ENDIF(CMAKE_C_SIZEOF_DATA_PTR)
For whatever reason CMAKE_C_SIZEOF_DATA_PTR is empty.
What could cause this to happen? Is there perhaps a race condition or
some other failure when CMake detects this value?
James
If it is a race condition that simply occurs sometimes, sproadically
then we should be able to reproduce this by writing a script that tries to
configure a project over and over again into a clean directory.
But I'm not convinced it's as simple as that. There must be something
happening (or some condition on certain machines/platforms/compilers) that
triggers it... otherwise, we'd see this on the CMake dashboard results
sometimes, wouldn't we?
What compiler/generator are you using in this instance?
Does it repeat with a fresh build directory on this project in this
environment? Or does it go away with a new fresh build?
Is the project that demonstrates this behavior public? (Can I try it
here...?)
Thanks,
David
I have a small project (http://scm.bluequartz.net/eim/emmpm) that I can
reproduce on. If you do a checkout you will need to do a git clone
--recursive due to the use of git submodules. It also depends on libTiff.
This is what I do to reproduce the issue.
On Windows 7 x64 (Ultimate in my case) running from a MSVC Command Prompt
x64 I invoke cmake-gui.exe and configure the project for Visual Studio 9
2008 x64. Configure and then generate. Close CMake-GUi.exe. Out in Windows
explorer navigate to the build directory and delete EVERYTHING except
CMakeCache.txt. I then run cmake.exe from the build directory from the same
command prompt as I invoked cmake-gui.exe from. I now get the following
error:
-- Generating Copy Rule for Debug DLL Library C:/Developer/x64/tiff/bin/tif
-- Generating Copy Rule for
Re: [CMake] BundleUtilities (was RPATH on Mac)
On Wed, Apr 20, 2011 at 11:38 AM, Michael Jackson mike.jack...@bluequartz.net wrote: ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio On Apr 20, 2011, at 11:25 AM, David Cole wrote: On Wed, Apr 20, 2011 at 11:17 AM, Michael Jackson mike.jack...@bluequartz.net wrote: On Apr 20, 2011, at 10:55 AM, David Cole wrote: What is wrong with that one ? Nothing is wrong with it, but there is no link from the app to the plugin, so fixup_bundle cannot determine that it's necessary and automatically pull it in. The plugin, from the app's point of view, is something that may or may not exist, and if it does, it's dynamically loaded. So you need to install it into the bundle first, and then you need to tell fixup_bundle about it so that it gets included in the set of fixed up libraries. Hope this helps, David Is that the part that changed from CMake 2.8.3 to 2.8.4? I am using CMake 2.8.3 and all my code works fine but I don't think I explicitly install the plugin but rather list it (the absolute path to the built plugin) as an argument to the fixup_bundle function. Will that scheme still work under CMake 2.8.4? There are some other issues with CMake 2.8.4 with BundleUtilities and my code which is why I have not updated from 2.8.3 Mike Jackson www.bluequartz.net In CMake 2.8.3 and earlier, libs listed in the 2nd arg to fixup_bundle were copied into the bundle. Half the people using it considered that behavior a bug, half liked it just fine. In 2.8.4, we fixed the bug (really, transferred it to the other half of the people)... In retrospect, I never should have allowed that change to go into CMake, but there you have it: 2.8.3 and earlier copy the plugins, 2.8.4 and later do not. So: if you want a plugin inside your bundle, with CMake 2.8.4 and later, you have to copy/install the plugin into the bundle yourself before calling fixup_bundle. Sorry for the persisting confusion, David So I should probably put the copy step into my configured cmake file that runs the 'fixup_bundle'? I guess an install rule with the proper path inside the app bundle should work. Isn't there an easier way? BUNDLE DESTINATION argument to the INSTALL(target.. ) should do it also correct? Thanks Mike Jackson ___ 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 I would recommend something like this (top of my head, not actually building from this): install( TARGETS myapp BUNDLE DESTINATION . ) That should produce a directory structure in CMAKE_INSTALL_PREFIX like so: ./myapp.app/Contents/MacOS/myapp Then for the plugin, something like: install( TARGETS plugin DESTINATION myapp.app/Contents/plugins ) Which should yield: ./myapp.app/Contents/MacOS/myapp ./myapp.app/Contents/plugins/libplugin.dylib Something along those lines. And then pass the full path to libplugin.dylib to fixup_bundle. ___ 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] Properly Detecting Win64
On Wed, Apr 20, 2011 at 12:05 PM, j s j.s4...@gmail.com wrote:
On Wed, Apr 20, 2011 at 10:55 AM, Michael Jackson
mike.jack...@bluequartz.net wrote:
I normally do this also BUT sometimes I try to short circuit the process
because I just want to regenerate the Solution/Projects and not have to wait
for a complete CMake configuration which takes a really long time on some
project due to the number of tests that need to be performed. At the time
this seems like a reasonable approach, just blow away everything except the
cache and let cmake regenerate everything else. Now I know this really isn't
a good idea. So maybe a bug maybe an operator error.
I've always had very bad luck with the Visual Studio projects
generator, and always start from a clean directory when something in
the configuration changes. I only run the default configuration tests
and I set the paths manually for all of my dependencies, so that saves
some time.
If I am just adding a source file, I can usually get away with not
blowing everything away. However, I do close Visual Studio first,
because of issues with the cmake scripts being run by the visual
studio project. The cmake gui is typically sufficient for updating
the build directory.
Regards,
Juan
___
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
On Apr 20, 2011, at 11:52 AM, j s wrote:
If it helps, I always configure from a clean directory. This script
is written in bash for cygwin, but I'm sure it would be easy enough to
do from some other script:
CMAKE=/cygdrive/C/Program\ Files\ \(x86\)/CMake\ 2.8/bin/cmake.exe
mkdir win32
(cd win32; $CMAKE -G Visual Studio 10 ..)
mkdir win64
(cd win64; $CMAKE -G Visual Studio 10 Win64 ..)
where .. is my top level directory containing a CMakelists.txt. I
have no problems then with:
IF (WIN32)
IF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
ELSE (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
ENDIF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
ENDIF (WIN32)
in my files.
Juan
On Wed, Apr 20, 2011 at 9:24 AM, Michael Jackson
mike.jack...@bluequartz.net wrote:
On Apr 20, 2011, at 8:55 AM, David Cole wrote:
On Tue, Apr 19, 2011 at 5:44 PM, James Bigler jamesbig...@gmail.com
wrote:
On Tue, Apr 12, 2011 at 2:24 PM, Bill Hoffman
bill.hoff...@kitware.com wrote:
On 4/12/2011 4:13 PM, David Cole wrote:
Does somebody have reproducible steps to get to the point where
CMAKE_SIZEOF_VOID_P disappears??
I've never seen that...
How many times do you have to re-configure before you start seeing
this
behavior? That sounds like something is just really wrong somewhere,
and
it would be a good thing to track down exactly what that is.
This variable is stored in this file:
CMakeFiles/CMakeCCompiler.cmake
It should not go away.
-Bill
I just had this happen to one of my colleagues with a fresh build
directory. When I looked into CMakeCCompiler.cmake this is what I found:
# Save compiler ABI information.
SET(CMAKE_C_SIZEOF_DATA_PTR )
SET(CMAKE_C_COMPILER_ABI )
IF(CMAKE_C_SIZEOF_DATA_PTR)
SET(CMAKE_SIZEOF_VOID_P ${CMAKE_C_SIZEOF_DATA_PTR})
ENDIF(CMAKE_C_SIZEOF_DATA_PTR)
For whatever reason CMAKE_C_SIZEOF_DATA_PTR is empty.
What could cause this to happen? Is there perhaps a race condition or
some other failure when CMake detects this value?
James
If it is a race condition that simply occurs sometimes, sproadically
then we should be able to reproduce this by writing a script that tries to
configure a project over and over again into a clean directory.
But I'm not convinced it's as simple as that. There must be something
happening (or some condition on certain machines/platforms/compilers) that
triggers it... otherwise, we'd see this on the CMake dashboard results
sometimes, wouldn't we?
What compiler/generator are you using in this instance?
Does it repeat with a fresh build directory on this project in this
environment? Or does it go away with a new fresh build?
Is the project that demonstrates this behavior public? (Can I try it
here...?)
Thanks,
David
I have a small project (http://scm.bluequartz.net/eim/emmpm) that I
can reproduce on. If you do a checkout you will need to do a git clone
--recursive due to the use of git submodules. It also depends on libTiff.
This is what I do to reproduce the issue.
On Windows 7 x64 (Ultimate in my case) running from a MSVC Command
Prompt x64 I invoke cmake-gui.exe and configure the project for Visual
Studio 9 2008 x64. Configure and then generate. Close CMake-GUi.exe. Out in
Windows explorer navigate to the build directory and delete EVERYTHING
except CMakeCache.txt. I then run cmake.exe from the build directory from
the same command prompt as I invoked
Re: [CMake] Properly Detecting Win64
On Wed, Apr 20, 2011 at 10:23 AM, David Cole david.c...@kitware.com wrote:
On Wed, Apr 20, 2011 at 12:05 PM, j s j.s4...@gmail.com wrote:
On Wed, Apr 20, 2011 at 10:55 AM, Michael Jackson
mike.jack...@bluequartz.net wrote:
I normally do this also BUT sometimes I try to short circuit the process
because I just want to regenerate the Solution/Projects and not have to wait
for a complete CMake configuration which takes a really long time on some
project due to the number of tests that need to be performed. At the time
this seems like a reasonable approach, just blow away everything except the
cache and let cmake regenerate everything else. Now I know this really isn't
a good idea. So maybe a bug maybe an operator error.
I've always had very bad luck with the Visual Studio projects
generator, and always start from a clean directory when something in
the configuration changes. I only run the default configuration tests
and I set the paths manually for all of my dependencies, so that saves
some time.
If I am just adding a source file, I can usually get away with not
blowing everything away. However, I do close Visual Studio first,
because of issues with the cmake scripts being run by the visual
studio project. The cmake gui is typically sufficient for updating
the build directory.
Regards,
Juan
___
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
On Apr 20, 2011, at 11:52 AM, j s wrote:
If it helps, I always configure from a clean directory. This script
is written in bash for cygwin, but I'm sure it would be easy enough to
do from some other script:
CMAKE=/cygdrive/C/Program\ Files\ \(x86\)/CMake\ 2.8/bin/cmake.exe
mkdir win32
(cd win32; $CMAKE -G Visual Studio 10 ..)
mkdir win64
(cd win64; $CMAKE -G Visual Studio 10 Win64 ..)
where .. is my top level directory containing a CMakelists.txt. I
have no problems then with:
IF (WIN32)
IF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
ELSE (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
ENDIF (${CMAKE_SIZEOF_VOID_P} MATCHES 4)
ENDIF (WIN32)
in my files.
Juan
On Wed, Apr 20, 2011 at 9:24 AM, Michael Jackson
mike.jack...@bluequartz.net wrote:
On Apr 20, 2011, at 8:55 AM, David Cole wrote:
On Tue, Apr 19, 2011 at 5:44 PM, James Bigler jamesbig...@gmail.com
wrote:
On Tue, Apr 12, 2011 at 2:24 PM, Bill Hoffman
bill.hoff...@kitware.com wrote:
On 4/12/2011 4:13 PM, David Cole wrote:
Does somebody have reproducible steps to get to the point where
CMAKE_SIZEOF_VOID_P disappears??
I've never seen that...
How many times do you have to re-configure before you start seeing
this
behavior? That sounds like something is just really wrong somewhere,
and
it would be a good thing to track down exactly what that is.
This variable is stored in this file:
CMakeFiles/CMakeCCompiler.cmake
It should not go away.
-Bill
I just had this happen to one of my colleagues with a fresh build
directory. When I looked into CMakeCCompiler.cmake this is what I found:
# Save compiler ABI information.
SET(CMAKE_C_SIZEOF_DATA_PTR )
SET(CMAKE_C_COMPILER_ABI )
IF(CMAKE_C_SIZEOF_DATA_PTR)
SET(CMAKE_SIZEOF_VOID_P ${CMAKE_C_SIZEOF_DATA_PTR})
ENDIF(CMAKE_C_SIZEOF_DATA_PTR)
For whatever reason CMAKE_C_SIZEOF_DATA_PTR is empty.
What could cause this to happen? Is there perhaps a race condition
or some other failure when CMake detects this value?
James
If it is a race condition that simply occurs sometimes,
sproadically then we should be able to reproduce this by writing a script
that tries to configure a project over and over again into a clean
directory.
But I'm not convinced it's as simple as that. There must be something
happening (or some condition on certain machines/platforms/compilers) that
triggers it... otherwise, we'd see this on the CMake dashboard results
sometimes, wouldn't we?
What compiler/generator are you using in this instance?
Does it repeat with a fresh build directory on this project in this
environment? Or does it go away with a new fresh build?
Is the project that demonstrates this behavior public? (Can I try it
here...?)
Thanks,
David
I have a small project (http://scm.bluequartz.net/eim/emmpm) that I
can reproduce on. If you do a checkout you will need to do a git clone
--recursive due to the use of git submodules. It also depends on libTiff.
This is what I do to reproduce the issue.
On Windows 7 x64 (Ultimate in my case) running from a MSVC Command
Prompt x64 I invoke cmake-gui.exe and configure the project for Visual
Studio 9 2008 x64. Configure and then generate. Close CMake-GUi.exe. Out in
Windows explorer navigate to the build directory and delete EVERYTHING
except CMakeCache.txt. I then run cmake.exe
[CMake] Disable buffer security check in visual studio /GS-
After profiling my Visual Studio 2005 application I see that over 5% of the execution time in the Release build was spent doing buffer security checks. I found the following link for CMake support http://www.cmake.org/pipermail/cmake-commits/2008-March/003844.html however I do not understand what that buys me. There is no option that I can see in cmake-gui for disabling buffer security checks. I would expect I could add my own option for my application but that would not help itk or vtk. Thanks, 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
[CMake] sequence of cmake external project
Hello cmake users, I'm wondering if someone can clarify the sequence commands of CMake external project for me. For example, I have 2 external projects as below: ExternalProject_Add(A PREFIX A INSTALL_COMMAND [copies includes files of A to some path] ) ExternalProject_Add(B PREFIX B DEPENDS A ) Project B's target cmake has some find_path commands to look for the includes of project A, which is not available until the INSTALL_COMMAND of project A. The question is, is the INSTALL_COMMAND of A executed before the CONFIGURE step of B or after? I'm seeing some confusing behavior of what the find_path finds and suspect the answer is 'after'. Can anyone confirm if this is true, and if so what's a better solution? I cannot run something ahead of the cmake either since the downloading of A includes is done in A's download step. Thanks! ___ 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] Properly Detecting Win64 - [Semi Off Topic Reply]
Hey Dave, So here are some timings for running CMake to the point where I can actually build my project. THe hardware is an Mac Pro 8 Core (16 Thread) 2.6GHz OS X 10.6.6 box also running Windows 7 x64. On OS X I use Makefiles in combination with Eclipse as the IDE so I generate straight Makefiles. On this system my project takes 10 seconds to configure to a point where it is ready to compile. On Windows using Visual Studio 9 2008 x64 as the generator this takes 58 seconds. When you are heavy into development where the CMake files are changing a bunch and there are lots and lots of runs of CMake then yes I thought I was taking a shortcut. Unfortunately this shortcut proved to have very bad side effects and now I don't do it any more. But still, 10 seconds versus 60 Seconds can be a frustrating difference when deadlines are looming and you are needing to go faster. -- Mike Jackson www.bluequartz.net On Apr 20, 2011, at 12:23 PM, David Cole wrote: In my opinion, blowing away everything except for the CMakeCache.txt file is asking for trouble, and puts you in an invalid (or at the very least, unexpected) state. Because some of the cached values may depend on some of the stuff that was just blown away. If you're blowing everything else away, why not blow away CMakeCache.txt, too? Is the CMake configure that high a percentage of your total build time that saving a few minutes on the whole makes it worth trouble like this? However, even so, I would like to understand and track down the source and the root cause of this trouble with CMAKE_SIZEOF_VOID_P -- because its correctness is arguably very important for many projects out there. So -- if somebody has a way to reproduce this without blowing away everything except for the CMakeCache.txt, I'd still like to hear it. Thanks, David ___ 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] Disable buffer security check in visual studio /GS-
On Wed, Apr 20, 2011 at 12:55 PM, John Drescher dresche...@gmail.com wrote: After profiling my Visual Studio 2005 application I see that over 5% of the execution time in the Release build was spent doing buffer security checks. I found the following link for CMake support http://www.cmake.org/pipermail/cmake-commits/2008-March/003844.html I guess that is not the best link since its a patch to enable detecting 64 bit portability but it does show CMake identifies the option. 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
Re: [CMake] sequence of cmake external project
On Wed, Apr 20, 2011 at 12:52 PM, Yu, Daphne (SCR US) daphne...@siemens.com wrote: Hello cmake users, I’m wondering if someone can clarify the sequence commands of CMake external project for me. For example, I have 2 external projects as below: ExternalProject_Add(A PREFIX A INSTALL_COMMAND [copies includes files of A to some path] ) ExternalProject_Add(B PREFIX B DEPENDS A ) Project B’s target cmake has some find_path commands to look for the includes of project A, which is not available until the INSTALL_COMMAND of project A. The question is, is the INSTALL_COMMAND of A executed before the CONFIGURE step of B or after? I’m seeing some confusing behavior of what the find_path finds and suspect the answer is ‘after’. Can anyone confirm if this is true, and if so what’s a better solution? I cannot run something ahead of the cmake either since the downloading of A includes is done in A’s download step. Thanks! ___ 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 All steps of B occur after the last step of A. B may depend on anything that is done in any step of A. If not, it's a bug: please provide steps to reproduce the problem. HTH, David ___ 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] Properly Detecting Win64 - [Semi Off Topic Reply]
But you've blown everything else away at that point, so the *build* is a full rebuild, right? CMake configure takes 60 seconds, but how long does the full build take? On Wed, Apr 20, 2011 at 12:58 PM, Michael Jackson mike.jack...@bluequartz.net wrote: Hey Dave, So here are some timings for running CMake to the point where I can actually build my project. THe hardware is an Mac Pro 8 Core (16 Thread) 2.6GHz OS X 10.6.6 box also running Windows 7 x64. On OS X I use Makefiles in combination with Eclipse as the IDE so I generate straight Makefiles. On this system my project takes 10 seconds to configure to a point where it is ready to compile. On Windows using Visual Studio 9 2008 x64 as the generator this takes 58 seconds. When you are heavy into development where the CMake files are changing a bunch and there are lots and lots of runs of CMake then yes I thought I was taking a shortcut. Unfortunately this shortcut proved to have very bad side effects and now I don't do it any more. But still, 10 seconds versus 60 Seconds can be a frustrating difference when deadlines are looming and you are needing to go faster. -- Mike Jackson www.bluequartz.net On Apr 20, 2011, at 12:23 PM, David Cole wrote: In my opinion, blowing away everything except for the CMakeCache.txt file is asking for trouble, and puts you in an invalid (or at the very least, unexpected) state. Because some of the cached values may depend on some of the stuff that was just blown away. If you're blowing everything else away, why not blow away CMakeCache.txt, too? Is the CMake configure that high a percentage of your total build time that saving a few minutes on the whole makes it worth trouble like this? However, even so, I would like to understand and track down the source and the root cause of this trouble with CMAKE_SIZEOF_VOID_P -- because its correctness is arguably very important for many projects out there. So -- if somebody has a way to reproduce this without blowing away everything except for the CMakeCache.txt, I'd still like to hear it. Thanks, David ___ 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] Properly Detecting Win64 - [Semi Off Topic Reply]
On Wed, Apr 20, 2011 at 12:04 PM, David Cole david.c...@kitware.com wrote: But you've blown everything else away at that point, so the *build* is a full rebuild, right? CMake configure takes 60 seconds, but how long does the full build take? My guess is that CMake is invoking a lot of processes in running its tests. Creating a process on windows is very expensive. I suspect having an equivalent solution written with make in cygwin would be very slow as well. Juan On Wed, Apr 20, 2011 at 12:58 PM, Michael Jackson mike.jack...@bluequartz.net wrote: Hey Dave, So here are some timings for running CMake to the point where I can actually build my project. THe hardware is an Mac Pro 8 Core (16 Thread) 2.6GHz OS X 10.6.6 box also running Windows 7 x64. On OS X I use Makefiles in combination with Eclipse as the IDE so I generate straight Makefiles. On this system my project takes 10 seconds to configure to a point where it is ready to compile. On Windows using Visual Studio 9 2008 x64 as the generator this takes 58 seconds. When you are heavy into development where the CMake files are changing a bunch and there are lots and lots of runs of CMake then yes I thought I was taking a shortcut. Unfortunately this shortcut proved to have very bad side effects and now I don't do it any more. But still, 10 seconds versus 60 Seconds can be a frustrating difference when deadlines are looming and you are needing to go faster. -- Mike Jackson www.bluequartz.net On Apr 20, 2011, at 12:23 PM, David Cole wrote: In my opinion, blowing away everything except for the CMakeCache.txt file is asking for trouble, and puts you in an invalid (or at the very least, unexpected) state. Because some of the cached values may depend on some of the stuff that was just blown away. If you're blowing everything else away, why not blow away CMakeCache.txt, too? Is the CMake configure that high a percentage of your total build time that saving a few minutes on the whole makes it worth trouble like this? However, even so, I would like to understand and track down the source and the root cause of this trouble with CMAKE_SIZEOF_VOID_P -- because its correctness is arguably very important for many projects out there. So -- if somebody has a way to reproduce this without blowing away everything except for the CMakeCache.txt, I'd still like to hear it. Thanks, David ___ 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 ___ 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] Creating dependencies after adding an external project?
I have a project that depends on HDF5. A user can either specify an
existing installation and thus use a find_package or choose to have HDF5
built with the project. I've been using Paraview as a template to
implement this but I can't seem to get the dependencies for my project
defined correctly when it builds HDF5.
So what I'm doing is an ExternalProject_Add command like this:
ExternalProject_Add(hdf5
URL ${HDF5_url}/${HDF5_gz}
URL_MD5 ${HDF5_md5}
UPDATE_COMMAND
PREFIX ${HDF5_prefix}
CMAKE_ARGS
-DBUILD_SHARED_LIBS:Bool=OFF
-DBUILD_TESTING:Bool=OFF
-DHDF5_ENABLE_Z_LIB_SUPPORT:Bool=ON
-DZLIB_INCLUDE_DIR:STRING=${ZLIB_INCLUDE_DIR}
-DZLIB_LIBRARY:STRING=${ZLIB_LIBRARY}
-DHDF5_BUILD_HL_LIB:Bool=ON
-DHDF5_BUILD_TOOLS:Bool=ON
-DCMAKE_INSTALL_PREFIX:PATH=${HDF5_prefix}
)
and then to be consistent with the find_package logic, I define
HDF5_INCLUDE_DIR, HDF5_LIBRARIES based on the installation paths I know
eventually will exist like this
set(HDF5_LIBRARY_DIR ${HDF5_prefix}/lib)
set(HDF5_LIBRARY
${HDF5_LIBRARY_DIR}/${CMAKE_STATIC_LIBRARY_PREFIX}hdf5${CMAKE_STATIC_LIBRARY_PREFIX})
set(HDF5_HL_LIBRARY
${HDF5_LIBRARY_DIR}/${CMAKE_STATIC_LIBRARY_PREFIX}hdf5_hl${CMAKE_STATIC_LIBRARY_PREFIX})
set(HDF5_LIBRARIES ${HDF5_HL_LIBRARY};${HDF5_LIBRARY})
and then when I need to build a binary that links against HDF5, I have
in a CMakeLists.txt file
add_executable(test.x ${test_src_files})
target_link_libraries(test.x ${HDF5_LIBRARIES})
But at build time I see errors complaining about No rule to make target
path to HDF5_prefix/libhdf5.a needed for test.x. I am confused. Do I
need to do more than just define HDF5_LIBRARIES? Do I need to define
libhdf5.a as a target? How do I do that? Defining libhd5 through
add_library( .. UNKNOWN IMPORTED) call does seem right because they are
not imported.
--
Lori A. Pritchett-Sheats, PhD.
CCS-2, Computational Physics and Methods
Office: 505-665-6675
Fax: 505-665-4972
Los Alamos National Laboratory
P.O. Box 1663
MS D413
Los Alamos, NM 87544
___
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] Properly Detecting Win64 - [Semi Off Topic Reply]
On Wed, Apr 20, 2011 at 12:58 PM, j s j.s4...@gmail.com wrote: On Wed, Apr 20, 2011 at 12:04 PM, David Cole david.c...@kitware.com wrote: But you've blown everything else away at that point, so the *build* is a full rebuild, right? CMake configure takes 60 seconds, but how long does the full build take? My guess is that CMake is invoking a lot of processes in running its tests. Creating a process on windows is very expensive. I suspect having an equivalent solution written with make in cygwin would be very slow as well. I do remember now that cygwin on Windows 7 64 bit is a lot slower than Windows 7 32 bit. Perhaps you can try running some comparisons with 32 bit Windows. This is possible because I believe that Visual Studio is a 32 bit program. Juan Juan On Wed, Apr 20, 2011 at 12:58 PM, Michael Jackson mike.jack...@bluequartz.net wrote: Hey Dave, So here are some timings for running CMake to the point where I can actually build my project. THe hardware is an Mac Pro 8 Core (16 Thread) 2.6GHz OS X 10.6.6 box also running Windows 7 x64. On OS X I use Makefiles in combination with Eclipse as the IDE so I generate straight Makefiles. On this system my project takes 10 seconds to configure to a point where it is ready to compile. On Windows using Visual Studio 9 2008 x64 as the generator this takes 58 seconds. When you are heavy into development where the CMake files are changing a bunch and there are lots and lots of runs of CMake then yes I thought I was taking a shortcut. Unfortunately this shortcut proved to have very bad side effects and now I don't do it any more. But still, 10 seconds versus 60 Seconds can be a frustrating difference when deadlines are looming and you are needing to go faster. -- Mike Jackson www.bluequartz.net On Apr 20, 2011, at 12:23 PM, David Cole wrote: In my opinion, blowing away everything except for the CMakeCache.txt file is asking for trouble, and puts you in an invalid (or at the very least, unexpected) state. Because some of the cached values may depend on some of the stuff that was just blown away. If you're blowing everything else away, why not blow away CMakeCache.txt, too? Is the CMake configure that high a percentage of your total build time that saving a few minutes on the whole makes it worth trouble like this? However, even so, I would like to understand and track down the source and the root cause of this trouble with CMAKE_SIZEOF_VOID_P -- because its correctness is arguably very important for many projects out there. So -- if somebody has a way to reproduce this without blowing away everything except for the CMakeCache.txt, I'd still like to hear it. Thanks, David ___ 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 ___ 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] Creating dependencies after adding an external project?
On Wednesday 20 April 2011, Lori Pritchett-Sheats wrote:
I have a project that depends on HDF5. A user can either specify an
existing installation and thus use a find_package or choose to have HDF5
built with the project. I've been using Paraview as a template to
implement this but I can't seem to get the dependencies for my project
defined correctly when it builds HDF5.
So what I'm doing is an ExternalProject_Add command like this:
ExternalProject_Add(hdf5
URL ${HDF5_url}/${HDF5_gz}
URL_MD5 ${HDF5_md5}
UPDATE_COMMAND
PREFIX ${HDF5_prefix}
CMAKE_ARGS
-DBUILD_SHARED_LIBS:Bool=OFF
-DBUILD_TESTING:Bool=OFF
-DHDF5_ENABLE_Z_LIB_SUPPORT:Bool=ON
-DZLIB_INCLUDE_DIR:STRING=${ZLIB_INCLUDE_DIR}
-DZLIB_LIBRARY:STRING=${ZLIB_LIBRARY}
-DHDF5_BUILD_HL_LIB:Bool=ON
-DHDF5_BUILD_TOOLS:Bool=ON
-DCMAKE_INSTALL_PREFIX:PATH=${HDF5_prefix}
)
and then to be consistent with the find_package logic, I define
HDF5_INCLUDE_DIR, HDF5_LIBRARIES based on the installation paths I know
eventually will exist like this
set(HDF5_LIBRARY_DIR ${HDF5_prefix}/lib)
set(HDF5_LIBRARY
${HDF5_LIBRARY_DIR}/${CMAKE_STATIC_LIBRARY_PREFIX}hdf5${CMAKE_STATIC_LIBRA
RY_PREFIX}) set(HDF5_HL_LIBRARY
${HDF5_LIBRARY_DIR}/${CMAKE_STATIC_LIBRARY_PREFIX}hdf5_hl${CMAKE_STATIC_LI
BRARY_PREFIX})
set(HDF5_LIBRARIES ${HDF5_HL_LIBRARY};${HDF5_LIBRARY})
and then when I need to build a binary that links against HDF5, I have
in a CMakeLists.txt file
add_executable(test.x ${test_src_files})
target_link_libraries(test.x ${HDF5_LIBRARIES})
But at build time I see errors complaining about No rule to make target
path to HDF5_prefix/libhdf5.a needed for test.x. I am confused. Do I
As the hdf5 external project been built ?
If not, you have to make sure via add_dependencies() that it gets build before
the target which uses it is built.
Alex
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Use of ADD_CUSTOM_COMMAND
Quoting Michael Hertling mhertl...@online.de:
On 04/20/2011 05:40 AM, Fraser Hutchison wrote:
Hi Gib,
Try the following:
GET_TARGET_PROPERTY(FUBAR_EXE fubar LOCATION)
ADD_CUSTOM_COMMAND(TARGET fubar POST_BUILD COMMAND ${CMAKE_COMMAND} -E
copy ${FUBAR_EXE} somepath)
Cheers,
Fraser.
Don't use the obsolete LOCATION property since it might have subtle
side effects, see [1]. Instead, use the new generator expressions
ADD_CUSTOM_COMMAND(TARGET fubar POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy $TARGET_FILE:fubar somepath)
or follow the advice Michael W. has provided in the meantime.
Regards,
Michael H.
OK, I'll take your word for it :-). One line is better than two, anyway.
Thanks
Gib
This message was sent using IMP, the Internet Messaging Program.
___
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] Use of ADD_CUSTOM_COMMAND
On 04/20/2011 11:56 PM, Gib Bogle wrote:
Quoting Michael Hertling mhertl...@online.de:
On 04/20/2011 05:40 AM, Fraser Hutchison wrote:
Hi Gib,
Try the following:
GET_TARGET_PROPERTY(FUBAR_EXE fubar LOCATION)
ADD_CUSTOM_COMMAND(TARGET fubar POST_BUILD COMMAND ${CMAKE_COMMAND} -E
copy ${FUBAR_EXE} somepath)
Cheers,
Fraser.
Don't use the obsolete LOCATION property since it might have subtle
side effects, see [1]. Instead, use the new generator expressions
ADD_CUSTOM_COMMAND(TARGET fubar POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy $TARGET_FILE:fubar somepath)
or follow the advice Michael W. has provided in the meantime.
Regards,
Michael H.
Hi Michael,
I wonder if something went amiss in your post.
This command:
ADD_CUSTOM_COMMAND(TARGET threshold POST_BUILD COMMAND
${CMAKE_COMMAND} -E copy $TARGET_FILE:threshold ../bin)
gives an error:
C:\Users\Gib\LN_structure\code\thresholdmake
Linking CXX executable threshold.exe
Creating library file: libthreshold.dll.a
Access is denied.
mingw32-make[2]: *** [threshold.exe] Error 1
mingw32-make[1]: *** [CMakeFiles/threshold.dir/all] Error 2
mingw32-make: *** [all] Error 2
while this one works OK:
ADD_CUSTOM_COMMAND(TARGET threshold POST_BUILD COMMAND
${CMAKE_COMMAND} -E copy threshold.exe ../bin)
Any ideas?
Gib
Which version of CMake do you use? IIRC, the generator expressions for
custom commands have been added quite recently in 2.8.4. Moreover, if
the directory ../bin doesn't exist at the time the custom command
is run, the executable will be copied to a file named bin in the
directory .., so you need to ensure the directory ../bin does
exist, cf. FILE(MAKE_DIRECTORY ...) or cmake -E make_directory.
Besides, don't use the .. path in that way; use variables like
CMAKE_BINARY_DIR instead, i.e. ${CMAKE_BINARY_DIR}/../bin, e.g.
If the issue still persists, could you check whether the following
CMakeLists.txt file also fails on your system? It works on mine:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8.4 FATAL_ERROR)
PROJECT(GENEXP C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
ADD_CUSTOM_COMMAND(TARGET main POST_BUILD COMMAND
${CMAKE_COMMAND} -E copy $TARGET_FILE:main ${CMAKE_BINARY_DIR}/bin)
If it fails, please post [C]Make's output for further investigation.
Regards,
Michael
PS: Always reply to the ML, so others may benefit from the discussion.
___
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] parallel ctest spawning too many threads
Fellow CMake users:
I'm having a problem with one of my projects when I run 'ctest -jN'. The
problem is that after 70-90 tests, ctest decides to submit all of the
remaining tests at once (~200 tests worth). For example (actual test names
replaced to protect the innocent :-)
% ctest -j16
Test project /var/tmp/foo
Start 192: testA_2
Start 191: testB_4
Start 190: testC_3
Start 189: testD_2
Start 188: testE_4
1/279 Test #189: testD_2 . Passed
1.81 sec
Start 187: testF_3
2/279 Test #192: testA_2 . Passed
2.98 sec
3/279 Test #191: testB_4 . Passed
2.81 sec
Start 186: testG_2
Start 185: testH_4
4/279 Test #188: testE_4 . Passed
2.81 sec
5/279 Test #190: testC_3 . Passed
2.92 sec
Start 184: testI_3
Start 183: testJ_2
6/279 Test #187: testF_3 . Passed
2.02 sec
Start 182: testK_4
7/279 Test #186: testG_2 . Passed
2.44 sec
...
82/279 Test #249: testZA_2 Passed
8.46 sec
83/279 Test #245: testZB_2 Passed
3.12 sec
Start 278: testZC_4
84/279 Test #278: testZC_4 Passed
4.27 sec
Start 266: testZD_4
Start 263: testZE_4
Start 275: testZF_4
Start 270: testZG_4
Start 269: testZH_4
# ...about 190 tests started all at the same time.
Start 89: testZZA_1
Start 88: testZZB_1
^C
These tests are running under mpirun (trailing number indicates number of
cores needed for the test) and so the total load on my machine jumps to
about 400!
My tests are registered using commands similar to this:
add_test(
NAMEtestA_4
COMMAND ${MPIEXEC} ${MPIEXEC_NUMPROC_FLAG} 4
${MPIEXEC_POSTFLAGS}
$TARGET_FILE:Ut_testA_4_exe
)
set_tests_properties( testA_4
PROPERTIES PROCESSORS 4 )
Has anyone seen this 'many threads spawning' behavior for ctest (I couldn't
find anything in the bug tracker). Is there a known resolution?
Thank you,
-kt
-
Kelly (KT) Thompson
k...@lanl.gov
505.665.8090
Los Alamos National Laboratory
CCS-2, MS D409, TA-3/B-422/R-101
___
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] Use of ADD_CUSTOM_COMMAND
On 21/04/2011 11:38 a.m., Michael Hertling wrote:
On 04/20/2011 11:56 PM, Gib Bogle wrote:
Quoting Michael Hertlingmhertl...@online.de:
On 04/20/2011 05:40 AM, Fraser Hutchison wrote:
Hi Gib,
Try the following:
GET_TARGET_PROPERTY(FUBAR_EXE fubar LOCATION)
ADD_CUSTOM_COMMAND(TARGET fubar POST_BUILD COMMAND ${CMAKE_COMMAND} -E
copy ${FUBAR_EXE} somepath)
Cheers,
Fraser.
Don't use the obsolete LOCATION property since it might have subtle
side effects, see [1]. Instead, use the new generator expressions
ADD_CUSTOM_COMMAND(TARGET fubar POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy $TARGET_FILE:fubar somepath)
or follow the advice Michael W. has provided in the meantime.
Regards,
Michael H.
Hi Michael,
I wonder if something went amiss in your post.
This command:
ADD_CUSTOM_COMMAND(TARGET threshold POST_BUILD COMMAND
${CMAKE_COMMAND} -E copy $TARGET_FILE:threshold ../bin)
gives an error:
C:\Users\Gib\LN_structure\code\thresholdmake
Linking CXX executable threshold.exe
Creating library file: libthreshold.dll.a
Access is denied.
mingw32-make[2]: *** [threshold.exe] Error 1
mingw32-make[1]: *** [CMakeFiles/threshold.dir/all] Error 2
mingw32-make: *** [all] Error 2
while this one works OK:
ADD_CUSTOM_COMMAND(TARGET threshold POST_BUILD COMMAND
${CMAKE_COMMAND} -E copy threshold.exe ../bin)
Any ideas?
Gib
Which version of CMake do you use? IIRC, the generator expressions for
custom commands have been added quite recently in 2.8.4. Moreover, if
the directory ../bin doesn't exist at the time the custom command
is run, the executable will be copied to a file named bin in the
directory .., so you need to ensure the directory ../bin does
exist, cf. FILE(MAKE_DIRECTORY ...) or cmake -E make_directory.
Besides, don't use the .. path in that way; use variables like
CMAKE_BINARY_DIR instead, i.e. ${CMAKE_BINARY_DIR}/../bin, e.g.
If the issue still persists, could you check whether the following
CMakeLists.txt file also fails on your system? It works on mine:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8.4 FATAL_ERROR)
PROJECT(GENEXP C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
ADD_CUSTOM_COMMAND(TARGET main POST_BUILD COMMAND
${CMAKE_COMMAND} -E copy $TARGET_FILE:main ${CMAKE_BINARY_DIR}/bin)
If it fails, please post [C]Make's output for further investigation.
Regards,
Michael
PS: Always reply to the ML, so others may benefit from the discussion.
I'm using cmake 2.8.2, which presumably explains the failure. The directory
../bin exists (otherwise the other form of the command would have failed).
Cheers
Gib
___
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] SuperBuild whoes
Hi all I'm trying to set up a SuperBuild here. Everything works nicely the first time round I build the project. The only real problem I have is that if I change the sources of one of the sub-projects, the SuperBuild still thinks everything is up to date. Of course, this is fully explainable by the fact that the SuperBuild knows nothing about the internal dependencies of the sub-project, and since the stamp files are all there and unchanged, it thinks everything is fine. How do I get around this? Anybody got an idea? Thanks Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, master, updated. v2.8.4-391-g12377a0
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 12377a0e608aaeb03caff1fdc6630fcafd2c5cc4 (commit) from 2f50ec5f5cb13d05df0fe7e4fd9e7faf631b20b6 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=12377a0e608aaeb03caff1fdc6630fcafd2c5cc4 commit 12377a0e608aaeb03caff1fdc6630fcafd2c5cc4 Author: KWSys Robot kwro...@kitware.com AuthorDate: Thu Apr 21 00:01:22 2011 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Thu Apr 21 00:13:03 2011 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index e31662d..ac4d5a0 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 04) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 20) +SET(KWSYS_DATE_STAMP_DAY 21) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
