jba@harald.ruc.dk (Jan B. Andersen) (09/21/89)
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-- `----------------'sbower@oracle.nl (Steve Bower) (09/21/89)
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.
jba@harald.ruc.dk (Jan B. Andersen) (09/22/89)
sbower@oracle.nl (Steve Bower) writes: [I (jba) asked about /switches vs. -options, "x1 x2 x2" vs. x1+x2+x3] >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. Yes, we have SMU/TCS (Source Management Utilities) on the MV. >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". No - it's the other way around. Several years ago, the computer science department at Roskilde University Center bought a MV/10000 and at the same time I was hired as a systems programmer/manager. Until now, it has mostly been used for teaching Simula. Most of my work has consisted in helping the students, installing software, issuing STR's and keeping track of the manuals (it's amazing how quickly they tend to disappear!) I have also developed my programming environment (APE) and a small mail system. In fact, one my favorit occupations is writing CLI-macros. But this year, we finally got the network installed, and the world of free, easily accessible Unix-software emerged. We only have 3 small Unix-machines at the department (1 NCR TOWER and 2 SUN's) without much diskspace. And now I want some of the Unix programming tools on the MV, things like grep, cut, paste, make, awk, Elm (I'm working on that!). Well, we actually have them all (except for Elm) because we have MV/UX, but I envy (sp?) all you in the Unix-world for the many utilities you have/can have. And in my position, I can afford to use some time in porting these to AOS/VS. But I would like to do it in a way, so others without MV/UX and SMU could have it, and maybe even port other programs, like mailx, nslookup or NNTP to AOS/VS. I can do without make and the other programs, but if it could be done without to much trouble I would very much like it, instead of writing hundreds of little macros to do slightly different tasks. >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. I wasn't planning of implementing both make and sh(1). The makefile would in all, except for the most trivial, cases have to be modified. >Perhaps you can make use of the GNU group's GNU-make and start from there? I have found a suitable make.Z at uunet, a neat little thing which pre-dates GNU. >They may even have an AOS/VS version of gnumake ported already! If they have, I would be most interested! >I'd be interested in hearing what you've come up with so far? Well, I just ftp'ed the make-program yesterday, inserted a #ifdef to #include <error.h> and compiled it. Unfortunately, it was #ifdef'ed for three different O/S (unix, eon ?? and os9) so it didn't do anything!! But some day next week, I hope to have a working version (with a Unix-like interface). >What kind of project is involved? The project is Elm 2.2 Patchlevel 10. Anyone got a PD-implementation of curses? This is were I'm stuck right now. Maybe I'll have to rewrite the screen-handling and restrict it to work on Dasher terminals. It's a start, and with the new VT-100 support in 7.65 that will cover 90% of the cases. >Just curious, Good luck, Steve. Thanks.