[master] 9305a2d pull out vcs_version.h / vmod_abi.h generation to own file again
Dridi Boukelmoune
dridi at varni.sh
Mon Mar 5 18:32:37 UTC 2018
On Mon, Mar 5, 2018 at 6:38 PM, Nils Goroll <nils.goroll at uplex.de> wrote:
>
> commit 9305a2d4c4734eaf93f5ecec2a823f5d493d0be8
> Author: Nils Goroll <nils.goroll at uplex.de>
> Date: Mon Mar 5 18:12:21 2018 +0100
>
> pull out vcs_version.h / vmod_abi.h generation to own file again
>
> This basically reverts a29fca70f7ccc75964bcfffb8c8ab1617fcf2bba,
> except that we are using python instead of make-inlined shell code to
> do the work.
>
> Reason: vcs_version.h needs to be up-to-date under all circumstances,
> otherwise we will end up with wrong version information in binary
> builds, which would divert developer resources into unproductive
> confusion compensation.
>
> With an all-in-one generate.py, we basically have the choice between:
>
> - running it with each build, which breaks incremental builds as
> generate.py rewrites central includes like vcl.h
>
> - adding version information to all generate.py-build files or similar
> mechanisms to avoid re-writing them unless they have actually
> changed.
>
> - contradicting the argument given above
>
> I think that, unless there are strong reasons for a single
> generate.py, avoiding these issues by splitting functions is the best
> option.
I'm afraid this isn't the last patch for this:
https://travis-ci.org/Dridi/libvmod-querystring/jobs/349421603
This is a cron job building vmod-querystring against current master
once a week, and today it fails with:
version.c:37:10: fatal error: 'vcs_version.h' file not found
#include "vcs_version.h"
^~~~~~~~~~~~~~~
1 error generated.
FYI, this is a source tree downloaded from github (same as
git-archive) and should result in NOGIT since this is not a dist
archive.
Dridi
More information about the varnish-commit
mailing list