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 08/02/2011 05:36 PM, David Cole wrote: > 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. > > > David C. For what my two cents are worth, I think that this is a great idea and would be incredibly helpful, though again I will not claim to be an expert here. :-) Cheers, Greg ___ 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 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. David C. ___ 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 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. If you copy BundleUtilities/GetPrerequisites and remove the FATAL_ERROR issued. Then the installation is fixed up correctly, including the libraries in lib/. The fix for this bug is to modify that error check. Okidoke, that sounds easy, and you obviously know what's going on better than me so I'll just run with that solution until it gets fixed in the mainline. Thank you very much for your help!!! :-) Cheers, Greg ___ 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/ThrowawayCode/cmake-issue-example/
> build/bundle/bin/'
>
> item_substring='/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/b
> uild/bundle/lib/'
>
> resolved_embedded_item='/Users/gcross/Documents/ThrowawayCode/cmake-issue-e
> xample/build/bundle/lib/libhellolib.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 /Applications/CMake
> 2.8-5.ap
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 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. Cheers, Greg ___ 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 8/2/11 12:47 PM, David Cole wrote: The "non .app dir" problem should go away if you use the recently released CMake 2.8.5. This bug was fixed in that version: http://public.kitware.com/Bug/view.php?id=12034 Thank you very much for the heads up, but I have already been running CMake 2.8.5 already and that particular fix doesn't solve my problem because I was hoping to put the executables and libraries in different directories --- namely bin/ for the executables and lib/ for the libraries, to fit the standard unix-style layout --- and the particular fix that you linked only helps in the case where all the executables and binaries are put in the same directory. Cheers, Greg ___ 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 Tue, Aug 2, 2011 at 3:42 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. :-) > > Cheers, > Greg > ___ > 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 > The "non .app dir" problem should go away if you use the recently released CMake 2.8.5. This bug was fixed in that version: http://public.kitware.com/Bug/view.php?id=12034 ___ 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 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. :-) Cheers, Greg ___ 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 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. Great! I knew that there had to be a better way that I was simply missing. Thanks a lot! :-D Cheers, Greg ___ 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
[CMake] Gathering up required shared libraries
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? Thanks a lot in advance! :-) Cheers, Greg ___ 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
