[PATCH] remove target_os

[PATCH] remove target_os

[Robert Millan]

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]


Hi,

Based on the description of host/target triplets in configure.ac:

dnl   build  -- the environment for building GRUB
dnl   host   -- the environment for running utilities
dnl   target -- the environment for running GRUB

it seems that target_os is an oxymoron.  There's no OS in the environment
where GRUB will run (well, there's the firmware, but we already use
target_vendor for that, and _os has a well-defined meaning).

Attached patch fixes that by supressing all references to target_os, and
replacing them with host_os where suitable.

Christian: since this mostly affects Cygwin, could you verify that it doesn't
cause breakage before I commit it?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

[-- Attachment #2: target_os.diff --]
[-- Type: text/x-diff, Size: 2628 bytes --]

2009-01-26  Robert Millan  <rmh@aybabtu.com>

	* Makefile.in (host_os, host_cpu): New variables.
	(target_os): Remove.  Update all users.

Index: Makefile.in
===================================================================
--- Makefile.in	(revision 1954)
+++ Makefile.in	(working copy)
@@ -47,8 +47,10 @@ PACKAGE_VERSION = @PACKAGE_VERSION@
 PACKAGE_STRING = @PACKAGE_STRING@
 PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
 
+host_os = @host_os@
+host_cpu = @host_cpu@
+
 target_cpu = @target_cpu@
-target_os = @target_os@
 platform = @platform@
 
 INSTALL = @INSTALL@
Index: conf/common.rmk
===================================================================
--- conf/common.rmk	(revision 1954)
+++ conf/common.rmk	(working copy)
@@ -146,7 +146,7 @@ CLEANFILES += update-grub_lib
 	./config.status --file=$@:$<
 	chmod +x $@
 grub-mkconfig_SCRIPTS = 00_header 10_linux 10_hurd 10_freebsd 30_os-prober 40_custom
-ifeq ($(target_os), cygwin)
+ifeq ($(host_os), cygwin)
 grub-mkconfig_SCRIPTS += 10_windows
 endif
 
Index: configure.ac
===================================================================
--- configure.ac	(revision 1955)
+++ configure.ac	(working copy)
@@ -103,12 +103,10 @@ case "$host_os" in
   mingw32) host_os=cygwin ;;
 esac
 
-case "$target_os" in
-  mingw32) target_os=cygwin ;;
-esac
+AC_SUBST(host_cpu)
+AC_SUBST(host_os)
 
 AC_SUBST(target_cpu)
-AC_SUBST(target_os)
 AC_SUBST(platform)
 
 #
@@ -200,10 +198,10 @@ AC_CHECK_FUNCS(posix_memalign memalign a
 
 # Use linker script if present, otherwise use builtin -N script.
 AC_MSG_CHECKING([for option to link raw image])
-if test -f "${srcdir}/conf/${target_cpu}-${platform}-${target_os}-img-ld.sc"; then
-  TARGET_IMG_LDSCRIPT='$(top_srcdir)'"/conf/${target_cpu}-${platform}-${target_os}-img-ld.sc"
+if test -f "${srcdir}/conf/${target_cpu}-${platform}-${host_os}-img-ld.sc"; then
+  TARGET_IMG_LDSCRIPT='$(top_srcdir)'"/conf/${target_cpu}-${platform}-${host_os}-img-ld.sc"
   TARGET_IMG_LDFLAGS="-Wl,-T${TARGET_IMG_LDSCRIPT}"
-  TARGET_IMG_LDFLAGS_AC="-Wl,-T${srcdir}/conf/${target_cpu}-${platform}-${target_os}-img-ld.sc"
+  TARGET_IMG_LDFLAGS_AC="-Wl,-T${srcdir}/conf/${target_cpu}-${platform}-${host_os}-img-ld.sc"
 else
   TARGET_IMG_LDSCRIPT=
   TARGET_IMG_LDFLAGS='-Wl,-N'
@@ -215,8 +213,8 @@ AC_MSG_RESULT([$TARGET_IMG_LDFLAGS_AC])
 
 # For platforms where ELF is not the default link format.
 AC_MSG_CHECKING([for command to convert module to ELF format])
-case "${host_os}:${target_os}" in
-  cygwin:cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
+case "${host_os}" in
+  cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
   *) ;;
 esac
 AC_SUBST(TARGET_OBJ2ELF)

