Discussion:
DeskLib and GCCSDK
Add Reply
Steve Fryatt
2020-05-11 15:04:10 UTC
Reply
Permalink
I've been attempting to build a version of the current DeskLib for use in
the GCCSDK, based on the sources at https://www.riscos.info/websvn/

A minor syntactical tweak to Makefile.unix notwithstanding, it seems to do
the right kinds of things, and

make -f Makefile.unix SCL=true install

puts the expected files into ~/gccsdk/env/...

If I then try to use it to compile an application (in this case WinEd from
the same source as above), then again it seems to do the correct sorts of
thing (except that WinEd's Makefile requires a lot of modification to make
it happy with the GCCSDK), but the process soon hits several problems.

The first, which I would like to sort out before moving on to the rest, is
that the DeskLib headers installed by the process above contain several

#include "DeskLib:Core.h"

lines and similar, which GCCSDK can't sensibly resolve. I can make things
build to a point where I'm looking at a handful of genuine-looking missing
or conflicting source files in WinEd by doing a search and replace to remove
the <DeskLib$Path> references from within ~/gccsdk/env/include/DeskLib/, but
this seems sub-optimal. Not least because the DeskLib docs refer to the
library being prepped for use in the GCCSDK, which suggests that this should
"just work". :-)

Is there some way to make GCCSDK happy with the files as they stand,
"DeskLib:Core.h" and the like included?

Also, where's the best place to ask about DeskLib nowadays. The last SVN
commit was 2012, and the Google Group that the documentation recommends for
support doesn't exist. Is anyone maintaining it?
--
Steve Fryatt

***@stevefryatt.org.uk
http://www.stevefryatt.org.uk/
Theo
2020-05-12 20:52:56 UTC
Reply
Permalink
Post by Steve Fryatt
The first, which I would like to sort out before moving on to the rest, is
that the DeskLib headers installed by the process above contain several
#include "DeskLib:Core.h"
lines and similar, which GCCSDK can't sensibly resolve. I can make things
build to a point where I'm looking at a handful of genuine-looking missing
or conflicting source files in WinEd by doing a search and replace to remove
the <DeskLib$Path> references from within ~/gccsdk/env/include/DeskLib/, but
this seems sub-optimal. Not least because the DeskLib docs refer to the
library being prepped for use in the GCCSDK, which suggests that this should
"just work". :-)
Is there some way to make GCCSDK happy with the files as they stand,
"DeskLib:Core.h" and the like included?
Also, where's the best place to ask about DeskLib nowadays. The last SVN
commit was 2012, and the Google Group that the documentation recommends for
support doesn't exist. Is anyone maintaining it?
I don't think anyone is maintaining it. I think the GCCSDK mailing list is
probably the place to ask, as there are at least some people with commit
access to the repo.

On pathnames, I have a feeling this has come up before but noone has
addressed it - Google is not being my friend today.

I think the canonical would be #include "DeskLib/Core.h" which should work
in GCC as a cross compiler and natively if you are supplying the right
-I flag. I think a recent version of the DDE should also handle that.

When cross-compiling, looking at the source:
https://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Frecipe%2Ffiles%2Fgcc%2Flibunixlib%2Fcommon%2Friscosify.c
https://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Frecipe%2Ffiles%2Fgcc%2Flibunixlib%2Fcommon%2Funixify.c
I think #include "DeskLib:/Core.h"
would look for the file in /DeskLib:/Core.h
so if /DeskLib: were to be a symlink to the right place it might work.
I'm not familiar with the GCC internals as to whether it does anything
beyond this, maybe it does.

I think asking on the list would be an idea since someone might know, but
otherwise you could submit a patch?

Theo
Steve Fryatt
2020-05-12 21:15:50 UTC
Reply
Permalink
On 12 May, Theo wrote in message
Post by Theo
On pathnames, I have a feeling this has come up before but noone has
addressed it - Google is not being my friend today.
I thought similar, but almost a day on Google (on and off) found me nothing.
Post by Theo
I think the canonical would be #include "DeskLib/Core.h" which should work
in GCC as a cross compiler and natively if you are supplying the right -I
flag. I think a recent version of the DDE should also handle that.
https://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Frecipe%2Ffiles%2Fgcc%2Flibunixlib%2Fcommon%2Friscosify.c
https://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Frecipe%2Ffiles%2Fgcc%2Flibunixlib%2Fcommon%2Funixify.c
Post by Theo
I think #include "DeskLib:/Core.h" would look for the file in
/DeskLib:/Core.h so if /DeskLib: were to be a symlink to the right place
it might work. I'm not familiar with the GCC internals as to whether it
does anything beyond this, maybe it does.
Aha. Thanks; I'll have a play at some point.

