bug-mes
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-mes] mes target selection - currently hardcoded


From: Danny Milosavljevic
Subject: Re: [bug-mes] mes target selection - currently hardcoded
Date: Mon, 4 Feb 2019 19:53:05 +0100

Hi Janneke,

On Mon, 04 Feb 2019 18:36:21 +0100
Jan Nieuwenhuizen <address@hidden> wrote:

> We also have to reconsider this GNUmakefile snippet
> 
> --8<---------------cut here---------------start------------->8---
> .config.make:
>       ${srcdir}/configure --prefix=$(prefix)
> --8<---------------cut here---------------end--------------->8---
> 
> maybe you got bitten by this too.

Maybe!  That would explain a lot.  It was kinda spooky.

> I think that means we need at least a --host flag on configure...but
> what about --build?  Should we add them both?  Have HOST-TYPE default to
> BUILD-TYPE?  WDYT?

If we do touch the mechanism anyway, I'd add host, build and target.

In general, the GNU naming convention for non-compilers (for example for
the tic tac toe game) are like this:

* build: The system that does the building of the tic tac toe game.
* host: The system that you want to run the tic tac toe game on.

The GNU naming conventions for building compilers are one step more
complicated since compilers also generate code for an architecture
when you run them.
So when building compilers it is:

* build: The system that does the building of the compiler.
* host: The system that you want to run the compiler on.
* target: The system that you want programs generated BY the compiler to run
on.

I'm not much of a fan of cross-compiling (after having it done for way too
long), but there's no reason not to support it.  Especially for bootstrapping
new architectures it is nice to AT FIRST bootstrap it using a cross compiler
(if only to see whether it's working at all).

So surprisingly, I advocate adding build, host and target, although I
hopefully won't use a different target myself ;)

In general, if anything, only the build system type could be usefully
autodetected.

The host system type can default to the build system type (and I think
that's good).

The target system type can default to the ... hmmmmmmmmmmm... host system
type, I guess?  Not sure.

If host and target are the same but build is different, you are offloading
for another system and want both the compiler you build and the executables
it eventually generates to run on the "client" system that requested the
offload.

If build and host are equal but target is different, you are building
for another system, but you want all the actual tools to run on your
machine as much as possible (embedded developers use this because their
targets have too little RAM to run dev tools--and certainly they can't
run a compiler there).

So I guess with autodetection it would be something like:

<let the user set up build_system, host_system, target_system variables first>

if [ -z $build_system ]
then
  build_system=`uname -m` # if we want it
  echo "error">&2 # if we want that instead
  exit 1 # if we want that
fi

if [ -z $host_system ]
then
  host_system=$build_system
fi

if [ -z $target_system ]
then
  target_system=$host_system
fi

Sometimes they call the gnu thing the "triple", so it would be build_triple, 
maybe.

On Guix we often use the Nix system type which is not a triple (example: 
armhf-linux).

Attachment: pgpiLhY3HS4fc.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]