[CMake] BundleUtilities not working

[Rashad M]

On Thu, Jul 30, 2015 at 8:55 PM, Bill Somerville <bill at classdesign.com>
wrote:

> On 30/07/2015 19:36, Rashad M wrote:
>
> Hi all,
>
> Hi Rashad
>
>
> We have a similar way here to get dll dependencies recursively and create
> a zip archive. Ideally, this could be integrated in cmake but not sure if
> that will be ok on cmake side. The code doesn't uses fixup_bundle(..) but
> follows a similar function syntax.
>
>  package_mingw(
>         ARCH "${mxearch}"
>         MXEROOT "${mxeroot}"
>          PREFIX_DIR "${archive_name}"
>          PEFILES  "${pefiles}"
>         SEARCHDIRS "")
> more details here:
> https://git.orfeo-toolbox.org/otb.git/blob/HEAD:/CMakeLists.txt#l422
> Note: this was only tested on a cross compiling build and contains some
> code specific for our project.
>
> [1]
> https://git.orfeo-toolbox.org/otb.git/blob/HEAD:/CMake/MinGWPackage.cmake
>
> That is all very Windows specific CMake already uses the same technique as
> your code but in a more platform independent way. You may want to consider
> optimizing in the same way as has been added to the BundleUtilities.cmake
> helper GetPrerequisites.cmake in:
>

Hi Bill,

Indeed these are all windows specific and that is the point here. To be
precise, these are more connected with mingw toolchain. I only tested them
on cross-compile toolchain.

>
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f01a8823
>
>
> since the objdump -p output on large framework libraries like Qt (10000+
> lines) is very inefficient when processed as a CMake variable. In our CMake
> built Qt5 project we are getting huge speed ups on the install phase on
> Windows with this change.
>

I see.

we use Qt4 and doesn't have any issue with speed. Maybe because I am using
a minimal set of components from Qt, Core, Gui, Xml, Sql. I will test this
nex enhancement and move to BundleUtilitles later.

Thanks




>
> Regards
> Bill Somerville.
>
>
>
> On Tue, Jul 28, 2015 at 7:04 PM, Brad King <brad.king at kitware.com> wrote:
>
>> On 07/28/2015 12:51 PM, Bill Somerville wrote:
>> > The possible lack of grep is a potential issue so your read
>> > back from file suggestion is interesting, is there a recognized place to
>> > write temporary files like this?
>>
>> IIRC the code in question runs during "cmake -P cmake_install.cmake"
>> scripts so CMAKE_CURRENT_BINARY_DIR may be a reasonable choice.
>> If for any reason you need to randomize the file name then you
>> could use string(RANDOM).
>>
>> Since this is specific to Windows perhaps $ENV{TEMP} will be useful,
>> though I don't recall off the top of my head whether applications
>> are supposed to read that directly.  Certainly a randomized file
>> name would be needed if a shared temp dir were used.
>>
>> -Brad
>>
>> --
>>
>> 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>
>> 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
>>
>
>
>
> --
> Regards,
>    Rashad
>
>
>


-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150731/679a2446/attachment.html>