Re: Results of the Bootstrap/Crossbuild Sprint
On 22 September 2014 22:55, Helmut Grohne <helmut@subdivi.de> wrote:
> On Mon, Sep 22, 2014 at 09:14:58PM +1000, Brendan O'Dea wrote:
>> As the upstream and maintainer of help2man, I figured that I should
>> chime in here.
>
> Thanks!
>
>> The recommended use of help2man is that it should be run by the
>> maintainer, and should not need to be run by the end user unless they
>> have made changes which have touched the dependencies of the manual
>> page. This is similar to autoconf, makeinfo, etc. where the products
>> are typically included in the distribution tarball.
>
> This doesn't make any sense to me. In general, we want to rebuild things
> from source. We have suffered long enough from outdated configure
> scripts and are generally switching to dh_autoreconf (i.e. running
> autoconf during build). In a similar vein, many packages run makeinfo
> and of course help2man during build. help2man has more than 200 reverse
> Build-Depends! Are you sure that all of these packages are using
> help2man in a wrong way? Maybe that's a communication problem (or a
> flawed recommendation)?
It is worth pointing out that the requirements of a project like
Debian, where we have control of such things as build dependencies and
are frequently applying patches, is vastly different from an
individual downloading a tarball, running configure && make install.
That latter class of folks are typically making no changes at all, and
just want the program and documentation to be installed. Those folks
should not be required to hunt down the appropriate tools required to
re-build things which could (and typically are) included in the source
distribution.
My recollection is that the main reason why Debian runs autoreconf
before building was that many packages simply needed that tweak to
pick up a new config.guess to allow for porting to new architectures.
>> My recollection is that coreutils at least doesn't use this behaviour,
>> and in fact includes a copy of help2man in the source distribution so
>> should not require a build-dependency at all (disclaimer: I've not
>> looked at the Debian packaging).
>
> Indeed, coreutils has its own copy of help2man. From a cross-builders
> pov, it does not matter whether coreutils embeds or uses help2man: Both
> variants make it fail to build.
Ah, I see: help2man attempts to execute the cross-built binary on the
host system. Hrm.
>> The recommended use is not actually to include the program in the way
>> that coreutils does, but to use the "missing" program from automake
>> (see "Using help2man With make" in
>> http://www.gnu.org/software/help2man/) which should allow the program
>> to build, but use the version of the manual page included in the
>> source (which may be out of date).
>
> If this is the case, then the detection logic in autotools is critically
> flawed. It should automatically use "missing" for help2man when
> cross-compiling. At the moment though, it figures that help2man is
> available and thus can be used.
Actually, automake/missing have changed since I last looked.
AM_MISSING_PROG used to check for the availability of the program, and
substitute "missing prog" is it was not found. It now appears to run
the missing script in all cases, and that script identifies if the
program failed to execute because it was not found, or some other
error.
Patching the missing script to handle the cross-building case would
appear to be one way to handle this, although I'm not sure how to
identify at that time whether or not a cross-build is in progress.
There seems to be a cross_compiling variable available during
configure, but I don't think that is exported in a way which is
available at the time which "missing help2man" is invoked via make.
> So where do we go from here? The one thing that's a fact, is that bison,
> coreutils and flex all fail to cross-build and that the step at which
> they fail involves help2man. Very likely more of those 200 packages
> mentioned above are affected (but not all of them have to be cross
> buildable). Finding a solution that works in general is highly
> desirable.
The quickest way would be a Debian-specific patch, but as noted above,
I'm not sure how to identify if a cross-build is in progress.
Have you asked automake upstream? Changing AM_MISSING_PROG to pass a
--cross flag to the missing script would seem like a useful addition,
since help2man may not be the only case where cross-building needs
special attention.
--bod
Reply to: