Curses / NCurses port for RISC OS?
Jon Ripley
curses library and I'm hoping that I won't need to port curses aswell.
I have looked at the Angband distro but there is no source available and
all I could find on Google was other people asking if the above had been
posted already.
Is there a port of the [n]curses library for RISC OS?
Hopefully yours,
Jon Ripley
--
http://jonripley.com/
John-Mark Bell
Jon Ripley <ne...@jonripley.com> wrote:
> I am looking at porting some software to RISC OS that requires the
> curses library and I'm hoping that I won't need to port curses aswell.
>
> I have looked at the Angband distro but there is no source available and
> all I could find on Google was other people asking if the above had been
> posted already.
>
> Is there a port of the [n]curses library for RISC OS?
http://www.riscos.info/downloads/unix-libraries/
John.
Alex Macfarlane Smith
I imagine so, as bitchx, less and nano use it. I think I have a copy I
built lying around somewhere but from memory it's a nobrainer to
cross-compile.
Alex.
--
E-mail: al...@archifishal.co.uk
WWW: http://www.archifishal.co.uk/
MSN: archi...@gmx.co.uk
Jon Ripley
> Jon Ripley wrote:
>>Is there a port of the [n]curses library for RISC OS?
>
> http://www.riscos.info/downloads/unix-libraries/
Thanks, especially for the links to all the other wonderfully useful
pre-ported libraries.
What's the etiquette for porting these days?
Philip Ludlam
>John-Mark Bell wrote:
>> Jon Ripley wrote:
>>>Is there a port of the [n]curses library for RISC OS?
>>
>> http://www.riscos.info/downloads/unix-libraries/
>
>Thanks, especially for the links to all the other wonderfully useful
>pre-ported libraries.
>
>What's the etiquette for porting these days?
etiquette?
Well roughly you read the articles that Peter's written on Drobe about
porting, read up on the porting stuff on riscos.info, grab youself a
Linux box and download (and build) the GCCSDK and AutoBuilder projects
from CVS and then plug away to your hearts content.
It's recomended that the Linux box is a Debian or Debian based distro as
AutoBuilder gets the source code through the dpkg command set.
Yours,
Phil L.
--
http://www.philipnet.com/ | http://director.sourceforge.net/
http://www.windowsadvice.com/blogs/philipnet/
Martin Dann
> I have looked at the Angband distro but there is no source available and
> all I could find on Google was other people asking if the above had been
> posted already.
Have you looked at Antony Sidwell's angband site.
http://ajps.mine.nu/angband/ports/
http://homepage.ntlworld.com/isparp1/angband/angband-kit.zip
Martin.
--
According to the human genome project, humans are 50-60% bananas.
When emailing me, please include the word Banana in the subject line.
Jon Ripley
Martin Dann wrote:
> In message <k1UUe.20318$k22....@fe2.news.blueyonder.co.uk>
> Jon Ripley <ne...@jonripley.com> wrote:
>
>
>>I have looked at the Angband distro but there is no source available and
>>all I could find on Google was other people asking if the above had been
>>posted already.
>
>
> Have you looked at Antony Sidwell's angband site.
> http://ajps.mine.nu/angband/ports/
> http://homepage.ntlworld.com/isparp1/angband/angband-kit.zip
Yes, it was one of the first places I looked after seeing it referenced
several times for other people looking for ncurses. The second link
seems to point to a corrupt file.
I have the library now, thanks.
Theo Markettos
> etiquette?
>
> Well roughly you read the articles that Peter's written on Drobe about
> porting, read up on the porting stuff on riscos.info, grab youself a
> Linux box and download (and build) the GCCSDK and AutoBuilder projects
> from CVS and then plug away to your hearts content.
Whilst this might seem, um, a little hardcore, it actually makes porting an
order of magnitude easier. Because you don't have to worry about messing
around with makefiles or mangling dots and slashes or autoconf or any of
that stuff before you compile a single line of code as you would natively.
So while you can build natively you're making a lot of unnecessary work for
yourself.
Theo
Jon Ripley
I have GCCSDK downloaded and built on my linux box and it has proved
useful although I still have a few roadblocks to overcome. With
/home/riscos/cross/bin in $PATH I can build some applications but no
files inside /home/riscos/env/[include|lib] are seen in the include or
link paths. This is proving very counter-productive at the moment and I
don't want to litter /home/riscos/cross/[include|lib] with files that go
elsewhere.
I now have a nice selection of emulators, 19 so far, that AFAIK the only
RISC OS versions of currently exist on my network.
I have installed and looked at the Autobuilder (without the $PATH mod)
but I am unsure about its longterm usefulness as it does not seem to
allow for building anything outside the Debian packages that it can
download. Many of the projects that I want to bring to RISC OS have not
already been ported by others and are not part of the Debian distro.
As a test I can autobuild bzip and a few other command line applications
but I have had no luck building most of the other packages that are
currently ported and available on the UPP site. I would like to be able
to compile most if not all of the tools already available before I start
looking into the packages that I already want to port.
If I was able to build GTK or X applications I would have more options
available to me.
There is a very dangerous bug in Autobuilder which can completely trash
any system where the porter is logged on as root and does a particular
action. For any user it can potentially cause severe data loss. I'm not
that silly but someone else might be.
Anyways, help is appreciated.
John-Mark Bell
Jon Ripley <ne...@jonripley.com> wrote:
> I have GCCSDK downloaded and built on my linux box and it has proved
> useful although I still have a few roadblocks to overcome. With
> /home/riscos/cross/bin in $PATH
Although this is suggested in the GCCSDK documentation, I wouldn't do this
by default. The porting tools (ro-config et al) are all aware of where
you've installed GCCSDK and will call the appropriate binaries for you.
> I can build some applications but no files inside
> /home/riscos/env/[include|lib] are seen in the include or link paths.
No. You must specify them on the compiler command line
(-I/home/riscos/env/include -L/home/riscos/env/lib).
> I have installed and looked at the Autobuilder (without the $PATH mod)
> but I am unsure about its longterm usefulness as it does not seem to
> allow for building anything outside the Debian packages that it can
> download.
This isn't entirely true. The fetch-program script is capable of retrieving
sources from a variety of locations, only falling back to the Debian package
as a last resort. In order to use any of the non-Debian retrieval methods,
you'll generally have to modify the package setvars script.
Here's some examples:
# Fetch from CVS:
AB_CVS_ROOT=:pserver:anon...@cvs-mirror.mozilla.org:/cvsroot
AB_CVS_MODULE=mozilla
# Fetch from SVN:
AB_SVB=http://svn.xiph.org/trunk/Tremor
# Fetch source tarball:
AB_URL=http://www.mirror.ac.uk/mirror/ftp.x.org/pub/X11R6.8.2/src-single/X11R6.8.2-src.tar.bz2
If none of the above variables are set, it'll try to apt-get the packagename.
> Many of the projects that I want to bring to RISC OS have not
> already been ported by others and are not part of the Debian distro.
That involves more work on your part, then. Retrieving the sources is the
easy bit; you then need to carry out the port using the porting tools and,
when you have produced a working package, provide the autobuilder with the
necessary infrastructure to do the work you did for the initial port
automatically. At a bare minimum this will be a setvars script. In most
cases, you'll also need to provide a set of RISC OS specific patches.
The whole point of this is that once something's been ported, newer releases
of the same package may be built without any extra effort (with the obvious
caveats about fixing up any issues caused by upstream changes). At some
point, it would be nice to see a web-based status report which allows simple
detection of build failures.
> As a test I can autobuild bzip and a few other command line applications
> but I have had no luck building most of the other packages that are
> currently ported and available on the UPP site. I would like to be able
> to compile most if not all of the tools already available before I start
> looking into the packages that I already want to port.
Note that not all the packages in the autobuilder will compile "out of the
box", generally due to upstream changes (the Firefox package currently
doesn't build for exactly this reason). Fixing things like this is generally
trivial (and aided by the last-failure file written to the package directory
within the autobuilder tree).
> If I was able to build GTK or X applications I would have more options
> available to me.
I've not built GTK myself, so can't comment on it (although most of the
supporting stuff such as glib compiles with very little effort). As for X,
/path/to/build -v x11/x.org
should build a working set of X libraries. In addition, you'll probably
want ChoX11 as I'm fairly certain that the autobuilder attempts to link
against that rather than XLib.
> There is a very dangerous bug in Autobuilder which can completely trash
> any system where the porter is logged on as root and does a particular
> action.
There's more serious problems at the user's end if they're running the
autobuilder as root.
> For any user it can potentially cause severe data loss. I'm not
> that silly but someone else might be.
Have you reported this? Even better, have you a patch to fix the issue?
John.
Jon Ripley
> In message <f03Ve.662$Kk3...@fe1.news.blueyonder.co.uk>
> Jon Ripley <ne...@jonripley.com> wrote:
>
>>Many of the projects that I want to bring to RISC OS have not
>>already been ported by others and are not part of the Debian distro.
>
>
> That involves more work on your part, then. Retrieving the sources is the
> easy bit; you then need to carry out the port using the porting tools and,
> when you have produced a working package, provide the autobuilder with the
> necessary infrastructure to do the work you did for the initial port
> automatically. At a bare minimum this will be a setvars script. In most
> cases, you'll also need to provide a set of RISC OS specific patches.
>
> The whole point of this is that once something's been ported, newer releases
> of the same package may be built without any extra effort (with the obvious
> caveats about fixing up any issues caused by upstream changes). At some
> point, it would be nice to see a web-based status report which allows simple
> detection of build failures.
Ok, for an example package that will compile and work wihtout
autobuilder. I download the package, add the $PATH mod, unzip the
package, cd to the directory, type 'mkdir BIN' and then 'make'. About 20
minutes later it is built. But for the life of me I cannot figure out
how to make autobuilder say anything other than 'no known build method'.
I have created a directory in autobuilder, created a setvars script,
setup AB_URL (currently pointing locally) and AB_CATEGORY and it manages
to download and unzip the package but no default or otherwise sensible
value of AB_MAKE or code in ab_make(){} makes any difference. All it
needs to do is essentially 'cd package; mkdir BIN; make'.
There must be some basic error here as I am having the most success not
using autobuilder. I can see the point of providing resources for
additional packages so that anyone can build and I'd like to contribute
but until I have the basics working there's nothing I can really add.
>>As a test I can autobuild bzip and a few other command line applications
>>but I have had no luck building most of the other packages that are
>>currently ported and available on the UPP site. I would like to be able
>>to compile most if not all of the tools already available before I start
>>looking into the packages that I already want to port.
>
> Note that not all the packages in the autobuilder will compile "out of the
> box", generally due to upstream changes (the Firefox package currently
> doesn't build for exactly this reason). Fixing things like this is generally
> trivial (and aided by the last-failure file written to the package directory
> within the autobuilder tree).
I haven't tried to build everything yet but it is not looking good. So
far only bzip and ncurses have auto-built.
>>If I was able to build GTK or X applications I would have more options
>>available to me.
>
> I've not built GTK myself, so can't comment on it (although most of the
> supporting stuff such as glib compiles with very little effort). As for X,
>
> /path/to/build -v x11/x.org
>
> should build a working set of X libraries. In addition, you'll probably
> want ChoX11 as I'm fairly certain that the autobuilder attempts to link
> against that rather than XLib.
Nothing but failures, I'll have another play in the morning. I still
have some libraries to install but there has been no indication of any
missing dependancies.
>>There is a very dangerous bug in Autobuilder which can completely trash
>>any system where the porter is logged on as root and does a particular
>>action.
>
> There's more serious problems at the user's end if they're running the
> autobuilder as root.
ROFL, indeed!
>>For any user it can potentially cause severe data loss. I'm not
>>that silly but someone else might be.
>
> Have you reported this? Even better, have you a patch to fix the issue?
Not reported this yet and I am not looking at patching the program until
I know that I can use it in a working fashion otherwise I'll be stuck in
a 'did it fail because it doesn't work or because I broke it' loop. Plus
I want to get to grips with using this system before I start firing off
bug reports.
Theo Markettos
> Ok, for an example package that will compile and work wihtout
> autobuilder. I download the package, add the $PATH mod, unzip the
> package, cd to the directory, type 'mkdir BIN' and then 'make'. About 20
> minutes later it is built.
Does it use autoconf? Probably the easiest programs to port are those which
build with autoconf. You do:
wget prog-src.tar.gz
cd prog
/home/riscos/env/ro-config [runs autoconf]
/home/riscos/env/ro-make
Try this with something like bzip2 outside of the autobuilder to get the
idea. It's best to use ro-make since that also provides RISC OS friendly
versions of other tools like uname (returns arm-riscos) and doesn't break
cases where you need to native compile things.
> But for the life of me I cannot figure out
> how to make autobuilder say anything other than 'no known build method'.
> I have created a directory in autobuilder, created a setvars script,
> setup AB_URL (currently pointing locally) and AB_CATEGORY and it manages
> to download and unzip the package but no default or otherwise sensible
> value of AB_MAKE or code in ab_make(){} makes any difference. All it
> needs to do is essentially 'cd package; mkdir BIN; make'.
$autobuilder/terminal/putty has some prebuild stuff it needs to do before
typing 'make'. setvars is effectively a prebuild script, so at the end I
put some commands for the prebuilding. This is where 'mkdir BIN' would go.
The script $autobuilder/build tries to guess which directory you're untarred
and cd into it so you don't need to.
Have a look at $autobuilder/build-program to see how it tries to make
things. It'll look for a Makefile or a makefile and try to ro-make it.
It also tries things like running autoconf, looking for an Imakefile, or
using a custom $AB_MAKE command.
> There must be some basic error here as I am having the most success not
> using autobuilder. I can see the point of providing resources for
> additional packages so that anyone can build and I'd like to contribute
> but until I have the basics working there's nothing I can really add.
Can you point us in the direction of what you were having trouble with?
>> I've not built GTK myself, so can't comment on it (although most of the
>> supporting stuff such as glib compiles with very little effort). As for X,
>>
>> /path/to/build -v x11/x.org
>>
>> should build a working set of X libraries. In addition, you'll probably
>> want ChoX11 as I'm fairly certain that the autobuilder attempts to link
>> against that rather than XLib.
I have, some months ago. It worked fine. I suggest trying to build
DeskLib, x.org, ChoX11, and glib in that order first. The autobuilder
doesn't enforce dependencies, so if a program tries to make use of a package
that isn't already built it'll complain. Usually it is autoconf which tells
you that some vital library wasn't found, so it's quite easy to tell from
the last-failure log.
>>>For any user it can potentially cause severe data loss. I'm not
>>>that silly but someone else might be.
I fixed a rather amusing (ahem) bug in the autobuilder where ./build foo/bar
would build as normal but ./build foo/bar/ would wipe everything in the
parent directory of the autobuilder tree, including the autobuilder! That
was... interesting! For this sort of thing I think it's worth publicising
the bug even if you haven't found out its cause, so other people realise
there's a risk.
Theo
Jon Ripley
> Jon Ripley <ne...@jonripley.com> wrote:
>
>>Ok, for an example package that will compile and work wihtout
>>autobuilder. I download the package, add the $PATH mod, unzip the
>>package, cd to the directory, type 'mkdir BIN' and then 'make'. About 20
>>minutes later it is built.
>
> Does it use autoconf? Probably the easiest programs to port are those which
> build with autoconf. You do:
No, not that I am aware of, there is only a makefile which needs to be made.
> wget prog-src.tar.gz
(Unzip the .zip file)
> cd prog
> /home/riscos/env/ro-config [runs autoconf]
No configure script found.
> /home/riscos/env/ro-make
The package is built sucessfully.
But how to make autobuilder make the package is bugging me.
Setvars is as follows:
AB_URL=http://jonripley.com/~jon/package-v1-1-2.zip
AB_CATEGORY=emulation
Autobuilder complains that there is no known build method. There is a
make file called makefile inside the package.
> Try this with something like bzip2 outside of the autobuilder to get the
> idea. It's best to use ro-make since that also provides RISC OS friendly
> versions of other tools like uname (returns arm-riscos) and doesn't break
> cases where you need to native compile things.
bzip compiles fine using all three methods.
> $autobuilder/terminal/putty has some prebuild stuff it needs to do before
> typing 'make'. setvars is effectively a prebuild script, so at the end I
> put some commands for the prebuilding. This is where 'mkdir BIN' would go.
> The script $autobuilder/build tries to guess which directory you're untarred
> and cd into it so you don't need to.
>
> Have a look at $autobuilder/build-program to see how it tries to make
> things. It'll look for a Makefile or a makefile and try to ro-make it.
> It also tries things like running autoconf, looking for an Imakefile, or
> using a custom $AB_MAKE command.
I have looked at $autobuilder/build-program and cannot see what is wrong
in this instance.
There is a makefile and $autobuilder/build-program still cannot make the
program. No changes to $AB_MAKE or ab_make(){} that I have made resulted
in anything other than various types of failure.
>>There must be some basic error here as I am having the most success not
>>using autobuilder. I can see the point of providing resources for
>>additional packages so that anyone can build and I'd like to contribute
>>but until I have the basics working there's nothing I can really add.
>
> Can you point us in the direction of what you were having trouble with?
Almost all packages listed in the autobuilder fail to build. I ran
autobuilder on the entire set overnight and only 13 packages were built
sucessfully.
I can see no good reason why packages that build with no problems
outside of autobuilder cannot be made by autobuilder or why autobuilder
is failing so miserably on my setup. (Fully patched complete install of
WBEL3.0 on an x86 machine.)
Also, the port is done already outside of autobuilder, but I want to get
autobuilder up and running as it might be useful, currently it looks
like too much hassle. I'd like to be proven wrong.
> I have, some months ago. It worked fine. I suggest trying to build
> DeskLib, x.org, ChoX11, and glib in that order first. The autobuilder
> doesn't enforce dependencies, so if a program tries to make use of a package
> that isn't already built it'll complain. Usually it is autoconf which tells
> you that some vital library wasn't found, so it's quite easy to tell from
> the last-failure log.
DeskLib fails, x.org fails, ChoX11 fails and glib fails. I have
installed the prebuilt libraries for these and still even tiny X
applications will fail to build.
A side note, I have built and installed ncurses and all applications
that include it fail to find the header files. I have later installed
the pre-built ncurses and tried again with no change.
>>>>For any user it can potentially cause severe data loss. I'm not
>>>>that silly but someone else might be.
>
> I fixed a rather amusing (ahem) bug in the autobuilder where ./build foo/bar
> would build as normal but ./build foo/bar/ would wipe everything in the
> parent directory of the autobuilder tree, including the autobuilder! That
> was... interesting! For this sort of thing I think it's worth publicising
> the bug even if you haven't found out its cause, so other people realise
> there's a risk.
The shell scripts inside autobuilder do not sanity check their command
line arguments, this can potentially result in 'rm -rf /' being executed
which as any sysadmin knows is not something you want to happen for even
a restricted user.
Have fun,
Peter Naulls
> Almost all packages listed in the autobuilder fail to build. I ran
> autobuilder on the entire set overnight and only 13 packages were built
> sucessfully.
I know that's simply not true as a generalisation. It's true that a
substantial number of the 150 _do_ fail due to upstream changes,
but it's not as great as you claim. But we're lacking specfics here.
>
> I can see no good reason why packages that build with no problems
> outside of autobuilder cannot be made by autobuilder or why autobuilder
> is failing so miserably on my setup. (Fully patched complete install of
> WBEL3.0 on an x86 machine.)
You mean, it compiles just fine when natively compiled for a completely
different OS when we're avoiding all the inherent problems of
cross-compiling
> DeskLib fails, x.org fails, ChoX11 fails and glib fails. I have
> installed the prebuilt libraries for these and still even tiny X
> applications will fail to build.
Do they now? Great, but unless you have specifics, there's nothing
that can be done.
> The shell scripts inside autobuilder do not sanity check their command
> line arguments, this can potentially result in 'rm -rf /' being executed
> which as any sysadmin knows is not something you want to happen for even
> a restricted user.
Try it - at worst, as a user, this would only result in files in /tmp
being removed. As has been said, you shouldn't be running things as
root in any case. But I don't see any patches from you to fix potential
problems.
Jon, above all else - I think you're getting way too dramatic about
this. If you want help, that's fine, but you _must_ give specifics -
instantiating a long thread as you've done and saying lots of things are
broken isn't a good use of anybody's time, nor is it likely to result
in anything being fixed. At worst, we have a thread with lots of
sub-replies and incoherent or incomplete answers.
I think you'd be far better served by staring with a _single_
problem, and working on the answer to that. Pointing fingers at lots
of apparent problem areas isn't going to solve anything.
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Jon Ripley
> Jon Ripley wrote:
>
>> Almost all packages listed in the autobuilder fail to build. I ran
>> autobuilder on the entire set overnight and only 13 packages were
>> built sucessfully.
>
> I know that's simply not true as a generalisation. It's true that a
> substantial number of the 150 _do_ fail due to upstream changes,
> but it's not as great as you claim. But we're lacking specfics here.
It is the specific number of packages and libraries that actually built
on my system.
>> I can see no good reason why packages that build with no problems
>> outside of autobuilder cannot be made by autobuilder or why
>> autobuilder is failing so miserably on my setup. (Fully patched
>> complete install of WBEL3.0 on an x86 machine.)
>
> You mean, it compiles just fine when natively compiled for a completely
> different OS when we're avoiding all the inherent problems of
> cross-compiling
No, I mean that it compiles just fine using the cross compiler in the
GCCSDK package. Cross compiling RISC OS binaries from a unix platform
for this package is not an issue.
I currently do the majority of my ports using Norcroft on RISC OS and
often having to do almost everything by hand. GCCSDk looks like a
wonderful tools and is proving to be very useful.
I tried to introduce a specific but that has been ignored, that's fine.
Simply taking a program that was known to compile and integrating it
into autobuilder is the issue at the moment. I am sure that once I can
get it to compile known working software I can branch out further. But
without being able to get autobuilder compile something that only
requires a make program to be run from the source directory this is
becoming frustrating.
> Do they now? Great, but unless you have specifics, there's nothing
> that can be done.
I am assuming that I should be having more luck than I am having all
things considered and there may be a basic error in the setup or
configuration that is preventing more optimal work being done.
> Jon, above all else - I think you're getting way too dramatic about
> this. If you want help, that's fine, but you _must_ give specifics -
> instantiating a long thread as you've done and saying lots of things are
> broken isn't a good use of anybody's time, nor is it likely to result
> in anything being fixed. At worst, we have a thread with lots of
> sub-replies and incoherent or incomplete answers.
Very good point.
> I think you'd be far better served by staring with a _single_
> problem, and working on the answer to that. Pointing fingers at lots
> of apparent problem areas isn't going to solve anything.
If I can solve this problem I am sure that things will get better.
Anyways, thanks,
Peter Naulls
[snip]
> I tried to introduce a specific but that has been ignored, that's fine.
> Simply taking a program that was known to compile and integrating it
> into autobuilder is the issue at the moment. I am sure that once I can
> get it to compile known working software I can branch out further. But
> without being able to get autobuilder compile something that only
> requires a make program to be run from the source directory this is
> becoming frustrating.
So I saw. But the reason it's been ignored is that you've tried
to introduce lots of issues at once. Without trying to be mean,
the frustration is largely of your own making.
Jon Ripley
> Jon Ripley wrote:
>
>
> So I saw. But the reason it's been ignored is that you've tried
> to introduce lots of issues at once. Without trying to be mean,
> the frustration is largely of your own making.
ROFL! Yup. Completely correct.
ATEOTD this is fun, I am learning stuff and who can argue with the
pleasure of beating a computer into submission.
If all this was easy it would be a lot less fun.
Anyways,
Theo Markettos
> Setvars is as follows:
>
> AB_URL=http://jonripley.com/~jon/package-v1-1-2.zip
I get 404 for that. Can you post a URL to the actual package, because I
can't have a go at compiling it to find out what breaks without access to
the source?
> Almost all packages listed in the autobuilder fail to build. I ran
> autobuilder on the entire set overnight and only 13 packages were built
> sucessfully.
So tell us which work, and look at the last-failure logs for the rest to see
what broke. If it makes no sense, post them here. If you do
$autobuilder/build -d it'll retain all the files used for compilation (in
the root of the autobuilder).
> I can see no good reason why packages that build with no problems
> outside of autobuilder cannot be made by autobuilder or why autobuilder
> is failing so miserably on my setup. (Fully patched complete install of
> WBEL3.0 on an x86 machine.)
There may be one or two difficulties with what tools you have installed (eg
various versions of flex and autoconf are incompatible with previous
versions) compared to the Debian setups many people use, but without
specifics it's hard to tell.
> A side note, I have built and installed ncurses and all applications
> that include it fail to find the header files. I have later installed
> the pre-built ncurses and tried again with no change.
Are these all just makefiles? autoconf will find the header files for you.
Handcrafted Makefiles won't, so you might have to add
-I/home/riscos/env/include -L/home/riscos/env/lib to gcc's command in the
Makefile. Depending on the Makefile, you might have luck appending these to
$CC or $CFLAGS (in other words:
CFLAGS=-I/home/riscos/env/include /home/riscos/env/ro-make
)
The trouble with handcrafted Makefiles is they're all different, so a
one-size-fits-all approach to porting doesn't work as it does to autoconf.
> The shell scripts inside autobuilder do not sanity check their command
> line arguments, this can potentially result in 'rm -rf /' being executed
> which as any sysadmin knows is not something you want to happen for even
> a restricted user.
OK, that's a slightly more broad instance of the problem I found. It ought
to be fixed asap, but it's a relatively limited priority IMO because of the
limited resources the developers have and the userbase of the autobuilder.
So I think they would accept a patch, but IMO it's not likely to be first
priority for development. (Note I'm speaking personally, but from a point
of view of a bit of knowledge about the internals. I'm not a significant
UPP/GCCSDK developer)
Theo
John-Mark Bell
Theo Markettos <theom...@chiark.greenend.org.uk> wrote:
> Jon Ripley <ne...@jonripley.com> wrote:
>
> > Almost all packages listed in the autobuilder fail to build. I ran
> > autobuilder on the entire set overnight and only 13 packages were built
> > sucessfully.
>
> So tell us which work, and look at the last-failure logs for the rest to
> see what broke. If it makes no sense, post them here.
Or stick them on some webspace and provide a link to them (they're likely to
be fairly big ;)
> If you do $autobuilder/build -d it'll retain all the files used for
> compilation (in the root of the autobuilder).
I'm fairly sure it leaves the build tree around if the build fails, too.
What confuses me about Jon's original example of a package that won't build
under the autobuilder is that it can't find the makefile. Obviously, without
the actual source tree it's somewhat difficult to make any judgment about why
this might be.
John.
Tom Harris
> In message <k1UUe.20318$k22....@fe2.news.blueyonder.co.uk>
> Jon Ripley <ne...@jonripley.com> wrote:
>
> > I have looked at the Angband distro but there is no source available
> > and all I could find on Google was other people asking if the above
> > had been posted already.
>
> Have you looked at Antony Sidwell's angband site.
> http://ajps.mine.nu/angband/ports/
> http://homepage.ntlworld.com/isparp1/angband/angband-kit.zip
I'm afraid I've missed the rest of this thread (so might be missing the
point entirely :-), but I did do some work on the RISC OS Angband ports a
few years ago.
There *is* source for the frontend - ISTR uploading at least one version
to the main Angband FTP server, though Antony's probably updated it since
then. However, it doesn't actually provide a curses library, as it uses
Angband's generic display interface.
I've got source for at least one RISC OS port of curses, done by Adrian
Jackson, which was used in his port of Curses. I never got around to doing
anything with it, so I'm not sure how well it works.
HTH,
Tom
--
Tom Harris
use...@tomharris.me.uk
Tom Harris
> I've got source for at least one RISC OS port of curses, done by Adrian
> Jackson, which was used in his port of Curses. I never got around to
> doing anything with it, so I'm not sure how well it works.
I meant his port of Omega - brain fried :-/
Peter Naulls
>
> I've got source for at least one RISC OS port of curses, done by Adrian
> Jackson, which was used in his port of Curses. I never got around to doing
> anything with it, so I'm not sure how well it works.
There's been a bit of a problem in the past, and still remains somewhat
of lots of ports of the same piece of software. That's part of
motivation behind the GCCSDK autobuilder - so there's a consistent
set of library/program ports which are easily rebuilt from the latest
sources. That also avoids sources having to hang around, since the
build contains any patches if they're required. You ought to be
using the ncurses port in the autobuilder.