[vlc-devel] [RFC] revision info causing rebuilding everything

[Rémi Denis-Courmont]

   Hello,

On Mon, 16 Feb 2009 10:41:09 +0100 (CET), jpd at m2x.nl wrote:
> Starting with the second, I think that a build number has some, but
> limited use: The main problems are that for each builder there needs
> to be a different number space, and the problem of tracking the build
> back to the source later.

That depends what you're tracking. git-describe gives a string that does
uniquely identify the last commit since it contains the commit hash.
Assuming the build tree has no unstaged changes, you can track the build
back to the exact source. If I recall correctly, we also include the
configure line, build host, and compiler infos. So let alone underlying
library issues, our version tracking was quite accurate.

> The former can be done by adding some tag to identify who built the tree.
> The alternative is to set a version tag by
> hand for each build, which adds up for non-release builds, and is easily
> forgotten.

We used git-describe, which does that automagically.

> So, automated generation of a build tag does have merits.
> The latter points us to a possible solution: One could tag the build
> with the git commit identifier.

That is what we did.

> If generating a build tag interferes with regular development
> then I would agree that the benefits do not outweigh the drawbacks.
> It probably is less of an issue to build something
> essentially equivalent into an automated build environment like, say, the
> one providing the nightly builds.

Last time they worked, nightly did not always rebuild everything either.
Yet the build bots were already quite busy.

> Coming back to the first issue, and without having looked at the
> implementation but purely thinking about the theory, it strikes me as
> inefficient in the extreme if a single object can trigger a rebuild of
> everything else that essentially does not depend on its contents.

I don't disagree but that's how make work. It only checks timestamps. It
could use something more clever, such as some hash of the file, but that
would not solve this particular problem anyway. In theory, the libvlccore
symbol lists would be a better "dependency". I will check if this works.
According to the automake documentation it should be do-able.

> Thus, I think that linking the modules against libvlccore.so is fine,
> but it may not become a make dependency for them: Shared objects should
> export a certain interface regardless of their build date. To ensure the
> make system will pick up API changes, the dependency for all shared
> objects including libvlccore.so should be set on the file exporting the
API;
> the header file.

Unfortunately, that's a "feature" of automake.

> The issues for static linking are a bit different, but even there the
> most a revision.o update may trigger is a relinking, not a full rebuild.

Statically linking plugins against libvlccore does not work. We would have
to get rid of all static data inside libvlccore first. Who's going to
bother when it would anyway make VLC even larger on disk for no obvious
benefit. I think we can ignore this problem.

> Thus, I would postulate that if generating a build number at each build
> triggers a full rebuild of everything, then that is a (separate) problem
> with the build system. The obvious reason for such a situation would be
> to ensure that all modules have the same build number. On the other hand,
> if the build tag is automated anyway, then adding a build tag to each .so
> becomes a possibility.

I don't disagree. My point was just that I would have appreciated if the
one adding the build number had also been the one trying to integrate it
properly within the build system. Instead that was committed and never
fixed after my objections. Then I reverted it, and it was re-committed (way
back). Then I broke it up silently instead, and then it was not
re-re-comitted until this 1.0 linking changes.

> In fact, generating the build tag could be made to depend on all other
> files making up the implementation of the shared object it is to tag,
> instead of forcibly generating a new one at every build.

That's unrealistic with the current build system.

-- 
Rémi Denis-Courmont