build: move config.h.in customizations to configure.ac

[marisn]

It allows config.h.in to be purely reconfigurable

Some obsolete code removed, LFS detection modernized

Contains files regenerated with autoconf 2.72

See discussion in #6479

[marisn]

LFS MinGW workaround was required ~15 years a go (see https://trac.osgeo.org/grass/ticket/1131 for its introduction). We break LFS on classic 32bit MinGW (long dead), but not on modern MinGW-w64 that we use.

[echoix]

On what OSes is autoconf 2.72 available now?

And for posterity (and me possibly wanting to automate again), what are the instructions needed for regenerating all?

[marisn]

Changes are not autoconf 2.72 specific and thus should be fine also on (a bit) older versions. Besides, as long as we ship generated files, there is little need to regenerate files.
I don't see a reason to automate, as changes to configure.ac are rare. As long as we keep only one source of truth (configure.ac), we'll be fine.

autoreconf or autoheader && autoconf

[wenzeslaus]

So the big change is that we are now using different tools to generate configure (and newly also config.h.in). Is that right?

Looks good to me otherwise.

[marisn]

Changes are not autoconf 2.72 specific and thus should be fine also on (a bit) older versions.

I was wrong. Minimum autoconf version is 2.71: #2281

[marisn]

So the big change is that we are now using different tools to generate configure (and newly also config.h.in). Is that right?

The big change is that we keep our custom build tweaks in configure.ac and not auto-generated files. This is the correct way how to do it. In the process we also got rid of some old cruft. Generally now it is necessary only to track changes in configure.ac file, the rest (configure, include/grass/conf.h.in) – only if you have a paranoia that autoconf in use have been compromised.

Changes in configure, include/grass/conf.h.in depend on autoconf used to generate them, thus there always will be changes. As previous version was generated with 2.71 but Debian Sid has moved to 2.72, it causes some changes as a side-effect.

[nilason]

Sorry to chime in this late, very busy days behind me. Great work to clean up the config.h.in! It was very unfortunate place to place manually added code from the start.

(Just wish you would have separated the unrelated 2.72 changes to a PR in its own, for clearer history).

[ninsbl]

Just noticed that current builds show up with Large File Support (LFS): no. See e.g.: https://github.com/OSGeo/grass/actions/runs/18658480388/job/53193250341#step:10:275
Not sure it this is related to this PR. Here: https://github.com/OSGeo/grass/actions/runs/18549653323/job/52874607114 it was stil enabled by default... Is that a regression that warrants a new issue?

[marisn]

That is an AMD64 build system – LFS on it is a no-op as it supports 64 bits natively. Please test in a 32 bit environment to see if LFS is handled correctly (we don't have any 32bit machine in our CI).