[CMake] Copying shared libraries in a post-build step

[J Decker]

On Tue, Dec 9, 2014 at 4:58 PM, Eric Wing <ewmailing at gmail.com> wrote:

> On 12/9/14, J Decker <d3ck0r at gmail.com> wrote:
> > This is all handled by install.
>
> I already addressed INSTALL. I know you can change the directory. That
> is irrelevant to the point which I already addressed.
>
> You gave a personal opinion about install... not sure that addresses it.

>
> >
> > Sounds really like you're working to build a package, which install is
> > intended to do.
>
> Another problem which I didn't make explicit was that Xcode's
> codesigning and entitlements phase will not work with INSTALL because
> it signs when you build via Xcode. And there are cases where you must
> develop and test with codesigning and entitlements enabled, like
> testing App Store purchases, Game Center, or want to use the new
> built-into-Safari JavaScriptCore debugger if you have a JSContext in
> your app.
>
> Also, iOS/Android/WinRT, the INSTALL target is useless.
>
Android It's not useless... it puts all the files in a correct place to be
able to do manual packaging things.
Massaging a system that's already been installed is a lot easier than
pulling from sources scattered all over the build directory; and doesn't
require a lot of custom macros and scripts to do the job.  True; I had to
write another cmake layer on top of the already existing projects which go
to their install... and make some custom commands for 'install' and
'package' for android that pull from the one place just what it needs to
stuff into the android directory... but those scripts were really simple
since everything was already in a simple, known location after install.


>
> The INSTALL thing is a hack in my opinion that we as a community have
> accepted as a solution. I'm now calling it out as a design problem in
> CMake, especially as the winds have shifted to more platforms focusing
> on shipping binaries than the former and now treat packaging as a
> first class citizen. It is an impediment to the natural workflow on
> those platforms, it is an impediment to people adopting CMake, and it
> is an impediment to people wanting to deal with native languages
> because build systems are too complicated. (The scripts I wrote are
> intended to deal with all those things in a new middleware product I'm
> developing and hopefully bring native crossplatform development to
> people that otherwise wouldn't touch it before.)
>
> Your scripts would still only work for one target... since you'd have to
pick one to build the rest of the package around, so if I have a build
product that has a dozen utilities, rather than having one place they can
all work from, I have now to either duplicate all files to all runnable
targets or have a central one that would be the only one to work.   This is
more of a hack.


>
> Thanks,
> Eric
> --
> Beginning iPhone Games Development
> http://playcontrol.net/iphonegamebook/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141209/68ff02a6/attachment-0001.html>