Re: [CMake] getting the rpath right on osx
On Monday, November 02, 2015 04:08:55 PM Andreas Pakulat wrote: > Hi, > > On Mon, Nov 2, 2015 at 2:49 PM, Boudewijn Rempt wrote: > > On Mon, 2 Nov 2015, Andreas Pakulat wrote: > > > > I think the idea of using @rpath as install name of the Qt libraries is > > > >> geared towards the usecase > >> of shipping Qt within the application bundle of the application. In that > >> case all you need is set > >> the rpath @executable_path/../Frameworks or so in the executable and thus > >> the app-bundle is > >> relocatable. In order to get that with CMake you'll likely need to use > >> the BundleUtilities, though > >> its been so long since I used those I don't know if they can handle this > >> scenario out of the box. > > > > Yes, that's what I'm trying to do -- well, I'm trying to do two > > things. One is setup a build environment where kde apps like desktoptojson > > can run, the other is creating a bundle, preferably using the same > > Qt. I got quite far by manually fixing up the applications built as part > > of kcoreaddons > > That would be fixed in kcoreaddons by extending the linker flags to include > the mentioned -Wl,-rpath,. There's no provisioning for this > inside CMake afaik since its hard for it to guess what the intention is. CMake does automatically handle this. If a library being linked has @rpath for its install ID, then CMake will insert the linker flag. This takes care of the build time rpath. And works for any library in target_link_libraries() where CMake knows its full path. A -L/-l approach does not work, but that is usually done for system libraries, in which case we normally don't care about rpaths. This kind of thing isn't handled automatically at install time, and requires the INSTALL_RPATH property to be set. > My > understanding (not a OSX expert yet here) is also that having the install > name of a framework on OSX be something like @rpath is quite unusual. Thats > usually something that users are 'patching' when they bundle their > application via install_name_tool. And thats what CMake supports doing via > the BundleUtilities module. If install rpaths are set correctly, and all copied 3rd party libraries use @rpath, there is no need for patching with install_name_tool. > > > and then manually patching up the executable inside the > > bundle to have the @executable_path/../Frameworks rpath added. But I'm > > still not sure why with a really simple example things don't work out > > of the box: I guess I had better build Qt with -norpath. > > See above, I think the way the Qt frameworks are setup when using -rpath is > simply not expected/anticipated so far by CMake (or the people maintaining > the qt5 cmake modules inside Qt). It is handled fine by CMake. If not, it would be a bug. > > However I never tried to use BundleUtilities with such a framework, maybe > they do manage to 'fixup' things for that as well. For a Qt4-based project > I'm using INSTALL_QT4_EXECUTABLE which eventually forwards to fixup_bundle > from BundleUtilities, so may be worth a try to avoid the manual steps. > > Even a Qt built with -norpath would require doing some 'manual' things to > get a all-in-one app bundle for the application (or use of > BundleUtilities), to copy things around and adjust the install and link > names in all the frameworks and executables to be related and thus make the > application relocatable. Yes, a Qt built with -norpath will require extra patching steps with install_name_tool. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Use CMAKE_MACOSX_RPATH to link a library outside build tree
On Sunday, August 23, 2015 04:46:17 AM Oleg Zhylin via CMake wrote: > Hi All, > I still need help with 0015708: Use CMAKE_MACOSX_RPATH to link a library > outside build tree - MantisBT. Could you please suggest are there any CMake > mechanisms to ensure a library outside build tree on mac is linked with > either @rpath and using hard-coded path on build machine? Either option > would actually help. > | | > | | | | | | > | 0015708: Use CMAKE_MACOSX_RPATH to link a library outside build tree - > | MantisBTThis issue is Mac OS X specific. I would like to link a library > | lib_xxx that sits outside my build tree at some arbitrary location. It > | will be at the same location in all systems. | > | > | View on www.cmake.org | Preview by Yahoo | > | > | | > > WBR ovz There is no CMake mechanism to control references when linking with external libraries. If you still want to do this, you'll need to edit the references in your binaries after linking. You'll be much better off if you modify the external libraries. For @rpath, use a command like this: or For absolute path If those external libraries have additional dependencies using @executable_path, you may also need to use "install_name_tool -change ..." Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Are CMAKE_CXX_FLAGS supposed to go on the link line?
FYI,
I also came across this discrepancy recently, and logged a bug for it.
http://www.cmake.org/Bug/view.php?id=15427
With the example provided in the bug report, I am seeing link errors under
Xcode which I do not see under Makefiles.
Clint
On Monday, March 02, 2015 07:33:38 PM Roman Bolshakov wrote:
> Apparently, command line to link executable is quite different from a
> shared library (Modules/CMakeCXXInformation.cmake):
>
> if(NOT CMAKE_CXX_LINK_EXECUTABLE)
> set(CMAKE_CXX_LINK_EXECUTABLE
> "
> -o ")
> endif()
>
>
> set(CMAKE_CXX_CREATE_SHARED_LIBRARY
> "
>
>
> -o ")
>
> CMAKE_CXX_FLAGS/CMAKE_C_FLAGS which are filled into
> don't go into a linker command for
> executable.
>
> 2015-01-22 19:11 GMT+03:00 Paul Smith :
> > I didn't get a response to the question below. I've since reproduced
> > this with a simple test case; maybe someone can let me know why this
> > difference appears and how I should handle it? I'm using cmake 3.1.0:
> >
> > Sample CMakeLists.txt:
> > $ cat >CMakeLists.txt < > cmake_minimum_required(VERSION 3.1.0)
> > project(FlagTest)
> > set(CMAKE_CXX_FLAGS -pthread)
> > add_executable(foo foo.cpp)
> > EOF
> >
> > $ echo 'int main(int argc, char**argv) { return 0; }' > foo.cpp
> >
> > On MacOSX with Xcode installed, I see the following behavior:
> > $ cmake -G Xcode . && cmake --build . 2>&1 | tee xc.out
> >
> > In the output I see that the "-pthread" flag DOES appear on the compile
> >
> > line for "foo.o", but DOES NOT appear in the link line for "foo":
> > $ grep pthread xc.out
> > /.../clang -x c++ ... -pthread ... -c /.../foo.cpp -o /.../foo.o
> >
> > This is correct for clang, which does not want -pthread on the link line
> > (unlike GCC, which wants it in both places). Now, I clean that up and
> >
> > try with the Makefile generator, and I see the following behavior:
> > $ cmake -G 'Unix Makefiles' . && cmake --build . -- VERBOSE=1 2>&1 | tee
> > mk.out clang: warning: argument unused during compilation: '-pthread'
> >
> > Now in this case we can see that the -pthread flag was added to BOTH the
> >
> > compile and the link line:
> > $ grep pthread mk.out
> > /usr/bin/c++ -pthread -o .../foo.cpp.o -c .../foo.cpp
> > /usr/bin/c++ -pthread .../foo.cpp.o -o foo
> > clang: warning: argument unused during compilation: '-pthread'
> >
> > This warning is totally bogus: it really means "unused during LINKING",
> > but anyway: I'm not sure what to do to get rid of this warning: I need
> > to support both Xcode and Makefiles on MacOSX (and Makefiles on Linux as
> > well as both GCC and Clang).
> >
> > Is the intent that CMAKE_CXX_FLAGS only ever appear on the compile line?
> > Or should it appear on both the compile and link lines? Is there an
> > equivalent flag to CMAKE_EXE_LINKER_FLAGS that always applies only to
> > compile lines, in all generators? Do we just have to continue to
> > bastardize add_definitions() for this, maybe?
> >
> > On Thu, 2015-01-08 at 18:52 -0500, Paul Smith wrote:
> >> If I'm on OSX, then when I set CMAKE_CXX_FLAGS and do not set
> >> CMAKE_EXE_LINKER_FLAGS, for example, and I use the Xcode generator,
> >> then
> >>
> >> I see:
> >> * CMAKE_CXX_FLAGS show up on the compilation line
> >> * CMAKE_CXX_FLAGS do NOT show up in the linker line
> >>
> >> On the other hand if I'm on OSX and I use the Unix Makefiles
> >> generator,
> >>
> >> then I see:
> >> * CMAKE_CXX_FLAGS show up on the compilation line
> >> * CMAKE_CXX_FLAGS ALSO show up in the linker line
> >>
> >> I assume the Xcode output is correct and the makefile output (with
> >> CMAKE_CXX_FLAGS in both) is not correct... but there's nothing I can
> >> find in the docs that says this explicitly.
> >>
> >> I've printed the contents of the CMAKE_CXX_FLAGS and
> >> CMAKE_EXE_LINKER_FLAGS at the end of my CMakeLists.txt and they're
> >> just
> >> what I expect. It's just that the link line has extra flags, when
> >> invoked from make.
> >
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For more
> > information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/cmake/help/training.html
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.o
Re: [CMake] CPack: .desktop files with tar.gz maker?
On Friday, November 07, 2014 03:50:32 PM Eric Wing wrote: > I have a build and packaging system where I can distribute (mostly) > standalone apps for Linux desktop. I am using the default CPack > installer which creates .tar.gz, .Z, and .sh files. > > I like this opposed to the .deb/.rpm package systems because users > don't need root access to install/use my stuff (and can place > anywhere), and I only need a single package for all Linux desktops. > > But it's pretty plain-Jane and it would be nice to provide an icon or > something. So I was wondering if anybody had > suggestions/advice/strategies on supporting .desktop files. As far as > I can tell, I need paths to the icon and the executable, which is > completely variable based on where the user puts it. And I'm not sure > where this file is supposed to be written to. (Remember that I don't > use root access.) > > Thanks, > Eric Perhaps you can do this: Include the .desktop file in your installation. To add, your installer can call xdg-desktop-menu install /share/applications/MyApp.desktop To remove, your installer can call xdg-desktop-menu uninstall /share/applications/MyApp.desktop If xdg-desktop-menu is called as root, it'll copy the .desktop file to the system location. If it is called as a non-root user, it'll copy the file to the user specific desktop area. xdg-desktop-menu also takes care of refreshing the icons in the launcher. During uninstall, it'll remove the copy. By the way, we do .rpm and .deb, but also give instructions for users to extract the files if they want their own installation directory. The above .desktop support can be put in a script and added to the postinst and prerm scripts for rpm and deb. This makes things more automatic for the majority of our users (basically download-click-and-run). Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Installation corrupts library on OS X
On Tuesday, October 21, 2014 06:52:58 PM Filipe Maia wrote:
> CMake's FindCUDA.cmake module adds the rpath when run on Mac OSX
> (from FindCUDA.cmake):
>
> if(APPLE)
> # We need to add the path to cudart to the linker using rpath, since the
> # library name for the cuda libraries is prepended with @rpath.
> if(CUDA_BUILD_EMULATION AND CUDA_CUDARTEMU_LIBRARY)
> get_filename_component(_cuda_path_to_cudart "${CUDA_CUDARTEMU_LIBRARY}"
> PATH)
> else()
> get_filename_component(_cuda_path_to_cudart "${CUDA_CUDART_LIBRARY}"
> PATH)
> endif()
> if(_cuda_path_to_cudart)
> list(APPEND CUDA_LIBRARIES -Wl,-rpath "-Wl,${_cuda_path_to_cudart}")
> endif()
> endif()
>
> This causes this problem for anything built with CUDA support
> (e.g. CUDA_ADD_EXECUTABLE), by having one rpath from the CUDA module and
> another one from cmake trying its automagic.
> The rpath should probably be removed from the module.
Oh! It comes from Modules/FindCUDA.cmake. That does need fixed.
Does the attached patch fix your problem?
Clint
> On Tue, Oct 14, 2014 at 9:56 PM, Clinton Stimpson
>
> wrote:
> > On Tuesday, October 14, 2014 12:10:36 PM Peter Eastman wrote:
> > > Hi Clint,
> > >
> > > In my case, it wasn't anything like that. I was only specifying
> > > /usr/local/cuda/lib once. More specifically, my CMakeLists.txt
> > > specified
> > >
> > > TARGET_LINK_LIBRARIES(${SHARED_TARGET} ${CUDA_LIBRARIES})
> > >
> > > where CUDA_LIBRARIES is
> > >
> > > /usr/local/cuda/lib/libcudart.dylib-Wl,-rpath-Wl,/usr/local/cuda/lib
> >
> > Since CMake 2.8.12, CMake will automatically figure out the
> > -Wl,-rpath-Wl,/usr/local/cuda/lib part for
> > /usr/local/cuda/lib/libcudart.dylib.
> >
> > So, the duplicate comes from CMake adding it once, and you adding it once.
> >
> > You should be able to remove any -Wl,-rpath flags that you add manually
> > with
> > CMake 2.8.12 and newer, and let CMake take care of that for you.
> >
> > > This library also linked against another of my libraries, that also
> >
> > happened
> >
> > > to link against CUDA. So that's why it was getting referenced twice:
> > once
> >
> > > directly, and once indirectly via a second library.
> > >
> > > In any case, it's not clear to me why CMake is calling
> > > "install_name_tool
> > > -delete_rpath". Everything works fine without doing that. And when you
> >
> > do
> >
> > > it, that breaks things.
> >
> > CMake calls "install_name_tool -delete_rpath" at install time to remove
> > the
> > build rpaths and add install rpaths as specified by the INSTALL_RPATH
> > target
> > property.
> >
> > For more details and examples:
> > http://www.kitware.com/blog/home/post/510
> > http://www.cmake.org/Wiki/CMake_RPATH_handling
> >
> > Clint
> >
> > > Peter
> > >
> > > On Oct 14, 2014, at 11:06 AM, Clinton Stimpson
> >
> > wrote:
> > > > Here's a simple way to reproduce from the command line:
> > > >
> > > > echo "void foo() {}" > lib.c
> > > > gcc -dynamiclib -o libtest.dylib -Wl,-rpath,/usr/lib
> >
> > -Wl,-rpath,/usr/lib
> >
> > > > lib.c install_name_tool -delete_rpath /usr/lib libtest.dylib
> > > > otool -L libtest.dylib
> > > >
> > > > # gives me the error: "load command 13 size zero (can't advance to
> >
> > other
> >
> > > > load commands)"
> > > >
> > > > At install time, CMake will call "install_name_tool -delete_rpath ...
> >
> > " as
> >
> > > > needed.
> > > >
> > > > I can't get into Apple's bug tracker. I don't know why. When I try
> > > > to
> > > > log
> > > > in, it comes back with a generic error and it asks me to email them
> >
> > with
> >
> > > > details about the error.
> > > >
> > > > When I do the same on Linux, the GNU linker will consolidate the
> >
> > duplicate
> >
> > > > paths.
> > > >
> > > > Thanks!
> > > >
> > > > Clint
> >
> > --
> > Clinton Stimpson
> > Elemental Technologies, Inc
> > Computational Simulation Software, LLC
> > www.csimsoft.com
> > --
>
[CMake] cache variables from compiler checks
I noticed something odd... If I delete the cache variable CMAKE_STRIP, then re-run cmake, it doesn't come back. If I delete the build/CMakeFiles directory, re-run cmake, it'll come back. Is that intentional? I have a dashboard build where I was re-configuring with a different initial CMakeCache.txt file, and some of the variables don't come back. Looks like I'll also need to remove the CMakeFiles directory while I write the CMakeLists.txt file. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Installation corrupts library on OS X
On Tuesday, October 14, 2014 12:10:36 PM Peter Eastman wrote:
> Hi Clint,
>
> In my case, it wasn't anything like that. I was only specifying
> /usr/local/cuda/lib once. More specifically, my CMakeLists.txt specified
>
> TARGET_LINK_LIBRARIES(${SHARED_TARGET} ${CUDA_LIBRARIES})
>
> where CUDA_LIBRARIES is
>
> /usr/local/cuda/lib/libcudart.dylib-Wl,-rpath-Wl,/usr/local/cuda/lib
Since CMake 2.8.12, CMake will automatically figure out the
-Wl,-rpath-Wl,/usr/local/cuda/lib part for
/usr/local/cuda/lib/libcudart.dylib.
So, the duplicate comes from CMake adding it once, and you adding it once.
You should be able to remove any -Wl,-rpath flags that you add manually with
CMake 2.8.12 and newer, and let CMake take care of that for you.
>
> This library also linked against another of my libraries, that also happened
> to link against CUDA. So that's why it was getting referenced twice: once
> directly, and once indirectly via a second library.
>
> In any case, it's not clear to me why CMake is calling "install_name_tool
> -delete_rpath". Everything works fine without doing that. And when you do
> it, that breaks things.
CMake calls "install_name_tool -delete_rpath" at install time to remove the
build rpaths and add install rpaths as specified by the INSTALL_RPATH target
property.
For more details and examples:
http://www.kitware.com/blog/home/post/510
http://www.cmake.org/Wiki/CMake_RPATH_handling
Clint
>
> Peter
>
> On Oct 14, 2014, at 11:06 AM, Clinton Stimpson wrote:
> > Here's a simple way to reproduce from the command line:
> >
> > echo "void foo() {}" > lib.c
> > gcc -dynamiclib -o libtest.dylib -Wl,-rpath,/usr/lib -Wl,-rpath,/usr/lib
> > lib.c install_name_tool -delete_rpath /usr/lib libtest.dylib
> > otool -L libtest.dylib
> >
> > # gives me the error: "load command 13 size zero (can't advance to other
> >
> > load commands)"
> >
> > At install time, CMake will call "install_name_tool -delete_rpath ... " as
> > needed.
> >
> > I can't get into Apple's bug tracker. I don't know why. When I try to
> > log
> > in, it comes back with a generic error and it asks me to email them with
> > details about the error.
> >
> > When I do the same on Linux, the GNU linker will consolidate the duplicate
> > paths.
> >
> > Thanks!
> >
> > Clint
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Installation corrupts library on OS X
On Tuesday, October 14, 2014 10:19:41 AM Peter Eastman wrote:
> Hi Clint,
>
> You're absolutely right:
>
> $ otool -l libOpenMMAmoebaCUDA.dylib | grep -A2 LC_RPATH
> cmd LC_RPATH
> cmdsize 32
> path /usr/local/cuda/lib (offset 12)
> --
> cmd LC_RPATH
> cmdsize 32
> path /usr/local/cuda/lib (offset 12)
>
> I'll try to figure out where the duplicate is coming from and see if that
> fixes it.
>
> I'd be glad to report this to Apple, but I can't figure out how to reproduce
> the problem without using CMake. I tried using install_name_tool to
> directly change all the paths myself, and that worked fine. It didn't
> produce the problem. Is CMake doing something different from just a series
> of calls to "install_name_tool -change" and "install_name_tool -id"?
>
> Peter
Here's a simple way to reproduce from the command line:
echo "void foo() {}" > lib.c
gcc -dynamiclib -o libtest.dylib -Wl,-rpath,/usr/lib -Wl,-rpath,/usr/lib lib.c
install_name_tool -delete_rpath /usr/lib libtest.dylib
otool -L libtest.dylib
# gives me the error: "load command 13 size zero (can't advance to other
load commands)"
At install time, CMake will call "install_name_tool -delete_rpath ... " as
needed.
I can't get into Apple's bug tracker. I don't know why. When I try to log
in, it comes back with a generic error and it asks me to email them with
details about the error.
When I do the same on Linux, the GNU linker will consolidate the duplicate
paths.
Thanks!
Clint
>
> On Oct 13, 2014, at 7:33 PM, clin...@elemtech.com wrote:
> > Yeah, I think you have duplicate LC_RPATH load commands. In that case,
> > your binaries can be corrupted by install_name_tool during "make
> > install." To check if that is your case, you can run this on the binary
> > before installation to see if you have duplicates. otool -l app | grep
> > -A2 LC_RPATH
> >
> > If the duplicates come from your own linker flags such as,
> > -Wl,-rpath,/some/path, you may need to remove those. Otherwise, it would
> > help if you can provide a minimal test case to reproduce the problem.
> >
> > It would also help if someone could report this corruption by
> > install_name_tool bug to Apple. You are the second to come to this
> > mailing list about this bug.
> >
> > Clint
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] VERSION and SOVERSION target properties on OS X
On Friday, October 10, 2014 12:43:53 PM Steven Velez wrote: > Forgive me if this question has been answered before but with CMAKE 2.8.12 > (I believe) xcode builds on OS X started generating shared libraries > decorated with the "VERSION" target property and symlinked by a bare dylib > name and one decorated with the SOVERSION. > > I understand this is common practice on many unixen, but it is complicating > our deployment and update logic (not cpack, sorry to say). > > Our application is fairly self-contained, so we would like to continue > generating only those bare-named dylibs, but we need to keep the SOVERSION > set to that the embedded "compatibility version" remains how we want it. > > I have not found a combination of values to these properties that does what > I would like, so I was wondering if there was a way to get the old > behavior perhaps with a policy or something? > > If there isn't a way to do it now, would there be an acceptable way to > specify this behavior that would be accepted as a patch? > > Thanks, > Steven That change was made to make the Xcode and Makefile generators consistent. To get what you want now (with both the older and newer CMake versions), you can remove the SOVERSION property and set the LINK_FLAGS property to pass - compatibilty_version to the linker. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CPack DragNDrop, adding an additional file to DMG
On Thursday, September 25, 2014 10:19:23 AM jmerkow wrote: > Yes. > > Im actually using the Bundle generator. We don't use bundle when compiling. > We only use bundles to launch for the binaries. DESTINATION "." points to > Contents/Resources/ in this case. > > -Jameson > Sorry, the Bundle generator doesn't let you do that. This is one of the reasons we have the DragNDrop generator, so you should use that instead. To do that, you'll also need to change your application to be a bundle in the build directory. You can also use variables for the DESTINATION parameter in your install() commands. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CPack DragNDrop, adding an additional file to DMG
On Thursday, September 25, 2014 08:36:18 AM jmerkow wrote: > Using CPack is it possible to add an additional file to the DMG? Many DMGs > accompany their bundles with readme's or other files. I haven't found > anything in the documentation to accomplish this. > > -Jameson Have you tried this? install(FILES readme.txt DESTINATION ".") -Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Setting additional Plist values for OS X Bundle
On Monday, August 25, 2014 01:10:27 PM Michael Jackson wrote:
> Are there are newer facilities in CMake 3.x that would allow me to add
> additional Plist values to the standard Mac OS X bundle plist that gets
> created?
>
> I use the following code currently:
>
> set_target_properties(${TARGET_NAME} PROPERTIES
> MACOSX_BUNDLE_INFO_STRING "${PROJECT_NAME}${DBG_EXTENSION} Version
> ${VERSION_STRING}, Copyright 2014 BlueQuartz Software."
> MACOSX_BUNDLE_ICON_FILE ${ICON_FILE_NAME}
> MACOSX_BUNDLE_GUI_IDENTIFIER "${PROJECT_NAME}${DBG_EXTENSION}"
> MACOSX_BUNDLE_LONG_VERSION_STRING "${PROJECT_NAME}${DBG_EXTENSION}
> Version ${VERSION_STRING}" MACOSX_BUNDLE_BUNDLE_NAME
> ${PROJECT_NAME}${DBG_EXTENSION}
> MACOSX_BUNDLE_SHORT_VERSION_STRING ${VERSION_STRING}
> MACOSX_BUNDLE_BUNDLE_VERSION ${VERSION_STRING}
> MACOSX_BUNDLE_COPYRIGHT "Copyright 2014, BlueQuartz Software. All
> Rights Reserved." )
>
>
> But I need to add the following to my plist:
>
> NSHighResolutionCapable
> True
>
>
> Thanks for any help
> --
> Mike Jackson www.bluequartz.net
Even with CMake 2.x, you can make your own .plist.in copied from
CMake/Modules/MacOSXBundleInfo.plist.in, then add your part in there.
NSHighResolutionCapable
True
Then add one more line to your set of target properties:
MACOSX_BUNDLE_INFO_PLIST
"${CMAKE_CURRENT_SOURCE_DIR}/MacOSXBundleInfo.plist.in"
- Clint
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CMake 3.0 and Visual Studio 2013 peculiarities
On Tuesday, August 05, 2014 11:30:57 AM Nagy-Egri Máté Ferenc wrote: > Hi! > > > > > I have been using CMake for quite some time now, but there are a few things > I don’t understand or I just don’t know how to accomplish. > > 1) Some time ago I posted about Unicode paths inside generated project files > do not work properly. The issue has been fixed. Though this issue is only a > cosmetic one, when I genetate anything with CMake under such a path I see > > -- Build files have been written to: > C:/Users/MßtÚFerenc/OneDrive/Develop/Active/GridRipper/VS2013 > > in the command line, where the actual path should contain “MátéFerenc”. I > don’t know if the displayed string internally is stored this way, or the > encoding gets messed at the very last moment when printed to the console. > Inspecting which is the case might uncover some bugs. Its messed up when printed to the console. CMake is using the ANSI code page, but your console is using the OEM code page. If you look at the two tables for your ANSI and OEM code pages, you'll see that á on the ANSI code page is the same as ß on the OEM code page. So, when CMake prints the á character, the console displays the ß character. There is a chcp command you can use to change your console code page to your ANSI code page to fix the display. - Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] undesirable Bdynamic/Bstatic link flags
I have a machine I'm trying to compile some code on, and CMake is apparently being smart and is inserting -Wl,-Bdynamic around some of the libraries from the CMAKE_CXX_IMPLICIT_LINK_LIBRARIES variable. Is there a way to stop that? Or is there a reason why it is doing that? Thanks, Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] good way to append link flags?
On Wednesday, April 23, 2014 06:25:24 PM Nils Gladitz wrote: > On 23.04.2014 18:16, Clinton Stimpson wrote: > > I am using > > set_property(TARGET mytarget APPEND PROPERTY LINK_FLAGS "...") > > multiple times to add various link flags. > > > > But when I inspect the actual link command, I see all my flags separated > > by > > semi-colons and no spaces between them, which is not what I want. > > > > Is this correct behavior for cmake? > > > > Clint > > Try APPEND_STRING (with explicit space) instead of APPEND. > Some flag variables/properties are interpreted as strings rather than lists. > > Nils Oh! Thanks, it works. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] good way to append link flags?
I am using set_property(TARGET mytarget APPEND PROPERTY LINK_FLAGS "...") multiple times to add various link flags. But when I inspect the actual link command, I see all my flags separated by semi-colons and no spaces between them, which is not what I want. Is this correct behavior for cmake? Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] INTERFACE_LINK_FLAGS ?
Is there a reason for the certain set of INTERFACE_* target properties we have? I have a situation where I'd like to add a /DELAYLOAD linker flag to any project that links against a certain library, but I get a message that INTERFACE_LINK_FLAGS is not supported. Do these INTERFACE_* properties need to be individually handled, or it is as simple as stripping the "INTERFACE_" prefix and applying the properties to consumers? - Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.12.201401116 is much slower than 2.8.12.1
On Thursday, January 16, 2014 03:13:31 PM Dominik Bernhardt wrote: > Hi, > > I just observed, that the current master branch is much slower than > the the release branch with tag 2.8.12.1 > I have built both branches with VS2010 with the Release configuration. > > Does anyone have an idea what might be the cause for that performance > degeneration? Does anyone else observe this behavior? I just tried on Linux and see a slight slowdown there too. On one of my projects, I see ~3.0 seconds for CMake 2.8.12 and ~3.8 seconds for CMake master. I don't have an idea why, but with my test, it doesn't see like "much" slower. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] missing -rpath-link flag
I have an example (attached) that gives a link error because an -rpath-link flag is missing. If I change the line add_library(static STATIC static.cpp) to add_library(static SHARED static.cpp) then the problem goes away. Also, if I change target_link_libraries(shared2 static) to target_link_libraries(shared2 static sharedb) the problem goes away. I had assumed anything done with target_link_libraries() on static libraries would be pushed up to the shared libraries/executables as needed. But in this case, it doesn't. Is this a bug in CMake? -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com test-rpath-link.tar.gz Description: application/compressed-tar -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindQt4 regression (changing QT_QMAKE_EXECUTABLE)
On Thursday, December 05, 2013 11:33:58 PM Simon Sasburg wrote:
> I've run into a problem after updating my cmake in using the FindQt4 module.
>
> It used to be the case that when QT_QMAKE_EXECUTABLE was changed by the
> user or by a SET(... FORCE) command, all the derived cache entries would be
> refreshed, however this does not work anymore.
>
> The cause seems to be git commit 21123416b4c2d49fe981279b10fbc78c8d07c491
> which removes the following code:
>
> if(QT_QMAKE_EXECUTABLE_LAST)
> string(COMPARE NOTEQUAL "${QT_QMAKE_EXECUTABLE_LAST}"
> "${QT_QMAKE_EXECUTABLE}" QT_QMAKE_CHANGED)
> endif()
> set(QT_QMAKE_EXECUTABLE_LAST "${QT_QMAKE_EXECUTABLE}" CACHE INTERNAL ""
> FORCE)
>
> I've attached a patch that restores this code so this works again, could
> this be included in the next cmake release?
>
> Best regards,
> Simon
Thanks! I noticed this problem recently too.
I've put it in for you.
http://cmake.org/gitweb?p=cmake.git;a=commit;h=4ee3b655
Clint
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] cpack & components problem
I have a situation where I'm generating a NSIS installer and I set CPACK_COMPONENTS_ALL to pick a few components I want to include. I use one component name for all my executables and shared libraries, and there is a 3rd party library (hdf5) that uses a different component name for installing shared libraries. There is not a way to customize the installation of hdf5 to set the component name, and there is there a way to disable the install() commands. I also want to run BundleUtilities to make sure my packages include dependent libraries. To do so, I have to pick a component name to run BundleUtilities with an install() command. But, the problem I have is the NSIS generator separates each component into its own directory and combines the results into the one and final .exe installer. BundleUtilities fails because the files are not in the same directory. Even if I try component groups, the NSIS generator still separates them by component name rather than by group. Can we have the cpack generators be consistent in how the components are installed? I'm thinking of installed components going into the same directory if they are in the same group, or in the same package file. Then, is there a good way to have cpack run a script like BundleUtilities after multiple components are installed in a certain directory? Or should the hdf5 cmake files be modified to allow people to override the install component names? This is what I have done for now. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Unicode path wrecks havoc with VS2013 generator
On Wednesday, November 13, 2013 03:12:13 PM Nagy-Egri Máté Ferenc wrote: > I have changed the encoding as you suggested and the project compiled fine: > > > 1>-- Build started: Project: cmTryCompileExec747919577, Configuration: > Debug Win32 -- 1> Microsoft (R) C/C++ Optimizing Compiler Version > 18.00.21005.1 for x86 1> Copyright (C) Microsoft Corporation. All rights > reserved. > 1> > 1> cl /c /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D > "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise > /Zc:wchar_t /Zc:forScope /Fo"cmTryCompileExec747919577.dir\Debug\\" > /Fd"cmTryCompileExec747919577.dir\Debug\vc120.pdb" /Gd /TC /analyze- > /errorReport:prompt testCCompiler.c 1> > 1> testCCompiler.c > 1> cmTryCompileExec747919577.vcxproj -> > C:\Users\MátéFerenc\SkyDrive\Develop\Active\GridRipper\VS2013\CMakeFiles\CM > akeTmp\Debug\cmTryCompileExec747919577.exe == Build: 1 succeeded, 0 > failed, 0 up-to-date, 0 skipped == > > > If you could issue a patch (2.8.12.2 if I’m not mistaken) that would correct > this bug, that would simply rock. Here is the fix for a future release. http://cmake.org/gitweb?p=cmake.git;a=commit;h=efe3a5dd Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Unicode path wrecks havoc with VS2013 generator
to include in the name of the > build directory. For example, buildñ, and run cmake in there pointing to > any source tree. > > > For me, the Visual Studio 9 2008 generator works fine and the project file > reports an encoding of Windows-1252. It fails with the the Visual Studio > 10 generator where the project file reports a utf-8 encoding, but it really > isn't utf-8. So I get errors like this: > C:\...\cmake\buildñ\CMakeFiles\CMakeTmp\cmTryCompileExec926 > 91608.vcxproj(56,110): > error MSB4025: The project file could not be loaded. Invalid character in > the given encoding. Line 56, position 110. > > > > Modifying cmVisualStudio10TargetGenerator.cxx to set the encoding of the > visual studio file to Windows-1252 instead of utf-8 fixes the problem for > me. > > > Clint > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Changes made for Mac fixup_bundle
BundleUtilities.cmake assumes a bundle layout, which is
App.app/
Contents/
MacOS/
Frameworks/
Instead, you have
install/
bin/TestApp
Frameworks/
MacOS/
Which does not work. You could try overriding the relative placement of
libraries with something like this:
function(gp_item_default_embedded_path_override item path)
set(path @executable_path PARENT_SCOPE)
endfunction()
Or modify the layout of your install tree.
Clint
On Wednesday, October 23, 2013 04:07:01 PM Yoon, Jong Seo wrote:
> The command I pass to fixup_bundle is
>
> fixup_bundle(\"${APPS}\" \"\${QTPLUGINS}\" \"${LIBRARY_DIRS}\")
>
> The arguments printed out is
>
> APPS =
> /Users/jongseoyoon/jsy/crkit/builds/release-1.6_build_2.8.3_2nd/crkit_build
> /install/bin/TestApp QTPLUGINS =
> LIBRARY_DIRS =
> /Users/foo/build/install/itk/lib/InsightToolkit/Users/foo/build/install/vtk
> /lib/vtk-5.6/Users/foo/build/install/qt-4.8.4/Users/foo/build/install/Framew
> orks/vtk-5.6.1/lib//Users/foo/build/install/Frameworks/qt-4.8.4/lib/Users/fo
> o/build/install/Frameworks/InsightToolkit
>
> The QTPLUGINS are empty for both cmake 2.8.3 and cmake 2.8.11.2.
> I don't use QTPLUGINS, but does this need to be not empty?
>
> Regarding the item_substring, that is not a typo. It does come out that way,
> and I tried to find where that is occurring, but I couldn't. Could that be
> the reason by it's failing to execute fixup_bundle?
>
> Thank you so much for helping me out!
>
> Sincerely,
>
> Jong
>
> -Original Message-
> From: Clinton Stimpson [mailto:clin...@elemtech.com]
> Sent: Tuesday, October 22, 2013 5:02 PM
> To: cmake@cmake.org
> Cc: Yoon, Jong Seo
> Subject: Re: [CMake] Changes made for Mac fixup_bundle
>
>
> Is this a typo?
> item_substring='/Users/foo/build /install/MacO'
>
> Can you please post the arguments you are passing to fixup_bundle()? The
> arguments are also printed out, for example: fixup_bundle
>app='/.../cmake/build/Tests/BundleUtilities/testdir2/testbundleutils2'
>libs='/.../cmake/build/Tests/BundleUtilities/testdir2/module2.so'
>dirs='/.../cmake/build/Tests/BundleUtilities'
>
> Clint
>
> On Tuesday, October 22, 2013 05:16:20 PM Yoon, Jong Seo wrote:
> > Hi Everyone,
> >
> > I have a question regarding the changes cmake changes from 2.8.3 to
> > 2.8.4 and above.
> >
> > I am getting this error when I try to make a dmg file for Mac using
> > cmake 2.8.11.2.
> >
> > exe_dotapp_dir/='/Users/foo/build/install/bin/'
> > item_substring='/Users/foo/build /install/MacO'
> > resolved_embedded_item='/Users/foo/build/install/MacOS/libITKBasicFilters.
> > 3. 20.dylib'
> >
> > Install or copy the item into the bundle before calling fixup_bundle.
> > Or maybe there's a typo or incorrect path in one of the args to
> > fixup_bundle?
> >
> > CMake Error at
> > /Users/foo/build/install/cmake/share/cmake-2.8/Modules/BundleUtilities
> > .cmak
> > e:568 (message): cannot fixup an item that is not in the bundle...
> > Call Stack (most recent call first):
> > /Users/foo/build/install/cmake/share/cmake-2.8/Modules/BundleUtilities
> > .cmake
> >
> > :656 (fixup_bundle_item)
> >
> > /Users/foo/build/bingcc/cmake_install.cmake:39
> > (fixup_bundle)
> >
> > The package I am trying to build works for cmake 2.8.3, but the error
> > message above shows up when I try to build it with cmake 2.8.4 and above.
> > Was there any changes to fixup_bundle from cmake 2.8.3 to cmake 2.8.4?
> >
> > Can anyone tell me what the error means?
> >
> > I am making this package with itk 3.20.1, vtk 5.6.1, and qt 4.8.4.
> >
> > Thank you so much for your help!
> >
> > Sincerely,
> >
> > Jong
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Visual Studio and /STACK
On Friday, October 25, 2013 02:52:45 PM David Cole wrote: > > Hmmm... Well that was a not backward compatible way of doing it. > > This behavior has existed for a long long time. > > Sorry for the extra effort you had to expend tracking down a mysterious > problem because of this change. I remember having some discussions > (probably just verbal, though, I can't find anything in email or bug > tracker) about whether this "simple change" should have a policy, and > we decided not to because we thought "out of stack space" errors would > be relatively easy to identify and correct in projects that require > large stack space. > > Out of curiosity, if you can share details, why did it take so long to > identify the problem in your case? (Or was it immediately obvious, and > you just took that long to trace it back to a CMake change?) > If you were curious... We also ran into this problem with an application. The error dialog that comes up on Windows specifically says stack overflow (at least with a debug build). So for us, it was easy to know that it was a stack overflow problem, but it wasn't clear why one developer had it and the others didn't, until we traced it back to the cmake version. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake policy CMP0022 error
On Friday, October 25, 2013 08:40:41 AM Stephen Kelly wrote: > Clinton Stimpson wrote: > > I have a target where I do this: > > SET_TARGET_PROPERTIES(mytarget PROPERTIES LINK_INTERFACE_LIBRARIES "") > > to hide 3rd party libraries from the link interface. > > > > When I do > > if(APPLE) > > > > CMAKE_MINIMUM_REQUIRED(VERSION 2.8.12) > > > > endif() > > I get an error at generate time. > > > > This is different than my previous experiences with cmake policies. Based > > on past experiences, I expected to see a warning if I had > > CMAKE_MINIMUM_REQUIRED(VERSION 2.8) > > but used CMake 2.8.12 which introduced CMP0022. > > You might have wrong understanding of policies. > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6d50d0197a5 > > Your use of cmake_minimum_required(VERSION 2.8.12) requests the non-backward > compatible behavior. Yeah, I knew that. I'm trying to point out that I did not get a warning when I was using cmake_minimum_required(VERSION 2.8) set_target_properties(mytarget PROPERTIES LINK_INTERFACE_LIBRARIES "") with CMake 2.8.12. That looks like a bug. > > > But in this case, I don't see a warning. > > The error I get with > > CMAKE_MINIMUM_REQUIRED(VERSION 2.8.12) > > is: > > > > CMake Error in .../CMakeLists.txt: > > Target "mytarget" has policy CMP0022 enabled, but also has old-style > > LINK_INTERFACE_LIBRARIES properties populated, but it was exported > > without the EXPORT_LINK_INTERFACE_LIBRARIES to export the old-style > > properties > > > > When I read the output from cmake --help-policy CMP0022, its not clear to > > me why I'm getting the error. > > 2.8.12 introduced a INTERFACE_LINK_LIBRARIES property, which should be used > instead of LINK_INTERFACE_LIBRARIES. The policy makes the > INTERFACE_LINK_LIBRARIES property ignored until it is set to NEW. > Oh! I somehow missed that the name was changed. INTERFACE_LINK_LIBRARIES -> LINK_INTERFACE_LIBRARIES. I re-read the docs and now I'm wondering how I missed that, duh. Thanks, Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake policy CMP0022 error
I have a target where I do this: SET_TARGET_PROPERTIES(mytarget PROPERTIES LINK_INTERFACE_LIBRARIES "") to hide 3rd party libraries from the link interface. When I do if(APPLE) CMAKE_MINIMUM_REQUIRED(VERSION 2.8.12) endif() I get an error at generate time. This is different than my previous experiences with cmake policies. Based on past experiences, I expected to see a warning if I had CMAKE_MINIMUM_REQUIRED(VERSION 2.8) but used CMake 2.8.12 which introduced CMP0022. But in this case, I don't see a warning. The error I get with CMAKE_MINIMUM_REQUIRED(VERSION 2.8.12) is: CMake Error in .../CMakeLists.txt: Target "mytarget" has policy CMP0022 enabled, but also has old-style LINK_INTERFACE_LIBRARIES properties populated, but it was exported without the EXPORT_LINK_INTERFACE_LIBRARIES to export the old-style properties When I read the output from cmake --help-policy CMP0022, its not clear to me why I'm getting the error. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Changes made for Mac fixup_bundle
Is this a typo? item_substring='/Users/foo/build /install/MacO' Can you please post the arguments you are passing to fixup_bundle()? The arguments are also printed out, for example: fixup_bundle app='/.../cmake/build/Tests/BundleUtilities/testdir2/testbundleutils2' libs='/.../cmake/build/Tests/BundleUtilities/testdir2/module2.so' dirs='/.../cmake/build/Tests/BundleUtilities' Clint On Tuesday, October 22, 2013 05:16:20 PM Yoon, Jong Seo wrote: > Hi Everyone, > > I have a question regarding the changes cmake changes from 2.8.3 to 2.8.4 > and above. > > I am getting this error when I try to make a dmg file for Mac using cmake > 2.8.11.2. > > exe_dotapp_dir/='/Users/foo/build/install/bin/' > item_substring='/Users/foo/build /install/MacO' > resolved_embedded_item='/Users/foo/build/install/MacOS/libITKBasicFilters.3. > 20.dylib' > > Install or copy the item into the bundle before calling fixup_bundle. > Or maybe there's a typo or incorrect path in one of the args to > fixup_bundle? > > CMake Error at > /Users/foo/build/install/cmake/share/cmake-2.8/Modules/BundleUtilities.cmak > e:568 (message): cannot fixup an item that is not in the bundle... > Call Stack (most recent call first): > /Users/foo/build/install/cmake/share/cmake-2.8/Modules/BundleUtilities.cmake > :656 (fixup_bundle_item) /Users/foo/build/bingcc/cmake_install.cmake:39 > (fixup_bundle) > > The package I am trying to build works for cmake 2.8.3, but the error > message above shows up when I try to build it with cmake 2.8.4 and above. > Was there any changes to fixup_bundle from cmake 2.8.3 to cmake 2.8.4? > > Can anyone tell me what the error means? > > I am making this package with itk 3.20.1, vtk 5.6.1, and qt 4.8.4. > > Thank you so much for your help! > > Sincerely, > > Jong -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake 2.8.12-rc2 FindHDF5 issues
On Thursday, September 19, 2013 01:47:23 PM Brad King wrote: > On 09/17/2013 06:16 PM, Clinton Stimpson wrote: > > I've narrowed it down to a regression caused by 04d4dc33. > > The following should fix this: > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0f05961f > > See the commit message for an explanation. > > Please test and let me know. > > Thanks, > -Brad It fixed my simple test case. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.12-rc2 FindHDF5 issues
On Tuesday, September 17, 2013 04:01:30 PM Orion Poplawski wrote:
> On 09/16/2013 09:58 PM, clin...@elemtech.com wrote:
> > Same here... and this looks like a regression:
> >
> > A simple CMakeLists.txt like this can reproduce it.
> >
> > set(CMAKE_BUILD_TYPE Debug)
> > find_package(HDF5 COMPONENTS C HL REQUIRED)
> > add_executable(foo foo.cpp)
> > target_link_libraries(foo ${HDF5_LIBRARIES})
> >
> > FindHDF5.cmake misuses CMAKE_BUILD_TYPE and CMAKE_CONFIGURATION_TYPES when
> > assembling the HDF5_LIBRARIES variable. If I clear out the
> > CMAKE_BUILD_TYPE variable, then the problem goes away.
> >
> > Clint
>
> cmake 2.8.11.2:
>
> -- Found HDF5:
> debug;/usr/lib64/libz.so;debug;/usr/lib64/libdl.so;debug;/usr/lib64/libm.so;
> debug;/usr/lib64/libhdf5_hl.so;debug;/usr/lib64/libhdf5.so;optimized;/usr/li
> b64/libz.so;optimized;/usr/lib64/libdl.so;optimized;/usr/lib64/libm.so;optim
> ized;/usr/lib64/libhdf5_hl.so;optimized;/usr/lib64/libhdf5.so
>
> cmake 2.8.12-rc2:
>
> -- Found HDF5:
> debug;HDF5_hdf5_LIBRARY_DEBUG-NOTFOUND;debug;HDF5_z_LIBRARY_DEBUG-NOTFOUND;d
> ebug;HDF5_dl_LIBRARY_DEBUG-NOTFOUND;debug;HDF5_m_LIBRARY_DEBUG-NOTFOUND;debu
> g;HDF5_hdf5_hl_LIBRARY_DEBUG-NOTFOUND;debug;HDF5_hdf5_LIBRARY_DEBUG-NOTFOUND
> ;optimized;/usr/lib64/libz.so;optimized;/usr/lib64/libdl.so;optimized;/usr/l
> ib64/libm.so;optimized;/usr/lib64/libhdf5_hl.so;optimized;/usr/lib64/libhdf5
> .so
>
>
> In comparing the CMakeCache:
[ snip ]
>
> As Rolf noted, FindHDF5 has not changed.
Right, it hasn't changed.
I've narrowed it down to a regression caused by 04d4dc33.
Will Dicharry, is this something you can look at? You are the maintainer for
both FindHDF5 and SelectLibraryConfigurations. A change in
SelectLibraryConfigurations caused a break in FindHDF5.
Clint
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] rpath trouble on macosx: cmake 2.8.9 ignores INSTALL_NAME_DIR and INSTALL_RPATH?
On Tuesday, September 10, 2013 09:43:59 AM Dan Kegel wrote:
> Howdy!
> I'm using 2.8.9 installed on MacOSX using macports, and am trying to get
> a minimal example of rpath working.
>
> Doing it without cmake works fine; see
> http://kegel.com/macosx/rpath/demo.txt
> which just does
> gcc -shared foo.c -install_name @rpath/foo.so -o foo.so
> gcc -Wl,-rpath $OTHERDIR x.c foo.so
> and works fine.
>
> But doing it with cmake eludes me. Here's what I'm trying:
> http://kegel.com/macosx/rpath/demo2.txt
> http://kegel.com/macosx/rpath/CMakeLists.txt
> That CMakeLists.txt is just
>
> cmake_minimum_required(VERSION 2.8)
> set(MYLIBDIR "${CMAKE_SOURCE_DIR}/otherdir")
>
> add_library(foo SHARED foo.c)
> set_target_properties(foo PROPERTIES INSTALL_NAME_DIR "@rpath")
>
> add_executable(x x.c)
> set_target_properties(
> x
> PROPERTIES
> BUILD_WITH_INSTALL_RPATH 1
> INSTALL_RPATH ${MYLIBDIR}
> )
> target_link_libraries(x foo)
>
> When I run demo2.txt, it does
>
> /usr/bin/gcc -dynamiclib -Wl,-headerpad_max_install_names -o
> libfoo.dylib -install_name /Users/dank/rpath/btmp/libfoo.dylib
> CMakeFiles/foo.dir/foo.c.o
> /usr/bin/gcc-o CMakeFiles/x.dir/x.c.o -c /Users/dank/rpath/x.c
> /usr/bin/gcc -Wl,-search_paths_first
> -Wl,-headerpad_max_install_names CMakeFiles/x.dir/x.c.o -o x
> libfoo.dylib
>
> and it appears to have totally ignored INSTALL_RPATH,
> so naturally running x fails with
> dyld: Library not loaded: /Users/dank/rpath/btmp/libfoo.dylib
>
> Can I buy a clue, please?
Using the INSTALL_RPATH property doesn't work correctly unless you use CMake
2.8.12 with the target property MACOSX_RPATH=1.
If you want it to work with the older version of CMake, then you need to set
the -Wl,-rpath linker flag yourself using the LINK_FLAGS target property.
set_target_properties(x PROPERTIES LINK_FLAGS "-Wl,-rpath,${MYLIBDIR}")
You should still keep the BUILD_WITH_INSTALL_RPATH=1 if you want the
INSTALL_NAME_DIR=@rpath to be applied at build time instead of waiting until
install time.
Clint
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] rpath trouble on macosx: cmake 2.8.9 ignores INSTALL_NAME_DIR and INSTALL_RPATH?
On Tuesday, September 10, 2013 04:03:08 PM Dan Kegel wrote: > On Tue, Sep 10, 2013 at 10:43 AM, Clinton Stimpson wrote: > > Using the INSTALL_RPATH property doesn't work correctly unless you use > > CMake 2.8.12 with the target property MACOSX_RPATH=1. > > Done, example http://kegel.com/macosx/rpath/demo2/CMakeLists.txt Actually, you want either of these set_target_properties(foo PROPERTIES INSTALL_NAME_DIR "@rpath") or set_target_properties(foo PROPERTIES MACOSX_RPATH 1) There is no need to set it as a property on target x. > > > If you want it to work with the older version of CMake, then you need to > > set the -Wl,-rpath linker flag yourself using the LINK_FLAGS target > > property. > Done, example http://kegel.com/macosx/rpath/demo3/CMakeLists.txt > > Next question: will cmake support relative rpaths, as in the example at > http://kegel.com/macosx/rpath/demo4/demo4.txt ? > i.e. > gcc -shared foo.c -install_name @rpath/lib/foo.so -o foo.so > gcc -Wl,-rpath,@loader_path/.. x.c foo.so > ? (I know, I should download and build trunk, but I'm pathetically lazy.) > - Dan Yes, it'll work in 2.8.12 like this. set_target_properties(x PROPERTIES INSTALL_RPATH "@loader_path/..") Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Absolute Path linking library
On Wednesday, September 04, 2013 03:01:06 PM Laurent Chauvin wrote:
> Thank you for your help Clint.
>
> I identified the problem. When I compile my library with
> CMAKE_MACOSX_RPATH, the library created is linked with
> @rpath/libMyLib.dylib.
> When I was recompiling (make) it was updating the library in the build
> directory but it was not re-installing (copying in the MyLibrary-install
> directory).
> That's why the link was keep failing.
>
> Is there a way to automatically reinstall when recompiling in Cmake ?
Not really.
You can always do a "make install" instead of "make", which will do both the
make and install in one step.
Clint
>
> Thank you very much.
> -Laurent
>
> On Wed, Sep 4, 2013 at 2:16 PM, Clinton Stimpson
wrote:
> > On Wednesday, September 04, 2013 01:22:11 PM Laurent Chauvin wrote:
> > > Does your example still works if you replace this line:
> > >
> > > target_link_libraries(app ${CMAKE_CURRENT_LIST_DIR}/../lib/liblib.dylib)
> > >
> > > by this one:
> > >
> > > target_link_libraries(app lib)
> >
> > No. It doesn't work. I get "ld: library not found for -llib"
> >
> > If I add a link_directories() I can get it working again.
> > If I were to use an export file, it would also work again.
> >
> > Feel free to try experiment with the example I gave you to verify that the
> > library can be found at runtime without setting DYLD_LIBRARY_PATH. You
> > only
> > need to supply 2 .cpp files with some dummy functions. The library and
> > executable are in two separate directories.
> >
> > Clint
> >
> > > ?
> > >
> > > Thank you.
> > > -Laurent
> > >
> > > On Wed, Sep 4, 2013 at 1:18 PM, Clinton Stimpson
> >
> > wrote:
> > > > On Wednesday, September 04, 2013 12:48:41 PM Laurent Chauvin wrote:
> > > > > Yes I'm using 2.8.12-rc2 for the library and the example.
> > > > >
> > > > > But my example is not in the same directory as my library.
> > > >
> > > > Neither was my example.
> > > >
> > > > > I can see in your example you specify the full path in
> > > > > target_link_libraries of your library, which I could probably do.
> > > > >
> > > > > The problem is, if later on my library I want to put the .dyld not
> > > > > in
> > > > > MyLib/lib but MyLib/testLib, then I will have (or users) to modify
> >
> > all
> >
> > > > > their CMakeLists to modify path of the library.
> > > > > That's why I would like not to have to hardcode the library path
> >
> > into my
> >
> > > > > example.
> > > >
> > > > Of course the users shouldn't hard code it. My example was simply
> > > > demonstrating the solution to the problem of locating the shared
> >
> > library
> >
> > > > at
> > > > runtime, which works in 2.8.12-rc2, without setting DYLD_LIBRARY_PATH.
> > > >
> > > > Really, this problem/solution for finding the .dylib at runtime has
> > > > nothing to
> > > > do with whether your target_link_libraries() has a full path or not.
> >
> > Or
> >
> > > > whether you are using LINK_DIRECTORIES or not.
> > > > I just tested with full path vs. LINK_DIRECTORIES, and it makes no
> > > > difference
> > > > to whether the library can be found at runtime.
> > > >
> > > > As an aside, I'm encouraging you to not use LINK_DIRECTORIES.
> > > >
> > > > Clint
> > > >
> > > > > I'm using find_package to find my library, and include the use file,
> > > >
> > > > which
> > > >
> > > > > define the include_directories and link_directories.
> > > > >
> > > > > I also checked the INSTALL(EXPORT ..), here
> >
> > http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cm
> >
> > > > ak>
> > > >
> > > > > e_file but I don't understand what it's doing and how it works.
> > > > >
> > > > > Thank you.
> > > > > -Laurent
> > > > >
> > > > > On Wed, Sep 4, 2013 at 12:26 PM, Clinton Stimpson
> > > >
> > > > wrote:
> > > > > > On Wednesda
Re: [CMake] Absolute Path linking library
On Wednesday, September 04, 2013 01:22:11 PM Laurent Chauvin wrote:
> Does your example still works if you replace this line:
>
> target_link_libraries(app ${CMAKE_CURRENT_LIST_DIR}/../lib/liblib.dylib)
>
> by this one:
>
> target_link_libraries(app lib)
No. It doesn't work. I get "ld: library not found for -llib"
If I add a link_directories() I can get it working again.
If I were to use an export file, it would also work again.
Feel free to try experiment with the example I gave you to verify that the
library can be found at runtime without setting DYLD_LIBRARY_PATH. You only
need to supply 2 .cpp files with some dummy functions. The library and
executable are in two separate directories.
Clint
>
> ?
>
> Thank you.
> -Laurent
>
> On Wed, Sep 4, 2013 at 1:18 PM, Clinton Stimpson
wrote:
> > On Wednesday, September 04, 2013 12:48:41 PM Laurent Chauvin wrote:
> > > Yes I'm using 2.8.12-rc2 for the library and the example.
> > >
> > > But my example is not in the same directory as my library.
> >
> > Neither was my example.
> >
> > > I can see in your example you specify the full path in
> > > target_link_libraries of your library, which I could probably do.
> > >
> > > The problem is, if later on my library I want to put the .dyld not in
> > > MyLib/lib but MyLib/testLib, then I will have (or users) to modify all
> > > their CMakeLists to modify path of the library.
> > > That's why I would like not to have to hardcode the library path into my
> > > example.
> >
> > Of course the users shouldn't hard code it. My example was simply
> > demonstrating the solution to the problem of locating the shared library
> > at
> > runtime, which works in 2.8.12-rc2, without setting DYLD_LIBRARY_PATH.
> >
> > Really, this problem/solution for finding the .dylib at runtime has
> > nothing to
> > do with whether your target_link_libraries() has a full path or not. Or
> > whether you are using LINK_DIRECTORIES or not.
> > I just tested with full path vs. LINK_DIRECTORIES, and it makes no
> > difference
> > to whether the library can be found at runtime.
> >
> > As an aside, I'm encouraging you to not use LINK_DIRECTORIES.
> >
> > Clint
> >
> > > I'm using find_package to find my library, and include the use file,
> >
> > which
> >
> > > define the include_directories and link_directories.
> > >
> > > I also checked the INSTALL(EXPORT ..), here
> >
> > http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cm
> > ak>
> > > e_file but I don't understand what it's doing and how it works.
> > >
> > > Thank you.
> > > -Laurent
> > >
> > > On Wed, Sep 4, 2013 at 12:26 PM, Clinton Stimpson
> >
> > wrote:
> > > > On Wednesday, September 04, 2013 12:02:55 PM Laurent Chauvin wrote:
> > > > > Thank you for you help Clint.
> > > > >
> > > > > I actually relinked, but as you said I still had the
> >
> > LINK_DIRECTORIES.
> >
> > > > > However, if I remove it, I have a linking error telling me it cannot
> > > > > find
> > > > > the library.
> > > > >
> > > > > Should I keep the library in Target_Link_Libraries, or with new
> >
> > flags,
> >
> > > > > dependency will automatically find the library ?
> > > >
> > > > You can leave your LINK_DIRECTORIES as its not the cause of your
> >
> > runtime
> >
> > > > failure to find the library.
> > > >
> > > > For compiling MyExample, did you also use CMake 2.8.12 RC?
> > > >
> > > > Here's a minimal example that works for me.
> > > >
> > > > -- lib/CMakeLists.txt
> > > > set(CMAKE_MACOSX_RPATH 1)
> > > > add_library(lib SHARED lib.cpp)
> > > >
> > > > -- app/CMakeLists.txt
> > > > add_executable(app app.cpp)
> > > > target_link_libraries(app
> >
> > ${CMAKE_CURRENT_LIST_DIR}/../lib/liblib.dylib)
> >
> > > > In lib/
> > > > I run "cmake . && make"
> > > >
> > > > In app/
> > > > I run "cmake . && make && ./app"
> > > >
> > > > With 2.8.12, it works.
> > > >
> > > > With an older version, I get
> > > > dyld: Libr
Re: [CMake] Absolute Path linking library
On Wednesday, September 04, 2013 12:48:41 PM Laurent Chauvin wrote:
> Yes I'm using 2.8.12-rc2 for the library and the example.
>
> But my example is not in the same directory as my library.
Neither was my example.
>
> I can see in your example you specify the full path in
> target_link_libraries of your library, which I could probably do.
>
> The problem is, if later on my library I want to put the .dyld not in
> MyLib/lib but MyLib/testLib, then I will have (or users) to modify all
> their CMakeLists to modify path of the library.
> That's why I would like not to have to hardcode the library path into my
> example.
Of course the users shouldn't hard code it. My example was simply
demonstrating the solution to the problem of locating the shared library at
runtime, which works in 2.8.12-rc2, without setting DYLD_LIBRARY_PATH.
Really, this problem/solution for finding the .dylib at runtime has nothing to
do with whether your target_link_libraries() has a full path or not. Or
whether you are using LINK_DIRECTORIES or not.
I just tested with full path vs. LINK_DIRECTORIES, and it makes no difference
to whether the library can be found at runtime.
As an aside, I'm encouraging you to not use LINK_DIRECTORIES.
Clint
>
> I'm using find_package to find my library, and include the use file, which
> define the include_directories and link_directories.
>
> I also checked the INSTALL(EXPORT ..), here
> http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmak
> e_file but I don't understand what it's doing and how it works.
>
> Thank you.
> -Laurent
>
> On Wed, Sep 4, 2013 at 12:26 PM, Clinton Stimpson
wrote:
> > On Wednesday, September 04, 2013 12:02:55 PM Laurent Chauvin wrote:
> > > Thank you for you help Clint.
> > >
> > > I actually relinked, but as you said I still had the LINK_DIRECTORIES.
> > > However, if I remove it, I have a linking error telling me it cannot
> > > find
> > > the library.
> > >
> > > Should I keep the library in Target_Link_Libraries, or with new flags,
> > > dependency will automatically find the library ?
> >
> > You can leave your LINK_DIRECTORIES as its not the cause of your runtime
> > failure to find the library.
> >
> > For compiling MyExample, did you also use CMake 2.8.12 RC?
> >
> > Here's a minimal example that works for me.
> >
> > -- lib/CMakeLists.txt
> > set(CMAKE_MACOSX_RPATH 1)
> > add_library(lib SHARED lib.cpp)
> >
> > -- app/CMakeLists.txt
> > add_executable(app app.cpp)
> > target_link_libraries(app ${CMAKE_CURRENT_LIST_DIR}/../lib/liblib.dylib)
> >
> > In lib/
> > I run "cmake . && make"
> >
> > In app/
> > I run "cmake . && make && ./app"
> >
> > With 2.8.12, it works.
> >
> > With an older version, I get
> > dyld: Library not loaded: @rpath/liblib.dylib
> >
> > Referenced from: /app
> > Reason: image not found
> >
> > Trace/BPT trap
> >
> > Clint
> >
> > > Thank you.
> > > -Laurent
> > >
> > > On Wed, Sep 4, 2013 at 11:59 AM, Clinton Stimpson
> >
> > wrote:
> > > > On Wednesday, September 04, 2013 11:53:45 AM Laurent Chauvin wrote:
> > > > > Hello,
> > > > >
> > > > > I just tried to set the MACOSX_RPATH 1 in the top CMakeLists of
> >
> > MyLib,
> >
> > > > and
> > > >
> > > > > when I now do otool -L libMyLib.dyld, I can indeed see
> > > >
> > > > @rpath/libMyLib.dyld.
> > > >
> > > > > However, my executable "MyExample" is still not able to find the
> >
> > library
> >
> > > > at
> > > >
> > > > > runtime. When I do otool -L MyExample, I still have libMyLib.dyld,
> >
> > not
> >
> > > > > @rpath/libMyLib.dyld.
> > > >
> > > > Did you relink MyExamle against the new libMyLib.dylib? CMake doesn't
> > > > modify
> > > > the install names of libraries being linked against, so if otool -L
> > > > MyExample
> > > > still gives "libMyLib.dylib", I'm assuming you didn't relink it.
> >
> > Using a
> >
> > > > cmake generated export file would take care of setting up dependencies
> >
> > so
> >
> > > > the
> > > > relink would happen simply by doing a make. If you use
>
Re: [CMake] Absolute Path linking library
On Wednesday, September 04, 2013 12:02:55 PM Laurent Chauvin wrote:
> Thank you for you help Clint.
>
> I actually relinked, but as you said I still had the LINK_DIRECTORIES.
> However, if I remove it, I have a linking error telling me it cannot find
> the library.
>
> Should I keep the library in Target_Link_Libraries, or with new flags,
> dependency will automatically find the library ?
You can leave your LINK_DIRECTORIES as its not the cause of your runtime
failure to find the library.
For compiling MyExample, did you also use CMake 2.8.12 RC?
Here's a minimal example that works for me.
-- lib/CMakeLists.txt
set(CMAKE_MACOSX_RPATH 1)
add_library(lib SHARED lib.cpp)
-- app/CMakeLists.txt
add_executable(app app.cpp)
target_link_libraries(app ${CMAKE_CURRENT_LIST_DIR}/../lib/liblib.dylib)
In lib/
I run "cmake . && make"
In app/
I run "cmake . && make && ./app"
With 2.8.12, it works.
With an older version, I get
dyld: Library not loaded: @rpath/liblib.dylib
Referenced from: /app
Reason: image not found
Trace/BPT trap
Clint
>
> Thank you.
> -Laurent
>
> On Wed, Sep 4, 2013 at 11:59 AM, Clinton Stimpson
wrote:
> > On Wednesday, September 04, 2013 11:53:45 AM Laurent Chauvin wrote:
> > > Hello,
> > >
> > > I just tried to set the MACOSX_RPATH 1 in the top CMakeLists of MyLib,
> >
> > and
> >
> > > when I now do otool -L libMyLib.dyld, I can indeed see
> >
> > @rpath/libMyLib.dyld.
> >
> > > However, my executable "MyExample" is still not able to find the library
> >
> > at
> >
> > > runtime. When I do otool -L MyExample, I still have libMyLib.dyld, not
> > > @rpath/libMyLib.dyld.
> >
> > Did you relink MyExamle against the new libMyLib.dylib? CMake doesn't
> > modify
> > the install names of libraries being linked against, so if otool -L
> > MyExample
> > still gives "libMyLib.dylib", I'm assuming you didn't relink it. Using a
> > cmake generated export file would take care of setting up dependencies so
> > the
> > relink would happen simply by doing a make. If you use LINK_DIRECTORIES,
> > you
> > miss the relink dependency.
> >
> > Clint
> >
> > > And I have same error (Library not loaded, image not found) when trying
> >
> > to
> >
> > > start the example.
> > >
> > > Should I add something more (or remove something) from my CMakeLists
> > > example ?
> > >
> > > I'm sorry I'm not really familiar with these mechanisms.
> > >
> > > Thank you very much.
> > > -Laurent
> > >
> > >
> > > On Wed, Sep 4, 2013 at 11:30 AM, Laurent Chauvin
> > >
> > > wrote:
> > > > Thank you very much for your answer.
> > > >
> > > > I will try to use the MACOSX_RPATH.
> > > >
> > > > However, I have some questions. As the flag suggests, it's only for
> >
> > mac.
> >
> > > > Is there anything similar for Linux (and eventually Windows systems) ?
> > > >
> > > > Also, the problem to set the full path of the library is, if I compile
> >
> > on
> >
> > > > Windows the extension of library will be dll, on Mac it will be dyld,
> >
> > and
> >
> > > > .a on linux.
> > > > I could make a condition to set the extension at the end of the name
> > > > of
> > > > the library like libMyLib.(dll, dyld, a) but, I feel like it's not
> >
> > really
> >
> > > > a
> > > > clean way to do it.
> > > >
> > > > Is there a better way to do it ?
> > > >
> > > > Thank you very much.
> > > > -Laurent
> > > >
> > > > On Wed, Sep 4, 2013 at 10:57 AM, Clinton Stimpson
> >
> > wrote:
> > > >> On Tuesday, September 03, 2013 09:47:45 PM Laurent Chauvin wrote:
> > > >> > Hello everyone,
> > > >> >
> > > >> > I'm working on a library, and I would like the users be able to
> >
> > create
> >
> > > >> their
> > > >>
> > > >> > own program and liking to my library (by specifying path in cmake).
> > > >> >
> > > >> > I created the library and an example to test it.
> > > >> > Everything compiles.
> > > >> >
> > > >> > However, when I
Re: [CMake] Absolute Path linking library
On Wednesday, September 04, 2013 11:30:51 AM Laurent Chauvin wrote:
> Thank you very much for your answer.
>
> I will try to use the MACOSX_RPATH.
>
> However, I have some questions. As the flag suggests, it's only for mac. Is
> there anything similar for Linux (and eventually Windows systems) ?
For Linux, the rpath feature for shared libraries already works well, but it
appears you are actually making static library on Linux. For Mac, the
equivalent of that Linux/Unix rpath feature was added to CMake 2.8.12.
For Windows, if there is a DLL, users of a dll commonly edit their PATH
environment variable to help find it at runtime. There really isn't anything
you as the author of the dll can do to help that.
>
> Also, the problem to set the full path of the library is, if I compile on
> Windows the extension of library will be dll, on Mac it will be dyld, and
> .a on linux.
> I could make a condition to set the extension at the end of the name of the
> library like libMyLib.(dll, dyld, a) but, I feel like it's not really a
> clean way to do it.
>
> Is there a better way to do it ?
Yes, there is a better way. Use install(EXPORT ..), which will take care of
those details for you.
Your MyLibConfig.cmake/mylib-config.cmake file can include it.
Clint
>
> Thank you very much.
> -Laurent
>
> On Wed, Sep 4, 2013 at 10:57 AM, Clinton Stimpson
wrote:
> > On Tuesday, September 03, 2013 09:47:45 PM Laurent Chauvin wrote:
> > > Hello everyone,
> > >
> > > I'm working on a library, and I would like the users be able to create
> >
> > their
> >
> > > own program and liking to my library (by specifying path in cmake).
> > >
> > > I created the library and an example to test it.
> > > Everything compiles.
> > >
> > > However, when I try to run my example I have this error:
> > >
> > > MyExample:
> > > libMyLib.1.dylib (compatibility version 1.0.0, current version
> >
> > 1.0.0)
> >
> > > /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
> >
> > version
> >
> > > 56.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> > > version 169.3.0)
> > >
> > > The problem is my example is not in the same directory as my library
> > > (not
> > > even in a subdirectory). And it seems it's linking to my library with a
> > > relative path.
> > >
> > > If I add the path of my library in DYLD_LIBRARY_PATH it works, but I
> >
> > would
> >
> > > like the users to be able to compile and link straight forward.
> > >
> > > To link the library to my example I use find_package(MyLib REQUIRED) and
> > > include(${MyLib_USE_FILE}) which basically do a LINK_DIRECTORIES with
> > > the
> > > absolute path of the library.
> > >
> > > Then I do add_executable and target_link_libraries(MyExample
> > > ${MyLib_LIBRARIES})
> > >
> > > Compilation is working fine. There is these options:
> > >
> > > -L/Absolute/Path/To/MyLib -lMyLib
> > >
> > > But at runtime, library cannot be found.
> > >
> > > Would it be possible to put the full path of my library when linking in
> >
> > the
> >
> > > CMakeLists ?
> >
> > You should use the full path to the library instead of LINK_DIRECTORIES.
> > Its easiest if you use install(EXPORT ...) to have CMake generate an
> > export
> > file for you that can be included by your FindMyLib.cmake file.
> > That export file will use the full path, and include any other necessary
> > information about the library.
> >
> > But to solve the problem of finding the library at runtime (specifying a
> > full
> > path won't solve it), CMake 2.8.12 has a new feature to address exactly
> > that
> > problem. For details: http://www.kitware.com/blog/home/post/510
> >
> > If you can use CMake 2.8.12, then you need to put
> >
> > set(MACOSX_RPATH 1)
> >
> > in the CMakeLists.txt of MyLib.
> >
> > If the user is using 2.8.12, then any executable they compile with your
> > library will be able to find the library, no matter where it is.
> >
> > By the way, 2.8.12 is in a release candidate stage right now, and right
> > now
> > would be a good time for you to test the new feature that is meant to
> > solve
> > your problem.
> >
> > Clint
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Absolute Path linking library
On Wednesday, September 04, 2013 11:53:45 AM Laurent Chauvin wrote:
> Hello,
>
> I just tried to set the MACOSX_RPATH 1 in the top CMakeLists of MyLib, and
> when I now do otool -L libMyLib.dyld, I can indeed see @rpath/libMyLib.dyld.
> However, my executable "MyExample" is still not able to find the library at
> runtime. When I do otool -L MyExample, I still have libMyLib.dyld, not
> @rpath/libMyLib.dyld.
Did you relink MyExamle against the new libMyLib.dylib? CMake doesn't modify
the install names of libraries being linked against, so if otool -L MyExample
still gives "libMyLib.dylib", I'm assuming you didn't relink it. Using a
cmake generated export file would take care of setting up dependencies so the
relink would happen simply by doing a make. If you use LINK_DIRECTORIES, you
miss the relink dependency.
Clint
> And I have same error (Library not loaded, image not found) when trying to
> start the example.
>
> Should I add something more (or remove something) from my CMakeLists
> example ?
>
> I'm sorry I'm not really familiar with these mechanisms.
>
> Thank you very much.
> -Laurent
>
>
> On Wed, Sep 4, 2013 at 11:30 AM, Laurent Chauvin
>
> wrote:
> > Thank you very much for your answer.
> >
> > I will try to use the MACOSX_RPATH.
> >
> > However, I have some questions. As the flag suggests, it's only for mac.
> > Is there anything similar for Linux (and eventually Windows systems) ?
> >
> > Also, the problem to set the full path of the library is, if I compile on
> > Windows the extension of library will be dll, on Mac it will be dyld, and
> > .a on linux.
> > I could make a condition to set the extension at the end of the name of
> > the library like libMyLib.(dll, dyld, a) but, I feel like it's not really
> > a
> > clean way to do it.
> >
> > Is there a better way to do it ?
> >
> > Thank you very much.
> > -Laurent
> >
> > On Wed, Sep 4, 2013 at 10:57 AM, Clinton Stimpson
wrote:
> >> On Tuesday, September 03, 2013 09:47:45 PM Laurent Chauvin wrote:
> >> > Hello everyone,
> >> >
> >> > I'm working on a library, and I would like the users be able to create
> >>
> >> their
> >>
> >> > own program and liking to my library (by specifying path in cmake).
> >> >
> >> > I created the library and an example to test it.
> >> > Everything compiles.
> >> >
> >> > However, when I try to run my example I have this error:
> >> >
> >> > MyExample:
> >> > libMyLib.1.dylib (compatibility version 1.0.0, current version
> >>
> >> 1.0.0)
> >>
> >> > /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
> >>
> >> version
> >>
> >> > 56.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
> >> > current
> >> > version 169.3.0)
> >> >
> >> > The problem is my example is not in the same directory as my library
> >>
> >> (not
> >>
> >> > even in a subdirectory). And it seems it's linking to my library with a
> >> > relative path.
> >> >
> >> > If I add the path of my library in DYLD_LIBRARY_PATH it works, but I
> >>
> >> would
> >>
> >> > like the users to be able to compile and link straight forward.
> >> >
> >> > To link the library to my example I use find_package(MyLib REQUIRED)
> >> > and
> >> > include(${MyLib_USE_FILE}) which basically do a LINK_DIRECTORIES with
> >>
> >> the
> >>
> >> > absolute path of the library.
> >> >
> >> > Then I do add_executable and target_link_libraries(MyExample
> >> > ${MyLib_LIBRARIES})
> >> >
> >> > Compilation is working fine. There is these options:
> >> >
> >> > -L/Absolute/Path/To/MyLib -lMyLib
> >> >
> >> > But at runtime, library cannot be found.
> >> >
> >> > Would it be possible to put the full path of my library when linking in
> >>
> >> the
> >>
> >> > CMakeLists ?
> >>
> >> You should use the full path to the library instead of LINK_DIRECTORIES.
> >> Its easiest if you use install(EXPORT ...) to have CMake generate an
> >> export
> >> file for you that can be included by your FindMyLib.cmake file.
> >> That export
Re: [CMake] Absolute Path linking library
On Tuesday, September 03, 2013 09:47:45 PM Laurent Chauvin wrote:
> Hello everyone,
>
> I'm working on a library, and I would like the users be able to create their
> own program and liking to my library (by specifying path in cmake).
>
> I created the library and an example to test it.
> Everything compiles.
>
> However, when I try to run my example I have this error:
> MyExample:
> libMyLib.1.dylib (compatibility version 1.0.0, current version 1.0.0)
> /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version
> 56.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 169.3.0)
>
> The problem is my example is not in the same directory as my library (not
> even in a subdirectory). And it seems it's linking to my library with a
> relative path.
>
> If I add the path of my library in DYLD_LIBRARY_PATH it works, but I would
> like the users to be able to compile and link straight forward.
>
> To link the library to my example I use find_package(MyLib REQUIRED) and
> include(${MyLib_USE_FILE}) which basically do a LINK_DIRECTORIES with the
> absolute path of the library.
>
> Then I do add_executable and target_link_libraries(MyExample
> ${MyLib_LIBRARIES})
>
> Compilation is working fine. There is these options:
>
> -L/Absolute/Path/To/MyLib -lMyLib
>
> But at runtime, library cannot be found.
>
> Would it be possible to put the full path of my library when linking in the
> CMakeLists ?
>
You should use the full path to the library instead of LINK_DIRECTORIES.
Its easiest if you use install(EXPORT ...) to have CMake generate an export
file for you that can be included by your FindMyLib.cmake file.
That export file will use the full path, and include any other necessary
information about the library.
But to solve the problem of finding the library at runtime (specifying a full
path won't solve it), CMake 2.8.12 has a new feature to address exactly that
problem. For details: http://www.kitware.com/blog/home/post/510
If you can use CMake 2.8.12, then you need to put
set(MACOSX_RPATH 1)
in the CMakeLists.txt of MyLib.
If the user is using 2.8.12, then any executable they compile with your
library will be able to find the library, no matter where it is.
By the way, 2.8.12 is in a release candidate stage right now, and right now
would be a good time for you to test the new feature that is meant to solve
your problem.
Clint
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] syntax error?
On Wednesday, August 14, 2013 04:25:10 PM David Cole wrote:
> > I'm using cmake from git master as of today and it gives me a warning
> >
> > CMake Warning (dev) in .../CMakeLists.txt:
> > Syntax Warning in cmake code at
> >
> > /.../CMakeLists.txt:309:10
>
> I do not get an error with this CMakeLists.txt:
>
> cmake_minimum_required(VERSION 2.8)
> project(xyz NONE)
>
> message("MSVC='${MSVC}'")
> message("MSVC_VERSION='${MSVC_VERSION}'")
>
> if (NOT (MSVC AND (MSVC_VERSION EQUAL 1600)))
> message("true")
> else()
> message("false")
> endif()
>
>
> I tried with 2.8.11.2 and 'nightly' -- does anybody else see a problem
> with this? Is it possibly something in 'master' that has already been
> fixed in 'nightly'?
>
> However, MSVC is empty unless I remove the "NONE" from project...
>
>
> HTH,
> D
Ah, you introduced a space after the "NOT" to silence the warning.
I'm not sure why it is picky about that space not being there.
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] syntax error?
Is the following a syntax error? if (NOT(MSVC AND (MSVC_VERSION EQUAL 1600))) ... I'm using cmake from git master as of today and it gives me a warning CMake Warning (dev) in .../CMakeLists.txt: Syntax Warning in cmake code at /.../CMakeLists.txt:309:10 -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building multiple configurations with Xcode?
. Only on windows is a debug > > library required for regular development because of the configuration > > specific C/C++ runtime libraries. > > > > If I made a framework for other people to use, and if for some reason they > > wanted to debug my framework, they could simply compile a debug only > > version and link with that. So I don't see a big need for both a release > > and debug framework. > > Closed source is not common/relevant? For closed source, they could gather some meaningful information with a debug framework. Having a foo.framework/Versions/A/foo foo.framework/Versions/A/foo_debug would be a quick way for them to debug by setting DYLD_IMAGE_SUFFIX=_debug. That's certainly quicker than recompiling their app against a debug framework in a different location. But, if I chose to give them this: Release/foo.framework/Versions/A/foo Debug/foo.framework/Versions/A/foo and their debug build was already linked with the debug foo framework, then debugging can already be done without setting any environment variable to tell the dynamic loader to use a different library. There are a few options here. > > > In the past, when I've had to debug the Qt libraries > > on Mac, I've either made a debug only build, or modified the frameworks. > > The modification was because Qt uses the same "_debug" suffix as the whole > > system, and I don't want the debug version of all of the system libraries > > because it is way too slow. So anyway, for me, this is a very low > > priority problem compared to other cmake issues. > > Right. > > The reporter at https://bugreports.qt-project.org/browse/QTBUG-30938 raises > a reason that DYLD_IMAGE_SUFFIX doesn't work for him anyway. I wonder what > qmake does here. > qmake links your apps against the framework (which under the covers means it is linked with the release Qt libraries), even for a debug build of your application. CMake and qmake behave the same here when developing a Qt based app. The DYLD_IMAGE_SUFFIX approach that works with Qt is to modify the Qt frameworks and rename the _debug files to _qtdebug. Then I set DYLD_IMAGE_SUFFIX=_qtdebug when running the application to debug the Qt libraries without debugging all system libraries (some of which are broken depending on the OS X version). -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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 and @rpath
On Wednesday, April 24, 2013 06:45:11 PM Jean-Christophe Fillion-Robin wrote: > Hi Folks, > > I have been working on improving BundleUtilities and GetPrerequisites > module so that it can be used to easily fixup a MacOSX bundle using @rpath. > > The set of changes I would like to propose is here: > https://github.com/jcfr/CMakeBundleUtilitiesExample/compare/f7a594ffba72b8cb > 83df9a166d7887bedc49f38b...75fa538 > > To try out the change, you could build the small project I created for that > purpose: https://github.com/jcfr/CMakeBundleUtilitiesExample#readme > > Let me know what you think. > > Thanks > Jc Is it to help make the same @executable_path based bundles but support copying in libraries and frameworks that used @rpath and change them over to be @executable_path based? Or is this to help create bundles that result in the use of @rpath? -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack Generator for the Mac App Store
On Monday, April 22, 2013 08:22:50 AM Brian Milco wrote: > > Does this workflow in your MacAppStore generator include anything that > > prevents making a .pkg for OS X Installer? > > From the stackoverlfow link below, the person says App Store submissions > > follow different rules. Do you know what those differences are? > > As I've never created an OS X Installer I really don't know. > > > it would be nice to at least start off well and go in the right > > > > direction. > > Agreed. > > > I'm not convinced that an implementation based on the Bundle generator way > > is the right start. > > I started with the Bundle generator because that's what I have been using > to distribute my application for the last couple of years. > > > Maybe I wasn't clear before. CMake can already do .app creation. > > I had forgotten that. I had gone with the Bundle generator two years ago > because I was able to get it working how I wanted quickly and easily. I > based my new generator on it because with the exception of the final dmg vs > pkg packaging they should build the same .app folder structure, and I > wanted both distribution methods to share the package creation and code > signing code. > > I spend some time this weekend looking at the implementation of the new > generator, right now the code signing is in the DragNDrop generator which > makes it available for all derived classes, allowing it to be used for both > Mac App Store signing, and also for developer code signing required by the > default behavior of OS X 10.8 Gatekeeper for non-App Store applications. > > I would like to hear your thoughts on what you think is the best approach > to structuring the code. > > Thanks, > Brian And I'm intrested in other people's thoughts too. I'm starting to think the code signing can be done with a cmake module instead of in the C++ cpack code. Being in DragNDrop generator does not make it available to all cpack generators usable on Mac. The signing of the pkg would still have to be in cpack. As a cmake module, it could be used at packaging time by having a install(CODE ...) in the CMakeLists.txt file. It is my understanding that cmake modules are generally preferred over c++ code, where possible. So my suggestion now is to have code signing in a cmake module, and the new cpack generator be a class derived from cmCPackGenerator. Without the Bundle generator behavior, because people should be able to use any cpack generator without modifying the CMakeLists.txt when switching generators. So, that's my 2 cents. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack Generator for the Mac App Store
On Thursday, April 11, 2013 03:30:39 PM Brian Milco wrote:
> Hi,
>
> I've added a CPack package generator for the Mac App Store for your
> consideration. You can find it on github:
> https://github.com/iPenguin/cmake/tree/cpack-mac-app-store-generator
>
> This is a first draft, but it should work to get a basic application
> uploaded via Apple's "Application Loader". I have no idea if this will work
> for the iOS App Store. Suggestions and comments are appreciated.
>
> This patch also includes code signing which is required by the Mac App
> Store, but it should also correctly sign your Bundle or DragNDrop packages
> to get your application working with OS X 10.8's default Gatekeeper
> settings if you supply a developer certificate.
>
> If you're building your app for distribution via the Mac App Store, and
> your website or other channels you might want to add something like the
> following to your CMakeLists.txt:
>
> if(${APP_STORE})
> set(CPACK_GENERATOR "MacAppStore")
>
> #The names of the App Store certs you got from Apple iTunesConnect
> set(CPACK_APPLE_CERT_APP "3rd Party Mac Developer Application:
> [YOUR NAME]")
> set(CPACK_APPLE_CERT_INSTALLER "3rd Party Mac Developer Installer:
> [YOUR NAME]")
>
> #The plist file containing your sandboxing entitlements[1]
> set(CPACK_APPLE_ENTITLEMENTS
> "${CMAKE_SOURCE_DIR}/resources/Entitlements.plist")
>
> else()
> set(CPACK_GENERATOR "Bundle")
>
> #The names of the Developer certs you got from Apple iTunesConnect
> set(CPACK_APPLE_CERT_APP "Developer ID Application: [YOUR NAME]")
> set(CPACK_APPLE_CERT_INSTALLER "Developer ID Installer: [YOUR
> NAME]")
> endif()
>
> #A list of additional files that need to be code signed, ie Frameworks,
> plugins, any additional binaries, etc.
> set(CPACK_APPLE_CODESIGN_FILES
> "/Contents/Frameworks/QtCore.framework/Versions/4/QtCore"
>
> "/Contents/Frameworks/QtGui.framework/Versions/4/QtGui")
>
> #how do I reference MACOSX_BUNDLE_GUI_IDENTIFIER directly in the
> generator code?
> set(CPACK_APPLE_BUNDLE_ID "${MACOSX_BUNDLE_GUI_IDENTIFIER}")
>
> -Brian
>
> [1]
> http://developer.apple.com/library/mac/#documentation/Miscellaneous/Referenc
> e/EntitlementKeyReference/Chapters/EnablingAppSandbox.html#//apple_ref/doc/u
> id/TP40011195-CH4-SW1
Why do you have this CPack generator creating the .app instead of letting the
CMake build step create the .app from the add_executable( ... MACOSX_BUNDLE ..
)?
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
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] nested replacement with @@
Another workaround is to make an intermediate variable in the CMakeLists.txt
file and use this intermediate variable from the .in file. That elminates the
nested @@'s.
Clint
On Wednesday, April 10, 2013 07:51:03 PM Eric Clark wrote:
> Nico,
>
> I had this same problem at one point in time, but was able to change it to
> the ${...} syntax which works beautifully. I know that you cannot use this
> syntax, but I will tell you that I did find a work-around for the nested
> @...@ syntax. The workaround is to run configure_file on the file twice.
> The nested @...@ symbols will always be replaced from the inside out which
> is the behavior that you want, you just have to run configure_file on the
> file for as many nests that you have. If the deepest nest you have is two
> nests, then you only need to run configure_file twice. I know this is kind
> of a kludge to fix it, but it does work from my experience...
>
> Hope this helps...
> Eric
>
> > -Original Message-
> > From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On
> > Behalf Of Nico Schlömer
> > Sent: Wednesday, April 10, 2013 12:55 PM
> > To: cmake
> > Subject: [CMake] nested replacement with @@
> >
> > Hi all,
> >
> > in a ProjectContfigTemplate.cmake.in file, I'd like to have variables such
> > as ${${PROJECT_NAME}_VERSION}. In ${}-syntax, the nesting is recognized
> > properly, and this string would be replaced by, e.g., "2.1".
> >
> > I know need to have ${}-variables in the output file, so I tried to switch
> > to the @-syntax. Replacing the above line by
> >
> > @@PROJECT_NAME@_VERSION@
> >
> > doesn't work however: The output file contains
> >
> > @Myproject_VERSION@
> >
> > i.e., only the inner variable was replaced.
> >
> > How to fix this?
> >
> > Cheers,
> > Nico
> > --
> >
> > 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
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
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] CTest / CDash integration
On Tuesday, April 09, 2013 04:42:57 PM Martin Baute wrote: > Am 09.04.2013 16:29, schrieb Clinton Stimpson: > > How are the config settings and binary path for CTest already given > > in the > > CMakeLists.txt file? Normally, a CMakeLists.txt file does not have a > > hardcoded binary path, nor does it have fixed config settings. > > Wrong wording, sorry. They are, after successful configuration, in the > CMakeCache.txt. Now I'm facing two options regarding CTest: > > - Doing incremental builds only, omitting information e.g. on the > number >of compiler warnings from the data sent to CDash. > > - Wiping the binary directory clean - including the platform-specific >configuration. > > Now, I could set up a CTest script that does the CMake configuration > for me. As it's platform specific, it would have to have lots of if / > else constructs, duplicating most of what CMakeLists.txt does. OR I > could create a CTestScript.cmake.in and forward the necessary settings > from CMakeLists.txt (using configure_file()). > > All this strikes me as somehow needlessly complicated when lots of the > necessary settings *could* be handled by the code that I add when I say > "include( CTest )". Add to that the somewhat lackluster documentation > of CTest itself (no variable docs, several command-line options under- > documented etc.), and I get the feeling that I'm simply *missing* > something, like, a crucial page in the Wiki or an integration guide > or somesuch. From what I've seen from the CMake / CTest / CDash trinity > so far, it's really big on "out of the box" functionality, which is why > I find this issue so confusing. > > Regards, Perhaps it would help if I explained these 2 different ways of using CTest. 1. non scripted mode $ cmake /path/to/source $ ctest -D Experimental This goes through the start/configure/build/test/submit phases using information from the CMakeLists.txt and CMakeCache.txt files. In other words, CMake information is given to CTest. 2. scripted mode $ ctest -S myscript.cmake where myscript.cmake could simply go through the start/configure/build/test/submit phases, or it can do more complex things. You'll also notice that I did not run cmake manually to set up the build tree. That is driven by myscript.cmake. That is the reason the config settings and the binary path go in myscript.cmake, because it is driving. In other words, CTest information is given to CMake. When used this way, I would not try to reverse that and feed CMake information into CTest. Apart from #1 and #2... the include(CTest) and add_test() commands in the CMakeLists.txt files only generate information files for use by CTest in scenario #1 or #2. It is to bridge the CTest and CMake tools (which can be used independently). -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] CTest / CDash integration
On Tuesday, April 09, 2013 04:11:06 PM Martin Baute wrote: > I realize I haven't been all that clear about my intentions. > > I want to keep the amount of configuration files at a minimum. > Lots of the information that is required for CTest (like config > settings, source path, binary path etc.) or CDash (server address, > project name) are already given in CMakeLists.txt, so naturally > I am looking to keep it all together instead of spreading it over > a number of different files cluttering my project. The CDash settings go into the CTestConfig.cmake file and that file resides next to the CMakeLists.txt file. Its in a separate file because one can use CTest/CDash without using CMake. How are the config settings and binary path for CTest already given in the CMakeLists.txt file? Normally, a CMakeLists.txt file does not have a hardcoded binary path, nor does it have fixed config settings. Between different computers, I can set a different binary path, and set different config settings. Because those aren't known in the CMakeLists.txt file, and they can vary between machines, a machine specific CTest script can provide that information. I keep a separate repository for CTest scripts for use by various machines. Each machine uses one of the scripts and can get updates to that script before getting updates to the source it is going to work on. I also keep the bulk of the CTest script in shared files, and the machine specific scripts have minimal code before including a shared script. > > The information available in the documentation is focussing on > various details, but doesn't really explain the "right" (intended) > way of putting together a CMake-built project that supports > uploading CTest results to a CDash server, so I was wondering > if I was missing something. > > Regards, -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] ctest & git submodules
Thanks. I may have to do that for now.
However, it seems to me that ctest already does a
git submodule update --recurse
but its missing the --init flag to deal with changes to the .gitmodules file.
Clint
On Tuesday, February 26, 2013 08:26:21 PM NoRulez wrote:
> Here is a working example:
>
> ## -- Update git submodules
> if (EXISTS "${CTEST_SOURCE_DIRECTORY}/.gitmodules")
> message (" -- Update git submodules ${MODEL} - ${CTEST_BUILD_NAME} --")
> execute_process (COMMAND ${GIT_EXECUTABLE} submodule update --init
> --recursive WORKING_DIRECTORY ${CTEST_SOURCE_DIRECTORY})
> endif ()
>
> Best Regards
>
> Am 26.02.2013 um 20:16 schrieb NoRulez :
> > Hi,
> >
> > I don't think so, you could check for a .git directory and then call
> >
> > git submodule update --init --recursive
> >
> > Best Regards
> >
> > Am 26.02.2013 um 18:34 schrieb Clinton Stimpson :
> >> Is there anything special I need to do with ctest so that the
> >> ctest_update() will recognize git submodules and do any init/update of
> >> those for me? I assumed it would be automatic, but that doesn't seem to
> >> be the case.>
> > --
> >
> > 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
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
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] ctest & git submodules
Is there anything special I need to do with ctest so that the ctest_update() will recognize git submodules and do any init/update of those for me? I assumed it would be automatic, but that doesn't seem to be the case. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding dylib with either @rpath or absolute paths to osx cmd line executable target
If you compile libiomp5 yourself with CMake, you can set the INSTALL_NAME_DIR target property and have CMake put that @rpath in for you instead of a post build rule running install_name_tool. Clint On Tuesday, February 19, 2013 09:03:57 AM Bart Nabbe wrote: > That is precisely what I ended up doing. A per target post build rule that > runs install_name_tool. With all cmake's wizardry, I sorta figured somebody > must have thought about this already ;) > > Thanks for the tip, I feel better now that I did not overlook something! > > On Feb 19, 2013, at 8:58, Clinton Stimpson wrote: > > Have you looked at using "install_name_tool -id" to change the id of the > > shared library. > > > > If you do install_name_tool -id @rpath/libiomp5.dylib > > /path/to/libiomp5.dylib > > > > Then when you link dylibLinkTest and then check it with otool -L, it will > > already have "@rpath/libiomp5.dylib" instead of just a plain > > "libiomp5.dylib" With that, there will be no need to constantly fix your > > executables with install_name_tool each time you link. > > > > BundleUtilities pulls all the dependencies into a bundle and uses > > @executable_path. BundleUtilities does not support @rpath, except that it > > is recognized and changed to @executable_path. > > > > Clint > > > > On Friday, February 15, 2013 06:57:35 PM Bart Nabbe wrote: > >> Hi, > >> > >> I'm sure I just overlooked something, but I can not get shared libraries > >> (at a non system location) to load properly at runtime after having had > >> them linked properly. If I run otool -L the library is listed without > >> any path>> > >> or loader reference: dylibLinkTest: > >>libiomp5.dylib (compatibility version 5.0.0, current version 5.0.0) > >>libtbb.dylib (compatibility version 0.0.0, current version 0.0.0) > >>/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > >> > >> 159.1.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current > >> version 52.0.0) > >> > >> > >> I can use the install_name_tool to change these to @rpath/libiomp5.dylib > >> and @rpath/libtbb.dylib respectively and all is well (I set rpath with a > >> linker option in my CMakeLists.txt). From searching I did learn about > >> the BundleUtilities, but I'm not quite sure how I would use it or if it > >> would really be suitable to solve the problem. > >> > >> Any suggestions would be greatly appreciated. > >> > >> > >> Thanks, > >> > >> Bart > >> > >> -- > >> > >> 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 -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding dylib with either @rpath or absolute paths to osx cmd line executable target
Have you looked at using "install_name_tool -id" to change the id of the shared library. If you do install_name_tool -id @rpath/libiomp5.dylib /path/to/libiomp5.dylib Then when you link dylibLinkTest and then check it with otool -L, it will already have "@rpath/libiomp5.dylib" instead of just a plain "libiomp5.dylib" With that, there will be no need to constantly fix your executables with install_name_tool each time you link. BundleUtilities pulls all the dependencies into a bundle and uses @executable_path. BundleUtilities does not support @rpath, except that it is recognized and changed to @executable_path. Clint On Friday, February 15, 2013 06:57:35 PM Bart Nabbe wrote: > Hi, > > I'm sure I just overlooked something, but I can not get shared libraries (at > a non system location) to load properly at runtime after having had them > linked properly. If I run otool -L the library is listed without any path > or loader reference: dylibLinkTest: > libiomp5.dylib (compatibility version 5.0.0, current version 5.0.0) > libtbb.dylib (compatibility version 0.0.0, current version 0.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 159.1.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current > version 52.0.0) > > > I can use the install_name_tool to change these to @rpath/libiomp5.dylib and > @rpath/libtbb.dylib respectively and all is well (I set rpath with a linker > option in my CMakeLists.txt). From searching I did learn about the > BundleUtilities, but I'm not quite sure how I would use it or if it would > really be suitable to solve the problem. > > Any suggestions would be greatly appreciated. > > > Thanks, > > Bart > > -- > > 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 -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack: Packaging debug and release configurations in a single zip
On Wednesday, February 06, 2013 01:09:20 PM Patrick Johnmeyer wrote:
> I have looked through the CMake wikis and several mailing list threads that
> the following google search returned, and I have not found a definitive
> answer to my question.
>
> [site:www.cmake.org/pipermail/cmake CPack multiple configurations in one
> package]
>
> My team delivers debug and release libraries, built under Visual Studio. We
> would like to package the debug and release libraries in a single zip file.
> However, I can only figure out how to get CPack to generate the zip for one
> configuration at a time. I could merge the two zip files after the fact,
> but it seems to me that there must be an easy way to get CPack to do this.
> Is there?
>
> Regards,
> pj
Here's one way I've done it.
option(CREATE_MULTI_CONFIG_PACKAGE "Enable creating a multi-config package with
both debug and release (doubles compile time)" OFF)
if(CREATE_MULTI_CONFIG_PACKAGE)
set up a secondary build tree at ${CMAKE_BINARY_DIR}/SecondaryBuildTree,
passing cmake options from here down to the secondary tree to make them match
I use execute_process to run cmake on the second tree and pass options down
(which compiler, and project specific settings that the user can modify for the
primary build tree).
add a custom target to build the second build tree by running "cmake --build"
# tell cpack to install both projects
set(CPACK_INSTALL_CMAKE_PROJECTS
# self project
"${CMAKE_BINARY_DIR};${CMAKE_PROJECT_NAME};ALL;/"
# other config project
"${CMAKE_BINARY_DIR}/SecondaryBuildTree;${CMAKE_PROJECT_NAME};ALL;/"
)
endif()
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack DEB dependencies
On Monday, January 28, 2013 10:07:04 PM Eric Noulard wrote:
> 2013/1/28 Clinton Stimpson :
> > When I try installing a cpack generated .rpm package on another machine,
> > it
> > also installs a handful of other dependent packages (including the 32 bit
> > libc.so.6 for one of the 32 bit executables among all the 64 bit ones).
> >
> > But a cpack generated .deb package isn't that smart.
>
> This is because CPackRPM uses rpmbuild which usually have a builtin step
> for auot-discovering basic dependencies. At least if you build it on the
> same platform/distro you'll be installing it.
>
> > Is there any way to fix
> > this, either in cpack or in my cpack config?
>
> You can try to set CPACK_DEBIAN_PACKAGE_SHLIBDEPS to ON.
> Read the doc to see why it is not on by default:
> cpack --help-variable CPACK_DEBIAN_PACKAGE_SHLIBDEPS
There is a typo in that help. It has the word "toi"
Ok, I'm running into that probably of not finding dependencies within my own
package. In the package, there are some 3rd party plugins without rpaths
(these plugins don't need them), but it complains about not finding dependent
libraries.
Do you know if there is some what to give it the path?
I'm hoping for something like this in my cpack config (which doesn't work):
set(ENV{LD_LIBRARY_PATH} "$ENV{DESTDIR}/${CMAKE_INSTALL_PREFIX}/lib")
I'm curious why rpmbuild didn't have this problem, do you know?
And why would automatic dependencies be ON by default for RPM but not for DEB?
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack DEB dependencies
On Monday, January 28, 2013 11:59:46 AM Clinton Stimpson wrote: > When I try installing a cpack generated .rpm package on another machine, it > also installs a handful of other dependent packages (including the 32 bit > libc.so.6 for one of the 32 bit executables among all the 64 bit ones). > > But a cpack generated .deb package isn't that smart. Is there any way to > fix this, either in cpack or in my cpack config? At a minimum, I think all > I really need is the 32 bit libc.so.6. I think I found what I'm looking for: set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON) -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] CPack DEB dependencies
When I try installing a cpack generated .rpm package on another machine, it also installs a handful of other dependent packages (including the 32 bit libc.so.6 for one of the 32 bit executables among all the 64 bit ones). But a cpack generated .deb package isn't that smart. Is there any way to fix this, either in cpack or in my cpack config? At a minimum, I think all I really need is the 32 bit libc.so.6. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] Making swig wrapper depend on the involved headers
On Wednesday, December 19, 2012 01:18:47 PM Daniel Russel wrote:
> I'm using the shipped UseSWIG package to add a swig module to my project
> (cmake 2.8). For those that don't know, swig works by running the swig
> command on an input file (a .i) and then building the files that it
> produces. The input file tells swig to scan certain header files and the
> output file depends on the contents of the header files. As a result, when
> one of the headers changes, swig needs to be rerun. However, this does not
> occur and I can't figure out a way to manually add the needed dependencies
> to cmake either (I've tried various things with setting source DEPENDENCY
> property and the ADD_DEPENDENCIES command passing in the dependencies). Any
> suggestions? Thanks. --
You can manually add dependencies like this
SET(SWIG_MODULE_foo_EXTRA_DEPS
${foo_SOURCE_DIR}/foo.h
)
...
SWIG_ADD_MODULE(foo python foo.i)
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
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] Testing Qt 5 RC 1 CMake files
I took a peek at building it earlier with Qt5. I started making changes and one of the more surprising ones was that #include pulled in my Qt4 QWidget from /usr/include/QtGui/QWidget. Instead of Qt5's QtWidgets/QWidget. That led to confusing linker errors. I got as far as trying to build some examples, but many of the examples seem to be broken. Does anyone know if the master branch has become stable and whether functionality and examples have been restored since the start of the breaking modularization changes months ago? I stopped when I saw these kinds of build problems. On Tuesday, December 11, 2012 05:24:37 PM David Cole wrote: > In VTK 'master' -- if you turn on the "VTK_Group_Qt" CMake option, either > in the gui, or by -D on the command line, then all the Qt-related modules > will be enabled. > > In VTK 5.10, there were some other configure time options (I'd have to go > look them up or try it out) to control building the Qt-related bits... > > On Tue, Dec 11, 2012 at 5:20 PM, Stephen Kelly wrote: > > John Drescher wrote: > > > I had some trouble building a x64 version of Qt 5.0 beta2 but then > > > after getting past that I found out that vtk-5.10.X would not work > > > with Qt5 so it pretty much ended what I wanted to test since pretty > > > much all of my current code uses vtk. > > > > I see. I just tried building VTK master in my Qt 4 environment, and I > > can't > > figure out how to build the Qt parts of it. > > > > I'm sure it's easy to port to Qt 5, but if I can't figure out how to build > > the Qt parts at all, then I can't do that. > > > > Thanks, > > > > Steve. > > > > > > -- > > > > 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 -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] Poor performance of copy_if_different
On Tuesday, November 06, 2012 12:46:01 PM Robert Dailey wrote:
> Is there an assumption here that CMAKE_CONFIGURATION_TYPES will not be
> set for single-configuration generators?
Yes, that's the assumption. That's how I normally check for single vs. multi
config generators.
>
> I have some code in my root CMake script that forces only 'debug' and
> 'release' configurations to exist (I didn't want the MinRelSize and
> friends in there). I think this will force the logic that depends on
> CMAKE_CONFIGURATION_TYPES to fail. What would you do in this case?
>
> Here is the code that sets CMAKE_CONFIGURATION_TYPES:
>
> cmake_minimum_required( VERSION 2.8.8 FATAL_ERROR )
>
> set( CMAKE_BUILD_TYPE debug )
> set( CMAKE_CONFIGURATION_TYPES debug release CACHE INTERNAL "" FORCE )
>
> project( gmms )
>
> ... etc ...
It doesn't make much sense to me why one could only do a release build with a
mulit-config generator... I normally leave those variables alone and let the
user set them. I find RelWithDebInfo quite useful sometimes.
But if you had to, perhaps you could do this, after your project(gmms):
if(CMAKE_CONFIGURATION_TYPES)
set( CMAKE_CONFIGURATION_TYPES debug release CACHE INTERNAL "" FORCE )
endif()
Or some code to strip out types from CMAKE_CONFIGURATION_TYPES except for
debug and release. So if it was empty to begin with, it could stay empty.
>
> On Tue, Nov 6, 2012 at 12:41 PM, Clinton Stimpson
wrote:
> > You could base your logic on CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD
> > TYPE.
> >
> > For example:
> >
> > if(CMAKE_CONFIGURATION_TYPES)
> >
> > foreach(type ${CMAKE_CONFIGURATION_TYPES})
> >
> > make_copy_rules(${type})
> >
> > endforeach()
> >
> > else()
> >
> > make_copy_rules(${CMAKE_BUILD_TYPE})
> >
> > endif()
> >
> > On Tuesday, November 06, 2012 12:34:22 PM Robert Dailey wrote:
> >> I figured out the problem.
> >>
> >> On single-configuration generators (like NMake, which I'm testing now)
> >> both release and debug configurations have the same binary output
> >> directory. Since I'm creating 1 custom target (and corresponding
> >> commands) per configuration, the 2nd configuration has the same
> >> outputs as the 1st, so the 2nd target fails because I"m adding
> >> different rules to the same output file. This isn't a problem with
> >> Visual Studio generators because my outputs go to Debug and Release.
> >>
> >> Know any good workarounds for this?
> >>
> >> On Tue, Nov 6, 2012 at 11:54 AM, Clinton Stimpson
> >
> > wrote:
> >> > Try this:
> >> > add_custom_command(
> >> >
> >> > OUTPUT ${bin_outputs}
> >> > COMMAND ${copy_commands}
> >> > DEPENDS
> >> >
> >> > )
> >> >
> >> > On Tuesday, November 06, 2012 11:50:54 AM Robert Dailey wrote:
> >> >> Thanks Clinton,
> >> >>
> >> >> Here is what I have so far:
> >> >>
> >> >>
> >> >> project( copy_dlls )
> >> >>
> >> >> set( copycmd "${CMAKE_COMMAND}" ARGS "-E" "copy_if_different" )
> >> >>
> >> >> set( configurations debug release )
> >> >> foreach( config ${configurations} )
> >> >>
> >> >> string( TOUPPER ${config} upper_config )
> >> >>
> >> >> get_property( binarydirs GLOBAL PROPERTY
> >> >>
> >> >> THIRD_PARTY_DIRS_${upper_config} ) foreach( dir ${binarydirs} )
> >> >>
> >> >> file( GLOB binaries "${dir}/*${CMAKE_SHARED_LIBRARY_SUFFIX}" )
> >> >>
> >> >> if( WIN32 AND config STREQUAL "debug" )
> >> >>
> >> >> file( GLOB pdbs "${dir}/*.pdb" )
> >> >> list( APPEND binaries ${pdbs} )
> >> >>
> >> >> endif()
> >> >>
> >> >> foreach( bin ${binaries} )
> >> >>
> >> >> get_filename_component( bin_file ${bin} NAME )
> >> >>
> >> >> list( APPEND bin_outputs ${bin} )
> >> >> list( APPEND copy_commands
> >> >>
&g
Re: [CMake] Poor performance of copy_if_different
You could base your logic on CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD TYPE.
For example:
if(CMAKE_CONFIGURATION_TYPES)
foreach(type ${CMAKE_CONFIGURATION_TYPES})
make_copy_rules(${type})
endforeach()
else()
make_copy_rules(${CMAKE_BUILD_TYPE})
endif()
On Tuesday, November 06, 2012 12:34:22 PM Robert Dailey wrote:
> I figured out the problem.
>
> On single-configuration generators (like NMake, which I'm testing now)
> both release and debug configurations have the same binary output
> directory. Since I'm creating 1 custom target (and corresponding
> commands) per configuration, the 2nd configuration has the same
> outputs as the 1st, so the 2nd target fails because I"m adding
> different rules to the same output file. This isn't a problem with
> Visual Studio generators because my outputs go to Debug and Release.
>
> Know any good workarounds for this?
>
> On Tue, Nov 6, 2012 at 11:54 AM, Clinton Stimpson
wrote:
> > Try this:
> > add_custom_command(
> >
> > OUTPUT ${bin_outputs}
> > COMMAND ${copy_commands}
> > DEPENDS
> >
> > )
> >
> > On Tuesday, November 06, 2012 11:50:54 AM Robert Dailey wrote:
> >> Thanks Clinton,
> >>
> >> Here is what I have so far:
> >>
> >>
> >> project( copy_dlls )
> >>
> >> set( copycmd "${CMAKE_COMMAND}" ARGS "-E" "copy_if_different" )
> >>
> >> set( configurations debug release )
> >> foreach( config ${configurations} )
> >>
> >> string( TOUPPER ${config} upper_config )
> >>
> >> get_property( binarydirs GLOBAL PROPERTY
> >>
> >> THIRD_PARTY_DIRS_${upper_config} ) foreach( dir ${binarydirs} )
> >>
> >> file( GLOB binaries "${dir}/*${CMAKE_SHARED_LIBRARY_SUFFIX}" )
> >>
> >> if( WIN32 AND config STREQUAL "debug" )
> >>
> >> file( GLOB pdbs "${dir}/*.pdb" )
> >> list( APPEND binaries ${pdbs} )
> >>
> >> endif()
> >>
> >> foreach( bin ${binaries} )
> >>
> >> get_filename_component( bin_file ${bin} NAME )
> >>
> >> list( APPEND bin_outputs ${bin} )
> >> list( APPEND copy_commands
> >>
> >> COMMAND ${copycmd} "${bin}"
> >>
> >> "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/${CMAKE_CFG_INTDIR}/${bin_file}"
> >>
> >> )
> >>
> >> endforeach()
> >>
> >> endforeach()
> >>
> >> add_custom_command(
> >>
> >> OUTPUT ${bin_outputs}
> >> ${copy_commands}
> >>
> >> )
> >>
> >> add_custom_target( copy_dlls_${config}
> >>
> >> COMMENT "Copying ${config} binaries..."
> >> DEPENDS ${bin_outputs}
> >>
> >> )
> >>
> >> endforeach()
> >>
> >>
> >> This doesn't seem to work though, CMake tells me:
> >>
> >> CMake Error: Attempt to add a custom rule to output
> >> "C:/Work/rdailey-hp/dpd-cmake/build-nmake-vc9/third_party/bdb/4.7.25/vc9s
> >> p1/ debug/bin/libdb47d.dll.rule" which already has a custom rule.
> >>
> >> I'm trying to stuff all the copy commands and output files into 1
> >> custom command, and wrap that with a custom target, so I can make
> >> other targets depend on the custom target.
> >>
> >> On Tue, Nov 6, 2012 at 11:44 AM, Clinton Stimpson
> >
> > wrote:
> >> > add_custom_command(
> >> >
> >> > OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/my.dll
> >> > COMMAND cmake -E copy ${CMAKE_CURRENT_SOURCE_DIR}/my.dll
> >> >
> >> > ${CMAKE_CURRENT_BINARY_DIR}/my.dll
> >> >
> >> > DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/my.dll
> >> > )
> >> >
> >> > add_custom_target(copy_dll ALL DEPENDS
> >> > ${CMAKE_CURRENT_BINARY_DIR}/my.dll)
> >> >
> >> > Whether you use 1 custom command per dll, or 1 for all dlls, is up to
> >> > you.
> >> >
> >> > If they usually change together, then you could have fewer custom
> >> >
> >> > comm
Re: [CMake] Poor performance of copy_if_different
Try this:
add_custom_command(
OUTPUT ${bin_outputs}
COMMAND ${copy_commands}
DEPENDS
)
On Tuesday, November 06, 2012 11:50:54 AM Robert Dailey wrote:
> Thanks Clinton,
>
> Here is what I have so far:
>
>
> project( copy_dlls )
>
> set( copycmd "${CMAKE_COMMAND}" ARGS "-E" "copy_if_different" )
>
> set( configurations debug release )
> foreach( config ${configurations} )
> string( TOUPPER ${config} upper_config )
>
> get_property( binarydirs GLOBAL PROPERTY
> THIRD_PARTY_DIRS_${upper_config} ) foreach( dir ${binarydirs} )
> file( GLOB binaries "${dir}/*${CMAKE_SHARED_LIBRARY_SUFFIX}" )
>
> if( WIN32 AND config STREQUAL "debug" )
> file( GLOB pdbs "${dir}/*.pdb" )
> list( APPEND binaries ${pdbs} )
> endif()
>
> foreach( bin ${binaries} )
> get_filename_component( bin_file ${bin} NAME )
>
> list( APPEND bin_outputs ${bin} )
> list( APPEND copy_commands
> COMMAND ${copycmd} "${bin}"
> "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/${CMAKE_CFG_INTDIR}/${bin_file}"
> )
> endforeach()
> endforeach()
>
> add_custom_command(
> OUTPUT ${bin_outputs}
> ${copy_commands}
> )
>
> add_custom_target( copy_dlls_${config}
> COMMENT "Copying ${config} binaries..."
> DEPENDS ${bin_outputs}
> )
> endforeach()
>
>
> This doesn't seem to work though, CMake tells me:
>
> CMake Error: Attempt to add a custom rule to output
> "C:/Work/rdailey-hp/dpd-cmake/build-nmake-vc9/third_party/bdb/4.7.25/vc9sp1/
> debug/bin/libdb47d.dll.rule" which already has a custom rule.
>
> I'm trying to stuff all the copy commands and output files into 1
> custom command, and wrap that with a custom target, so I can make
> other targets depend on the custom target.
>
> On Tue, Nov 6, 2012 at 11:44 AM, Clinton Stimpson
wrote:
> > add_custom_command(
> >
> > OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/my.dll
> > COMMAND cmake -E copy ${CMAKE_CURRENT_SOURCE_DIR}/my.dll
> >
> > ${CMAKE_CURRENT_BINARY_DIR}/my.dll
> >
> > DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/my.dll
> > )
> >
> > add_custom_target(copy_dll ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/my.dll)
> >
> > Whether you use 1 custom command per dll, or 1 for all dlls, is up to you.
> > If they usually change together, then you could have fewer custom
> > commands. In that case, the OUTPUT would have multiple files and both
> > DEPENDS would have multiple files.
> >
> > Another alternative is to use add_custom_command(TARGET POST_BUILD ...) if
> > these are dlls that you compile yourself and need to copy after the build
> > step.
> >
> > On Tuesday, November 06, 2012 11:23:03 AM Robert Dailey wrote:
> >> Also, is it safe to add 1 custom command for each DLL copy? Or would
> >> you somehow only use 1 custom command and copy them all with it? Also
> >> would I add the custom commands to the custom target?
> >>
> >> On Tue, Nov 6, 2012 at 11:11 AM, Clinton Stimpson
> >
> > wrote:
> >> > On Tuesday, November 06, 2012 11:06:45 AM Robert Dailey wrote:
> >> >> I use ${CMAKE_COMMAND} -E copy_if_different to copy DLL files to my
> >> >> binary output directory. The custom target runs this command about
> >> >> 50-100 times (for that many files).
> >> >>
> >> >> I notice that when all files are already copied, the commands still
> >> >> run extremely slowly. It takes just as long to copy all the files as
> >> >> it does to copy none of them.
> >> >>
> >> >> I used the Sysinternals tool called Process Monitor to see what CMake
> >> >> is doing as it runs copy_if_different. It's opening the full file and
> >> >> seems to be comparing actual contents instead of something simple,
> >> >> such as timestamp.
> >> >>
> >> >> I do not need such a thorough check, I simply want the check to see
> >> >> which timestamp is higher and copy if the source is newer than the
> >> >> target.
> >> >>
> >> >> Any reason why copy_if_different is so slow? Is my assumption correct?
> >> >> How can I make it faster?
> >> >
> >> > How about using plain "cmake -E copy ..." and rely on the timestamp
> &g
Re: [CMake] Poor performance of copy_if_different
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/my.dll
COMMAND cmake -E copy ${CMAKE_CURRENT_SOURCE_DIR}/my.dll
${CMAKE_CURRENT_BINARY_DIR}/my.dll
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/my.dll
)
add_custom_target(copy_dll ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/my.dll)
Whether you use 1 custom command per dll, or 1 for all dlls, is up to you. If
they usually change together, then you could have fewer custom commands. In
that case, the OUTPUT would have multiple files and both DEPENDS would have
multiple files.
Another alternative is to use add_custom_command(TARGET POST_BUILD ...) if
these are dlls that you compile yourself and need to copy after the build
step.
On Tuesday, November 06, 2012 11:23:03 AM Robert Dailey wrote:
> Also, is it safe to add 1 custom command for each DLL copy? Or would
> you somehow only use 1 custom command and copy them all with it? Also
> would I add the custom commands to the custom target?
>
> On Tue, Nov 6, 2012 at 11:11 AM, Clinton Stimpson
wrote:
> > On Tuesday, November 06, 2012 11:06:45 AM Robert Dailey wrote:
> >> I use ${CMAKE_COMMAND} -E copy_if_different to copy DLL files to my
> >> binary output directory. The custom target runs this command about
> >> 50-100 times (for that many files).
> >>
> >> I notice that when all files are already copied, the commands still
> >> run extremely slowly. It takes just as long to copy all the files as
> >> it does to copy none of them.
> >>
> >> I used the Sysinternals tool called Process Monitor to see what CMake
> >> is doing as it runs copy_if_different. It's opening the full file and
> >> seems to be comparing actual contents instead of something simple,
> >> such as timestamp.
> >>
> >> I do not need such a thorough check, I simply want the check to see
> >> which timestamp is higher and copy if the source is newer than the
> >> target.
> >>
> >> Any reason why copy_if_different is so slow? Is my assumption correct?
> >> How can I make it faster?
> >
> > How about using plain "cmake -E copy ..." and rely on the timestamp check
> > done by a custom command (add_custom_command()).
> > You need to make sure the input/ouput parts of the custom command are set
> > correctly so it can do a timestamp check.
> >
> > --
> > Clinton Stimpson
> > Elemental Technologies, Inc
> > Computational Simulation Software, LLC
> > www.csimsoft.com
> > --
> >
> > 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
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
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] Poor performance of copy_if_different
On Tuesday, November 06, 2012 11:06:45 AM Robert Dailey wrote:
> I use ${CMAKE_COMMAND} -E copy_if_different to copy DLL files to my
> binary output directory. The custom target runs this command about
> 50-100 times (for that many files).
>
> I notice that when all files are already copied, the commands still
> run extremely slowly. It takes just as long to copy all the files as
> it does to copy none of them.
>
> I used the Sysinternals tool called Process Monitor to see what CMake
> is doing as it runs copy_if_different. It's opening the full file and
> seems to be comparing actual contents instead of something simple,
> such as timestamp.
>
> I do not need such a thorough check, I simply want the check to see
> which timestamp is higher and copy if the source is newer than the
> target.
>
> Any reason why copy_if_different is so slow? Is my assumption correct?
> How can I make it faster?
How about using plain "cmake -E copy ..." and rely on the timestamp check done
by a custom command (add_custom_command()).
You need to make sure the input/ouput parts of the custom command are set
correctly so it can do a timestamp check.
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] GenerateExportHeader for module library
On Nov 1, 2012, at 8:01 AM, Stephen Kelly wrote:
> Gregoire Aujay wrote:
>
>> Hello,
>>
>> I am doing my tests with visual 2008 and mingw.
>>
>> As far as I understand a module is like a shared library that cannot be
>> linked. Instead it is dynamically loaded and then we find and use symbols
>> in it. It is like doing the linker's job manually at runtime.
>>
>> If nothing is exported from my module then I do cannot find any symbol in
>> it. Or at least I do not know how to do so.
>>
>> I modified the GenerateExportHeader module to be able to export symbols
>> from my MODULE:
>>
>> # if(${type} STREQUAL "MODULE")
>># message(WARNING "This macro should not be used with libraries of
>># type MODULE") return()
>> # endif()
>> if(NOT ${type} STREQUAL "STATIC_LIBRARY" AND NOT ${type} STREQUAL
>> "SHARED_LIBRARY" AND NOT ${type} STREQUAL "MODULE_LIBRARY")
>>message(WARNING "This macro can only be used with libraries")
>>return()
>> endif()
>>
>>
>> Regards,
>>
>> Gregoire
>>
>
> Please file a bug report so that this is not forgotten.
>
> Ideally also provide some code to test it. I'm not familiar with how plugins
> should be loaded in a cross-platform way (without Qt, that is).
>
Perhaps the BundleUtilities test can be modified to use GenerateExportHeader if
you need some coverage.
It also loads plugins at runtime (without Qt).
Clint
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake on Windows x64
On Monday, October 15, 2012 01:37:42 PM John Drescher wrote: > > Having CMAKE_SYSTEM_PROCESSOR be "x86" for a 64-bit build is very > > inconvenient when detecting machine-dependent compiler flags, > > constructing directory names for outputs based on configuration, > > configuring third party search directories, etc. It's always possible to > > work around (among other things, one can consult the generator string for > > Visual Studio builds, though not for MinGW builds) but that doesn't mean > > it shouldn't be better behaved - it's entirely reasonable to assume that > > CMAKE_SYSTEM_PROCESSOR should be the target processor for the build, > > especially so that you can have similar behavior on Windows, Linux, and > > Mac. Though as previously discussed I also have the opposite problem on > > Linux when compiling for 32-bit CPU on 64-bit OS. > I see. I have always compared the size of the pointer for this.. > > John Same here, I use CMAKE_CXX_SIZEOF_DATA_PTR if I need to know that info in a CMakeLists.txt file. Clint -- 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] QT4_WRAP_CPP and Implicit Dependencies
If you run moc on Main.h, which includes Dum.h, moc doesn't even open "Dum.h"
to scan its contents.
That tells me there is no way that moc would be required to rescan Main.h if
Dum.h is modified.
Clint
On Oct 10, 2012, at 10:32 PM, Miller, Frank wrote:
> Greetings,
>
> Suppose we have a header file, Dum.h, that is included by another header
> file, Main.h, and Main.h needs to be processed with the qt moc tool.
> When Dum.h changes, should we rerun moc on Main.h?
>
> QMake says yes. CMake, using QT4_WRAP_CPP, says no.
>
> I am inclined to believe qmake on this one. However, I have yet to think
> of a way to break a build by not rerunning moc. Is this a problem?
>
> Please pardon me if you think this question is in the wrong forum. I am
> asking here because I know there are a lot of qt users in this community
> and qmake is clearly not doing anything wrong.
>
> Here is a simple example:
>
>=== CMakeLists.txt ===
>cmake_minimum_required( VERSION 2.8.0 )
>project( mocdep )
>find_package( Qt4 REQUIRED )
>include( ${QT_USE_FILE} )
>include_directories( ${CMAKE_BINARY_DIR} )
>QT4_WRAP_CPP( mocdep_MOCSOURCES Main.h )
>add_executable( mocdep Main.cpp ${mocdep_MOCSOURCES} Main.h )
>target_link_libraries( mocdep ${QT_QTCORE_LIBRARY} ${QT_QTGUI_LIBRARY} )
>
>=== mocdep.pro ===
>HEADERS = Main.h Dum.h
>SOURCES = Main.cpp
>
>=== Dum.h ===
>#pragma once
>
>=== Main.h ===
>#pragma once
>#include "Dum.h"
>#include
>
>class MainWindow : public QMainWindow
>{
>Q_OBJECT
>};
>
>=== Main.cpp ===
>#include "Main.h"
>#include
>
>int main( int argc, char * argv[] )
>{
>QApplication app(argc, argv);
>
>MainWindow mainWindow;
>mainWindow.show();
>
>return app.exec();
>}
>
> Frank
>
> This communication, including any attachments, may contain information that
> is proprietary, privileged, confidential or legally exempt from disclosure.
> If you are not a named addressee, you are hereby notified that you are not
> authorized to read, print, retain a copy of or disseminate any portion of
> this communication without the consent of the sender and that doing so may be
> unlawful. If you have received this communication in error, please
> immediately notify the sender via return e-mail and delete it from your
> system.
> --
>
> 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] RPATH not set for "first" build library
This doesn't look like a cmake bug to me. Someone tried to "fix" dlopen() for this case you are demonstrating, when the --enable-new-dtags linker flag is used. http://sources.redhat.com/ml/libc-hacker/2002-10/msg00048.html But the patch was rejected because it was by design. http://sourceware.org/ml/libc-hacker/2002-11/msg00011.html If you add the --disable-new-dtags linker flag to your executables, they will both work. I would suggest using absolute paths to libraries you want to dlopen(). If you need help getting a path, you can use dladdr() to get the path of your executable. You can also put that code into a .so and it would give you a path to your .so in case it was different than your executable. Clint On Aug 25, 2012, at 9:52 AM, Martin Vogt wrote: > Hello, > > I have a library "A", which dlopens another library "B". > > But this does not work with cmake under the following circumstances: > > - in tree build > - library in another directory > > I have attached an example for the behaviour. > > The reason for this is, that cmake does not set the RPATH in library A, > and thus dlopen does not work on library B: > > library A: > >> readelf -d build/libmyopen.so >> [..] >> 0x0001 (NEEDED) Shared library: [libdl.so.2] >> 0x0001 (NEEDED) Shared library: [libc.so.6] >> 0x000e (SONAME) Library soname: [libmyopen.so] >> 0x000c (INIT) 0x648 > > The working version is a library A1 > >> readelf -d build/libmyopen1.so >> 0x0001 (NEEDED) Shared library: [libc.so.6] >> 0x000e (SONAME) Library soname: [libmyopen1.so] >> 0x000f (RPATH) Library rpath: >> [/tmp/rpath_not_set_in_first_lib/build] >> 0x001d (RUNPATH)Library runpath: >> [/tmp/rpath_not_set_in_first_lib/build] >> 0x000c (INIT) 0x678 > > The only difference between library A and library A1 is that > A1 is the "second" library in the cmake projekt. > Whereas "second"means, that A1 is linked against an arbitatry > other library in the project. > > This is from the demo project in the attachment: > > [/tmp/rpath_not_set_in_first_lib]$./build/works > dlopen start > [/tmp/rpath_not_set_in_first_lib]$./build/works_not > dlopen start > libdummy.so: cannot open shared object file: No such file or directory > [/tmp/rpath_not_set_in_first_lib]$ > > If this is a bug, I can open a bug report for this. > > regards, > > Martin > -- > > 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] CMake files for static builds of Qt 5
On Wednesday, August 22, 2012 05:03:47 PM Stephen Kelly wrote: > Forwarding to the cmake list. > > Context: We're discussing the patch at: > > https://codereview.qt-project.org/#change,33193 > > in which a line similar to (eg from QtCore.prl): > > QMAKE_PRL_LIBS = -lpthread -lz -licui18n -licuuc -lm -ldl -pthread - > lgthread-2.0 -lrt -lglib-2.0 > > The line in QtGui.prl looks like: > > QMAKE_PRL_LIBS = -L/usr/X11R6/lib64 -ljpeg -L/home/stephen/dev/src/qtbase- > static/lib -lQtCore -lz -licui18n -licuuc -lm -ldl -pthread -lgthread-2.0 > -lrt -lglib-2.0 -lpthread -lpng -lz -lGL > > is parsed out of files with an extension .prl which get shipped alongside > the Qt libraries (and are created as part of a Qt build). That string is > then used as the list of dependent libraries for the Qt targets for static > builds. > > This is for convenience, so that users of Qt do not have to specify the > static dependencies themselves, and so that I don't have to maintain the > list 'artificially' in the cmake files in Qt either. > > However, there are issues, see below: > > On Tuesday, August 21, 2012 16:52:19 Stephen Kelly wrote: > > On Tuesday, August 21, 2012 08:21:01 Clinton Stimpson wrote: > > > On Tuesday, August 21, 2012 01:32:33 PM Stephen Kelly wrote: > > > > This means adding a string of -L and -l entries to the > > > > LINK_INTERFACE_LIBRARIES, which isn't particularly nice, but I > > > > don't > > > > think > > > > it has a downside, unless you see one? > > > > > > Doesn't that add -L and -l entries for the Qt libraries themselves > > > as > > > well? > > > > Yes, it does. > > > > > For example, QtGui depends on QtCore, and is there a -lQtCore in > > > QtGui's prl file. > > > > Yes. I'm not really aware of what kinds of problems that causes though. > > > > > This kind of thing prevents being able to create cmake export files > > > and > > > have them work on other Linux machines which may have a different > > > location these system libraries. > > > > Yes, I suppose this set-up assumes that the static Qt and the user of it > > are built with the same environment. > > > > > Maybe we already had that problem, but with the old way, > > > we could fix the Find* files in CMake. With this way, we can't fix > > > the > > > prl > > > files. > > > > Yes, although prl files are also just text files. Arguably if someone is > > moving a Qt installation to another machine or environment (I'm not sure > > that's supposed to work anyway) maybe they should change those prl files > > too. > > > > Moving to a different machine/environment means that those libraries > > could have been built with different flags/be different versions etc. > > Building third party software against this 'moved' Qt might then be > > using a different static library than the Qt itself. Would you really > > expect that to work all the time? It sounds hacky to even attempt. > > > > > It feels like going against the grain of CMake's way of handling > > > libraries. > > > > Yes, but it is the maintainable solution unfortunately. > > So, for the cmake list - Is moving a static library (Qt in this case) to an > evironment different from the build environment expected to work? > > If QtCore is built statically against icuuc version 46 and then moved to an > environment where icu version 48 is available, but not 46, and you build > your software linked with the static Qt and the other version of icu, do > you expect it to work? Consdier the query repeated with any library > dependency you like. > > Thanks, To clarify, I wasn't talking about moving Qt. I was talking about a pre- compiled libraries that depend on Qt being put on another machine, along with their cmake export files. The QMAKE_PRL_LIBS has paths -L/usr/X11R6/lib64 -L/home/stephen/dev/src/qtbase-static/lib And I'm concerned those paths would show up in the export file. Also, I dislike adding "-L/home/stephen/dev/src/qtbase-static/lib -lQtCore" when we already have /home/stephen/dev/src/qtbase-static/lib/libQtCore.so when using QtGui. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake is unable to find QtCore!
Did you make the mistake of relocating your Qt installation? You could run qmake -query to see the paths it prints out, to make sure it matches your installation. Clint On Aug 12, 2012, at 12:59 PM, Toronto Andrew wrote: > Yes to both John, I did point the CMake gui to the position of the qmake.exe > within the bin, and it does come with whatever DLLs the source comes with. > > I am using Qt 4.8.0 and the latest CMake gui for Windows (x86). > > Some other things to get out of the way: > QTDIR is set to C:/Qt/4.8.0/bin, and this directory has been added to the > list of PATH variables... > > > > -- > View this message in context: > http://cmake.3232098.n2.nabble.com/CMake-is-unable-to-find-QtCore-tp7581149p7581154.html > Sent from the CMake mailing list archive at Nabble.com. > -- > > 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] Disabling C for C++-only projects
On Wednesday, July 25, 2012 10:06:27 PM Johannes Zarl wrote: > Hi, > > Out of curiosity (and thinking about saving a couple of seconds during the > first cmake run) I tried just to use C++ as language for some KDE program. > > It turns out that without C enabled, standard modules like FindKDE, FindQt4 > and FindJPEG don't run because they use the CheckSymbolExists module. > > I'm wondering if this counts as a bug in FindQt4 and FindKDE, because after > all these two projects are C++, so any platform test should IMO be using the > same compiler as the build-process does? > This has already been fixed in FindQt4 since CMake 2.8.6. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] fixup_bundle() doesn't like libglut.3.dylib
o classify it as a system library, you can > > >> >> > provide a > > > > CMake > > > > >> >> > function named gp_resolved_file_type_override to look > > >> >> > for that > > >> >> > library > > >> >> > (probably anything starting with "/usr/X11/lib") and set > > >> >> > its type > > > > to > > > > >> >> > "system" -- that will cause fixup_bundle to ignore it > > >> >> > for copying > > > > and > > > > >> >> > fixup purposes. > > >> >> > > > >> >> > > > >> >> > HTH, > > >> >> > David > > >> >> > > > >> >> > > > >> >> > On Mon, May 7, 2012 at 10:57 AM, Joe Ping-Lin Hsiao > > >> >> > > > >> >> > > > >> >> > wrote: > > >> >> >> Hi, > > >> >> >> > > >> >> >> I use CMake to create an installer for a Mac program > > >> >> >> which uses > > >> >> >> GLUT. > > >> >> >> The GLUT library that the program links against with > > >> >> >> is > > >> >> >> /usr/X11/lib/libglut.dylib. > > >> >> >> > > >> >> >> When I use fixup_bundle() to create an installer, I > > >> >> >> get the > > >> >> >> following > > >> >> >> error message: > > >> >> >> > > >> >> >> install_name_tool: changing install names or rpaths > > >> >> >> can't be > > > > redone > > > > >> >> >> for: > > /Users/phsiao/dev/video/video_spot_tracker.app/Contents/MacOS/libglut.3. > > dylib> > > >> >> >> (for architecture ppc7400) because larger updated load > > >> >> >> commands do not > > >> >> >> fit (the program must be relinked, and you may need to > > >> >> >> use > > >> >> >> -headerpad > > >> >> >> or -headerpad_max_install_names) > > >> >> >> > > >> >> >> The first thing I tried was to add > > >> >> >> -headerpad_max_install_names > > > > and > > > > >> >> >> -headerpad to the linker flags, but no success. > > >> >> >> (Actually > > >> >> >> -headerpad_max_install_names already exists in > > >> >> >> CMakeFies/link.txt before I put it in.) > > >> >> >> > > >> >> >> The next thing I tried was to add '-arch x86_64' to > > >> >> >> both CXX_FLAGS and > > >> >> >> LINKER_FLAGS to avoid fixup_bundle() to fix > > >> >> >> dependencies for > > >> >> >> architecture ppc7400, but the error remains. > > >> >> >> > > >> >> >> Any idea how to get around this? > > >> >> >> > > >> >> >> Thanks, > > >> >> >> Joe > > >> >> >> -- > > >> >> >> > > >> >> >> 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 -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] relocatable build directory: howto?
On May 5, 2012, at 5:52 AM, Dave Abrahams wrote: > > on Sat May 05 2012, Michael Wild > wrote: > >> On 05/05/2012 07:25 AM, Dave Abrahams wrote: >>> >>> I need to preserve the built-but-not-yet-installed state of some >>> projects, and the tool I'm driving CMake with moves the result of every >>> build step from a read-write build directory into a readonly cache. The >>> result is that the generated cmake_install.cmake files no longer work, >> >>> because they are full of absolute paths. I wrote a simple program to >>> adjust the paths in the cmake_install.cmake files as a postprocessing >>> step, replacing $CWD, where it is found, with a cmake variable. The >>> only problem: on my Mac, /tmp is a symlink to /private/tmp, and in some >>> scenarios the absolute path in cmake_install.cmake is the short one >>> wheras while $CWD is the long one. No match :( >>> >>> I started to write some code to address this problem, but it's getting >>> complex to the point where it seems like "there must be a better way." >>> So I ask: is there? >>> >>> Thanks in advance, >>> >> >> I'm afraid that the answer is no. There is the variable >> CMAKE_USE_RELATIVE_PATHS, but that is broken and does not work in >> general. Just out of curiosity: Why do you need to cache the build tree >> in the first place? > > I'm driving CMake with a package installation system (0install) that > doesn't allow for subpackages (it may someday, but that's not supported > as of now). This system installs packages into a cache. It's > undesirable to have to build a cmake package twice just to produce its > -dev (on windows, includes import libraries) and -bin (includes > DLLs/so's) incarnations. The way we deal with that now is to make the > preinstall (built) state a separate 0install package and let 0install > put that in the cache, then come back later and install from that > package. > > Which reminds me; it would be awesome if there were a way to get cmake > to clean everything but the leaves in its dependency graph. IOW, I'd > like to throw out all the .o files after having built libraries. Is > there a way? > >> Would it be enough to "make install DESTDIR=/path/to/cache"? > > Only if I want to build twice. > In case its applicable, I just thought I'd mention that you can run "cmake -P cmake_install.cmake " if you want to customize the installation of the files, even putting the -dev files in one place and the -bin in another, then run you own packaging tool on those directories afterwards. Maybe you could cache those directories instead of the build tree, or was there something else you still needed from the build tree? Clint -- 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] CCTray like tool for CDash?
CDash has RSS functionality. Perhaps there is already a client you can use with that to give you a popup for new submissions. On Wednesday, April 18, 2012 11:59:46 am noru...@me.com wrote: > Is someone interested in such a tool? > Does CDash have any callback functionality? > > Best Regards > > Am 18.04.2012 um 07:41 schrieb noru...@me.com: > > Yes, it is a notification client for cruise control to get information > > from the build server without opening a web browser every time. > > > > You could also manage projects on the build server. > > > > It is a small app which runs as a system tray to show the status of the > > builds. > > > > Best Regards > > NoRulez > > > > Am 17.04.2012 um 19:49 schrieb Eric Noulard : > >> 2012/4/17 Alexander Neundorf : > >>> On Monday 16 April 2012, NoRulez wrote: > >>>> Hello, > >>>> > >>>> is there a tool for CDash which is equivalent to CCTray for Cruise > >>>> Control or is such tool planned? > >>> > >>> what is CCTray ? > >> > >> seems to be a notification application for continuous integration > >> system: http://ccnet.sourceforge.net/CCNET/CCTray.html > > > > -- > > > > 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 -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] FindQt4 with Official Nokia install
On Monday, January 09, 2012 11:26:15 am Michael Jackson wrote: > I am having an issue with my project compiling against the Official Nokia > Qt4 downloaded from Nokia. The issue (I think) is that for some reason > when FindQt4 is running it determines that QT_USE_FRAMEWORKS is false and > so I don't get all of the proper include directories. Namely the > -F/Path/To/Frameworks on the compile line which makes code like > > #include fail. > > Is anyone else having issues compiling their projects against the > official Nokia Qt downloads? I usually build Qt myself but a colleague of > mine is using the prebuilt binaries and ran into this problem. > > Thanks for any sanity check. Just trying to figure out where the possibly > bug lies. I am going to assume it is in my code somewhere since I don't > remember any one else complaining about the same thing. > It works for me. But perhaps you're hitting a bug that was fixed in CMake 2.8.6. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] Interrupt problems in cmake-gui
Yeah it does look like synchronization is needed to fix this. The current interrupt functionality depends on message output or progress reporting to actually process the interrupt on the worker thread, which isn't good enough. I'm not sure if you've considered this, but it seems simpler to add an interrupt callback in cmSystemTools, much like the callbacks work for stdout/stderr. Then cmake-gui could register an interrupt callback and coordinate that with the button click. The synchronization of a simple flag can then be handled within cmake-gui using QAtomicInt. Clint On Dec 30, 2011, at 6:10 PM, Robert Dailey wrote: > I don't know much about Qt, but what I do know is the fix involves using a > direct connection. In CMakeSetupDialog::doInterrupt(), I changed the > invokeMethod() command to use Qt::DirectConnection. > > However, this solution is not thread safe, hence why I asked about > synchronization. I could implement a multiple-reader/single-writer lock, but > I'd much rather use Boost.Thread, but this would require introducing the > boost library into the cmake build. > > The following methods in cmSystemTools need to be made thread-safe (using a > combination of read locks & writer locks). Qt has a reader/writer lock but I > can't use this in cmSystemTools, since it will require cmake.exe to depend on > Qt, which doesn't make much sense. > > GetErrorOccuredFlag() > SetFatalErrorOccured() > GetFatalErrorOccured() > ResetErrorOccuredFlag() > > I was thinking of turning cmSystemTools into a singleton (you would have a > static instance() method and access members through that) and using > inheritance to implement a thread-safe variant of this class. I could create > thread-safe overrides the above methods and utilize polymorphism to access > the thread safe version in cmake-gui, whereas cmake.exe would not use it, > since by itself it does not need it. > > I'd like to introduce boost into CMake for this. > > If you can find a better implementation that'd be great, I haven't been > working with the CMake code base as long as you guys have, so you probably > know an easier fix. The main issue is that the blocking functions (such as > while, foreach) do not return control to Qt until after they are done > executing, and the only way to reliably interrupt them is by setting the > fatal error flag. It requires no additional interrupt logic. These are the > findings of my investigation and debugging. > > Thanks in advance for your input. > > - > Robert Dailey > > > On Fri, Dec 30, 2011 at 12:53 PM, clin...@elemtech.com > wrote: > There isn't a lock. > > Synchronization is done by threads having event loops and calling Qt slots in > a queued fashion (like posting messages to the other event queue). > > I imagine you just need to add another place where the interrupt is checked > and gracefully return (which should take you back to the event loop). > > Clint > > > - Reply message - > From: "Robert Dailey" > Date: Fri, Dec 30, 2011 10:07 am > Subject: [CMake] Interrupt problems in cmake-gui > To: "CMake ML" > > I found the problem in code and currently have a fix. However, the code > change requires some thread synchronization. Does anyone know if there is a > reader/writer lock object in the CMake source code? > > - > Robert Dailey > > > On Fri, Dec 30, 2011 at 9:58 AM, Robert Dailey wrote: > I have a foreach/while loop that checks if files exist. The files it is > checking are on a Windows network share. So, each check takes a while. > Sometimes after I click "Configure" in cmake-gui.exe, I want to click "Stop" > during this check. However, the stop does not seem to interrupt the loop. I > know this because let's say the whole loop takes 20 seconds to complete. If I > let the loop run without clicking stop, it takes 20 seconds. If I click stop > at about 10 seconds, then 10 seconds later it stops. In other words, clicking > stop does not take affect until 20 seconds have passed anyway. So it > obviously isn't stopping it. My loops basically look like this: > > while() >foreach() > if( EXISTS ) > endif() >endforeach() > endwhile() > > If I am checking 20 files, each check takes about 1 second to equal a total > time of 20 seconds. So, at most, after clicking stop, there should be a 1 > second wait time. > > Can anyone verify that while/foreach loops can or cannot be interrupted by > cmake-gui? > > - > Robert Dailey > > -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: Fwd: cpack DragNDrop on OSX 10.7
mental" on the recent cmake from > >>> git, you find the result here: > >>> http://www.cdash.org/CDash/buildSummary.php?buildid=1836104 > >>> > >>> I noticed one test related to BundleUtilities failed, but I don't know > >>> if it is related? > >>> > >>> Cheers, > >>> Yngve > >>> > >>> On 19 December 2011 16:47, David Cole wrote: > >>>> Use "--verbose" on the CPack command line to get more information > >>>> about why it's failing. > >>>> > >>>> Also, look for log files under the _CPack_Packages directory to see if > >>>> there are any additional details in there. > >>>> > >>>> Does it happen consistently every time you run cpack, or is it > >>>> sporadic? > >>>> > >>>> We frequently see errors from Apple's hdiutil command line tool on the > >>>> CMake dashboard, but it does not happen every time. It happens more > >>>> often than we would like, but it very often works the next time we > >>>> try, so we have not pursued coming up with a work-around too > >>>> aggressively. > >>>> > >>>> > >>>> HTH, > >>>> David > >>>> > >>>> > >>>> On Mon, Dec 19, 2011 at 10:39 AM, Yngve Levinsen > >>>> > >>>> wrote: > >>>>> Dear developers, > >>>>> > >>>>> I am using DragNDrop packaging, and suddenly now when I upgraded to > >>>>> 10.7 there seem to be a problem somewhere. I noticed it just after > >>>>> the upgrade to 10.7 but it could of course be unrelated. I use CMake > >>>>> version 2.8.6 installed using Homebrew. > >>>>> > >>>>> Somehow when I run "cpack -G DragNDrop" the bundles are not added to > >>>>> the dmg. I am using the fixup_bundle() to add all libraries, which > >>>>> then fails because the .app doesn't exist in the _CPack_Packages > >>>>> directory. The bundle is created and I noticed that it is added if I > >>>>> use e.g. the ZIP generator instead. > >>>>> > >>>>> Anyone else can confirm this? I tried to search for it in the > >>>>> archives, but I could not find it. > >>>>> > >>>>> Best Regards, > >>>>> Yngve I. Levinsen > >>>>> -- > >>>>> > >>>>> 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 > > -- > > 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 -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] import/export and DLL's
> > See also the "new in 2.8.6" module GenerateExportHeader: > > > http://cmake.org/cmake/help/cmake-2-8-docs.html#module:GenerateExportHeade > r > > cmake --help-module GenerateExportHeader > > I see the header has this: #ifdef IS_STATIC_BUILD ... #else ... #endif Is there any way to generate this configured header for a static or for a shared build, so one doesn't have to add preprocessor defines to use the header file? -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] 2D arrays
How about the following two examples for a table or 2d array.
In the first one, each column can have a name too. Its like an array of
pointers in C++.
set(fruits apple orange banana)
set(animals cat dog elephant)
set(columns fruits animals)
foreach(column ${columns})
foreach(item ${${column}})
message("${column} has item ${item}")
endforeach()
endforeach()
Or if you have pairs, one fruit with one animal
set(tuples
"apple\;cat"
"orange\;dog"
"banana\;elephant"
)
foreach(pair ${tuples})
message("pair has items ${pair}")
foreach(component ${pair})
message("component = ${component}")
endforeach()
endforeach()
Both of those seem close enough to 2d array functionality using the cmake
language.
Clint
On Nov 29, 2011, at 4:28 PM, Robert Dailey wrote:
> I have created a pretty clean solution to this until there is native support
> for multi-dimensional arrays in CMake. I have attached the module, hopefully
> it will prove useful to others. Here is an example of how to use it:
>
> set( two_dee_array
> apple cat
> orange dog
> banana elephant
> )
>
> array2d_begin_loop( advanced "${two_dee_array}" 2 "fruit;animal" )
> while( advanced )
> message( "Fruit: ${fruit}" )
> message( "Animal: ${animal}" )
> array2d_advance()
> endwhile()
>
> -
> Robert Dailey
>
>
> On Mon, Nov 28, 2011 at 2:31 PM, Robert Dailey wrote:
> Is it possible to have 2D arrays in CMake? As far as the core syntax is
> concerned, it seems like only 1D arrays are supported. So far I've had to
> work around this issue by using a flat array and skipping over elements using
> foreach() with a range and step.
>
> Any ideas? Thanks.
>
> -
> Robert Dailey
>
> --
>
> 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] CMake, Qt4, Ubuntu and Phonon
On Tuesday, November 22, 2011 02:34:55 pm Félix C. Morency wrote: > As we pointed out in the bug thread located at > > https://bugs.launchpad.net/ubuntu/+source/phonon/+bug/893170 > > the FindPhonon script is not portable to Windows. I agree with André's > comment: the source of the problem is the Ubuntu way of distributing > Qt4 and Phonon. > > We also have to keep in mind that the official CMake module FindQt4 > doesn't actually find Qt4 correctly on Ubuntu. I think this is a > problem for both Ubuntu and CMake. The two solutions to this problem I > can think of are 1) Patch the FindQt4 script so it can find Phonon > correctly when not distributed with Qt4 and 2) Make pressure on the > Ubuntu community so it distribute Phonon as a Qt4 (optional) package > (like Debian does). > > I would like to have your feedback on this issue so we can discuss > alternative solutions. Feel free to comment on the bug report to make > pressure on the Ubuntu community. > > I would be happy to patch the FindQt4 module if the community agrees > on this solution. Does it work if one is using qmake simply because phonon is in the linker's standard search paths? Or does qmake on Ubuntu know how to find phonon? phonon is treated as a Qt module as far as qmake and FindQt4.cmake are concerned, and not as a 3rd party library, like zlib and others. But, I'm not opposed to modifying FindQt4.cmake, but I have a concern if one builds their own Qt (different version) without phonon, is it OK to find /usr/lib/libphonon.so? -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] Problem with LINK_DIRECTORIES
>From the Modules/Platform/* files, it looks like the only difference between
>the
two is when using CYGWIN or MinGW. I'm not sure which to use.
Clint
On Monday, November 14, 2011 01:51:49 pm Robert Dailey wrote:
> What is the difference between CMAKE_LINK_LIBRARY_SUFFIX and
> CMAKE_IMPORT_LIBRARY_SUFFIX? Which should I use?
>
> -
> Robert Dailey
>
> On Mon, Nov 14, 2011 at 2:49 PM, Clinton Stimpson
wrote:
> > That's what I do sometimes. To make that easier, CMake gives some
> > convenience
> > variables for library prefixes and suffixes if you are on multiple
> > platforms.
> >
> > Clint
> >
> > On Monday, November 14, 2011 01:20:29 pm David Cole wrote:
> > > If you already know where all the libraries are, please just use the
> > > full paths to those libraries, and do not use find_library.
> > >
> > > On Mon, Nov 14, 2011 at 3:15 PM, Robert Dailey
> >
> > wrote:
> > > > On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling
> > > > > > >
> > > > wrote:
> > > >> On 11/14/2011 06:17 PM, Robert Dailey wrote:
> > > >> > Well maybe you can tell me I'm doing this wrong then, but based on
> >
> > how
> >
> > > >> >I
> > > >> >
> > > >> > am
> > > >> > currently setting up my third party libraries, it is required.
> > > >> >
> > > >> > So basically all third party libraries we use are not installed
> > > >> > individually, instead we have a server on our intranet that
> > > >> > contains precompiled versions of all libraries in a specific and
> > > >> > consistent hierarchy. For this reason, it doesn't make sense to
> > > >> > use
> > > >> > find_library(), which would normally always give you absolute
> > > >> > paths to your library files
> > > >> > and thus link_directories() would not be needed.
> > > >> >
> > > >> > Instead I have a script in CMake that iterates each third party
> > > >> > library and
> > > >> > adds its lib link directory to a list. When done I take this whole
> > > >> > list of
> > > >> > link directories and pass it to link_directories() in my top level
> > > >> > CMakeLists file, this way each and every project will include all
> > > >> > of the third party library lib directories to have access to
> > > >> > them.
> > > >>
> > > >> Instead of populating a list with the libraries' directories, you
> >
> > might
> >
> > > >> set up one variable for each library containing the latter's full
> >
> > path,
> >
> > > >> e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the
> > > >> top-level CMakeLists.txt, these variables propagate to subordinate
> >
> > CMakeLists.txt
> >
> > > >> files and, thus, will be known wherever they are needed in your
> >
> > project.
> >
> > > >> > For each target I simply create a list of my libs, like so:
> > > >> >
> > > >> > set( libraries zlib libbdb47 )
> > > >>
> > > >> SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})
> > > >>
> > > >> > I pass each one of these to target_link_libraries() and I leave it
> >
> > up
> >
> > > >> > to the compiler to search for where to find the file in the
> > > >> > provided link directories.
> > > >>
> > > >> An unrestricted use of LINK_DIRECTORIES() means asking for trouble;
> > > >> especially with numerous directories, there's a growing probability
> > > >> that the -L option will lure the linker into a wrong directory some
> > > >> day. There're even situations which can't be resolved with -L/-l at
> > > >> all: Suppose you have a directory x with liba.so and libb.so, and a
> > > >> directory y with different versions of lib{a,b}.so. Suppose further
> > > >> you want to link against x/liba.so and y/libb.so. How do you achieve
> > > >> this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,
> > > >> insisting on the use of LINK_DIRECTORIES() limits the possibilities
> > > >> how to organize the libraries on your intranet serv
Re: [CMake] Problem with LINK_DIRECTORIES
not have a > > pre-packaged Find module provided by CMake. This means I'd end up > > writing 80% of the find modules myself. This is a lot of work for no > > perceived benefit. > > With my points made and circumstances explained, can you still give me a > > good reason to use find_library? > > I understand and agree with the issues that come with using > > link_directories(), however I haven't run into those issues yet and our > > consistent organization of third party libraries on our intranet server > > are carry over from our legacy build system that I'm replacing. > > -- > > > > 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 -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.8.5 qt4 macros and file names with parentheses
On Monday, October 31, 2011 02:39:16 pm Pierre-Francois Laquerre wrote:
> Short version: shouldn't the macros in Modules/Qt4Macros.cmake call
> ADD_CUSTOM_COMMAND with VERBATIM?
Yes, it looks like it should. Can you add a bug in the bug tracker?
Thanks,
Clint
>
> Long version:
>
> I'm trying to build
> https://github.com/pflaquerre/torch/tree/build-under-path-with-parentheses
> with cmake 2.8.5. It works fine when building in, say, /tmp/test/, but
>
> not in /tmp/test(foo):
> > cd "/tmp/test(foo)/build.rel/qtlua/qlua" && /usr/lib64/qt4/bin/rcc -name
> > qlua -o /tmp/test(foo)/build.rel/qtlua/qlua/qrc_qlua.cxx
> > /tmp/test(foo)/qtlua/qlua/qlua.qrc /bin/sh: -c: line 0: syntax error
> > near unexpected token `('
> > /bin/sh: -c: line 0: `cd "/tmp/test(foo)/build.rel/qtlua/qlua" &&
> > /usr/lib64/qt4/bin/rcc -name qlua -o
> > /tmp/test(foo)/build.rel/qtlua/qlua/qrc_qlua.cxx
> > /tmp/test(foo)/qtlua/qlua/qlua.qrc' make[2]: ***
> > [qtlua/qlua/qrc_qlua.cxx] Error 1
> > make[2]: Leaving directory `/tmp/test(foo)/build.rel'
> > make[1]: *** [qtlua/qlua/CMakeFiles/libqlua.dir/all] Error 2
> > make[1]: Leaving directory `/tmp/test(foo)/build.rel'
> > make: *** [all] Error 2
>
> The issue is obviously the lack of quotes around the paths, but I'm
> not sure what is causing it. One of the offending cmake files is
> https://github.com/pflaquerre/torch/blob/build-under-path-with-parentheses/
> qtlua/qlua/CMakeLists.txt, which calls MACRO_QT4_AUTOGEN from
> https://github.com/pflaquerre/torch/blob/build-under-path-with-parentheses/
> qtlua/cmake/MacroQt4AutoGen.cmake, which in turn calls the cmake macros
> QT4_WRAP_UI, QT4_ADD_RESOURCES, QT4_WRAP_CPP and QT4_GENERATE_MOC.
> However, it doesn't seem like those cmake files are doing anything wrong
> as far as quoting goes. I had a look at the latest Modules/Qt4Macros.cmake
> on github and noticed that there are a few places where
ADD_CUSTOM_COMMAND
> is not called with VERBATIM. For instance, QT4_CREATE_MOC_COMMAND only
> uses VERBATIM on
>
> WIN32:
> > MACRO (QT4_CREATE_MOC_COMMAND infile outfile moc_flags moc_options)
> >
> > # For Windows, create a parameters file to work around command line
> >length limit IF (WIN32)
> ># Pass the parameters in a file. Set the working directory to
> ># be that containing the parameters file and reference it by
> ># just the file name. This is necessary because the moc tool on
> ># MinGW builds does not seem to handle spaces in the path to the
> ># file given with the @ syntax.
> >GET_FILENAME_COMPONENT(_moc_outfile_name "${outfile}" NAME)
> >GET_FILENAME_COMPONENT(_moc_outfile_dir "${outfile}" PATH)
> >IF(_moc_outfile_dir)
> > SET(_moc_working_dir WORKING_DIRECTORY ${_moc_outfile_dir})
> >ENDIF(_moc_outfile_dir)
> >SET (_moc_parameters_file ${outfile}_parameters)
> >SET (_moc_parameters ${moc_flags} ${moc_options} -o "${outfile}"
> >"${infile}") STRING (REPLACE ";" "\n" _moc_parameters
> >"${_moc_parameters}") FILE (WRITE ${_moc_parameters_file}
> >"${_moc_parameters}")
> >ADD_CUSTOM_COMMAND(OUTPUT ${outfile}
> > COMMAND ${QT_MOC_EXECUTABLE}
> >@${_moc_outfile_name}_parameters DEPENDS ${infile}
> > ${_moc_working_dir}
> > VERBATIM)
> > ELSE (WIN32)
> >ADD_CUSTOM_COMMAND(OUTPUT ${outfile}
> > COMMAND ${QT_MOC_EXECUTABLE}
> > ARGS ${moc_flags} ${moc_options} -o ${outfile}
> >${infile} DEPENDS ${infile})
> > ENDIF (WIN32)
> >
> > ENDMACRO (QT4_CREATE_MOC_COMMAND)
>
> Is this on purpose? Adding VERBATIM to the ADD_CUSTOM_COMMAND calls in
> that file solved the quoting issue and allowed me to build without any
> problems. Is that project just misusing cmake, or is it really a
> problem with Qt4Macros.cmake?
>
> Regards,
>
> Pierre-Francois
> --
>
> 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
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
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] Windows installer creating duplicate entries in Add/Remove Programs
On Thursday, October 27, 2011 12:11:36 pm Robert Dailey wrote: > On Thu, Oct 27, 2011 at 1:10 PM, Clinton Stimpson wrote: > > On Thursday, October 27, 2011 12:03:20 pm Robert Dailey wrote: > > > *cricket... cricket...* > > > > > > - > > > Robert Dailey > > > > > > On Tue, Oct 25, 2011 at 1:19 PM, Robert Dailey > > > > wrote: > > > > I noticed that when I install CMake 2.8 updates, I get duplicate > > > > entries > > > > > > in "Programs and Features" in windows 7 (the Add/Remove programs > > > > area). > > > > > > > > This seems like a bug. I searched the bug database but didn't find > > > > anything on this. > > > > > > > > Can anyone confirm? > > > > > > > > - > > > > Robert Dailey > > : > > :) Yeah it looks like a bug to me. > > > > The culprit is in CMakeCPack.cmake where it sets > > CPACK_PACKAGE_INSTALL_REGISTRY_KEY. > > > > That registry key is patch version specific, while the default install > > directory is minor version specific. So overwriting a previous install > > will > > still create a new set of registry keys, and a new entry in Add/Remove > > programs. > > Is there a bug open for this? If so please link it so I can add it to the > bugs to fix thread for the next release :P I was not able to find an open bug for this. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] Windows installer creating duplicate entries in Add/Remove Programs
On Thursday, October 27, 2011 12:03:20 pm Robert Dailey wrote: > *cricket... cricket...* > > - > Robert Dailey > > On Tue, Oct 25, 2011 at 1:19 PM, Robert Dailey wrote: > > I noticed that when I install CMake 2.8 updates, I get duplicate entries > > in "Programs and Features" in windows 7 (the Add/Remove programs area). > > > > This seems like a bug. I searched the bug database but didn't find > > anything on this. > > > > Can anyone confirm? > > > > - > > Robert Dailey :) Yeah it looks like a bug to me. The culprit is in CMakeCPack.cmake where it sets CPACK_PACKAGE_INSTALL_REGISTRY_KEY. That registry key is patch version specific, while the default install directory is minor version specific. So overwriting a previous install will still create a new set of registry keys, and a new entry in Add/Remove programs. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] Problem with QT3 not generating .cpp files using Cmake
Not sure if this is the whole reason, but it looks like you are missing the
${SAMPLE_FORMS_CPP} in add_executable().
Clint
On Tuesday, October 11, 2011 09:46:40 am Darrell Langford wrote:
> Okay, the problem I am having is as follows. I am converting a C++ QT3
> program over from using qmake to cmake and have hit a snag.
>
> The following is my basic layout for the cmakelists.txt file, what happens
> is, when the UIC command gets called from the QT_WRAP_UI it doesn't
> generate out .cpp files, just the .h files.
>
> In qmake for qt3, every .ui file when it goes through UIC gets it's own .h
> and .cpp file, and the .ui.h is your own implementation of some of the
> functions. So Although everything builds, when it hits time to link, it
> has tons of undefined references to itself, because the actual
> implementations never got generated.
>
> Any help or suggestions would be greatly appreciated.
>
> CMakeLists.txt
> #**
> # Find QT
>
> FIND_PACKAGE(Qt3 REQUIRED)
>
> ADD_DEFINITIONS(${QT_DEFINITIONS})
> INCLUDE_DIRECTORIES(${QT_INCLUDE_DIR}
> ${CMAKE_CURRENT_BINARY_DIR}
>
> ${CMAKE_CURRENT_SRC_DIR})
>
> SET(SAMPLE_SOURCES main.cpp
> Sample.cpp
> UIImpl.cpp )
>
> SET(SAMPLE_HEADERS UIImpl.h
>Sample.h )
>
> SET(SAMPLE_HEADERS_UI_H SampleControl.ui.h
>SampleControl2.ui.h)
>
>
> SET(SAMPLE_FORMS SampleControl.ui
> SampleControl2.ui )
>
> QT_WRAP_UI(SAMPLEAPP SAMPLE_FORMS_H SAMPLE_FORMS_CPP ${SAMPLE_FORMS})
> QT_WRAP_CPP(SAMPLEAPP SAMPLE_HEADERS_MOC ${SAMPLE_HEADERS}
> ${SAMPLE_FORMS_H})
>
>
>
>
> link_directories(${PROJECT_BINARY_DIR}/src
> ${PROJECT_SOURCE_DIR}/../lib
> ${CMAKE_CURRENT_BINARY_DIR})
>
>
> add_executable(SAMPLEAPP ${SAMPLE_SOURCES}
> ${SAMPLE_HEADERS_MOC}
> ${SAMPLE_FORMS_HEADERS}
> ${SAMPLE_HEADERS_UI_H}
> )
> target_link_libraries(SAMPLEAPP ${QT_LIBRARIES})
> #**
>
>
> Snippet out of my actual build.make file that is generated from cmake
>
> src/SampleControl.h: ../src/SAMPLEAPP/ui/SampleControl.ui
> $(CMAKE_COMMAND) -E cmake_progress_report SAMPLEAPP/build/CMakeFiles
> $(CMAKE_PROGRESS_22) @$(CMAKE_COMMAND) -E cmake_echo_color
> --switch=$(COLOR) --blue --bold "Generating SampleControl.h"
> SAMPLEAPP/build/src && /usr/bin/uic-qt3 -o
> SAMPLEAPP/build/src/SampleControl.h
> SAMPLEAPP/src/SAMPLEAPP/ui/SampleControl.ui
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
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] FindQt4
On Friday, September 30, 2011 03:54:26 pm MM wrote:
> hi,
>
> I generated a msvc10 solution with cmake 2.8.5.
>
> I use the following in the project's CMakeLists.txt
> FIND_PACKAGE(Qt4 4.5.3 COMPONENTS QtCore QtGui QtOpenGL REQUIRED)
> IF(QT4_FOUND)
> INCLUDE(${QT_USE_FILE})
> TARGET_LINK_LIBRARIES(nhui ${QT_LIBRARIES})
> ELSE()
> MESSAGE(FATAL_ERROR "Qt>=4.5.3 not found")
> ENDIF()
>
> opening the solution in vs2010 and linking against qwtplot3d required
> adding these 2 libs on winxp32bit
> OpenGL32.Lib et GlU32.Lib
>
> I would have thought QtOpenGL4.lib required these above 2 libs and so
> FindQt4 would have added them automatically?
>
QtOpenGL4.dll needs those libraries, but that doesn't necessarily mean users
of that library need to link with opengl32.lib and glu32.lib also.
If your code needs to link with opengl32.lib, then you can use
find_package(OpenGL) and target_link_libraries().
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.6 available for download
On Wednesday, October 05, 2011 09:53:53 am Alexander Neundorf wrote: > On Wednesday 05 October 2011, Clinton Stimpson wrote: > > On Wednesday, October 05, 2011 08:29:00 am Marcus D. Hanwell wrote: > > > On Wed, Oct 5, 2011 at 6:53 AM, Peter Kuemmel wrote: > > > > When I install the .sh version over an existing 2.8.4 release > > > > and use "CodeBlocks - Unix Makefiles" QtCreator only shows the > > > > CMakeLists.txt, nothing more. > > > > > > > > Seems the "CodeBlocks - Unix Makefiles" generator is broken in 2.8.6. > > > > > > > > The entry > > > the two generated .cbp files. > > > > > > I just tried this with CMake compiled from master, on a fresh ParaView > > > build tree (hadn't made one in a while) using, > > > > > > cmake -G "CodeBlocks - Unix Makefiles" ~/ssd/src/ParaView > > > > > > I was able to open the resulting build directory in Qt Creator 2.3.1 > > > and see all of the source files etc. I can dig a little deeper if you > > > let me know what version of Qt Creator you are using, a project you > > > see the issue with etc. I could also give the installer a try if the > > > problem persists (I normally just build from source and current CMake > > > master is 2.8.6). > > > > So I see that one of my projects has this problem. > > I've narrowed it down to this commit: > > http://cmake.org/gitweb?p=cmake.git;a=commit;h=a5683f8 > > > > If I remove the code that commit adds, from the current HEAD, then my > > problem goes away. > > > > When checking the XML, it complained about a few lines that looked like > > this: > > > > So it appears that code doesn't handle preprocessor defines with quoting. > > Can you please create a ticket in the bugtracker and attach such a bad > project file ? > > Thanks > Alex Oh, do you still want this in the bug tracker? It was a simple fix. http://cmake.org/gitweb?p=cmake.git;a=commit;h=240d39 -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.8.6 available for download
On Wednesday, October 05, 2011 08:29:00 am Marcus D. Hanwell wrote: > On Wed, Oct 5, 2011 at 6:53 AM, Peter Kuemmel wrote: > > When I install the .sh version over an existing 2.8.4 release > > and use "CodeBlocks - Unix Makefiles" QtCreator only shows the > > CMakeLists.txt, nothing more. > > > > Seems the "CodeBlocks - Unix Makefiles" generator is broken in 2.8.6. > > > > The entry > the two generated .cbp files. > > I just tried this with CMake compiled from master, on a fresh ParaView > build tree (hadn't made one in a while) using, > > cmake -G "CodeBlocks - Unix Makefiles" ~/ssd/src/ParaView > > I was able to open the resulting build directory in Qt Creator 2.3.1 > and see all of the source files etc. I can dig a little deeper if you > let me know what version of Qt Creator you are using, a project you > see the issue with etc. I could also give the installer a try if the > problem persists (I normally just build from source and current CMake > master is 2.8.6). > So I see that one of my projects has this problem. I've narrowed it down to this commit: http://cmake.org/gitweb?p=cmake.git;a=commit;h=a5683f8 If I remove the code that commit adds, from the current HEAD, then my problem goes away. When checking the XML, it complained about a few lines that looked like this: So it appears that code doesn't handle preprocessor defines with quoting. Peter, is that your problem also? Can you edit your .cbp to remove lines like that? Or copy it to a file with a .xml extension then open it in a program that can check the xml (e.g. firefox). -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] dmg CPack Options
On Thursday, September 22, 2011 09:07:49 am Michael Jackson wrote: > Is there an option to pack the entire installation folder _including_ the > folder itself into the dmg disk image during CPack? > > I have several applications, tools, documents and such and they are all > currently put "loose" in the dmg file, I would rather have and enclosing > folder. > > I am using unix symlinks to cut down on repeated frameworks and libraries > so Zip and tgz don't support symlinks correctly which is forcing me to try > the "DragAndDrop" option. > You're probably looking for this: set(CPACK_INCLUDE_TOPLEVEL_DIRECTORY 1) -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] Problem and proposed solution with cmake -E rename across devices
On Wednesday, August 31, 2011 10:30:22 am David Cole wrote: > On Wed, Aug 31, 2011 at 11:49 AM, David Cole wrote: > > The cmake -E rename command is documented to work only when src and > > dst are on the same volume: > > > > If you run "cmake -E" with no other args, the rename command is > > documented as: > > > > rename oldname newname- rename a file or directory (on one volume) > > > > I think doing a copy as a fallback is a reasonable thing, but I think > > it's on your side of the fence. CMake properly returns an error and > > tells you "can't do that rename operation" and then it should be uo to > > you to make a copy if that's what you want. > > > > Others may want to do something else if rename cannot be done. I don't > > think we should add code that says CMake will do a copy if rename > > fails... > > > > On Tue, Aug 30, 2011 at 3:21 PM, Clifford Yapp wrote: > >> We've run into an issue with cmake -E rename where the rename fails > >> due to rename() throwing EXDEV when done between devices (different > >> partitions, nfs to local, etc). Erik Greenwald has investigated and > >> has proposed a fix to allow cmake -E rename to succeed across devices > >> - if possible we'd like to get this or some related fix included, > >> since this is a real-world build environment situation for us: > >> > >> http://public.kitware.com/Bug/view.php?id=12433 > >> > >> Cheers, and thanks! > >> > >> CY > >> ___ > >> 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 > > Furthermore: > > Additionally, "cmake -E rename" is supposed to be guaranteed to be > "atomic" -- adding this code makes it "mostly atomic" and would negate > the intent of some significant callers of rename... > > Thx, > David What about adding something like "cmake -E move" which could be used to rename files but also support moving between devices? -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com ___ 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] FindQt4 fails to find QtUiTools in windows cross-environment
On Friday, August 26, 2011 10:54:44 am Dominik Schmidt wrote: > Hey! > > I'm facing an issue with FindQt4 module when cross-compiling from Linux > to Windows. The QtUiTools are not found on the first run of cmake, > executing cmake a second time finds it (I attached the diff of > CMakeCache.txt before and after the second cmake run). > > I suspect the issue is connected to this QTBUG: > https://bugreports.qt.nokia.com/browse/QTBUG-20498 > > The description is only half-true, it's built here, but as a static > library in contrast to the rest of Qt which is built as dynamic ones. > A fix for this has been put in. http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=a67be31 -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com ___ 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] Gathering up required shared libraries
On Tuesday, August 02, 2011 06:36:45 pm David Cole wrote: > On Tue, Aug 2, 2011 at 8:05 PM, Clinton Stimpson wrote: > > On Aug 2, 2011, at 5:47 PM, Gregory Crosswhite wrote: > >> On 8/2/11 4:32 PM, Clinton Stimpson wrote: > >>> There is no scanning the file system to find which libraries to fix up. > >>> Any libraries used by executables will be considered in the set of > >>> libraries to fix up, regardless of where they are installed (in bin/ > >>> or lib/). Any libraries not found as a dependency can be specified by > >>> the second parameter of fixup_bundle(). Plugins are a typical example > >>> of that, because executables and libraries don't link against plugins. > >> > >> Doh! For some reason I thought I saw that the code was doing that but I > >> see now that I was mistaken. > >> > >>> You don't need to add your libraries to the second parameter. If you > >>> did, you'd have to know them all up front, and that defeats one of the > >>> purpose of BundleUtilities. > >> > >> Sorry, I obviously didn't make it clear that I was referring to > >> libraries that I was not planning on linking the program against --- > >> that is, libraries provided for the benefit of other developers but not > >> actually used by my program. Having said that, discussing this has > >> made me realize that in my case it would probably make more sense for > >> me to link against my own shared library anyway to prevent code from > >> being duplicated in both program and library, so my use case is not as > >> likely as I had been originally imagining. > > > > Oh, so you're also providing libraries for other developers. In that > > case, you do specify them into the second parameter of fixup_bundle(). > > If those libraries have additional dependencies, then BundleUtilities > > could be useful for that. > > > > Clint > > ___ > > 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 > > Let's not lose sight of the intent behind fixup_bundle here. I don't > want to confuse things by trying to make it all things to all people. > > For our purposes, a "bundle" is a relocatable file system entity (a > directory) which contains a set of executables and libraries that > after fixup, are entirely self-contained, referring to each other only > by relative paths, and will work on any compatible OS, regardless of > where they are placed in the target file system. > > On the Mac, this is achieved by copying external libraries "into the > bundle" and fixing up their references. Elsewhere, this is typically > achieved by copying libraries into the same directory with the > executable (on Windows, just works, on Linux, works as long as you use > $ORIGIN RPATH references). > > When you do not have a ".app" directory, and you are not copying into > the same directory with the executable, then the question in my mind > becomes "what exactly is 'the bundle' at this point?" > > With a dir/bin, dir/lib typical Linux style layout, "dir" would be > "the bundle"... > > If we really want to support this, perhaps we need another function to > extend fixup_bundle so that you pass in the bundle's directory, and > its main executable, or a list of executables. Instead of trying to > derive it from just the main executable like we do now. > Ok.. that does sound like a good idea. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com ___ 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] Gathering up required shared libraries
On Aug 2, 2011, at 5:47 PM, Gregory Crosswhite wrote: > On 8/2/11 4:32 PM, Clinton Stimpson wrote: >> There is no scanning the file system to find which libraries to fix up. >> Any libraries used by executables will be considered in the set of libraries >> to fix up, regardless of where they are installed (in bin/ or lib/). Any >> libraries not found as a dependency can be specified by the second parameter >> of >> fixup_bundle(). Plugins are a typical example of that, because executables >> and >> libraries don't link against plugins. > > Doh! For some reason I thought I saw that the code was doing that but I see > now that I was mistaken. > >> You don't need to add your libraries to the second parameter. If you did, >> you'd have to know them all up front, and that defeats one of the purpose of >> BundleUtilities. > > Sorry, I obviously didn't make it clear that I was referring to libraries > that I was not planning on linking the program against --- that is, libraries > provided for the benefit of other developers but not actually used by my > program. Having said that, discussing this has made me realize that in my > case it would probably make more sense for me to link against my own shared > library anyway to prevent code from being duplicated in both program and > library, so my use case is not as likely as I had been originally imagining. Oh, so you're also providing libraries for other developers. In that case, you do specify them into the second parameter of fixup_bundle(). If those libraries have additional dependencies, then BundleUtilities could be useful for that. Clint ___ 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] Gathering up required shared libraries
On Tuesday, August 02, 2011 05:09:04 pm Gregory Crosswhite wrote:
> On 08/02/2011 03:10 PM, Clinton Stimpson wrote:
> > On Tuesday, August 02, 2011 03:38:01 pm Gregory Crosswhite wrote:
> > You need an @ONLY for configure_file() so it doesn't substitute the ${}
> > parts also.
>
> Doh! Thanks for the tip. :-)
>
> > You should either pass in the executable or a .app/ directory to
> > fixup_bundle()
>
> Okay, but what if I have my own shared libraries that I also want to
> fixup that get installed in lib/?
They will get fixed up if they are either referenced by an executable in the
bin directory, or if its passed in the second argument of fixup_bundle().
> It would be preferable if
> fixup_bundle were to scan not only everything in bin/ but also
> everything in lib/, since it searches recursively for both executables
> and libraries in the bundle directory, and that is set to bin/ ---
> though I suppose I could work around this manually by passing in all of
> the libraries that get installed into lib/ into the second argument of
> fixup_bundle().
There is no scanning the file system to find which libraries to fix up.
Any libraries used by executables will be considered in the set of libraries
to fix up, regardless of where they are installed (in bin/ or lib/). Any
libraries not found as a dependency can be specified by the second parameter of
fixup_bundle(). Plugins are a typical example of that, because executables and
libraries don't link against plugins.
You don't need to add your libraries to the second parameter. If you did,
you'd have to know them all up front, and that defeats one of the purpose of
BundleUtilities.
>
> > But after those fixes... there is another error that says:
> > "Install or copy the item into the bundle before calling fixup_bundle.
> > Or maybe there's a typo or incorrect path in one of the args to
> > fixup_bundle?"
> >
> > I thought that check applied only to parameters passed in the second
> > argument of fixup_bundle(), so that looks like a bug. That function is
> > also only called on Mac if that helps explain some behavior you are
> > seeing.
> > If I comment out the FATAL_ERROR it issues, then it completes and gives a
> > working installation. Would you like to file a bug report for this?
>
> I went ahead and file a bug report describing my issue:
> http://public.kitware.com/Bug/view.php?id=12382
>
> However, in response to your remark that "I thought that check applied
> only to parameters passed in the second argument", consider that even if
> this were true then there would still be a problem. To see why,
> consider the following example (again, all sources attached to this
> e-mail):
>
> = CMakeLists.txt =
> cmake_minimum_required(VERSION 2.8.5)
>
> set(CMAKE_INSTALL_PREFIX ${CMAKE_BINARY_DIR}/bundle)
>
> add_executable(hello hello)
> add_library(hellolib SHARED hellolib)
> install (TARGETS hello DESTINATION bin)
> install (TARGETS hellolib DESTINATION lib)
>
> configure_file(
> ${CMAKE_SOURCE_DIR}/FixBundle.cmake.in
> ${CMAKE_BINARY_DIR}/FixBundle.cmake
> @ONLY
> )
> install(SCRIPT ${CMAKE_BINARY_DIR}/FixBundle.cmake)
>
> = FixBundle.cmake.in =
> include (BundleUtilities)
>
> fixup_bundle(
>"${CMAKE_INSTALL_PREFIX}/bin/hello@CMAKE_EXECUTABLE_SUFFIX@"
>
> "${CMAKE_INSTALL_PREFIX}/lib/@CMAKE_SHARED_LIBRARY_PREFIX@hellolib@CMAKE_SH
> ARED_LIBRARY_SUFFIX@" "@LIBRARY_OUTPUT_PATH@"
> )
>
> =
>
> The resulting error message is
>
> =
> -- Install configuration: ""
> -- Up-to-date:
> /Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle/bin/
> hello -- Installing:
> /Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle/lib/
> libhellolib.dylib -- fixup_bundle
> --
> app='/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle
> /bin/hello' --
> libs='/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundl
> e/lib/libhellolib.dylib' -- dirs=''
> -- fixup_bundle: preparing...
> -- fixup_bundle: copying...
> -- 1/4: *NOT* copying
> '/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle/lib
> /libhellolib.dylib' -- 2/4: *NOT* copying
> '/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle/bin
> /hello' -- fixup_bundle: fixing...
> -- 3/4: fixing up
> '/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle/lib
> /libhellolib.dylib'
>
> exe_dotapp_dir/='/Users/gcross/Documents/T
Re: [CMake] Gathering up required shared libraries
On Tuesday, August 02, 2011 03:38:01 pm Gregory Crosswhite wrote:
> On 8/2/11 1:09 PM, Clinton Stimpson wrote:
> > Ok, can you make an example that demonstrates the problem?
> >
> > I think this should work without overriding get_dotapp_dir() in
> > BundleUtilities.
>
> The example is attached to this e-mail. I don't actually use Boost in
> this example except as a means of pulling in a dependency on a
> non-system shared library, so if necessary replace all references to it
> in CMakeLists.txt with some other package on your system that will
> generate a dependency on a non-system shared library in order to see
> something akin to what I am seeing.
>
> My CMakeLists.txt file looks like this:
>
> CMakeLists.txt
> cmake_minimum_required(VERSION 2.8.5)
>
> set(CMAKE_INSTALL_PREFIX ${CMAKE_BINARY_DIR}/bundle)
>
> find_package( Boost COMPONENTS thread REQUIRED )
> link_directories ( ${Boost_LIBRARY_DIRS} )
> include_directories ( ${Boost_INCLUDE_DIRS} )
>
> add_executable(hello hello)
> target_link_libraries(hello ${Boost_LIBRARIES})
> install (TARGETS hello RUNTIME DESTINATION bin)
>
> configure_file(
> ${CMAKE_SOURCE_DIR}/FixBundle.cmake.in
> ${CMAKE_BINARY_DIR}/FixBundle.cmake
You need an @ONLY for configure_file() so it doesn't substitute the ${} parts
also.
> == VERSION 2 ERROR MESSAGE ==
> -- Install configuration: ""
> -- Up-to-date:
> /Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle/bin/
> hello -- fixup_bundle
> --
> app='/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle
> /bin/hello' -- libs=''
> -- dirs=''
> -- fixup_bundle: preparing...
> -- fixup_bundle: copying...
> -- 1/4: *NOT* copying
> '/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle/bin
> /hello' -- 2/4: copying '/opt/local/lib/libboost_thread-mt.dylib'
> Error copying file "/opt/local/lib/libboost_thread-mt.dylib" to
> "/libboost_thread-mt.dylib".
> -- fixup_bundle: fixing...
> -- 3/4: fixing up
> '/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle/bin
> /hello' -- 4/4: fixing up '/libboost_thread-mt.dylib'
>
> exe_dotapp_dir/='/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/
> build/bundle/bin/' item_substring=''
>resolved_embedded_item='/libboost_thread-mt.dylib'
the "/libboost_thread-mt.dylib" comes from the missing @ONLY in configure_file()
Without that, it gave you
function(gp_item_default_embedded_path item default_embedded_path_var)
set( "@executable_path/../lib" PARENT_SCOPE)
endfunction(gp_item_default_embedded_path)
instead of
function(gp_item_default_embedded_path item default_embedded_path_var)
set(${default_embedded_path_var} "@executable_path/../lib" PARENT_SCOPE)
endfunction(gp_item_default_embedded_path)
>
> As you can see, neither version works. The first version doesn't work
> because fixup_bundle requires an executable file rather than a
> directory, and the second version doesn't work because it sets the
> bundle directory to bin/ *inside* of the installation prefix and so it
> doesn't see that the libraries are also inside the bundle.
You should either pass in the executable or a .app/ directory to fixup_bundle()
But after those fixes... there is another error that says:
"Install or copy the item into the bundle before calling fixup_bundle.
Or maybe there's a typo or incorrect path in one of the args to fixup_bundle?"
I thought that check applied only to parameters passed in the second argument
of fixup_bundle(), so that looks like a bug. That function is also only called
on Mac if that helps explain some behavior you are seeing.
If I comment out the FATAL_ERROR it issues, then it completes and gives a
working installation. Would you like to file a bug report for this?
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
___
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] Gathering up required shared libraries
On Tuesday, August 02, 2011 02:03:23 pm Gregory Crosswhite wrote: > On 8/2/11 12:53 PM, Clinton Stimpson wrote: > > On Mac, are you making a .app bundle, or are you doing a layout similar > > to Linux, with bin/, lib/ layout, or something else? > > The latter --- I was hoping to use a layout similar to Linux with bin/, > lib/, etc. since the program is console-based and so it doesn't have a GUI. Ok, can you make an example that demonstrates the problem? I think this should work without overriding get_dotapp_dir() in BundleUtilities. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com ___ 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] Gathering up required shared libraries
On Tuesday, August 02, 2011 01:42:47 pm Gregory Crosswhite wrote: > On 8/2/11 9:28 AM, Clinton Stimpson wrote: > > You shouldn't need to copy GetPrerequisites and BundleUtilities. > > > > For Linux you can do: > > set_target_properties( ... PROPERTIES INSTALL_RPATH "\$ORIGIN/../lib") > > > > To get /usr/lib/ to be treated as non-system libraries, you can implement > > gp_resolved_file_type_override() > > to adjust that behavior. > > See gp_item_default_embedded_path() in GetPrerequisites for more > > information. > > > > And finally, to copy the dependents into lib/ instead of bin/, you can > > implement > > gp_item_default_embedded_path_override() > > to return a different path. > > See gp_resolved_file_type() in GetPrerequisites for more information. > > Okay, so that gets me *nearly* everything that I want, but my new > problem is that on Mac OSX fixup_bundle incorrectly assumes that the > bundle directory is where the executable is --- namely, bin/, rather > than the installation directory --- and then complains that the > libraries have not been copied into the bundle; if I instead pass in the > installation directory then it complains because it isn't a ".app" dir. > Thanks to your advice I now know to specifically look for *_override > hooks in the BundleUtilities, but unfortunately unless I am missing > something it looks like there are no such hooks that will let me change > this behavior, so I will need to copy BundleUtilities and then modify > get_dotapp_dir to return the parent of the directory of the executable > rather than the directory of the executable itself. > > Could I request that overrides be added to in BundleUtilities similar to > the ones in GetPrerequisites so that someone facing my situation won't > have to do this in the future? It looks to me though like an override > in get_dotapp_dir might suffice, and I could easily implement that > myself by following the pattern for overrides in GetPrerequisites and > then send you all a patch, but you all have a better sense of the big > picture than a relative newcomer to hacking on CMake like myself so I > would be happy for any feedback you have on this idea. :-) > On Mac, are you making a .app bundle, or are you doing a layout similar to Linux, with bin/, lib/ layout, or something else? What version of CMake are you using? There was a bug fix in 2.8.5 if not doing a .app bundle on Mac. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com ___ 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] Gathering up required shared libraries
On Monday, August 01, 2011 07:12:15 pm Gregory Crosswhite wrote: > Hey everyone, > > I am using CMake to build a package which has the normal unix layout, > i.e. programs are in bin/, libraries are in lib/, etc., and I would like > to simply copy all of the required shared non-system libraries into lib/ > and make sure that the executable is updated to look for them there so > that I can have an standalone distribution. CMake *almost* supports > this with fixup_bundle, but unless I am missing something it doesn't > seem to give me any control as to where the shared libraries are > installed, and it doesn't update the executable except on OSX --- though > the latter is not a big deal since if I understand correctly I can just > add @executable_path@/../lib to the RPATH. Furthermore, on Linux it > incorrectly assumes that libraries in /usr/lib should be considered > system libraries (that is, guaranteed to be available everywhere), when > in fact only libraries in /lib should be, which means that I can't even > easily use get_prerequisites directly to find all of the libraries that > I need and then copy them to the correct location myself. > > (Of course, an alternative would be to just statically-link everything, > but frankly having searched around it looks like it is simply impossible > for me to force all non-system libraries to be statically linked, > especially since once of them is libgfortran which is included > automatically by the gfortran compiler and I can't figure out a good way > to get CMake to reliably link statically to libgfortran instead of > dynamically. If anyone has any recommendations on this front I would be > happy to hear them.) > > So anyway, at the moment to do what I want it looks like I would have to > make my own project-specific copies of GetPrerequisites.cmake and > BundleUtilities.cmake and then hack them up in order to force them to do > what I want. But I can't help but think that there must have lots of > people out there who have wanted to do what I want to do and so this > problem must have been solved in a much better way. So does anyone have > advice for a way to do what I want, i.e. an easy way to copy all > non-system libraries (where only /lib is interpreted to be the location > of system libraries) to a directory of my choosing relative to the > installation prefix and to modify the executable to make sure it finds > them? Or is my only option really to copy into my project and hack up > GetPrerequisites.cmake and BundleUtilities.cmake? > You shouldn't need to copy GetPrerequisites and BundleUtilities. For Linux you can do: set_target_properties( ... PROPERTIES INSTALL_RPATH "\$ORIGIN/../lib") To get /usr/lib/ to be treated as non-system libraries, you can implement gp_resolved_file_type_override() to adjust that behavior. See gp_item_default_embedded_path() in GetPrerequisites for more information. And finally, to copy the dependents into lib/ instead of bin/, you can implement gp_item_default_embedded_path_override() to return a different path. See gp_resolved_file_type() in GetPrerequisites for more information. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake QT4 toolbar icons disappear
On Jul 29, 2011, at 10:58 AM, James Sutherland wrote:
> I have the following in my CMakeLists.txt:
>
> install( DIRECTORY "${QT_PLUGINS_DIR}/imageformats"
> DESTINATION ${plugin_dest_dir}/plugins
> COMPONENT Runtime
> )
>
> This results in the appropriate libraries (libqtiff.dylib included) being
> installed in my app bundle at
> Contents/MacOS/plugins/imageformats
Have a look here:
http://doc.qt.nokia.com/latest/deployment-mac.html
To see if the results you are getting agree.
A possible hint:
If the Contents/Resources/qt.conf file has Plugins=plugins, then that means you
put plugins in
Contents/plugins, not Contents/MacOS/plugins.
Contents/MacOS/plugins will work if qt.conf has Plugins=MacOS/plugins.
Clint
>
> Then I have this:
>
> install( CODE "
> file(GLOB_RECURSE QTPLUGINS
>
> \"\${CMAKE_INSTALL_PREFIX}/${plugin_dest_dir}/plugins/imageformats/*${CMAKE_SHARED_LIBRARY_SUFFIX}\")
> include(BundleUtilities)
> fixup_bundle( \"${APPS}\"
> \"\${QTPLUGINS}\"
> \"${DIRS}\")
> " COMPONENT Runtime
> )
>
> Is it obvious what I am missing?
> I double checked that the QTPLUGINS variable above does, in fact, contain the
> appropriate shared libraries. But "fixup_bundle" is entirely mysterious to
> me...
>
> James
>
>
>
> On Fri, Jul 29, 2011 at 10:14 AM, David Cole wrote:
> Probably qtiff4 ...
>
> You can see the available ones in your Qt build tree at "plugins/imageformats"
>
>
> On Fri, Jul 29, 2011 at 12:10 PM, James Sutherland
> wrote:
> > The icons are all *.tif images.
> > Would that require a plugin? Do you happen to know what one?
> > James
> >
> > On Thu, Jul 28, 2011 at 9:33 PM, clin...@elemtech.com
> > wrote:
> >>
> >> Sounds like your icons are in a format supported by a plugin, and the
> >> installation has missing that plugin.
> >>
> >> Clint
> >>
> >> - Reply message -
> >> From: "James Sutherland"
> >> Date: Thu, Jul 28, 2011 8:01 pm
> >> Subject: [CMake] CMake QT4 toolbar icons disappear
> >> To: "cmake"
> >>
> >> I have a QT4 application that I am building via CMake.
> >> In the build directory where the "local" application is built, it works
> >> fine.
> >> In the install directory, that application is missing all toolbar icons
> >> when it runs (but is otherwise functional).
> >> Any ideas what could be causing this? It must have something to do with
> >> the installation process I guess?
> >> FWIW, I followed the example code at the link
> >> on http://www.vtk.org/Wiki/BundleUtilitiesExample
> >> James
> >> ___
> >> Powered by www.kitware.com
> >>
> >> Visit other Kitware open-source projects at
> >> http://www.kitware.com/opensource/opensource.html
> >>
> >> Please keep messages on-topic and check the CMake FAQ at:
> >> http://www.cmake.org/Wiki/CMake_FAQ
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> http://www.cmake.org/mailman/listinfo/cmake
> >
> >
> > ___
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.cmake.org/mailman/listinfo/cmake
> >
>
> ___
> 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] FindQt4 errors out when locating QtUITools under CMake 2.8.5
On Monday, July 25, 2011 10:55:58 am Charlie Sharpsteen wrote: > I ran into an issue after upgrading from CMake 2.8.4 to 2.8.5---the > following no longer works: > > FIND_PACKAGE(Qt4 COMPONENTS QtUiTools REQUIRED) > > I traced the problem down to a hunk in commit > e7f05d9759ec5bc393760daee91bb7223f6c56d0: > > diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake > index 108012a..86fce9d 100644 > --- a/Modules/FindQt4.cmake > +++ b/Modules/FindQt4.cmake > @@ -608,18 +608,6 @@ IF (QT_QMAKE_EXECUTABLE AND QTVERSION) > > If I `patch -R` this hunk before building and installing CMake 2.8.5 then > FIND_PACKAGE can successfully locate QtUiTools. > > More details on GitHub: > > https://github.com/Kitware/CMake/issues/7 > Thanks for finding. Its been fixed in git. 702538e Qt4: Fix reference of undefined variable when detecting frameworks on Mac OS X -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com ___ 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
