Re: automake compile problems

[Eric Blake]

On 05/30/2018 02:23 PM, Andy Armstrong wrote:
> Hi Eric,

[top-posting is a bit harder to read on a technical list, so I'll stick 
with the easier-to-read inline posting]

> That could well be a far better approach. I am not sure how to perform cross 
> platform builds, especially taking into account the interesting platform 
> uniqueness such as codepage etc.

I'm not proposing cross-building (which is indeed a possibility, but a 
much more technically challenging one to get correct, so it's never my 
first suggestion), so much as having two machines:

- development machine: has autotools installed, has nano.git 
[https://git.savannah.gnu.org/cgit/nano.git] checked out (or however you 
are currently trying to build the latest nano); probably GNU/Linux, and 
most likely using ASCII encoding
- build machine: your mainframe with EBCDIC encoding

On the development machine, run all of the prep steps, including any 
required 'autoconf' and 'automake' steps, prior to './configure && make 
dist', which creates nano-$vers.tar.$suff (where $suff is typically .gz 
or .xz, depending on what compression the developers liked)

Then copy nano-*tar* file to the build machine (whether by ftp, or by a 
shared network drive, or by whatever other means you have at your disposal)

Then on the build machine, unpack the tarball (perhaps involving some dd 
invocations to transliterate from ASCII to EBCDIC as needed - but do so 
in a manner which preserves timestamps - I honestly don't know what 
steps are required in transferring an ASCII-encoded tarball into use on 
an EBCDIC machine)

Now, on the build machine, you only have to type './configure && make'; 
you don't have to run autoconf or automake (well, as long as you didn't 
mess up timestamps such that make thinks configure.ac is newer than 
configure, or some similar spurious change in dependency).

In fact, the parts about the development machine have often already 
taken place without requiring you to anything: 
https://ftp.gnu.org/gnu/nano/ includes nano-2.9.7.tar.xz, which was 
built precisely in the same manner that you would build it, by a 
developer who had autotools on their machine and ultimately ran 'make dist'.

So, rather than building from nano.git, just build the pre-built tarball.

> I have not used the 'make dist' argument before, but it would prerequisite that 
> I chose the appropriate configure and make arguments to compile for the 
> platform I am targeting.....thoughts?

'make dist' is SUPPOSED to produce an idempotent and complete tarball 
(modulo noise like changes in timestamps), independent of what configure 
options you used (if it doesn't, that's a bug in the particular package 
you are trying to build).  'make distcheck' tries to check that this is 
actually the case, by forcefully creating a tarball, faking a PATH with 
no autotools, and performing a VPATH build from the tarball, to exercise 
what an end user without autotools is likely to encounter (not all 
developers use 'make distcheck' the way they should, but it's part of 
the GNU Coding Standards, and automake tries to promote it for developers).

> I am not even sure of the official 'name' of the system I am targeting? s390? 
> omvs? To be clear, I am targeting USS on zSystems, not Linux on z. Thoughts? 
> Best practices?

Running config.guess (which is included in many different tarballs, 
again because automake finds it useful) should give the 'official' name 
of your system, at least in terms that the autotools cater to.

Admittedly, very few people use USS on zSystems while ALSO trying to use 
lots of GNU software, so it's highly likely that you have a LOT of 
non-portable assumptions to overcome when porting open source software 
to your platform (such as the 10-year-old autoconf bug you just 
reported, where we regressed from something that worked to something 
that tickles a latent bug in m4's eval that has been present even 
longer).  And actually fixing those bugs may require patching 
configure.ac or Makefile.am, at which point the 2-machine approach 
requires making the tweak, rerunning 'make dist', and copying over the 
new tarball for each tweak you want to test.  But having the separation 
between devel and build machine, even if it involves a lot of iterative 
copying, may still be easier than trying to have the build machine BE 
the development machine, where you have to get an entire ecosystem of 
software running before you can directly build from git instead of from 
tarballs.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org