.generated path errors

[TinoDidriksen]

From a git clean -f -d -x folder, we now get errors like cp: .generated//Users/tino/langtech/kal/./../giella-core/fst-filters/block-mwe-compounds.regex: No such file or directory

Ping @flammie

[TinoDidriksen]

macOS-only, btw. On Linux we get a different error: No rule to make target 'tokeniser-gramcheck-gt-desc.pmhfst'

If I force macOS to use GNU make 4.4.1 instead of Apple's 3.81, then that also gets to tokeniser. Is newer make actually required these days? Simple enough to install from MacPorts - I just haven't seen that mentioned anywhere.

[flammie]

I think we are trying to support apple's default make tool. But tbh I don't work on mac and most CI is not on mac either, plus I haven't found a way to test that old make easily, it refuses to build and install on linux already, the breakages related to apple make only will take some extra time to solve.

The pmhfst part builds now again on my linux, it seems it relied on make keeping an intermediate build files without being required to do so.

[TinoDidriksen]

I've told the Greenlandic team to install and use GNU make. sudo port selfupdate ; sudo port install gmake and add export "PATH=/opt/local/libexec/gnubin:$PATH" to ~/.zprofile

It's very similar for Homebrew: https://formulae.brew.sh/formula/make + PATH="$HOMEBREW_PREFIX/opt/make/libexec/gnubin:$PATH"

So I'd suggest requiring newer make. It already requires gsed, so gmake is a natural extension.

[flammie]

From what I can gather it usually seems mac make does just resolve the rebuild graph always in a way that matches % over .generated/xxx instead of building xxx and copying it over to .generated/, but also screws up the automagic variables $@ and or $<, this is similar to the .generated/.generated/ bug I guess.

[Trondtr]

I can confirm the following behaviour:

1. All fsts build on Linux
2. No fst builds on Mac

The problem might be an old GNU make?

Not a single fst building is quite serious, so we should sort this out.

[snomos]

@TinoDidriksen wrote:

So I'd suggest requiring newer make. It already requires gsed, so gmake is a natural extension.

I agree. Let's require newest make, and then drop all the workarounds for Apple's patchy, old and flaky version. @flammie can you do?

[snomos]

I can confirm that installing GNU make solves the issues on my Mac: brew install make, then gmake (or follow the instructions here to continue to run make).

[flammie]

I think I'll put a test in all languages now with a warning and change it to an error after I'm back from computel. Based on https://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_check_gnu_make.m4

[flammie]

I pushed the test to langs now if someone with affected make can test? I'm not sure if apple's make identifies itself as gnu make anyways.

[TinoDidriksen]

Seems to work.

With PATH=/opt/local/bin:/usr/bin:/opt/local/libexec/gnubin:$PATH:

checking for GNU make... make
checking whether GNU make is at least 3.82... no
configure: WARNING: GNU Make too old (3.81), please install at least 3.82

With PATH=/opt/local/libexec/gnubin:/opt/local/bin:/usr/bin:$PATH:

checking for GNU make... make
checking whether GNU make is at least 3.82... yes

[flammie]

mm. It's not the best, since the first test picks up apple's make and then realises it's too old, but perhaps having that make first in the PATH will be problematic overall to have everyone fix their PATHs... I need to at least reformulate the error message a bit,

[TinoDidriksen]

It picks up and uses the older make, which is what people expect. It just needs to be an error instead of warning.