2017-07-19 16:42 GMT+02:00 David Cole <dlrd...@aol.com>:
> Very nice example. Does CMake have a place to put examples like VTK
> does...? If so, where is it? And if not, it would be super useful to
> start one somewhere "official."
I guess the wiki is for that? Though I think my example should be
cleaned up before being put up anywhere.
>
> However, one word of caution on the example. I know it was targeted at
> Linux, and perhaps for a very simple case it's proper, but using an
> unconditional "local" for everything in a
> gp_resolved_file_type_override would not be something you'd want to do
> in general, especially on Windows. You would end up with probably on
> the order of a hundred (or maybe nowadays even a few hundred) DLLs
> from the Windows system directories inside your bundle. Almost
> certainly not what you intended.
Yes, good point and I should have said something about that. My
example was quick and dirty.
In my real projects, I've so far always ended up with separate calls
to fixup_bundle for the different platforms anyway (though never used
fixup_bundle on Linux before), so I guess my mind was thinking "oh
well, this is just for Linux" when I wrote it.
Elvis
>
>
> Cheers,
> David C.
>
>
>
> On Wed, Jul 19, 2017 at 9:57 AM, Elvis Stansvik
> <elvis.stans...@orexplore.com> wrote:
>> 2017-07-19 13:42 GMT+02:00 Roman Wüger <roman.wue...@gmx.at>:
>>> The problem with BundleUtilities which Inder is that it doesn't support
>>> generator expressions.
>>>
>>> Maybe I do something wrong?
>>> But I need to specify the path to the executable (generator expression) and
>>> the paths where to look for dependencies. Right?
>>
>> You don't need to use a generator to fetch the executable path. You
>> will know the path, since you installed the executable with
>> install(..) :) I think most people essentially hardcode the executable
>> path in their call to fixup_bundle(..).
>>
>> If you really want to, I think there is a way to use generator
>> expressions, and that is to put the fixup_bundle(..) call in a
>> separate file (say InstallStuff.cmake.in), and then process that file
>> with file(GENERATE OUTPUT ...) [1] to produce InstallStuff.cmake with
>> generator expressions evaluated and then use install(SCRIPT
>> InstallStuff.cmake). But that's much too complicated IMHO, and I would
>> avoid it.
>>
>> I made a minimal example that links against zlib and also the Boost
>> library you mentioned:
>>
>> cmake_minimum_required(VERSION 2.8)
>>
>> project(bundletest)
>>
>> find_package(ZLIB REQUIRED)
>> find_package(Boost REQUIRED COMPONENTS filesystem)
>>
>> add_executable(bundletest main.cpp)
>>
>> target_include_directories(bundletest PRIVATE ${ZLIB_INCLUDE_DIRS}
>> ${Boost_INCLUDE_DIRS})
>>
>> target_link_libraries(bundletest ${ZLIB_LIBRARIES} ${Boost_LIBRARIES})
>>
>> install(TARGETS bundletest
>> RUNTIME DESTINATION "bin"
>> )
>>
>> install(CODE "
>> function(gp_resolved_file_type_override resolved_file type_var)
>> set(\${type_var} local PARENT_SCOPE)
>> endfunction()
>> include(BundleUtilities)
>> fixup_bundle(\"\${CMAKE_INSTALL_PREFIX}/bin/bundletest\" \"\" \"\")
>> " COMPONENT Runtime)
>>
>> main.cpp:
>>
>> #include <iostream>
>> #include <zlib.h>
>> #include <boost/filesystem.hpp>
>>
>> using namespace boost::filesystem;
>>
>> int main (int argc, char *argv[]) {
>> // Pretend we're using zlib and Boost
>> deflateInit(0, 0);
>> std::cout << file_size(argv[1]) << std::endl;
>> return 0;
>> }
>>
>> The overriding of the gp_resolved_file_type_override was necessary, to
>> make it treat all libraries as local (otherwise it skips "system"
>> libraries). See the docs for GetPrerequisites.
>>
>> Building/installing this with
>>
>> mkdir build
>> cd build
>> cmake -DCMAKE_INSTALL_PREFIX=~/bundletest_install ..
>> make install
>>
>> produces:
>>
>> /home/estan/bundletest_install
>> /home/estan/bundletest_install/bin
>> /home/estan/bundletest_install/bin/bundletest
>> /home/estan/bundletest_install/bin/libm.so.6
>> /home/estan/bundletest_install/bin/libstdc++.so.6
>> /home/estan/bundletest_install/bin/libc.so.6
>> /home/estan/bundletest_install/bin/libz.so.1
>> /home/estan/bundletest_install/bin/libpthread.so.0
>> /home/estan/bundletest_install/bin/libboost_system.so.1.58.0
>> /home/estan/bundletest_install/bin/libgcc_s.so.1
>> /home/estan/bundletest_install/bin/libboost_filesystem.so.1.58.0
>>
>> I did the build on Ubuntu, and tested that it also runs in a clean
>> Fedora 24 Docker container.
>>
>> Hope that helps some.
>>
>> Elvis
>>
>> [1] https://cmake.org/cmake/help/v3.9/command/file.html
>>
>>>
>>> Please, could you give me a hint?
>>>
>>> Regards
>>> Roman
>>>
>>>> Am 19.07.2017 um 12:40 schrieb Elvis Stansvik
>>>> <elvis.stans...@orexplore.com>:
>>>>
>>>> 2017-07-19 10:24 GMT+02:00 Roman Wüger <roman.wue...@gmx.at>:
>>>>> Hello,
>>>>>
>>>>> I have a project which depends on a self compiled 3rd party project
>>>>> (boost)
>>>>> Boost is here only an example, there are other 3rd party libraries too.
>>>>>
>>>>> If I call the "install" command on the target, then it would be packaged.
>>>>> But how could I add the shared libraries and especially the links for the
>>>>> shared libraries?
>>>>>
>>>>> E.g.:
>>>>> libboost_filesystem.so -> libboost_filesystem.so.1.48.0
>>>>> libboost_filesystem.so.1.48.0
>>>>>
>>>>> Thanks in advance
>>>>
>>>> I think fixup_bundle() from BundleUtilities is what you want [1].
>>>>
>>>> We're using it to make our Windows and macOS installs standalone, but
>>>> (I think) it should work on Linux as well.
>>>>
>>>> [1] https://cmake.org/cmake/help/v3.8/module/BundleUtilities.html
>>>>
>>>>>
>>>>> Best Regards
>>>>> Roman
>>>>> --
>>>>>
>>>>> 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.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.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
