OSLib and ELF

[John Tytgat]

In message <gemini.jgadf501hxveo03mn.tony at vanderhoff.org>
          Tony van der Hoff <tony at vanderhoff.org> wrote:
> John Tytgat <John.Tytgat at aaug.net> wrote:
> > Technically this isn't difficult.  As indicated by JMB in this thread as
> > well, he made some ELF patches for OSLib which I only had to update a few
> > bits as update to get it working with the current experimental GCCSDK 4.1
> > cross-compiler.
> > 
> > I would like to put forward the following plan and voluntering to execute
> > it when there is a consensus:
> > 
> >   Create OSLib 7.00 supporting ELF and AOF based APCS-32 static libraries.
> >   The former done by GCCSDK 4, the latter done by GCCSDK 3.4 cross-compilers.
> 
> I have a slight concern over having to use different cross-compilers for the
> the two variants. It requires GCCSDK 3.4 to remain current, and the GCCSDK
> project, for all its positive attributes, has not got a good history in that
> respect.

Eh really ? What things in history are you referring to ?

> I believe, apart from my other concerns below, that because of vested
> interests, as well as differing development environments, this action is
> likely to fork the code, with development continuing on the ELF branch, and
> the ALF branch becoming a back-water. That would be unacceptable.

I see no reason why OSLib would become forked because of the usage of two
cross-compilers.  We should be able to output either AOF either ELF output
using the same sources & build system but using different cross-compilers.

> > I'm leaving out the APCS-R version and native Norcroft/GCC build on RISC
> > OS as I think they are not that relevant anymore today.
> 
> Sorry, I strongly disagree. The OSLib philosophy has been to always retain
> backward compatibility, unless there were very good reasons not to do so.

Ok, lets discuss possible good reasons. ;-)

> If
> I understand you correctly, your reason for proposing to drop APCS-R as well
> as the RISC OS build capability is one of laziness, rather than any
> technical obstacle.

I haven't said "laziness", I've said "relevant".  I don't think making
*new* OSLib releases containing APCS-R libraries are relevant anymore,
especially when it is going to be labeled '7.00' i.e. major new release.
But I'm more than happy to hear cases from developers planning to use *new*
OSLib releases in their APCS-R programs in the future.  I think by now
every active developer has his programs switched to APCS-32.

You asked for good reasons: the most important one is that time is limited
for every developer so I want to focus on efforts which are for sure
beneficial for other RISC OS developers and users.  I'm not convinced at all
that's going to be the case for new APCS-R based OSLib releases.

> I don't think that's good enough. Whether or not this
> backward compatibility is currently relevant is not up for debate;

I haven't said that 'backward compatibility' is not relevant, I've said in
my proposal that I think that APCS-R and native RISC OS build are not
relevant for new releases.

> we have
> promised our users that backward compatibility will be maintained. I put in
> a lot of effort to maintain the RISC OS build capability when I developed
> the UNIX build facility for this very reason.

We have to watch out that 'infinite' backward compatibility does not result
in any strangelation of further development or contributions.

An example : one problem I have with the current cross-compile facility of
OSLib is that it doesn't allow parallel build, even worse, it breaks if you
try this because not all dependencies are in place.  I've looked a couple
of times into fixing this and my opinion is that improving this could be
seriously helped if the overall build structure could be changed as well.

Doing this would break native OSLib builds without further changes so either
we buy that and declare this as no longer a feature of OSLib 7, either we
try to use the same set of Makefiles with GNU make (which I think is the
best solution for this situation).

However seen the very long build times on RISC OS I'm not candidate to check
this out myself.  I'm very happy to help and work together with someone else
taking care of those changes for RISC OS native build but on the other hand
is it worth to do these efforts today ? So far we've only Tom who wants to
build DefMod2 natively using his own build setup so he's not going to be
affected by such a change.  And we have Druck who finds it "very important".
But at what expense ?

I've added to the proposal to make such build changes but when RISC OS build
feature needs to be retained I'll have to drop that as I can't justify
for myself the efforts involved.

> Additionally, I don't see that much is to be gained by dropping APCS-R or
> RISC OS build,

Less work, less QA, faster build times, smaller releases, less high
stonestep for additional improvements (like outlined above) etc.  So mine
and other OSLib developer's time can be spent on other RISC OS developments
(hopefully) making a difference there.

> and it is absolutely imperative that APCS-32 be maintained.

Of course, that's why I stated this as first line in my proposal.  With
ELF only APCS-32 ABI is supported.

> My vote is therefore against this.