Re: [PATCH] remove target_os

[Christian Franke]

Robert Millan wrote:
> Hi,
>
> Based on the description of host/target triplets in configure.ac:
>
> dnl   build  -- the environment for building GRUB
> dnl   host   -- the environment for running utilities
> dnl   target -- the environment for running GRUB
>
> it seems that target_os is an oxymoron.  There's no OS in the environment
> where GRUB will run (well, there's the firmware, but we already use
> target_vendor for that, and _os has a well-defined meaning).
>
> Attached patch fixes that by supressing all references to target_os, and
> replacing them with host_os where suitable.
>
> Christian: since this mostly affects Cygwin, could you verify that it doesn't
> cause breakage before I commit it?
>
>   

Hi Robert,

thanks for sending the patch first. Cygwin build looks good.


But even if GRUB itself is build for some $target_cpu-$target_vendor 
(i386-pc), the target_os is not useless if cross-compilation support is 
desired:

- GRUB tools like grub-setup are build for the target_os
- Package structure may depend on target_os.

- The gcc code generator may emit special code tailored for the assumed 
target_os
Examples:
Stack frame checks
Nested function trampolines (__enable_execute_stack())

Unfortunately, gcc has no '-fno_os' option to specify the bare CPU as 
target.
Fortunately, all current issues can be handled by autoconf checks.


>  AC_MSG_CHECKING([for command to convert module to ELF format])
> -case "${host_os}:${target_os}" in
> -  cygwin:cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
> +case "${host_os}" in
> +  cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
>    *) ;;
>  esac
>   

This won't work for a Linux cross compiler hosted on Cygwin. It would 
emit ELF format and does not need pe2elf.

But all this is theoretical unless cross compilation is really needed.

Christian

Re: [PATCH] remove target_os

[Javier Martín]

[-- Attachment #1: Type: text/plain, Size: 2744 bytes --]

Hi GRUB devs,
El lun, 26-01-2009 a las 20:57 +0100, Christian Franke escribió:
> Robert Millan wrote:
> > Hi,
> >
> > Based on the description of host/target triplets in configure.ac:
> >
> > dnl   build  -- the environment for building GRUB
> > dnl   host   -- the environment for running utilities
> > dnl   target -- the environment for running GRUB
> >
> > it seems that target_os is an oxymoron.  There's no OS in the environment
> > where GRUB will run (well, there's the firmware, but we already use
> > target_vendor for that, and _os has a well-defined meaning).
> >
> > Attached patch fixes that by supressing all references to target_os, and
> > replacing them with host_os where suitable.
> >
> > Christian: since this mostly affects Cygwin, could you verify that it doesn't
> > cause breakage before I commit it?
> >
> >   
> 
> Hi Robert,
> 
> thanks for sending the patch first. Cygwin build looks good.
> 
> 
> But even if GRUB itself is build for some $target_cpu-$target_vendor 
> (i386-pc), the target_os is not useless if cross-compilation support is 
> desired:
> 
> - GRUB tools like grub-setup are build for the target_os
> - Package structure may depend on target_os.
> 
> - The gcc code generator may emit special code tailored for the assumed 
> target_os
> Examples:
> Stack frame checks
> Nested function trampolines (__enable_execute_stack())
> 
> Unfortunately, gcc has no '-fno_os' option to specify the bare CPU as 
> target.

Might -ffreestanding be what you are looking for?

> Fortunately, all current issues can be handled by autoconf checks.
> 
> 
> >  AC_MSG_CHECKING([for command to convert module to ELF format])
> > -case "${host_os}:${target_os}" in
> > -  cygwin:cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
> > +case "${host_os}" in
> > +  cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
> >    *) ;;
> >  esac
> >   
> 
> This won't work for a Linux cross compiler hosted on Cygwin. It would 
> emit ELF format and does not need pe2elf.

