Re: Is detecting endianness at compile-time unworkable?

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Mon, Jul 30 2018, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> And, as an aside, the reason we can't easily make it better ourselves is
>> because the build process for git.git doesn't have a facility to run
>> code to detect this type of stuff (the configure script is always
>> optional). So we can't just run this test ourselves.
>
> It won't help those who cross-compile anyway.

I was being unclear, what I mean by having "a hard dependency on some
way of doing checks via compiled code in our build system" is that we
would do some equivalent of this:

    diff --git a/Makefile b/Makefile
    index 08e5c54549..b021b6e1b6 100644
    --- a/Makefile
    +++ b/Makefile
    @@ -1107,7 +1107,7 @@ DC_SHA1_SUBMODULE = auto
     endif

     include config.mak.uname
    --include config.mak.autogen
    +include config.mak.autogen
     -include config.mak

     ifdef DEVELOPER

And document that in order to build git you needed to do './configure &&
make' instead of just 'make', and we'd error out by default if
config.mak.autogen wasn't there.

Now obviously that would need some sort of escape hatch. I.e. you could
invoke 'make' like this:

    make CONFIGURE_MAK_AUTOGEN_FILE=some-file

That's how you would do cross-compilation, you'd arrange to run
'./configure' on some system, save the output, and ferry over this
'some-file' to where you're building git, or you would manually prepare
a file that had all the settings we'd expect to have been set already
set.

Now, whether we do this with autoconf or not is just an implementation
detail. Looking at this some more I think since we already use the
$(shell) construct we could just have some 'configure-detect' Makefile
target which would compile various test programs, and we'd use their
output to set various settings, a sort of home-grown autoconf (because
people are bound to have objections to a hard dependency on it...).

> I thought we declared "we make a reasonable effort to guess the target
> endianness from the system header by inspecting usual macros, but will
> not aim to cover every system on the planet---instead there is a knob
> to tweak it for those on exotic platforms" last time we discussed
> this?

Yes, but I think it's worth re-visiting that decision, which was made
with the constraints that we don't have a build system that can do
checks via compiled code, so we need this hack in the first place
instead of things Just Working.

And as I pointed out in the linked E-Mail this also impacts us in other
ways, and will cause other issues in the future, so it's worth thinking
about if this is the right path to take.