The other option which had occurred to me, given that the library builds
fine but then causes apps which try to include it to choke, was that the
install process for GCCSDK could do some suitable search and replace of the
various header files.

The problem is that as a non-desklib user, I've no real idea what "correct
behaviour" is...
Post by Theo
I think asking on the list would be an idea since someone might know, but
otherwise you could submit a patch?
That was somewhere on the plan, if I could decide what the correct thing was
to do.

I may as well admit that the aim of this was to get to a position where I
could try and identify some of the more interesting crashiness of WinEd on
modern hardware, and submit some fixes.

:-)
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
Theo
2020-05-12 22:34:30 UTC
Reply
Permalink
Post by Steve Fryatt
On 12 May, Theo wrote in message
Post by Theo
On pathnames, I have a feeling this has come up before but noone has
addressed it - Google is not being my friend today.
I thought similar, but almost a day on Google (on and off) found me nothing.
I have a vague recollection David Higton might have been involved, perhaps
he can remember?
Post by Steve Fryatt
Post by Theo
I think #include "DeskLib:/Core.h" would look for the file in
/DeskLib:/Core.h so if /DeskLib: were to be a symlink to the right place
it might work. I'm not familiar with the GCC internals as to whether it
does anything beyond this, maybe it does.
Aha. Thanks; I'll have a play at some point.
(oops, typo - that should be #include "DeskLib:Core.h" in the above
paragraph, in case it was unclear)
Post by Steve Fryatt
The other option which had occurred to me, given that the library builds
fine but then causes apps which try to include it to choke, was that the
install process for GCCSDK could do some suitable search and replace of the
various header files.
The problem is that as a non-desklib user, I've no real idea what "correct
behaviour" is...
It would be possible, but compilers should be able to handle the canonical
form without source modification. It's especially important if you don't
know if you're cross compiling or not, and makes a mess of eg checking out a
new copy from a source repo or comparing hashes to see if anything changed.

Picking a random piece of RISC OS source:
https://gitlab.riscosopen.org/RiscOS/Sources/Toolbox/Window/-/blob/master/c/events
that does have
#include "objects/toolbox.h"
which indicates that Norcroft is happy with that syntax.

I think therefore the right thing to do would be to patch the headers to be
in the
#include "DeskLib/Wimp.h"
format, and then Makefiles need -IDeskLib:
and the path structure should be !DeskLib.DeskLib.h.Wimp
and in !Boot you have:
*Set DeskLib$Path <Obey$Dir>.

I don't know if this would break existing Makefiles though, or are they
already broken?
Post by Steve Fryatt
Post by Theo
I think asking on the list would be an idea since someone might know, but
otherwise you could submit a patch?
That was somewhere on the plan, if I could decide what the correct thing was
to do.
It might be worth having this discussion on the list, in case anyone
disagrees?
Post by Steve Fryatt
I may as well admit that the aim of this was to get to a position where I
could try and identify some of the more interesting crashiness of WinEd on
modern hardware, and submit some fixes.
If you would like commit access to the WinEd repo, do drop me a line...

Theo
David Higton
2020-05-13 15:00:29 UTC
Reply
Permalink
Post by Theo
Post by Steve Fryatt
On 12 May, Theo wrote in message
Post by Theo
On pathnames, I have a feeling this has come up before but noone has
addressed it - Google is not being my friend today.
I thought similar, but almost a day on Google (on and off) found me nothing.
I have a vague recollection David Higton might have been involved, perhaps
he can remember?
The only person I can recall as having done any development on DeskLib
in years is Rick Murray.

I did try to use it some years ago, but I couldn't get it to build and
work for me. I apologise, it's so long ago that I cannot remember any
of the details.

It must be well over a decade, maybe even two, since I actually used
DeskLib successfully. But, if you can get it to build with the tools
that you want to use, I remember that it does make an app's
infrastructure very easy to create.

David
News
2020-05-12 22:39:47 UTC
Reply
Permalink
Post by Steve Fryatt
I may as well admit that the aim of this was to get to a position
where I could try and identify some of the more interesting
crashiness of WinEd on modern hardware, and submit some fixes.
I use WinEd with all the David Pilling software I play with, because
it is all template based. I haven't noticed any problems. I was
editing some of the DPScan templates over the last week or so without
problem.

Can you give an idea of what the problems are - I would find that
useful.
--
Chris Johnson
Steve Fryatt
2020-05-13 09:25:27 UTC
Reply
Permalink
On 12 May, News wrote in message
Post by Steve Fryatt
I may as well admit that the aim of this was to get to a position where
I could try and identify some of the more interesting crashiness of
WinEd on modern hardware, and submit some fixes.
I use WinEd with all the David Pilling software I play with, because it is
all template based. I haven't noticed any problems. I was editing some of
the DPScan templates over the last week or so without problem.
Can you give an idea of what the problems are - I would find that useful.
The GUI is *very* unstable, to the point of being useless, on a Titanium.
For example, load WinEd, and open a new template browser. Click on the
Create Window button in the toolbar, then immediately click on Cancel.