A, say, AMD64 Linux cross compiler hosted on x86 Cygwin would have
$build=i686-pc-cygwin and $host=amd64-linux-gnu. Thus, no conflict ought
to arise even with cross compilation enabled.

AFAIK, the full power of $build+$host+$target only matters when building
_compilers_ (and binutils, etc.), because you might want to use an
AMD64/Linux machine to build a compiler that will run on PPC/Darwin but
produce executables for a x86/Cygwin machine

> 
> But all this is theoretical unless cross compilation is really needed.
>
> Christian
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: [PATCH] remove target_os

[Vesa Jääskeläinen]

Javier Martín wrote:
> A, say, AMD64 Linux cross compiler hosted on x86 Cygwin would have
> $build=i686-pc-cygwin and $host=amd64-linux-gnu. Thus, no conflict ought
> to arise even with cross compilation enabled.
> 
> AFAIK, the full power of $build+$host+$target only matters when building
> _compilers_ (and binutils, etc.), because you might want to use an
> AMD64/Linux machine to build a compiler that will run on PPC/Darwin but
> produce executables for a x86/Cygwin machine

Now lets move this idea to GRUB 2:

There is a build server is running on PPC/Linux and it wants to build
all architectures supported by GRUB 2 (provide proper boot code for all
arch and tools) and then makes software bundles (rpm,deb, or so) for all
architectures.

In example if all shell tools are to be ran on x86-64/Linux and then
boot code needs to be compatible with x86-32 as there is PC-BIOS present
on target system.

Re: [PATCH] remove target_os

[Christian Franke]

Javier Martín wrote:
>> Unfortunately, gcc has no '-fno_os' option to specify the bare CPU as 
>> target.
>>     
>
> Might -ffreestanding be what you are looking for?
>
>   

The option '-ffreestanding' is the same as '-fno-hosted'.

According to gcc (4.3.1) source, '-fno-hosted' clears variable 
'flag_hosted' and sets '-fno-builtin'. The latter is already set within 
GRUB build.

A cleared 'flag_hosted' apparently has only 2 effects:
- disable the special handling of 'main()'.
- #define __STDC_HOSTED__ to 0 instead of 1

There is no effect on the target_os dependent parts of the gcc code 
generation. For example, on i386, __enable_execute_stack() calls are 
generated for target_os netbsd, openbsd and cygwin, but not for linux. 
The emit call is hard-coded in 
gcc/configs/i386/i386.c:x86_initialize_trampoline().

Other workarounds are needed to support building GRUB with code 
generators tailored for various target_os.


>>
>>>  AC_MSG_CHECKING([for command to convert module to ELF format])
>>> -case "${host_os}:${target_os}" in
>>> -  cygwin:cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
>>> +case "${host_os}" in
>>> +  cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
>>>    *) ;;
>>>  esac
>>>   
>>>       
>> This won't work for a Linux cross compiler hosted on Cygwin. It would 
>> emit ELF format and does not need pe2elf.
>>     
>
> A, say, AMD64 Linux cross compiler hosted on x86 Cygwin would have
> $build=i686-pc-cygwin and $host=amd64-linux-gnu. Thus, no conflict ought
> to arise even with cross compilation enabled.
>
>   

But the opposite won't work: $host=i686-pc-cygwin would enable 
grub-pe2elf, even if this gcc emits ELF for a linux target.

Christian

Re: [PATCH] remove target_os

[Javier Martín]

[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]

El mar, 27-01-2009 a las 18:51 +0200, Vesa Jääskeläinen escribió:
> Javier Martín wrote:
> > A, say, AMD64 Linux cross compiler hosted on x86 Cygwin would have
> > $build=i686-pc-cygwin and $host=amd64-linux-gnu. Thus, no conflict ought
> > to arise even with cross compilation enabled.
> > 
> > AFAIK, the full power of $build+$host+$target only matters when building
> > _compilers_ (and binutils, etc.), because you might want to use an
> > AMD64/Linux machine to build a compiler that will run on PPC/Darwin but
> > produce executables for a x86/Cygwin machine
> 
> Now lets move this idea to GRUB 2:
> 
> There is a build server is running on PPC/Linux and it wants to build
> all architectures supported by GRUB 2 (provide proper boot code for all
> arch and tools) and then makes software bundles (rpm,deb, or so) for all
> architectures.
> 
> In example if all shell tools are to be ran on x86-64/Linux and then
> boot code needs to be compatible with x86-32 as there is PC-BIOS present
> on target system.

