[Coco] OS-9 / NitOS-9 C programmers, lend me your makefiles

Sun Nov 15 09:03:56 EST 2020

Jeff,

I searched the EOU B5 and can't seem to find the Source/Compiler/CPP
folder.  Is there another location I can find this at?

WIlliam Carlin, Jr.

On Sun, Nov 15, 2020 at 2:50 AM Jeff Teunissen <deek at d2dc.net> wrote:

> I've actually stopped using c_prep entirely here, and have switched to
> a different C preprocessor.
>
> I think the 'cpp' in CoCoC is a descendent of the original c.prep. It
> may be found in the directory Source/Compiler/CPP. It's pretty
> excellent and mostly ANSI-compatible. I've added a few features, like
> #error, #file, #warning, stringification using #, token pasting using
> ##, and optionally restricting macro expansion to only happen outside
> of string/character literals.
>
> Most importantly for me at least, it seems to be faster and consume
> less memory than c_prep, which is important for future enhancements.
> Rather than using a static array for definitions, cpp uses a linked
> list, so it's not wasting as much memory and can thus handle many more
> definitions.
>
> I do have a copy of the (C and assembly) Kreider library. It's also in
> CoCoC, and can be found in the directory Source/Libs/KLibc; once I've
> got the whole toolchain (C compiler, assembler, linker) building,
> maintainable, etc. I do plan to start really fixing up the bugs in the
> C library. I have noticed the Y2K bug in ctime(), but I discovered
> that it's missing the source code to scanf/fscanf/sscanf so I've been
> disassembling it.
>
> On Sun, Nov 15, 2020 at 1:11 AM William Carlin <whcarlinjr at gmail.com>
> wrote:
> >
> > Jeff,
> >
> > Here is the link to the folder on my Google Drive.  The files are under
> the
> > "Microware C Projects" folder.  I have uploaded the two .lzh archives and
> > the same files are also on a DriveWire disk, "Make91SRC.os9"  The source
> > code to MROFF is also there if you did not grab that when I previously
> > shared it with you. That is in the "CLib_Kreider_91_doc.lzh" archive.
> >
> >
> https://drive.google.com/drive/folders/1IZ89kvYU04sfVYufnyqBuvOFZDs59CLv?usp=sharing
> >
> > To compile you are going to need:
> > cc252 (cc v2.5.2)  This should already be on the EOU beta 5 disk.
> > Otherwise you can find it on the Climax C Compiler release on the Color
> > Computer Archive
> > The Kreider clib.l  This should also be on the EOU 5 beta disk.
> > I also use Kreider's fixed version of cstart.r but that should not
> prevent
> > compilation.  This should also be on the EOU beta 5 disk.
> > You will also need my updated version of c_prep v1.9  I am unofficially
> > bumping the version up to 1.10.
> >
> > I have allowed/fixed source line concatenation of more than one line of
> > code.  If more than one line of consecutive code ends with a backslash
> '\'
> > the lines will be concatenated into a single line of code.  Leading
> spaces
> > are removed so you can make your source look "pretty".
> >
> > I have also fixed the __FILE__, __DATE__, and __TIME__ built in macros to
> > be enclosed in double quotes when expanded.  Previously these macros were
> > not enclosed in double quotes when expanded and could not be displayed
> with
> > the %s printf format argument.  This also allows for easy inclusion in
> the
> > format text as the preprocessor correctly concatenates consecutive double
> > quotes.  If there is a way to make the preprocessor enclose an expanded
> > macro with double quotes around it, I have not been able to find it.  In
> > GNU you can prepend a '#' in front of the macro to stringify it.
> However,
> > C-prep 1.9 does not include this feature.
> >
> > #__FILE__ will expand to "filename.c" (GNU)
> > __FILE__ will expand to filename.c (OS-9, both MWC c.prep and c_prep
> v1.9)
> >
> > BTW, the __DATE__ macro is not Y2K compatible.  This has more to do with
> > the implementation of ctime() in the Kreider clib.l
> >
> > BTW if you have a copy of the assembly source code for the Kreider CLib,
> > please drop that in the Incoming folder on my Google Drive.  The Y2K fix
> > should be as simple as adding 1900 to the D register before moving it off
> > to be included in the returned date string.
> >
> > William Carlin, Jr.
> >
> >
> > On Sat, Nov 14, 2020 at 11:37 PM Jeff Teunissen <deek at d2dc.net> wrote:
> >
> > > I noticed there's a bug in the OS-9 port in that when Neil changed the
> > > code to work with spaces, he actually changed it to work _only_ with
> > > spaces and not tabs. Unfortunately, this means that the OS9 version
> > > _cannot_ use Makefiles that are compatible with every other Make in
> > > the world, and vice versa. This is an oversight that needs correcting;
> > > if you get to it before I do, awesome, otherwise I'll do it. :)
> > >
> > > On Sat, Nov 14, 2020 at 11:17 PM William Carlin <whcarlinjr at gmail.com>
> > > wrote:
> > > >
> > > > Jeff,
> > > >
> > > > I saw all the references to EON in the source but I couldn't find any
> > > > reference to it on Google.  There is a modern OS called EON but I do
> not
> > > > think it has any relation to the EON referenced in PD Make.
> > > >
> > > > I'll LHArc my source code, copy it up to my Google Drive, and then
> share
> > > > the link here.  The reason I wanted to know how to add empty
> directories
> > > to
> > > > the LZH archives was to archive this source code when the time to
> share
> > > it
> > > > out was appropriate.
> > > >
> > > > William Carlin, Jr.
> > > >
> > > >
> > > > On Sat, Nov 14, 2020 at 7:25 AM Jeff Teunissen <deek at d2dc.net>
> wrote:
> > > >
> > > > > More information discovered about our favorite Make:
> > > > >
> > > > > It was originally written for an OS I have never heard of, called
> > > > > "eon", by someone named Neil Russell. I surmise Neil had been
> either
> > > > > working or studying at an Australian university when he wrote it,
> from
> > > > > his ACSNet email address.
> > > > >
> > > > > A later version Neil posted in December 1986, though, suggested he
> was
> > > > > by then working at Fairlight (makers of the Fairlight CMI digital
> > > > > music workstation) and had ported it to OS-9 (whether 6809 or OSK,
> I
> > > > > do not know). This is still not the same program we know on the
> CoCo,
> > > > > because it doesn't read a /DD/Sys/Make.default data file for its
> > > > > defaults -- they're compiled in.
> > > > >
> > > > > Still, some interesting history there that I will have to integrate
> > > into
> > > > > CoCoC.
> > > > >
> > > > > --
> > > > > Coco mailing list
> > > > > Coco at maltedmedia.com
> > > > > https://pairlist5.pair.net/mailman/listinfo/coco
> > > > >
> > > >
> > > > --
> > > > Coco mailing list
> > > > Coco at maltedmedia.com
> > > > https://pairlist5.pair.net/mailman/listinfo/coco
> > >
> > > --
> > > Coco mailing list
> > > Coco at maltedmedia.com
> > > https://pairlist5.pair.net/mailman/listinfo/coco
> > >
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > https://pairlist5.pair.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>