OSLib and ELF

[John Tytgat]

In message <gemini.jgcgwg01ih5uo06me.tony at vanderhoff.org>
          Tony van der Hoff <tony at vanderhoff.org> wrote:

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

And did someone force you to upgrade ? ;-) It's true we're highlighting here
the same discussion on priorities.  With the GCCSDK 3.3.3 pre-release 1 we've
issued that the APCS-26 support is deprecated and might be removed in
later versions.  With 3.4.6 release, it was no longer there for C/C++
compilations.

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

I'm not wearing it ;-) but IMHO I believe we have an issue with OSLib
development that trying to be full backwards compatible (feature wise, I'm
not talking about OSLib API here) that it puts a load on further development
and discourages future contributions.  That's my opinion and I would be very
happy to be proven wrongly here.  A solution to that is to focus on the
important features and have to courrage to declare some of them deprecated.

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

Ok I see your point.  We'll see but not something I want to persue.

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

But then we're talking about developers updating APCS-R programs which do
not run on Iyonix nor A9home ? I would be very amazed to hear examples of
this.  Moreover, I don't see any reason why they would upgrade OSLib
library ? For new APIs ? Would be odd seen that new APIs are targetting
the OS versions of RO5/Select. Bug fixes ? I think we have a very modest
bug fix set made the last years.

> 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 firmly believe the ELF update is relevant as otherwise I would not
volunteer to do this.  OSLib's strength and mission is to be a lightweight
veneer for OS swis (and I think it shouldn't be more than that).  If
DeskLib wants to differentiate itself against OSLib, it should not try to
mimic that (and I don't think it will happen).

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

Exactly.  We can let it be demand driven, i.e. create a 6.91 when the
APCS-R need for fixes araises.

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

Thanks.

> [snip]
> > 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,

The -j make option.  Basically doing more than one build step at the same
time.  Keeping multicore/cpu happy.  It roughly cuts build times in 2 or 3.

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

Again priority ;-)

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

Yes, that's very reasonable to do and as I said before, I'm happy to help
and work together with someone else taking further care of this.

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

No changes.  I.e. have it on board as well in the ELF build.

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

Well sure, Tom, any specifics you want to share why/how you build
OSLib/DefMod differently ?

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

Ok thanks.

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

If someone wants to step up, I'm *more* than happy to hand over JMB and
mine patches we have made so far. Volunteers ?

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

It is tempting but I'm not immediately offering myself to be in the driving
seat.  On the other hand, I'm happy to further contribute OSLib improvements.

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