[vlc-devel] Which contrib for 1.1.2?

[Rémi Denis-Courmont]

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.

>> Just like --enable-macosx-defaults is retarded
>> as it requires everybody to rebuild everything every time you decide to
>> change one setting.
> 
> This settings is useless, and deprecated. It could safely be removed.

That did not prevent Felix from updating it a few days ago.

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

-- 
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis