octave: automake-1.15: command not found

[ryandesign (Ryan Carsten Schmidt)]

​https://build.macports.org/builders/ports-10.7_x86_64-builder/builds/17319/steps/install-port/logs/stdio

/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_math_octave/octave/work/octave-5.2.0/build-aux/missing: line 81: automake-1.15: command not found
WARNING: 'automake-1.15' is missing on your system.
         You should only need it if you modified 'Makefile.am' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'automake' program is part of the GNU Automake package:
         <http://www.gnu.org/software/automake>
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <http://www.gnu.org/software/autoconf>
         <http://www.gnu.org/software/m4/>
         <http://www.perl.org/>
make: *** [Makefile.in] Error 127

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I cannot reproduce this issue on a 10.7 VM.
The only times I have seen this type of error is when configure.ac is newer than configure.
The scripts then helpfully try to regenerate configure.
Is it possible that there is is some issue with the modifications times of the files?
Is there any way to check?

I was going to resubmit the job, but the buildbot seems to be down.

[ryandesign (Ryan Carsten Schmidt)]

Replying to MarcusCalhoun-Lopez:

I cannot reproduce this issue on a 10.7 VM.
The only times I have seen this type of error is when configure.ac is newer than configure.
The scripts then helpfully try to regenerate configure.
Is it possible that there is is some issue with the modifications times of the files?
Is there any way to check?

No, but surely there is not a timestamp problem on multiple servers. The ​10.9 and ​10.10 machines had the same error.

I was going to resubmit the job, but the buildbot seems to be down.

See #60098. Feel free to submit jobs; they'll get done eventually. I deleted the octave failcache entry for 10.7 so it'll get retried if there's another port in the queue that depends on octave.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Request for Help:

I am unable to reproduce this error on my VMs.
I am also unable to figure out why this would be happening.

The only difference is the add addition of /opt/bblocal/libexec/libarchive in the PATH variable.
I do not think this is the reason, but it is the only difference I can see.

Any help would be appreciated.

[dyne2meter]

Thank you, Marcus. Deep gratitude, of course, for all the good work done by you and other port maintainers.

When you wrote "The only times I have seen this type of error is when configure.ac is newer than configure," I remembered having had an exchange like this on a previous occasion. Perhaps thst was with octave, and perhaps with another port.

I'm using the +openblas variant so I build octave every time it's updated. I simply cleaned the failed build and re-submitted the upgrade request. This has worked for me in the past (or so I recall), and has now succeeded, today.

I suspect the problem with configure.ac arose because I interrupted another (unrelated) upgrade some time in the past several weeks, but this is pure speculation on my part. Another system I use, also with OS 10.11, and virtually identical as far as installed ports, has proceeded normally with the upgrade, without this error, and I may have done the earlier upgrade on that system without having interrupted it. I sometimes wish I were more systematic about keeping logs of my macports activity. Then my analysis might be more rigorous (that is, useful). Thanks again!

[mf2k (Frank Schima)]

Why not just add automake as a build dependency?

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to mf2k:

Why not just add automake as a build dependency?

That is indeed a possibility, but if at all possible, I would like to understand the problem before attempting a solution.

[ryandesign (Ryan Carsten Schmidt)]

I also could not reproduce it on my 10.7 test VM, but my VM runs off a slow disk whereas the buildbot workers use fast SSDs.

I agree with dyne2meter that just retrying the build seems to work eventually. After the revision was increased it built fine on 10.9 and 10.10 and other systems but ​failed with this error on 10.11. A ​retried the build and it seems to be working this time.

Maybe there is a race condition in the build system.

[ryandesign (Ryan Carsten Schmidt)]

Replying to mf2k:

Why not just add automake as a build dependency?

A Portfile developer who wants to patch an autotools-based build system can choose either to patch the configure.ac and Makefile.am files and then run autoreconf or patch configure and Makefile.in and not run autoreconf. The maintainer of the octave port has chosen the latter. Therefore it is imperative that autoreconf (or autoconf or automake) not be run; running them would wipe out the patches to configure and Makefile.in. And there's no evidence so far that changing the port to patching configure.ac and Makefile.am and running autoreconf would fix the race condition.

[dyne2meter]

Regarding race conditions, I don't know if it's relevant, as I lack the necessary technical background, but the build that failed for me (and then succeeded on retry) is an 8-core system, whereas the system that built without a problem has only two cores. It's only an anecdote, but there it is, FWIW.

[ryandesign (Ryan Carsten Schmidt)]

That can definitely be relevant, and thanks for reminding me of it. Our build (virtual) machines do have 8 cores and 8 GB RAM each and seem to experience the problem intermittently. My test VM had 8 cores but only 4 GB RAM (which means MacPorts would only start 4 jobs), but after bumping it up to 8 GB as well (which will let MacPorts start 8 jobs) I was able to reproduce the problem there.

[ryandesign (Ryan Carsten Schmidt)]

I think the problem was introduced in [17b7c5e10202901bdd9382ed62b5b22b7b7e38bf/macports-ports]. That added this command:

    reinplace \
        "s|__MACPORTS_JAVA_VERSION__|${java_version}|g" \
        ${worksrcpath}/Makefile.in \
        ${worksrcpath}/scripts/java/module.mk

The problem is that scripts/java/module.mk is one of the prerequisites of Makefile.in (along with all of the other .mk files). So if the reinplace modifies Makefile.in at 12:00:00 and scripts/java/module.mk gets modified at 12:00:01, then make sees Makefile.in's dependency module.mk as newer than Makefile.in and wants to run automake to rebuild Makefile.in. But if they both happen to get modified before the clock advances to the next second (more likely the faster the disk is), then the build succeeds.

As I said above, a Portfile developer must either modify the original files and autoreconf to regenerate the generated files, or must modify the generated files. Not both! The fix is not to modify module.mk.

[ryandesign (Ryan Carsten Schmidt)]

In 9764577d75c4c1c19126cd23fd1e715e4231e89b/macports-ports (master):

octave: Don't patch scripts/java/module.mk

Fixes race condition that sometimes results in build failure.

Closes: #60283