Fix building sak with cross-compilers

[MisterDA]

The build and target compiler invocations may differ. For instance, if cross-compiling with build/host x86_64-*-linux and target x86_64-pc-windows, the build/host object extension is .o, but the target uses .obj.

The AX_PROG_CC_FOR_BUILD macro has fixes from revision 21 to 26 that are needed, or it would overwrite OBJEXT and EXEEXT with BUILD_OBJEXT and BUILD_EXEEXT without defining the latter.

A subtlety is that building on Windows for native Windows targets isn't cross-compiling, thus it's not the build compiler for sak (*-pc-cygwin/*-pc-msys) that is used, but the host/target compiler.

cc @shym

[gasche]

As a non-expert I looked at whether I could close my eyes and merge it right away. My assessment is "not quite":

• the first two commits look fine and I would merge them
• the third commit looks globally okay, and/but it is the first (unless I missed something) to introduce BUILD_* variables at the Makefile level. If I understand correctly, Simplify the build of cross compilers #13526 left Makefiles mostly unchanged (except Makefile.cross which is for advanced stuff), and now we are gradually introducing host/build/target distinctions into normal makefiles. I'm not opposed, but I wouldn't mind getting confirmation from Someone Knowledgeable (@dra27, @shindere, @shym) that this is the right way to go.

[shym]

• b5b1daa Prefer Autoconf EXEEXT to our exeext
  LGTM

• b8cdedb Reformat an AS_IF
  LGTM

• 034f8b7 Fix sak build not using the proper build compiler invocation
  I don’t understand what use cases this is fixing (I see the changes of extensions in cross-compiler setups but is there anything more than aesthetic considerations?).
  I agree that this is introducing quite some variables. To avoid the $(BUILD_O) for instance, I would rather go that way:

  • merge the rules for sak into one (separating compilation from linking is not really useful there),
  • define a do-it-all SAK_BUILD variable in Makefile.build_config.in set up during configure,
  • if the extension of the sak binary really matters (note that we often use .exe extensions on Unix...), define SAK also in configure/Makefile.build_config.in.

  But I like the idea of defining outputobj and outputexe at the same place in configure.ac!

[MisterDA]

I don’t understand what use cases this is fixing (I see the changes of extensions in cross-compiler setups but is there anything more than aesthetic considerations?).

$ clang-20  -Foruntime/sak.o -c runtime/sak.c
$ clang-20  -o runtime/sak runtime/sak.o
clang-20: error: no such file or directory: 'runtime/sak.o'
clang-20: error: no input files

I'm using here clang-20 for the build compiler, but with a *-pc-windows target (MSVC ccomp_type). You see that the build flags are mixed up: it's using -Fo.
The AX_PROG_CC_FOR_BUILD update fixes a confusion between the build and the target object and executable extensions.

I agree that this is introducing quite some variables. To avoid the $(BUILD_O) for instance, I would rather go that way:

• merge the rules for sak into one (separating compilation from linking is not really useful there),
• define a do-it-all SAK_BUILD variable in Makefile.build_config.in set up during configure,
• if the extension of the sak binary really matters (note that we often use .exe extensions on Unix...), define SAK also in configure/Makefile.build_config.in.

I agree this could be cleaner, but if we build sak using MKEXE_VIA_CC, we can't pass it the list of cflags, because of the msvc syntax (cflags need to be passed before the /link flag). This would require some special casing or duplication… I'm scratching my head and I can't find a nice way.

I think dra27 has plans to remove sak, so introducing these build variables could be seen as temporary.

[MisterDA]

I've managed to make a single invocation to build sak. MSVC still generates a sak.obj. That's a bit unfortunate. I have two proposals: one using the direct invocation: 232aa53, and one with build variables 9e09521 (it uses BUILD_OBJEXT/BUILD_O, BUILD_EXEEXT, build_outputexe and build_outputobj). My preference goes to using build variables.

The run-crosscompiler-tests label should be added to this PR

[shym]

Thank you for that update!
I prefer that version and it looks good to me, I have only minor stylistic suggestions.

[gasche]

Thanks both!