So you propose --target to be reused like this (a PS3 building GRUB2 for
an amd64 BIOS PC with Linux) :
./configure --build=ppc64-linux --host=x86_64-linux-gnu --target=i686-pc
              ^--compiling system ^--tools system         ^--boot arch

I think we already have a better-geared switch for that (--with-platform
it is?), which is currently used to distinguish between BIOS and EFI
boot code on both x86 and x86-64.

> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: [PATCH] remove target_os

[Javier Martín]

[-- Attachment #1: Type: text/plain, Size: 2810 bytes --]

El mar, 27-01-2009 a las 18:21 +0100, Christian Franke escribió:
> Javier Martín wrote:
> >> Unfortunately, gcc has no '-fno_os' option to specify the bare CPU as 
> >> target.
> >>     
> >
> > Might -ffreestanding be what you are looking for?
> >
> >   
> 
> The option '-ffreestanding' is the same as '-fno-hosted'.
> 
> According to gcc (4.3.1) source, '-fno-hosted' clears variable 
> 'flag_hosted' and sets '-fno-builtin'. The latter is already set within 
> GRUB build.
> 
> A cleared 'flag_hosted' apparently has only 2 effects:
> - disable the special handling of 'main()'.
> - #define __STDC_HOSTED__ to 0 instead of 1
> 
> There is no effect on the target_os dependent parts of the gcc code 
> generation. For example, on i386, __enable_execute_stack() calls are 
> generated for target_os netbsd, openbsd and cygwin, but not for linux. 
> The emit call is hard-coded in 
> gcc/configs/i386/i386.c:x86_initialize_trampoline().

In that case, we are dealing with a GCC bug. We might want to require
the user to create a bare "no-OS" cross compiler. These thingies are
most likely only known to OS developers, but you can build a perfectly
good "i686-pc-elf" GCC (only with no libc, of course). This might be the
Right Way (TM) of building boot code, instead of the current way of
using the OS-targetter compiler and trying to tell it not to do what it
was built to do.

> 
> Other workarounds are needed to support building GRUB with code 
> generators tailored for various target_os.
> 
> 
> >>
> >>>  AC_MSG_CHECKING([for command to convert module to ELF format])
> >>> -case "${host_os}:${target_os}" in
> >>> -  cygwin:cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
> >>> +case "${host_os}" in
> >>> +  cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
> >>>    *) ;;
> >>>  esac
> >>>   
> >>>       
> >> This won't work for a Linux cross compiler hosted on Cygwin. It would 
> >> emit ELF format and does not need pe2elf.
> >>     
> >
> > A, say, AMD64 Linux cross compiler hosted on x86 Cygwin would have
> > $build=i686-pc-cygwin and $host=amd64-linux-gnu. Thus, no conflict ought
> > to arise even with cross compilation enabled.
> >
> >   
> 
> But the opposite won't work: $host=i686-pc-cygwin would enable 
> grub-pe2elf, even if this gcc emits ELF for a linux target.

"The opposite" of a the described situation would be a Linux AMD64
machine cross compiling for a Cygwin x86 machine, that is
$build=amd64-linux-gnu and $host=i686-pc-cygwin. In that case,
i686-pc-cygwin-gcc would generate PE executables, and thus grub-pe2elf
_is_ required indeed.

> 
> Christian
> 
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: [PATCH] remove target_os

[Christian Franke]

