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