In message <ef2a8d0c53.Jo@hobbes.bass-software.com>
John Tytgat <John.Tytgat@aaug.net> wrote:
<snip>
> > > > > After removing that 'mv' (in r6249) and fixing a couple of other
> > > > > Autobuilder bugs (r6248 and r6250), I got a zip RiscPkg package built.
> > > > >
> > > > > John.
> > > >
> > > > I'm now 'At revision 6250' and still get the error,
> > >
> > > Which error do you mean with "the error", the original
> > > "mv: cannot stat '../zip30-joty/acorn/swiven.c': No such file or directory"
> > > one ?
> >
> > Yes, no change. I deleted everything in the build(s) directory before
> > re-running build zip, I think that is clean enough.
>
> I believe you didn't do svn update for the autobuilder directory (where
> the fixes were made), perhaps you did that for gcc4 directory ?
>
I tried
"svn update" doesn't seem to need the full line as the orignal install.
~/gccsdk/autobuilder$ svn update svn://svn.riscos.info/gccsdk/trunk/autobuilder ~/gccsdk/autobuilder
Skipped 'svn://svn.riscos.info/gccsdk/trunk/autobuilder'
At revision 6252.
Summary of conflicts:
Skipped paths: 1
"svn update" seems to get its file source from the destination instead.
I think this is sufficient for an update, but please advise otherwise.
$ svn update ~/gccsdk/autobuilder
At revision 6252.
$
If the bash script build shows "Modified: Sun 06 Jan 2013"
in case that is indication.
Still getting the mv: cannot stat... error as before.
> > > > but looking back up
> > > > the terminal, there is an error trying to open *.orig.tar.bz2
> > > >
> > > > 2013-01-10 22:21:18 URL:http://ftp.uk.debian.org/debian/pool/main/z/zip/zip_3.0-6.debian.tar.gz [7132/7132] -> "zip_3.0-6.debian.tar.gz" [1]
> > > > tar (child): *.orig.tar.bz2: Cannot open: No such file or directory
> > > > tar (child): Error is not recoverable: exiting now
> > >
> > > I see the same think in my last-success log file for 'zip'. It looks
> > > like this error gets ignored as the build continues and succeeds making
> > > the final package (not that I fully understand why this can happen).
> > >
> > > John.
> >
> > Yes, I noticed later in the failure file, that it does this (incase of?)
> > for a .xz and .bz2 instance.
> > As you say, that looks like that is always done, so shouldn't be a problem.
> > Could it be something related to the CWD?
>
> Not sure what you're hinting at. The thing which bothers me there is that
> error return value of processes in those build scripts get ignored.
> That's sloppy and recipe for lot of frustration.
>
I was a bit uncertain with the behavior in this new distro of mine,
but for things that dont involve sudo, I think everything is the same.
I had some doubts around ownership and cwd, but the difference is only
when using sudo compared with Ubuntu distros.
I'm not experienced to comment on the thread useage, I assume what
has been used is a quick way of using whatever form the archive comes
in, rather than finding out first.
I have a library book "Gnu/Linux Application Programmimg" which seems
to be all about compilers and processes.
Something similar for RISC OS would be helpfull.
I cant speak for lowlevel programming of process's in RISC OS, but
from a scripting point of view, I realised that Filer_Run and FilerHRun
can start a parallel process that is untied to the calling program.
Compared to Obey <prog/command> or Taskwindow <prog/command> which is
similar to fork(), or is it vfork() that waits for completion before
proceeding.
IPC's could come to play in the form of System commands or variables
when Filer_Run is used, but IPC from a spawned Taskwindow would require
a pipe of some form which involves another process anyway, and can't
easily be done from a script.
A program could call FilerHRun a program/alias, continue on
with other jobs, then check for some expected output from the
FilerHRun process at any time with IfThere <somefile> or
If "<somevariable>" <>""/.
One thing I was considering looking at, is (unsure of syntax here)
system("FilerHRun foo") or exec("
in place of fork() exec()
In C it should be easy enough to test for a file existing,
Variables I'm unsure of yet.
Actually for what I'm doing at the moment a second process could be
avoided if the system variable could be read, or failing that,
create an extra argument to parse to the binary.
In the case of tar's multipart forking, it may be just the multipart
argument handling that screws things up rather than the forking process.
> > Digressing here:
> > 'Cant stat' is usually a missing file or a file name misunderstanding.
> > I have just found that parsing a directory name with slashes to my
> > RISC OS tar gives this error.
> > I have now modified my directory leafname extraction routine to swap
> > "." and "/" around also.
> > Chris's tesseract port works well with full RISC OS paths if I run them
> > through my swap routine and is probably the case for most ports
> > unless the argument parsing is modified in the source.
> > Modifying may be easy sometimes, but other times the source might
> > want to detect particular extensions so it can get complicated.
> >
> > Generally we always feed the unix ports unix names and the unix port
> > outputs RISC OS names which is a simple rule to remember anyway.
>
> Feel free to develop your own Unix -> RISC OS path translation code, but
> why not use UnixLib's __riscosify() (unixlib/local.h) instead ?
>
I won't be tackling anything as big as rewriting the translation code.
Personally, I think if sfixing was stripped out, it would be easier to
follow what is going on and tweaks could be made.
For example there is a (rather silly) case of a RISC OS file being
named foo,e1f and the file gets lost. I'm not sure if this is ","
related or ,xyz as yet. I /have/ got ,xyz translation enabled.
I thought the basic riscosify/unixify stuff is already enabled, unless
you use Set/UnSet Unixenv$foo$nonametrans to turn it off.
Then there is the strict unix constant that can be set, I think.
Is there a special step to take that can swap / and . regardless?
ADFS::/HardDisc4/$/foo still must be getting swapped by UnixLib
when writing it back out to the RISC OS filing system.
Ron M.
_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
No comments:
Post a Comment