OSLib and ELF

[John Tytgat]

In message <f6760cd24e.druck at druck.freeuk.net>
          "David J. Ruck" <druck at druck.org.uk> wrote:

> On 11 Apr 2007 Tony van der Hoff <tony at vanderhoff.org> wrote:
> 
> > On 10 Apr at 23:07 "David J. Ruck" <druck at druck.org.uk> wrote in message
> > <ee8b8dd14e.druck at druck.freeuk.net>
> > 
> >> 
> >> It is essential that a RISC OS box can build all the sources to critical
> >> components, no matter how long the build time is. Any general purpose
> >> computer platform that is incapable of tying its own shoelaces is not
> >> worth using.
> >> 
> > Whilst I would agree that it is desirable to maintain native build
> > capability, if the choice, dictated by developer availability, has to be
> > between adding ELF support and maintaining native build capability, what
> > should we choose?
> 
> There is no reason why it is an either or choice.

I don't understand your reply.  The deal is simple: if someone finds
native build important enough, volunteer to work together, test and fix it
based on adapted cross-compile build.

> > There is an argument that says that ELF support can only be added in a cross
> > development environment, so we might as well go the whole hog and abandon
> > native development entirely.
> 
> I haven't seen any reasoning to support that argument, apart from the 
> fact that the GCC developers can't be bothered to ensure they don't 
> break native building.

You are forgetting that I'm wearing here my OSLib project admin hat here.
Nowhere I've said I'm speaking as GCCSDK developer or on behalf of.

I would appreciate a more positive attitude here.  I'm proposing to do
OSLib developments (more than even simply the ELF changes) and drawing a
line how far I can justify for myself in this. I've said that I want to help
and work together with someone else taking care of the RISC OS native build
aspects but that I don't want to drive this myself.

Can you be bothered to offer your time and take up the offer for
cooperation ?

> > There is another argument that says that ELF is an alien environment, and we
> > should ignore its existance, in favour of keeping native build capability.
> 
> I don't see why we can't subsume ELF in to the native evironment, once 
> loader issues are resolved.

Eh? Which loader issues are you talking about ?

> > I guess, personally, given the stark choice, I'd have to put my weight
> > behind dropping native builds :(
> > 
> > Philosophical arguments aside, there is not a lot wrong in having to build
> > code in a cross environment if that results in positive advantages. How many
> > people, actually build OSLib natively?
> 
> As I said, its not a matter of how many, but that it remains possible. 
> Not only is it a major philosophical issue,

As this is all voluntary driven and seen that you find this a "major
philosophical issue", care to spend your part of time in it ?

> but also has contractual 
> implications, once you cannot build all dependencies natively, to 
> check point the build environment you have to also included the entire 
> cross compiler platform. That is not viable given how little money 
> there is in supporting the tail end of legacy systems.

This argument is also applicable to all closed source libraries we're
using in RISC OS developments.  Moreover, being able to build an OS
from the ground up starts with cross-compiling and then, when the OS
and hardware involved justifies this, native build can be considered.

This puts the priority on cross-compile facilities more than native
building.  And that's exactly the priority aspect where it is all about it.
I can't justify my developer time spending on addressing philosophical
issues.  I want to make the difference for the users involved, not for the
philosophers amought us.

John.
-- 
John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven