🚀 go-pugleaf

In article <115@harald.UUCP> jba@harald.ruc.dk (Jan B. Andersen) writes:
>If one was to port a make-program to AOS/VS, how much should the
>interface be changed? I mean, should one accept '/switches' instead
>of '-options'? Should the 'newline-escape' be changed from '\' to '&'?
>
>One thing which has puzzled me, is how to express things like:
>
>  $ make XLIBS="x1.a x2.a x3.a"
>
>Should it be
>
>  ) make XLIBS/DEFINE=x1.lb+x2.lb+x3.lb
>
>to avoid the CLI splitting it up into seperate args? Doing otherwise
>would require more parsing. Is it worth it?
>
>      /|  /       Postmaster@RUC.dk               /^^^\     .----------------.
>     / | /        DG-passer@RUC.dk               { o_o }    | SIMULA does it |
>    /--|/         jba@meza.RUC.dk                 \ o / --> | with CLASS     |
>`--'   '          rucjb@os1100.uni-c.dk        --mm---mm--  `----------------'


This is an interesting (if messy) question:  How much of an existing
interface should be changed so that it fits into the "look-and-feel"
of the existing interface.

Since this question could be argued for decades, I'll just give you
my opinion as to "make" in general.

Just an aside:  Are you aware of the "make" offering from DG?  I think it's
bundled in with the TCS (Text Control System), very old, however I think 
it's out there somewhere.  Sorry I don't have access to my DG documentation
at the moment, If you really want to know I can probably find out for you
or perhaps someone from DG can reply with the info.

I'm under the impression that you have a substantial development investment 
made on some Unix platform, and you would like to move it to the DG with a 
minimum of fuss, thus the urge to port "make".

As to make:  I've worked on AOS/VS for many years now, and I'm currently
using "make" every day because I've transferred to a Unix group. 
 
Make has so many options, and interfaces so closely with the shell, that 
I think it will be difficult to integrate it into AOS/VS without taking 
some other considerations into account.

Environment variable support will be needed, switches for all the subcommands
that "make" normally calls (cc, ld) will have to be modified, etc.   Simple
expansion of something like   `ls *.c`   which is so easy in a make script
is very tough in AOS/VS (sure, [!fi], but it can only handle the simple cases).
Even determining date dependencies will be tough!  You'll also have to worry
about the (friendly) CLI sticking it's nose into whatever parameters you
want to feed to make.  I'm sure you've already encountered headaches (well
at least pain-in-the-a**) when the cli compresses your whitespace, steals
your commas, and expands your brackets and parenthesis!

So, if you really want to pursue such a path,  My recommendation is:
Don't modify the interface to support DG-isms at all.  Don't allow switches
and don't rely on the CLI to do much for you.  Simply write "make" as a "c" 
program which grabs the command line and takes care of everything itself.
Use the standard Unix switch format and parse it yourself.  I think the 
extra parsing is worth it, because whatever you come up with (such as "+"'s
in your example) will (sooner or later, it always does) come back and bite
you later.

Advantages:  You can use "make" just as you expect from a Unix background, 
no extra documentation, etc. albeit you may want to sacrifice some of "make"'s
many switches.  Make scripts often contain further recursive make calls, if
you stick to the Unix syntax you won't have to worry about modifying every
script that comes in the door.

Disadvantages:  It doesn't feel like AOS/VS if it doesn't have switches!
Honestly, other than that, I can't see any advantages to moving to DG's 
"/switch=4" format from the Unix "-switch 4" format.  Either way, you're
going to have to parse it in a program.  (Unless of course you're thinking
of just using the CLI - shudder!).

If you really want to go for the gold, implement both!  let the last one 
encountered take precedence and issue warnings for duplicate or conflicting 
switch usages.

Either way, it's a lot of work... It's been my experience that rather than use
makefiles technology, it was often easier to simply create some general purpose
macros (Add a .ob to a .lb, compile one file using a certain file which
contained an include list, etc.) and work with those.

Perhaps you can make use of the GNU group's GNU-make and start from there?
They may even have an AOS/VS version of gnumake ported already! 

I'd be interested in hearing what you've come up with so far?
What kind of project is involved?

Just curious, Good luck, Steve.