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

[jpd at m2x.nl]

On Fri, February 13, 2009 18:10, Rémi Denis-Courmont wrote:
> - forces a relink of anything that links against libvlccore at every
>   make invocation.
[snip]
>
> If we include revision infos, we need to relink every plugin (200+)
> at every make. In my opinion, this is completely unacceptable. And
> then, when doing one-shot release builds, revision infos are hardly
> any use, since we have the release version number. Hence, I think, we
> can realistically only choose between.

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


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.

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.

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.

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.

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.


The independence of the symbol containing the build information might
for example be achieved by making the api to it a function and exporting
that, not the (static) actual data, should it be necessairy.