[vlc-devel] Which contrib for 1.1.2?

[Pierre d'Herbemont]

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.