[vlc-devel] macosx: remove some more intermediates creating when packaging and creating the dmg

[Felix Paul Kühne]

On 02.01.2012, at 20:16, Rafaël Carré wrote:

> Le 2012-01-02 14:02, Felix Paul Kühne a écrit :
>> Hello,
>> 
>> On 02.01.2012, at 19:24, Rafaël Carré <rafael.carre at gmail.com> wrote:
>> 
>>> Le 2012-01-02 07:32, Felix Paul Kühne a écrit :
>>>> 
>>>> macosx: remove some more intermediates creating when packaging and creating the dmg
>>> 
>>> I don't see the point of removing intermediates,
>> We share something here ;) i don't see the point in keeping them.
> 
> They could hold valuable information, if a file in package is screwed up
> we can look in those dirs and find at which step screwing happened.
That's the theory of keeping intermediate products, which I can understand and which applies to a lot of intermediates.
However, what we basically do is: create a folder -> cp -r foldercontent disk-image -> make disk-image read-only. That's it! Unless you don't trust cp, there is virtually nothing which can go wrong in this process (and never went for me since starting to do the Mac releases in the 0.8.5 days).


>> Basically, the folder and the writable disk image removed by this commit are never used again ever. If the makefile user decides to redo the disk-image, the folder and the image will be removed and re-created.
> 
> We could have some proper dependencies in here and thus reuse those targets.
Re-using doesn't really make sense here, since basically it's always the VLC.app, which changes (well, yes, and the changelog), so yeah, sure you can update these within the intermediate, but it's a lot easier to just rm -rf and re-do.


>>> neither in
>>> 0c1d889772c303da34ea305bf808bc03ad5755df
>> Here's another thing:
>> When changing xib files, I frequently end-up recreating the non-redistributable VLC.app, so I do "rm -rf VLC.app && make VLC.app" often multiple times per hour. This obviously doesn't lead to the desired effect of updating the xib files within the application bundle in case VLC-tmp.app is still around.
> 
> Dependencies bug.
Definitely, but hard to solve, since the creation dates of the xib files and the nib files actually being used in the VLC*.app will always be different.

> 
>> Since nobody ever uses VLC-tmp.app except for creating VLC.app || VLC-release.app, there is no point in keeping it either except for the sole sake of making my life more painful. And no, removing this intermediate prior to every single recreation of VLC.app is not an option for me either.
> 
> About this I'm encline to just remove that 'VLC.app' target and copy the
> plugins every time.
> 
> How much time saving are we talking about by using ln -s instead of cp -R ?
make VLC.app takes 7.4s, make VLC-release.app needs 17.5s (this is on a 3,1 GHz Mid 2011 iMac [iMac12,2]), so the difference will be bigger on less up-to-date machines.
On jones, which isn't exactly slow either, it's 22.5s vs. 9.7s.

This doesn't sound like a lot, but it sums up if you tend to do that more than once in a while.

> We could also have the default target be the redistributable one and
> have a VLC-dev.app if it's really much faster
You can do that. In fact, I don't care as long as I have a fast target and no intermediate product I need to remove prior to rebuilding the dev target.

> 
>>> IIRC we discussed this on IRC already.
>> True, but back then, I didn't think of the consequences and therefore didn't argument correctly.
> 
> OK, but please next time send patches on the ML so we can discuss them
Honestly, I didn't expect such a discussion about 2 rm -r statements.

>> I'll also revert mounting an intermediate disk image within the vlc build folder instead of the default-location-where-every-other-disk-image-ever-used-by-any-app gets mounted, since this just adds
>> 1) more complexity to a build system which is only vaguely
> understandable by outsiders and
> 
> one argument is not really more complexity
True. However, it's off-standard and off-standard things with no reason are, well, hard to understand for outsiders. I did understand and share your opinion about your original idea. However, since regrettably it didn't work-out due to the Finder's limitations, I just wanted to let you know that I'll be removing that.

>> 2) yet another stupid folder which is most of the time used for nothing.
> 
> A folder doesn't really take up much disk space, not sure what you are
> trying to solve here.
I'm try to keep a certain level of simplicity (well, let's be honest, that will never happen with VLC ;)), since the build folder already includes almost 30 items, so I just want to prevent it from being cluttered even more.

>> Additionally, this folder is pointless, since the AppleScript working on the disk image at this point can't make use of it anyway.
> 
> What do you mean?
> 
> Anyway you can remove it if you really wish since it doesn't solve the
> problem I wanted to solve. There can still be a conflict if 2 vlc images
> are mounted with the same name since the script works on disk label and
> not on mount point.

That's the point :-)

Best regards,

Felix