Reportedly not building under Make 4.4

[alerque]

Per this report Nix had build failures with Make 4.4. I use 4.3, which I think is the newest we've confirmed works. We should look into what 4.4 does that trips us up and fix it.

Upstream NEWS has deprecations and backwards incompatible changes.

[alerque]

It's possible v0.14.7 will fix this. The order of operations for recursing variables into included files seems to have changed in 4.4, but we're already changing the way we use them for other reasons to provide distros with partial missing dependencies more "outs".

# With nix-channel up to date and unstable being the default
$ nix-build -E 'with import <nixpkgs> {}; callPackage ./default.nix {}'

[ctrlcctrlv]

Oh boy. I use GNU Make a lot. I hope none of my projects are affected. That NEWS post is scary. GNU usually doesn't break that much rel-to-rel.

[ctrlcctrlv]

Actually @alerque this is a good opportunity for us to discuss something I looked into while trying to compile Khaled's work. Why do we have a CMakeLists.txt, but it only works on Win32 (AFAICT). I tried some stuff to get it to work on GNU/Linux but failed.

I like GNU Make, but personally I think this project has outgrown it and is too complex to still be using it. Should I write a cross-platform CMakeLists? I can't really test Windows though...

[alerque]

This issue is confirmed fixed in v0.14.7 as a side effect of other re-arrangement. The new arrangement is better anyway even if if wasn't originally to fix this issue.

The CMakeLists.txt file has never been fully completed. It was setup to try to get Windows builds going and it did get part way there, but we never got full installation packaging going at all and now it has fallen considerably behind.

Personally I've never liked CMake at all and don't have much interest in switching. I've done things 20× more complex in autotools based projects and the current level of this project doesn't really bother me at all in it. I could envision switching at some point in the future to meson or something if a compelling reason comes up that we really get something better out of the deal, but every time I've looked into it so far there were still serious downsides.

If the Windows build ever gets up to speed then I'd be willing to maintain the CMake build and would consider buffing out the cross platform issues so it could be used on the Linux side too. At that point we could evaluate dropping autotools and whether that would leave any *nix platforms in the cold. Until Windows gets up to speed though (whether with CMake or something else) I don't see the point in investing any time into it.

[ctrlcctrlv]

@alerque That's all fair.

You probably know why I like CMake: it's easy to hack it and make it do stupid, probably long-term difficult to maintain, but very convenient, things.

If you like Autotools there's no reason to switch. Just thought I'd ask about it given CMakeLists.txt. :-)

So, another option of course is to require MSYS2 to build on Windows. This isn't really such a big hurdle for developers, who are the only ones who want to build binaries anyway. If we did this we could drop the CMakeLists.txt entirely, and build on both Windows and GNU/Linux with GNU Autotools.

[alerque]

I believe I suggested MSYS2 already somewhere in comments on Windows related issues. I've also successfully setup cross-compiling using mingw-gcc to build Windows targets from autotools projects (e.g. for bzip3). I think that is feasible here too, although it would probably also need to be paired with something like luastatic to bundle a Lua interpreter in the built SILE binary. In any case I'm willing to consider facilitating any approach that is helpful to get Windows builds off the ground and since somebody was contributing CMake stuff to that end I let it go, but since it isn't fully functional even for Windows I don't think we need to keep it at parity or switch for Linux either.

[ctrlcctrlv]

Thanks. I'll consider looking into if I find time. I've fixed FontForge's Windows build before with MSYS2 so know how.