OSLib and ELF

[Tony van der Hoff]

On 10 Apr at 22:23 John Tytgat <John.Tytgat at aaug.net> wrote in message
<2f8889d14e.Jo at hobbes.bass-software.com>
>> In message <gemini.jgadf501hxveo03mn.tony at vanderhoff.org>
          Tony van der Hoff <tony at vanderhoff.org> wrote:

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

Well, it is precisely the sort of thing we are discussing here; I think
GCCSDK has a somewhat cavalier attitude to supporting old code; IME, almost
every release, whilst undoubtedly an improvement, requires changes to
existing projects using it. I was forced to drop 26-bit build for
OSLibSupport against my wishes at the end of 2005, because GCC considered it
'no longer relevant'. But it was to me...

I personally don't agree with that philosophy, but it's your project, and
you (and the other developers) make the rules. That is your prerogative :)

I am very grateful to you for helping out with OSLib, and without you,
OSLib-ELF is unlikely to happen, but please, do not wear your GCCSDK hat
here.

[snip]
> 
> 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 agree there's no reason why it *should*, but I think that unless we are
careful, it *could*. Maybe I'm just being a little paranoid.

[snip]
> 
> I haven't said "laziness", I've said "relevant".  

No, the former was *my* word :). The problem is that we don't know how many
users are still relying on APCS-R, so we don't know its relevance. We are
using the term "relevance" to justify not performing a certain amount of
work. However, the degree of relevance is a stab in the dark.

The problem is that those users who are, for whatever reason, haven't moved
on to APCS-32, in all likelyhood don't subscribe to this list, and will be
in for a nasty shock next time they come to rebuild their project,
especially if, as Druck points out, it is one of those which is not easily
ported to APCS-32 (let alone ELF). I just have an uncomfortable feeling
about giving a (small) group of users a possible maintenance headache.

Druck points out one possible pitfall: existing projects which are not
easily converted to APCS-32.

There is a further question mark over OSLib's future in its entirety. Some
GCCSDK people are pushing DeskLib hard as an alternative to OSLib. I, and
probably most 'serious' developers prefer the lightweight veneer that OSLib
offers, but how many serious developers are left? Perhaps the whole damn
thing is no longer relevant, and we're wasting our time moving to support
ELF.

> 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.
> 
OK, Maybe Druck's suggestion is the happy medium; we simply freeze APCS-R at
6.9. I'm still a bit concerned about what happens if new SWIs are issued
that are required in APCS-R; we may have to support them. Other than a
back-port, I don't see how that would work. But realistically, given the
current rate of development of the OS, that seems extremely unlikely. Third
parties are more likely to release new SWIs.

> 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.
> 
Well, fair enough, and if you're going to do the work, then that should be
your choice.

[snip]
> > 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.
> 
Absolutely, and if that were the choice, then I'd support dropping APCS-R
unconditionally. However, I don't believe that is the choice. The reason for
dropping APCS-R is not as far as I can see a technical issue; it is one of
work-avoidance (maybe laziness is too strong a term :). The question
therefore is whether the saving in effort by the OSLib developers is worth
the extra effort required by OSLib users in keeping up. The former may be
quantifiable; the latter almost certainly isn't. 

> 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.
> 
I'm not entirely sure I understand what you mean by parallel build, and why
that would be considered so advantageous as to outweigh other
considerations, but certainly I would agree that the the build structure
could be improved. The reason it's not happened from my perspective is that
it did't seem to be worth the effort.

> 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).
> 
OK, let's take it as read that one way or another it is imperative that
native builds are a prerequisite. 

> However seen the very long build times on RISC OS I'm not candidate to
> check this out myself. 

Verifying it is one thing, but is it possible for you to maintain a
structure that *should* work natively, so that any changes to make files
would be minimal to maintain native capability?

> 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 ?

Well, of course that's only on this list. I know there are (or at least have
been) others who build natively. I dont't understand why you are singling
out DefMod; surely anything we discuss applies to the entire project. 

Come to that, what are your proposals re OSLibSupport?

Would it be useful to investigate incorporating Tom's build system?

> 
> 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.
> 

As I previously mentioned, I really don't think I can make the time
available to do this. So, the choices seem to be rather stark: If ELF
support is considered a prime requirement, then you, John will have to do
it, and we have to drop native builds. Personally I don't have too much of a
problem with that. 

Alternatively we ignore ELF for the time being, until such time as there is
someone available to do the entire task, retaining native builds. That may,
of course, be never. Again, personally, I don't have too much of a problem
with that.

Perhaps, given my present very limited involvement with RISC OS, it is time
for me to hand over my 7 year stewardship of OSLib to someone else; and
allow the project freedom to move in a different direction.

Any volunteers?

[snip]


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