groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [groff] I hate git-version-gen


From: Werner LEMBERG
Subject: Re: [groff] I hate git-version-gen
Date: Sun, 18 Mar 2018 03:44:34 +0100 (CET)

> My usual procedure is to git pull, build a distribution tarball in
> the standard way described in INSTALL.REPO, then build an
> installable package from that with the standard OpenBSD packaging
> system, which, in a nutshell
> 
>  1. extracts the tarball
>  2. applies distribution patches (minor things like adjusting the
>     operating system name and section titles to local conventions)
>  3. runs configure
>  4. runs make
>  5. runs make install to a fake area
>  6. uses a packing list to validate that the right files
>     got installed in fake area
>  7. builds a package from the fake area
> 
> This procedure implies testing both the out-of-tree build (for
> building the dist tarball) and the in-tree build (when building the
> final package).  It also implies that i do testing with the real,
> final paths and interdependencies of modules that users will later
> on have on their production systems.

This looks completely reasonable.

> I can then install the resulting package into the real operating
> system, run regression suites, and do manual run-time testing.
> 
> This time, the effects of git-version-gen caused failures in steps
> 1, 2, 6, and 7, and at run-time, see below for the reasons.

All your issues can be solved if you do one additional step.

  git archive --format=tar.gz \
              --prefix=groff-current/ HEAD \
              > groff-current.tar.gz
  tar xzvf groff-current.tar.gz
  cd groff-current
  echo 1.22.4 > .tarball-version                   <---
  ./bootstrap
  ./configure
  make
  make install

> I doubt that nowadays, anybody still uses the native build system to
> install self-compiled software directly into the operating system,
> so i don't see how that is relevant...

I do this all the time.

> right now, the string is "1.22.3.rc1.43-e7a3", with "3.rc1", even
> though this is actually a *4* release candidate.

Yes, this is a mistake.  Bertrand, please fix :-)


    Werner



reply via email to

[Prev in Thread] Current Thread [Next in Thread]