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

[Rafaël Carré]

Le 2012-01-02 18:58, Felix Paul Kühne a écrit :
> 
> 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.

Probably

>>>> 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.

Can you elaborate?

>> 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.

Any suggestion for the name? VLC-dev.app is good?

>>>> 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 see at least 2 problems in the current state

VLC*.app now uses cp -R and then rm while it could just have been mv
(0c1d889772c303da34ea305bf808bc03ad5755df)

I'll remove the rm. Let's see if we can get dependencies handled properly.

If not we'll just add a phony rule which you can use and will always
regenerate those files.

2nd problem:     rm -f "$(top_builddir)/vlc-$(VERSION)-rw.dmg"
is duplicated