"WinEd may have gone wrong...", which is an abort on data transfer in the
Menu_Show function (which I think is DeskLib).

There are many other examples, which tend to catch me just before I save a
file. These days, I only use it under RISC OS 5 on RPCEmu, where it is
indeed very stable. Given the age of the software, my guess is ARMv7 issues.

This is version 3.20 (September 2008). The latest that I'm aware of is 3.21
(alpha), if you build from source.
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
Martin
2020-05-13 10:33:27 UTC
Reply
Permalink
Post by Steve Fryatt
On 12 May, News wrote in message
Post by News
Post by Steve Fryatt
I may as well admit that the aim of this was to get to a
position where I could try and identify some of the more
interesting crashiness of WinEd on modern hardware, and submit
some fixes.
I use WinEd with all the David Pilling software I play with,
because it is all template based. I haven't noticed any problems.
I was editing some of the DPScan templates over the last week or
so without problem.
Can you give an idea of what the problems are - I would find that useful.
The GUI is *very* unstable, to the point of being useless, on a
Titanium. For example, load WinEd, and open a new template browser.
Click on the Create Window button in the toolbar, then immediately
click on Cancel.
"WinEd may have gone wrong...", which is an abort on data transfer
in the Menu_Show function (which I think is DeskLib).
There are many other examples, which tend to catch me just before I
save a file. These days, I only use it under RISC OS 5 on RPCEmu,
where it is indeed very stable. Given the age of the software, my
guess is ARMv7 issues.
This is version 3.20 (September 2008). The latest that I'm aware of
is 3.21 (alpha), if you build from source.
I would love to see WinEd made a little more stable, as it is my
favourite template editor. Currently using a Titanium, previously
RPi3 and Iyonix.

Mind you, it only occasionally crashes for me ... and in the Load ->
New -> Create Win -> Cancel scenario it 'only' creates 128 ZeroPain
logs here. menu_Show does seem implicated, when r14 is -1 , and an
LDM from r3 at &14 in steps up to &BEC fails.

But I maybe have the advantage of having v3.22a (Oct 2008) here!
I was feeding back issues and suggestions to Adam before he lost
interest, so it may be worth trying to contact hime if you have not
already tried.

Martin
--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.
News
2020-05-13 09:54:08 UTC
Reply
Permalink
Post by Steve Fryatt
The GUI is *very* unstable, to the point of being useless, on a Titanium.
Odd - I do all my development on a Titanium machine. I cannot
remember having problems editing existing template files, although it
is a few years since I created a completely new template file.

I'll take more notice of what is going on.
--
Chris Johnson
Alan Adams
2020-05-13 09:55:44 UTC
Reply
Permalink
Post by News
Post by Steve Fryatt
I may as well admit that the aim of this was to get to a position
where I could try and identify some of the more interesting
crashiness of WinEd on modern hardware, and submit some fixes.
I use WinEd with all the David Pilling software I play with, because
it is all template based. I haven't noticed any problems. I was
editing some of the DPScan templates over the last week or so without
problem.
Can you give an idea of what the problems are - I would find that
useful.
I use it a lot too. The only problem I've ever encountered is on a couple
of occasions it's refused to open a template it previously created. I
don't know whether I still have an example around. If I find one, I'll let
you know.
--
Alan Adams, from Northamptonshire
***@adamshome.org.uk
http://www.nckc.org.uk/
Jean-Michel
2020-05-13 06:50:03 UTC
Reply
Permalink
Post by Theo
Post by Steve Fryatt
The first, which I would like to sort out before moving on to the rest, is
that the DeskLib headers installed by the process above contain several
#include "DeskLib:Core.h"
lines and similar, which GCCSDK can't sensibly resolve. I can make things
build to a point where I'm looking at a handful of genuine-looking missing
or conflicting source files in WinEd by doing a search and replace to remove
the <DeskLib$Path> references from within ~/gccsdk/env/include/DeskLib/, but
this seems sub-optimal. Not least because the DeskLib docs refer to the
library being prepped for use in the GCCSDK, which suggests that this should
"just work". :-)
Is there some way to make GCCSDK happy with the files as they stand,
"DeskLib:Core.h" and the like included?
Also, where's the best place to ask about DeskLib nowadays. The last SVN
commit was 2012, and the Google Group that the documentation recommends for
support doesn't exist. Is anyone maintaining it?
I don't think anyone is maintaining it. I think the GCCSDK mailing list is
probably the place to ask, as there are at least some people with commit
access to the repo.
Unless you are only looking for a GCC version only, I think Rick Murray
did it and Desklib is part of RISC OS source code, downloadable from RISC
OS OPEN.

