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

Sun Nov 15 14:04:11 EST 2020

The "dcc" compiler is not in EOU yet. It should be in Beta 6, with as many
of my updates to the libraries and headers as possible.

Right now if you want to check out the preprocessor, you want to look at
the GitHub repository at <https://github.com/Deek/CoCoC>. The source and
OS-9 binaries may be found there.

On Sun, Nov 15, 2020, 9:04 AM William Carlin <whcarlinjr at gmail.com> wrote:

> 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
> >
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>