Just to be sure: you mean "against dropping APCS-R" ? And/or "against
dropping RISC OS build" ? Not even for a major OSLib release ?

> > For this I think the following steps are needed:
> > 
> >   - Convert the OSLib sf.net CVS repository to SVN (cfr the SVN support
> >     page, it's quite a procedure to do).  The reason is mostly for
> >     convieniance reasons and I think we're going to move some files as
> well
> >     which doesn't result in history lost with SVN.
> 
> It's undoubtedly a good idea to move to SVN, and in fact, I've been
> considering it myself, but prevented from doing so by other priorities.
> However, I don't see it as a pre-requisite to further development, and would
> argue in favour of doing it as a seperate project to the ELF work, in order
> to avoid changing too many things at the same time. On balance my vote would
> be to perform the ELF work first, and get that stable within CVS, before
> moving the whole stable package to SVN; possibly even maintaining the two
> repositories in parallel until the next major upgrade.
> 
> I wouldn't object wildly to moving the whole OSLib source to SVN, and then
> taking a breather while users get their own systems in sync. Personally, all
> my code is still in CVS, so it would imply a certain upheaval for me, which
> I'd want to avoid.

I really would prefer to do it before the ELF developments like originally
stated, i.e. move to SVN first and do the ELF developments.  History keeping
is much better than SVN and SVN checkins can involve more files at the same
time keeping all those changes together resulting in better reporting
afterwards.

For the SVN move, the impact for the developer is very minimal.  Instead of
doing:

  cvs -z3 -d:ext:USERNAME at PROJECTNAME.cvs.sourceforge.net:/cvsroot/PROJECTNAME checkout MODULENAME

you do:

  svn co https://svn.sourceforge.net/svnroot/PROJECTNAME/trunk

and the end result on your disc is the same apart from the .cvs and .svn
subdirectories.  The .cvsignore files can be dropped and preplaced by
svn:ignore SVN properties.  And there is also an excellent SVN RISC OS port.

> Presumably we would need to modify the download instructions on the home
> page.

Of course, that was part of the proposal.  Including the outline of the
development plans for OSLib 7.00 after having a consensus.

> >   - Import JMB's and mine changes to support ELF build.
> >   - Changes in the build system (maybe on top the possibility of doing
> >     parallel builds).
>
> I assume you would be quite happy to manage this development, John?

Yes, certainly for the full proposed plan as originally said.  But like for
everybody else, time for this is not unlimited so if we expect that all
OSLib features (including native build facility) needs to be supported
and that this is not open for further debate, then I'm not even sure I
have a proposal to make at all.

As the ELF build can only be done with GCCSDK 4 which is currently in
experimental/testing cross-compile stage and there is not even a RISC OS
build yet so I can not add ELF build changes and make sure that the
RISC OS build remains working, let alone has ELF support as well.

So I'm a bit stuck with my proposal to be honest.

> I'm
> unfortunately very tied up at present with other projects, and cannot
> contemplate doing it this year. Given the above caveats, you have my
> blessing to proceed. Assuming you stick with CVS for the time being, I take
> it you will do this on a new branch, which can eventually be merged back
> into the trunk.

I've no problem doing this on a (svn ;-)) branch and merging it in at
a later moment. An the other hand, you expressed a fear of an ELF vs AOF
fork which might perhaps better be addressed doing all those new
developments on trunk and if there is a need for stability fixes on the
latest 6.90 release, why not create a release fix branch on 6.90 code
instead ?

I don't mind which approach we're taking here to be honest.

> I take it that implies a third version of the library, namely OSLib
> (APCS-R), OSLib32 (APCS-32), and OSLib-ELF?

In order to avoid all confusion for others: APCS-R and APCS-32 are ABIs and
are independant from the object fileformat used (i.e. AOF/ALF vs ELF). So
we can rephraze this question into: OSLib (AOF/ALF APCS-R), OSLib32
(AOF/ALF APCS-32) and OSLib-ELF (ELF APCS-32).  And yes the ELF support
means a separate version.  Not only the binary (library) is different, but
also the ASM headers.

> I assume there will be no changes to the C and ASM headers;

No changes foreseen for C headers, but the ASM headers will be different
for gas assembler syntax.

> we would need to maintain the deep, wide, and UNIX directory structures.

I would question the relevancy of 'deep' as well today.  My guess is that
most, if not all, OSLib users are using a FS which doesn't have the old
FileCore number of objects limitation.  But that's probably raising the same
arguments for APCS-R and native build support... :-/

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