Javier Martín wrote:
> El mar, 27-01-2009 a las 18:21 +0100, Christian Franke escribió:
>   
>> Javier Martín wrote:
>>     
>>>> Unfortunately, gcc has no '-fno_os' option to specify the bare CPU as 
>>>> target.
>>>>     
>>>>         
>>> Might -ffreestanding be what you are looking for?
>>>
>>>   
>>>       
>> The option '-ffreestanding' is the same as '-fno-hosted'.
>>
>> According to gcc (4.3.1) source, '-fno-hosted' clears variable 
>> 'flag_hosted' and sets '-fno-builtin'. The latter is already set within 
>> GRUB build.
>>
>> A cleared 'flag_hosted' apparently has only 2 effects:
>> - disable the special handling of 'main()'.
>> - #define __STDC_HOSTED__ to 0 instead of 1
>>
>> There is no effect on the target_os dependent parts of the gcc code 
>> generation. For example, on i386, __enable_execute_stack() calls are 
>> generated for target_os netbsd, openbsd and cygwin, but not for linux. 
>> The emit call is hard-coded in 
>> gcc/configs/i386/i386.c:x86_initialize_trampoline().
>>     
>
> In that case, we are dealing with a GCC bug. We might want to require
> the user to create a bare "no-OS" cross compiler. 
>
>   

Is building a bare 'no-OS' compiler supported by the upstream GCC sources?
Probably a too strict prerequisite for building GRUB.


>>>>>  AC_MSG_CHECKING([for command to convert module to ELF format])
>>>>> -case "${host_os}:${target_os}" in
>>>>> -  cygwin:cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
>>>>> +case "${host_os}" in
>>>>> +  cygwin) TARGET_OBJ2ELF='grub-pe2elf' ;;
>>>>>    *) ;;
>>>>>  esac
>>>>>   
>>>>>       
>>>>>           
>>>> This won't work for a Linux cross compiler hosted on Cygwin. It would 
>>>> emit ELF format and does not need pe2elf.
>>>>     
>>>>         
>>> A, say, AMD64 Linux cross compiler hosted on x86 Cygwin would have
>>> $build=i686-pc-cygwin and $host=amd64-linux-gnu. Thus, no conflict ought
>>> to arise even with cross compilation enabled.
>>>
>>>   
>>>       
>> But the opposite won't work: $host=i686-pc-cygwin would enable 
>> grub-pe2elf, even if this gcc emits ELF for a linux target.
>>     
>
> "The opposite" of a the described situation would be a Linux AMD64
> machine cross compiling for a Cygwin x86 machine, that is
> $build=amd64-linux-gnu and $host=i686-pc-cygwin. In that case,
> i686-pc-cygwin-gcc would generate PE executables, and thus grub-pe2elf
> _is_ required indeed.
>   

Yes - I was wrong, sorry.


Robert: Patch is IMO GTG.

Christian

Re: [PATCH] remove target_os

[Javier Martín]

[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]

El mar, 27-01-2009 a las 20:56 +0100, Christian Franke escribió:
> Javier Martín wrote:
> > El mar, 27-01-2009 a las 18:21 +0100, Christian Franke escribió:
> >   
> >> Javier Martín wrote:
> >>     
> >>>> Unfortunately, gcc has no '-fno_os' option to specify the bare CPU as 
> >>>> target.
> >>>>     
> >>>>         
> >>> Might -ffreestanding be what you are looking for?
> >>>
> >>>   
> >>>       
> >> The option '-ffreestanding' is the same as '-fno-hosted'.
> >>
> >> According to gcc (4.3.1) source, '-fno-hosted' clears variable 
> >> 'flag_hosted' and sets '-fno-builtin'. The latter is already set within 
> >> GRUB build.
> >>
> >> A cleared 'flag_hosted' apparently has only 2 effects:
> >> - disable the special handling of 'main()'.
> >> - #define __STDC_HOSTED__ to 0 instead of 1
> >>
> >> There is no effect on the target_os dependent parts of the gcc code 
> >> generation. For example, on i386, __enable_execute_stack() calls are 
> >> generated for target_os netbsd, openbsd and cygwin, but not for linux. 
> >> The emit call is hard-coded in 
> >> gcc/configs/i386/i386.c:x86_initialize_trampoline().
> >>     
> >
> > In that case, we are dealing with a GCC bug. We might want to require
> > the user to create a bare "no-OS" cross compiler. 
> >
> >   
> 
> Is building a bare 'no-OS' compiler supported by the upstream GCC sources?
> Probably a too strict prerequisite for building GRUB.

