Re: RISC OS port

[Marco Gerards <metgerards@student.han.nl>]

Timothy Baldwin <tim.lists@majoroak.f2s.com> writes:

Whoops, I just noticed I forgot to answer this email... :/

>> > Define BUILD to "build/" when cross compiling or to ""
>> > when not cross-compiling and prefix use of the utilites
>> > in makefiles with $(BUILD).
>> >
>> > Shall I do that?
>> 
>> This does not look like a clean solution to me.
>
>> Normally this is not 
>> required to do it like this, right?
>
> The gcc package also uses multiple runs of configure.
>
> You're right, genmoddep does not require the services of configure,
> but then why was support for checking the build system compiler
> added to configure.ac?
>
> I suggest removing that support, and only use BUILD_CC for compiling
> genmoddep. Support for building cross versions of the tools could be
> retained by supporting configure's --target option. 

So you mean you can choose if grub-mkimage is compiled for the host or
target system?  I think that would be useful.  Considering two
scenarios:

1) Building the PPC version of GRUB using a PC.  In the case
   grub-mkimage (the one form the ieee1275/ppc directory) works on the
   PC, I can make an ELF including some modules.  This is really
   useful when developing.

2) When cross-compiling a Debian package, everything has to be build
   for the host, with some specific tools used in the buildprocess as
   an exception.

So if configure somehow supports this in a sane way, it would seem
nice to have.  As most people here know, I am quite clueless about the
autotools... :/

>> Why do you need perl?
>
> A perl program is used to convert the list of machine names 
> and numbers from Linux.

I have my doubts about adding a dependency for perl to GRUB, although
it is required for automake too.  So when is it required, when the
developers change something or when a user wants to compile it?

>> Can't you use GRUB_ERR_BAD_FS 
>> or GRUB_FS_BAD_FILE_TYPE instead?
>
> The error is probably not one of those, and could almost anything.

Sorry, I do not understand what you mean.

>
>  
>> > +void *EXPORT_FUNC(memcpy) (void *dest, const void *src, grub_size_t n);
>> > +void *EXPORT_FUNC(memset) (void *s, int c, grub_size_t n);
>> 
>> Why do you want to do this?  Can't you just use grub_memcpy and
>> grub_memset instead?
>
> They are called implictally by gcc.

Right.  I had stuff like this in the PPC port as well.  Perhaps you
can make a libgcc.h, like I did for the PPC port?

>> > -#define FUNCTION(x) .globl EXT_C(x) ; .type EXT_C(x), @function ; EXT_C(x):
>> > -#define VARIABLE(x) .globl EXT_C(x) ; .type EXT_C(x), @object ; EXT_C(x):
>> > +#define FUNCTION(x) .globl EXT_C(x) ; .type EXT_C(x), "function" ; EXT_C(x):
>> > +#define VARIABLE(x) .globl EXT_C(x) ; .type EXT_C(x), "object" ; EXT_C(x):
>> 
>> Can you please explain this change?
>
> "@" marks the start of a comment in ARM GNU as syntax, producing a syntax
> error. I expect double quotes to work for all architures. Tested on x86 and PowerPC.

Ok.

Thanks,
Marco