[comp.sys.atari.st] Alcyon 4.14 more bugs than . . .

RDROYA01@ULKYVX.BITNET (Robert Royar) (01/08/87)

I'm using the Alcyon compiler v 4.14 for this. I've been working on a cc
program that compiles and links multiple files.  I have it working fine
using a startup file to get all its parameters.  I run the compiler using
Pexec() testing for a 0 return which means no error.  Unfortunately,
Alcyon's compiler always returns 0, even when there have been multiple
errors in a compilation phase.  I read somewhere in this group that version
4.14 of the compiler now passed a return code as it exitted, and that the
code would tell whether there had been any errors.  But this can't be true
can it?  How does the Make program distributed this summer tell whether or
not to continue compilation?  I looked at its Pexec() code and it's
identical to the code I have.  The only thing I can figure to do is to catch
bios conout calls and test them for error markers (such as # for cp68 and *
for c068) but then I might also abort on warnings.  Any ideas?

On another note.  Earlier I wrote about problems with wildcard expansion.
Well, it turns out that all of the devpack tools have the same problem.  For
example logged into drive C: with AR68.PRG on C:\BIN and a bunch of *.o
files on drive E:\, try to create the library m:\lib.arc with the following
command
\bin\ar68 r m:\lib.arc e:\*.o
a few whirring sounds and back to the command prompt or desktop. The
brain-damaged .___open code strikes again.

Can you say "class-action suit?"  Seriously, I can't believe anyone would
release tools as damaged as this and not bother even to check if they work,
and remember a good deal of the ST OS was written with them, so some of the
errors are bound to be embedded deeply in the system.