hull@hao.UUCP (Howard Hull) (12/27/85)
Gee, I got this very nice letter from Courtney Prodehl at caip via CSNET (to which I have no hope of replying) saying >You seem to have an inordinate amount of difficulty compiling with Lattice C. >For starters, it sounds like you failed to read through the install-c batch >file on the C disk. It mentions toward the end that Lattice C REQUIRES the >logical name assignments mentioned be included in your startup-sequence. Well, it didn't seem like an unusual amount of trouble to me; the compilers always seem to require weirdo syntax library flags (even 4.2BSD :-) does) So I took another look at my install-C file to find out what I didn't read. Amazing results; the following is the ENTIRE contents of my C1.0:s/install-C file: ; This script will install the entire contents of the C directory on ; this disk into the C: directory. ; copy C1.0:c C: all Courtney goes on to say >Then, >the batch files provided, namely lca and linka, can be used which are a lot >easier than remembering where the include files are located, and the strange >syntax of the linker. > >Also, if you use the compiler driver, LC, rather than LC1 and LC2 (the batch >file lca does this), your quad file will get written to ram disk, this is >MUCH faster than running each phase of the compiler separately. so I tried to run ED on my C1.0:c/LC file, and ED snapped right back File contains binary and dumped me. I was not able to find the files lca and linka at all. There are a coulple of long ASCII files in the C1.0:examples directory that contain information that is duplicated in the update documentation. But I had already determined that the printed documentation was hopelessly out of phase with what was in the 11- page update addendum sheets. As a for instance, the main documentation calls out the command line LINK FROM C.0,XYZ.O,QRS.O TO CPROG LIBRARY LC.LIB,AMIGA.LIB which, while close, is still is a no cigar transaction on account of no C.0 file on my disk. Am I missing something? are there files on these disks that cannot be found with "dir C1.0: OPT A"? Also, how do you find the file dates and the file sizes? (I had a real tussle with the Amiga "Back to the Future" social disease after several of my files got contaminated from the also brand new Assm1.0 disk...) Does anyone know what's going on here? Did my Amiga Dealer sell me a "Hongkong Copy" of C1.0? Doesn't seem like it, as it came with the developer's manual and was nicely wrapped in plastic, and it cost A LOT of money, too! Best Regards, Howard Hull [If yet unproven concepts are outlawed in the range of discussion... ...Then only the deranged will discuss yet unproven concepts] {ucbvax!hplabs | allegra!nbires | harpo!seismo } !hao!hull
mykes@3comvax.UUCP (Mike Schwartz) (12/27/85)
This is how I set up my system for compiling lattice 'C' stuff native on the Amiga. 1. I formatted a disk and used the install command to make it into a bootable disk. Then I copied most of the commands from my workbench disk's :c directory. I also copied the fonts, devices, etc. I then deleted a lot of the workbench :c commands from my new disk. I then created a directory to hold the 'C' compiler and linker as :lc. I also copyied the include files (in the standard tree structured format) subdirectories to this disk. This disk I call my lattice 'C' workbench disk. You can edit the file :s/startup-sequence to assign any devices that you might want, set your default working directory, etc. 2. My second disk I call my work disk. All my work disks must have a special subdirectory on them called :clib, which contains lstartup.obj and the 'C' libraries. For convenience's sake, I concatonated these three files to make clib.lib - lc.lib+amiga.lib+debug.lib. The rest of the work disks are used to hold (flame on) a few source files along with the MONSTROUS output of the sad lattice 'C' compiler (flame off). I find that the 880K floppies are enough to hold about 3 to 4 fair size projects at a time. 3. Using this configuration, the following commands compile hello.c: df0:lc/lc1 -idf0:include/ -oram: hello df0:lc/lc2 -odf1:hello.o ram:hello df0:lc/alink df1:clib/lstartup.obj+hello.o library=df1:clib/clib.lib to hello These commands can be simplified by putting the following assigns in your startup-sequence file on df0: assign cc: df0:lc assign ci: df0:include assign clib: df1:clib/clib.lib assign cmain: df1:clib/lstartup.obj This makes the compilation commands: cc:lc1 -ici: -oram: hello cc:lc2 -odf1:hello.o ram:hello cc:alink cmain:+hello.o library=clib: to hello I hope that this helps some of you out there. I have played around with system configurations for native development, and have found that using the RAM disk too much (too much == not much) that the linker and compiler have a hard time. Also, Lattice 'C' doesn't handle lots of if ... else if... in a row too well (you need gobs of stack). /mykes
farmer@ico.UUCP (01/03/86)
For what it's worth, here is how I go about compiling the using only one drive. I made copys of my workbench, and and C1.0 disk. Then I edited the startup file on the workbench disk to copy things like dir, list, cd, assign, copy, execute, label, ed, echo, rm, and list to ram: and assigned c: ram:. Then I stick the C disk in the drive, and type cd df0:examples. Finally I just type execute make prog and although a bit slow, it all seems to work. David Farmer The usual disclaimers: Interactive is not responsible for what I do in my spare time.
hull@hao.UUCP (Howard Hull) (01/05/86)
From the referenced article by Peter da Silva, commenting on my article... > > ...you should copy the ".q" file to a > > blank disk before the compiler metamorphosizes it. > > Why? I'm not familiar with Lattice 'C' on the Amiga, but Lattice 'C' on the > IBM PC does exactly the same thing. I have never had LC2 clobber a .q file > prematurely, nor have I ever found a use for the .q file. All it is is a > compiler intermediate. Do you keep your /tmp/ctm files around on UNIX? No. I had just gotten the wrapper off the Lattice_C compiler, and was going through the book "serially" using AmigaTerm as a goat. I thought I might want (read: subsequently *have* to) use some of the LC2 flags to get out of one kind of mess or another. I wouldn't have had the problem at all if Lattice had prioritized the order in which the commands were presented in terms of ease of use. Is it not conventional to put the preferred commands (i.e. "LC") first? Or is it like in hardware, where everybody automatically knows to head straight for the Appendix and try to figure it all out from there... :-) Comment: Bruce Barrett's "Amiga Reference Card" posted by Dale Luck has been the most helpful alternative to trying remember it all starting on Page 4-1 going through page 4-9 of the Lattice C book just to get the flags. ***** Mild Flame ***** (Pass this by if you've got your momentum up.) I remember once bringing a thick manual to the office of a work associate (after he had asked over the phone "how do I do xxxx?".) I thought I was helping him by showing him where in this thickness were the 20 or so pages that applied to his particular question. He sneered and said "But I wanted to know how to do it *without* having to read the documentation!". Although I might have instantly reacted "well, what a fine smart-ass we have here", I instead thought it over for a bit and wrote up a condensed one-sheet summary. When you realize that for every complex function we implement for which we do not also produce a Top Level Summary (i.e., you have to close your eyes to miss it) either in an appendix or on a cover or thick tab sheet/card, we dissipate n programmers times m hours of effort, which surely is worth more to the Gross National Product than the time it would have taken to write and publish a decent summary. Howard Hull [If yet unproven concepts are outlawed in the range of discussion... ...Then only the deranged will discuss yet unproven concepts] {ucbvax!hplabs | allegra!nbires | harpo!seismo } !hao!hull
jerem@tekgvs.UUCP (Jere Marrs) (01/06/86)
This discussion of the Lattice-C compiler didn't (I think) mention the version number. I have version 3.02, and there is a very nice Make script file which seems to compile programs nicely. If you ED the Make file, all of the commands and options are shown with the linking of the object modules too. It seems to work well. I know people on CompuServe who have compiled Michael Mounier's Aterm.c (30k source) successfully with Lattice. I'm just a beginner in C, but the Lattice package seems to do everything I have asked so far. There are several things to scrutinize: The #include files are above the source files in the disk directory and must be taken into account in the include statement in the source program. ED will not accept binary, but EDIT (the line editor) will. There is a README file in Examples that might be of some help. Have fun. Jere Marrs Tektronix, Inc. Beaverton, Oregon