OSLib and ELF

[Tony van der Hoff]

On 6 Apr at 18:36 John Tytgat <John.Tytgat at aaug.net> wrote in message
<466565cf4e.Jo at hobbes.bass-software.com>

> [ Apologies for the late reply.  My original answer on this mail thread
>   never made it to the list and only now I've a bit of room for taking
this
>   up again. ]

And yet you show anxiety when you get no response over a holiday weekend?
Like Tom, I've been away ;-)

Perhaps it would be useful to bring the private discussion back to the list.

>   
> In message <2cbf71af4e.druck at druck.freeuk.net>
>           "David J. Ruck" <druck at druck.org.uk> wrote:
> 
> > How much work would it be to generate an ELF version of OSLib as well as
> > an ALF? [...]
> 
> 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.

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'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. 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 don't think that's good enough. Whether or not this
backward compatibility is currently relevant is not up for debate; 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.
Additionally, I don't see that much is to be gained by dropping APCS-R or
RISC OS build, and it is absolutely imperative that APCS-32 be maintained.

My vote is therefore against this.


> 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. Presumably we would need to modify the download
instructions on the home page.

>   - 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? 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 take it that implies a third version of the library, namely OSLib
(APCS-R), OSLib32 (APCS-32), and OSLib-ELF?

I assume there will be no changes to the C and ASM headers; we would need to
maintain the deep, wide, and UNIX directory structures.

> Thoughts ?
Yes.


-- 
Tony van der Hoff        | mailto:tony at vanderhoff.org
Buckinghamshire, England