[net.micro.amiga] Disk organization for developing

cosell@BBN-PROPHET.ARPA (12/30/85)

From: Bernie Cosell <cosell@BBN-PROPHET.ARPA>

I'd like to second the request that developers share their insights
wrt juggling things on the disks so that the development cycle is
as painless as possible.  I'm a developer and I've started to puzzle
through where the "include" hierarchy will live and junk like that
and I really can't come up with a satisfactory layout.  Any advice
or tricks would be appreciated.  Thanks

  /Bernie
   cosell@bbn-prophet
   USENET: bbncc5!bpc

perry@atux01.UUCP (P. Kivolowitz) (12/31/85)

As people have been asking about how to layout disk contents for C
development I thought I'd share the way I've gravitated towards. I
place everything on df0 except the  c  load time libraries. Df0 is
(of course) a cli only disk. Get rid of libraries, fonts, and pro-
grams in c: that you don't absolutely need.

I include in c: only programs like  run, date, copy, delete, type,
format and other essentials in  addition to the lattice  c compiler
as well as alink.

My rational for putting the include files on df0 went like this:

The include files are around 500 blocks.
The libraries are around 250 blocks.

I'd rather have more room keep source, object, and executables
around on the development disk.

As it is (while trying to port a *very* popular unix game) I ran
out of disk space and had to create a source disk distinct from an
object/executable disk.

Hope this helped


					Perry S. Kivolowitz
---------------------------------
Next JAUG* Meeting is Jan 24th - the first was hampered by snow but
the 80 people who trudged through the mini-storm had a blast.

*Jaug is non-profit and is not associated with C-A, Inc.

mykes@3comvax.UUCP (Mike Schwartz) (01/01/86)

Beyond a shadow of a doubt, the best place to keep EVERYTHING is on the
ram disk.  Until someone does a reasonably priced ram expansion ($500 or
less), I am afraid some floppy scheme will have to do.

It is really too bad that Latticeis all we have, it's 200K, uses it's
own IO library (which is SLLLLLOOOOOWWWWW), and generates a 10K program
for "Hello World" (amazing).  You can bet that as soon as ANY other 'C'
compiler comes out, I will bury my Lattice 'C' or burn it or something
appropriate.

lbg@gitpyr.UUCP (Lee B Grey) (01/03/86)

In article <861@caip.RUTGERS.EDU>, cosell@BBN-PROPHET.ARPA writes:
> From: Bernie Cosell <cosell@BBN-PROPHET.ARPA>
> 
>                      ...  I'm a developer and I've started to puzzle
> through where the "include" hierarchy will live and junk like that
> and I really can't come up with a satisfactory layout.  Any advice
> or tricks would be appreciated.  Thanks
> 
>   /Bernie
>    cosell@bbn-prophet
>    USENET: bbncc5!bpc

This may be common knowledge, so I'll keep it short.  The first pass of the
compiler allows you to specify up to four paths to be searched for include
files.  I have found this to be a big help in organizing myself.  Not only
that, the Make script supplied allows you to specify up to three additional
options on the command line.  I changed my Make script so that it checks
the correct paths.  If I ever want to access a non-standard include file,
I can specify it on the command line, rather than editting the Make script or
moving the include file.

One note, the Make script came without disk specifiers;  I changed that so that 
I can compile from any current directory.  I hope this was clear.  I tried to be
so brief that I think I wasted everyone's time.  If so, let me know and I'll
do this again, only better.  Lots of luck.

Lee