Re: Is detecting endianness at compile-time unworkable?

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Aug 1, 2018, 07:16 UTC
Message-ID: <87pnz2tv38.fsf@evledraar.gmail.com>
In-Reply-To: <xmqq600wkc4i.fsf@gitster-ct.c.googlers.com>

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

Show 8 quoted lines

> Æ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...).

Show 5 quoted lines

> 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.