Bonne journée.
--
Jean-Michel
Steve Fryatt
2020-05-13 09:29:11 UTC
Reply
Permalink
On 13 May, Jean-Michel wrote in message
Post by Jean-Michel
Post by Theo
I don't think anyone is maintaining it. I think the GCCSDK mailing list
is probably the place to ask, as there are at least some people with
commit access to the repo.
Unless you are only looking for a GCC version only, I think Rick Murray
did it
Rick has a hacked around version of an older version, I think. It claims to
be based on a 2004 vintage, which would mean that it misses many of the
changes of the current version in SVN, but then appears to have some
different changes of Rick's own devising.
Post by Jean-Michel
Desklib is part of RISC OS source code, downloadable from RISC OS OPEN.
Have you got a link to that?
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
Theo
2020-05-13 12:12:37 UTC
Reply
Permalink
Post by Steve Fryatt
On 13 May, Jean-Michel wrote in message
Post by Jean-Michel
Unless you are only looking for a GCC version only, I think Rick Murray
did it
Aha, that was it.
Post by Steve Fryatt
Rick has a hacked around version of an older version, I think. It claims to
be based on a 2004 vintage, which would mean that it misses many of the
changes of the current version in SVN, but then appears to have some
different changes of Rick's own devising.
Post by Jean-Michel
Desklib is part of RISC OS source code, downloadable from RISC OS OPEN.
Have you got a link to that?
Looks like you found the thread:
https://www.riscosopen.org/forum/forums/12/topics/3405

and a previous thread on the header issue:
https://www.riscosopen.org/forum/forums/11/topics/6322
which links to another thread here:
https://groups.google.com/forum/#!topic/comp.sys.acorn.programmer/6e_j4_nGjzE

I'm happy to give commit access to anyone who wants to sort it out, as it
looks like the problem has been around for a while.

Theo
Jean-Michel
2020-05-13 15:12:25 UTC
Reply
Permalink
Post by Steve Fryatt
On 13 May, Jean-Michel wrote in message
Post by Jean-Michel
Post by Theo
I don't think anyone is maintaining it. I think the GCCSDK mailing list
is probably the place to ask, as there are at least some people with
commit access to the repo.
Unless you are only looking for a GCC version only, I think Rick Murray
did it
Rick has a hacked around version of an older version, I think. It claims to
be based on a 2004 vintage, which would mean that it misses many of the
changes of the current version in SVN, but then appears to have some
different changes of Rick's own devising.
Post by Jean-Michel
Desklib is part of RISC OS source code, downloadable from RISC OS OPEN.
Have you got a link to that?
I have an ARMX6 and I downloaded OMAP4Dev
from:
https://www.riscosopen.org/content/downloads/risc-os-tarballs

In RiscOs.sources.lib there is a lib named Desk (not desklib)
Comparing the directoriy of headers with that of Rick desklib, it seems to
me that it is the same library. and more complete.
With Desk (from ROOL) there is no source, just the headers and the
library.

I use DDE and so I added Desk to my libraries, but I mostly use OsLib as
in your documentation: "wimp Programming in C" on your website.
Thanks for this tutorial, it should help Risc OS programmers get started.
DDE + ToolBox + Risc OS libraries and documentation are now affordable.
It's just my opinion.
--
Jean-Michel
Steve Fryatt
2020-05-13 16:25:09 UTC
Reply
Permalink
On 13 May, Jean-Michel wrote in message
In RiscOs.sources.lib there is a lib named Desk (not desklib) Comparing
the directoriy of headers with that of Rick desklib, it seems to me that
it is the same library. and more complete.
With Desk (from ROOL) there is no source, just the headers and the
library.
Desk was a "reimagining" of DeskLib sometime in the early 1990s by one of
the original developers, which involved some significant namespace and API
changes. To differentiate it from DeskLib (then at around 2.00, IIRC), it
got the version number 3.00 and the trendy name "Desk".

The idea was that everyone would upgrade, so this made sense. The
improvements made a lot of sense, too, from what I remember. Upgrading a
project to use Desk was a lot of work. Most developers didn't bother.

Now it seems that DeskLib has reached version 3.00 itself, which isn't at
all confusing.
I use DDE and so I added Desk to my libraries, but I mostly use OsLib as
in your documentation: "wimp Programming in C" on your website. Thanks for
this tutorial, it should help Risc OS programmers get started.
No problem; it's grown a bit in the past few weeks, thanks to lock-down.

:-)
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
Loading...