[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