Path: utzoo!attcan!utgpu!watmath!att!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mcsun!hp4nl!orcenl!sbower From: sbower@oracle.nl (Steve Bower) Newsgroups: comp.os.aos Subject: Re: Should 'make' for AOS/VS look like Unix-make? Message-ID: <513.nlhp3@oracle.nl> Date: 21 Sep 89 15:48:10 GMT References: <115@harald.UUCP> Reply-To: sbower@oracle.nl (Steve Bower) Organization: ORACLE Europe, The Netherlands Lines: 93 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.