[vlc-devel] Which contrib for 1.1.2?

[Jacques Boileau]

Hi,

I may have missed something, but I didn't think a dated contrib was enough
to link it to a particuler VLC version. How does someone pick the correct
contrib? Is it simply looking at the date of the release and find the
contrib that has the latest date prior to the release date? I would have
though Jean-Baptiste might have already packaged contribs for a next release
while developement is ongoing. If it is always that the latest contrib is
for the latest VLC version, that's easy enough as far as I am concerned but
just need to know. Would it be something nice to add to the about box 'built
using contrb...' ?

Jacques Boileau



On Fri, Aug 6, 2010 at 8:55 AM, Pierre d'Herbemont <pdherbemont at free.fr>wrote:

> 2010/8/6 Rémi Denis-Courmont <remi at remlab.net>:
> >
> > On Fri, 6 Aug 2010 10:39:53 +0200, "Pierre d'Herbemont"
> > <pdherbemont at free.fr> wrote:
> >>> The way you do on Mac OS X is totally retarded. Hard-coding a version
> >>> number in the Makefile is mind-boggingly stupid as it does not scale to
> >>> the (large) number of revisions.
> >>
> >> Why so? What you say seems to be very pertinent, but lacks good
> >> justification. It works way better than a stupid date because it means
> >> you can reproduce the same binary for a given version without having
> >> to look up or even think.
> >
> > That's not true. You can match a date to a commit relatively easily,
> albeit
> > with a limited precision. Indeed, there are relatively few changesets
> > pushed on a different date that they're written. To the contrary, there
> is
> > no easy way to match a contrib number to a particular changeset. You have
> > to go through all of them.
>
> > Either way, this is wrong. git-describe should be used instead. That
> > provides exact changeset precision, while not interfering with the
> history.
> > This is also true for source tarball snapshots by the way.
> >
> > If you want nice version numbers, then contribs should be tagged - in
> their
> > own dedicated repository.
>
> Thanks. This makes sense. Using git-describe would be really nice, but
> that requires some extra logic in order to get the right contrib for a
> given changeset.
>
> >> Anyway adding a setting or even modifying configure for whatever
> >> platform will trigger your very slow, inefficient, ugly and buggy
> >> build system.
> >
> > That's why you should avoid it. That's why I've been moving some of the
> > build logic to individual makefiles. I can't say I see anyone else doing
> > much effort though.
> >
> > That beinh said, I don't think you can avoid the rebuild in general. If
> you
> > change the "global" build rules, dependency propagation is going to be
> > inefficient. Even if we had switched to CMake or whatever, we'd be stuck
> > with the same problem. Since you're potentially altering the build
> > environment for the whole source tree, any _correct_ build framework will
> > trigger a full recompilation.
>
> > By the way, automake does not recompile the source code if config.h is
> > unchanged.
> >
> > If you're not happy with "my" build system ,you're welcome to replace it.
> > For real. Not just like toying with CMake in a way that it only works on
> > your computer.
>
> I am not really happy with the autotools, but I have to admit that
> they do their job, and that you've fixed most of the outstanding issue
> in our local build system. Though, from times to times I still get
> dependency bugs, and I have to manually trigger bootstrap. Could be
> some autoconf bug. However redoing the work with CMake was certainly
> stupid.
>
> Pierre.
>  _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20100806/3bb44c56/attachment.html>