Re: [Bug-xorriso] libisofs fails out-of-tree

[Thomas Schmitt]

Hi,

i now tested that libisoburn builds out-of-source.
So only libisofs had severe problems.


> I was going to push a branch to your gitlab instance but it doesn't
> allow registration,

We would have to ask Mario Danic for access. But as development is
currently mostly a one man show, i don't mind to apply the changes
manually. I must understand them anyway.


> so I've a fork on my personal gitlab.com account:
> https://gitlab.com/rossburton/libisofs/commits/outoftree

> acinclude: fix version script
> Makefile: fix demo build when out-of-tree

This is now tested here and will be committed soon. I plan it as one
commit:

  acinclude.m4
  Makefile.am
  Made libisofs ready for building out-of-source. Thanks Ross Burton.

Another one will be

  configure.ac
  Disabled autotools macro AM_MAINTAINER_MODE on advise of Ross Burton.

(Need to do a round of tests with and without in order to learn about
 the consequences on behavior.)


> util: fix path to version.h

I'm not sure whether i like this. But i dislike the "../version.h", too.

> your approach to move it alongside the other headers is better.

Probably. But removing version.h in favor of source based version numbers
is another candidate. Vreixo Formoso left the project more than 10 years
ago. So actually i should do it as in libburn and libisoburn. (But
libisofs was always less handwork when changing version numbers.)

For now i plan to commit the preliminary remedy as part of "Made libisofs
ready":
  AM_CPPFLAGS = -I $(top_builddir)/libisofs

This can hardly be wrong.


> Remove config.h remnants

This handwork was done in vain, i fear.
The line in configure.ac can be removed, of course. But the includes are
for a second job of that source code: GNU xorriso.

It bundles libburn, libisofs, libisoburn, libjte, and xorriso_main.c in
a statically linked binary. It's main purpose is to avoid the need for
installing dynamic libaries or a system-wide xorriso binary, when just
a modern xorriso is desired by a single user of an old system. (It also
avoids the hard to defend legal position of GNU on linking dynamic GPL
libraries.)
The GNU xorriso tarball gets derived automatically from the library
sources by
  libisoburn-*/xorriso/make_xorriso_standalone.sh

The config.h approach is used because else one would see the options of
all involved libraries with each source file's compilation. GNU xorriso
is rarely packaged by distro developers who want to see all options of
the compile run in a build log.

But probably i should do something against the "../" in
  #include "../config.h"
It's at least ugly.
And i have to test GNU xorriso's out-of-source readiness. (No .ver file
give some hpe. But libisofs/util.c is involved.)


> Doing a 'make distcheck' periodically, and definitely instead of just
> 'make dist' as part of the release, is a good way to be sure the builds
> continue to work.

I do the current tests from freshly unpacked release tarballs where i
replace the affected files by the newer ones from my dirty development
corner. From that corner they later will go to a local git clone to get
committed and pushed.

At release time, the tarballs are made from fresh git clones and then
tested on my development machine, on old Debian 6, FreeBSD 8, OpenSolaris,
and NetBSD. This includes program runs for regression tests.
A release usually lasts a weekend. I have a long cheat sheet for that.

And then comes Debian packaging for sponsored upload. N sponsors means
N + 1 opinions about how it should be done.

(I also have a large collection of bootable ISOs for repacking and
 analyzing whether the repacked ISOs sufficiently. resemble the originals.
 But that happens in the weeks before release.)


Have a nice day :)

Thomas