I can't vouch so for all possible environments, but I can say that
"clean" no-OS targets like i386-pc-elf exist at least for x86 and x86_64
(this last being added as of GCC 4.3.2). However, as I said, if
-ffreestanding does not do its job of providing a "true" freestanding
environment (i.e. without relying on _any_ external libraries or
syscalls, as opposite to the usual hosted environment), a bug report
should be posted.


[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: [PATCH] remove target_os

[Christian Franke]

Javier Martín wrote:
> El mar, 27-01-2009 a las 20:56 +0100, Christian Franke escribió:
>   
>> Is building a bare 'no-OS' compiler supported by the upstream GCC sources?
>> Probably a too strict prerequisite for building GRUB.
>>     
>
> I can't vouch so for all possible environments, but I can say that
> "clean" no-OS targets like i386-pc-elf exist at least for x86 and x86_64
> (this last being added as of GCC 4.3.2). However, as I said, if
> -ffreestanding does not do its job of providing a "true" freestanding
> environment (i.e. without relying on _any_ external libraries or
> syscalls, as opposite to the usual hosted environment), a bug report
> should be posted.
>
>   

I haven't examined more recent gcc sources yet, the extra effect of 
-ffreestanding on 4.3.1 is a no-op if the program does not use main().

How do those no-OS targets handle the platform independent libgcc 
functions, e.g. __divdi3 which is used for 64bit integer division at 
least on i386 ? Is a no-OS version of libgcc provided or should the 
programmer handle these cases ?

Christian

Re: [PATCH] remove target_os

[Robert Millan]

On Mon, Jan 26, 2009 at 08:57:10PM +0100, Christian Franke wrote:
> But even if GRUB itself is build for some $target_cpu-$target_vendor 
> (i386-pc), the target_os is not useless if cross-compilation support is 
> desired:
> 
> - GRUB tools like grub-setup are build for the target_os
> - Package structure may depend on target_os.

That would be host_os.  Consider this example: a system running on cpu
FOO cross-compiles grub (i.e. stuff like grub-probe or grub-mkimage)
so that it will run on cpu BAR.  However, grub-mkimage should generate
images for cpu BAZ (accordingly, the modules are built for BAZ too).

This means build_cpu=FOO host_cpu=BAR target_cpu=BAZ.

host_os, then, is the OS that runs on BAR.  It isn't necessarily related
to BAZ.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

remove OS part of --target=xxx (Re: [PATCH] remove target_os)

[Robert Millan]

On Tue, Jan 27, 2009 at 06:33:47PM +0100, Javier Martín wrote:
> 
> So you propose --target to be reused like this (a PS3 building GRUB2 for
> an amd64 BIOS PC with Linux) :
> ./configure --build=ppc64-linux --host=x86_64-linux-gnu --target=i686-pc
>               ^--compiling system ^--tools system         ^--boot arch

I'm not proposing to change the way --target is used, only describing what
its argument is supposed to mean, based on a comment from configure.ac.

I agree that having to specify an OS for --target in command-line is odd
too, but it's a different problem.  Maybe we could ask the config.sub
maintainer for a dummy value, such as "unknown" or so (I think Glibc had
a --host for standalone -no OS- arm builds, perhaps we could use the
same).

> I think we already have a better-geared switch for that (--with-platform
> it is?), which is currently used to distinguish between BIOS and EFI
> boot code on both x86 and x86-64.

--with-platform is an override for the default platform that is otherwise
derived from target_vendor, AFAIK.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [PATCH] remove target_os

[Robert Millan]

On Tue, Jan 27, 2009 at 08:56:59PM +0100, Christian Franke wrote:
> 
> Robert: Patch is IMO GTG.

Ok.  If noone objects I'll check it in soon.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [PATCH] remove target_os

[Robert Millan]

On Sat, Feb 07, 2009 at 10:54:32PM +0100, Robert Millan wrote:
> On Tue, Jan 27, 2009 at 08:56:59PM +0100, Christian Franke wrote:
> > 
> > Robert: Patch is IMO GTG.
> 
> Ok.  If noone objects I'll check it in soon.

Committed.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."