$VK0%CLVM.BITNET@WISCVM.ARPA (Valdis Kletnieks) (10/29/85)
I wish to thank the two people who E-mailed me telling me that VMS has a "make" facility available. However, whereas "make" is part of the bundled Un*x, VAX DEC/MMS, Version 2.0 (SPD 20.03.05) is an additional-charge product. My copy of the DEC Reference Service says that as a mininum charge to install this on a Vax 780 with a mag-tape, you need to order: Single-Use License Option - QE500-UZ $2,100 Distribution & Documentation Option - QE500-HM $521 total $2,621 (Please, no flames if this is wrong...) (software maintainance is extra...) flame on... It's really nice that some sites have this tool, but I don't see it at my site. Not all Vaxen run Un*x, and the ones that don't do not necessarily have all this neat stuff bundled in. My original point still stands, that editing a Makefile will not make it all better. I will grant that giving the equivalent of -Dvoid=int on the command may "solve" the problem, but that is ** NOT ** the same thing. All those of you talking about "portable" C code and associated issues out there: Make SURE that when porting between operating systems that the concepts are in fact equivalent. In this case, not editing the makefile and defining 'void' in the compile command will do it. However, I shudder to think what will happen if people taking fast-and-loose interpretations of the concept of a 'makefile' run into something more subtle and not as easy to see. Software portability is not just getting your int's the right length.... flame off... Valdis Kletnieks Systems Programmer Educational Resources Center Clarkson University BITNET: $VK0@CLVM.BITNET UUCP: {pur-ee,ccvaxa,sun}!csd-gould!clutx!vk0 decvax!sii!trixie!csd-gould!clutx!vk0 ICBM: 44 40N 75 00W
root%bostonu.csnet@CSNET-RELAY.ARPA (BostonU SysMgr) (10/30/85)
(Flame about no Make under VMS thus impacting portability) There is a collision here of two notions of portability (at least.) One is C code that will run anywhere and C code that will run under any UNIX system (as extreme but common examples.) The former (gee, UNIX does, make VMS do it too...oh those cwazy unix programmers...foiled again!) is very difficult, unless I was quite conscious that I needed to have my programs run under VMS or some such I would be loathe to toss out all my software engineering tools just to make life easy for sensory deprivation environments, that is the job of a VMS programmer, if my code is reasonable it will probably work with some effort, if it's not worth their effort, well, then why should it be worthwhile to me? Someone has to pay me big bucks to ensure a complicated piece of code will run under *any* C compiler, that's non-trivial. On the other hand, to write a C program that runs under any UNIX system, well that's just a chore, not very hard really as long as the system wasn't spec'd to run using peculiar features of, say, SYSV or Berkeley (eg. shared mem or internet specific.) And speak of the pot calling the kettle black! Just try to move VMesS Footran programs to UNIX, they won't even try to follow the damn language standards, let alone library calls and surrounding software (I'll take the DCL that builds this mess anyday if *you* will just follow the language standard.) Hrmph, I say sir, hrmph. Yeah, I know the answer, UNIX/C promised a lot of portability, while VMS never promised anything. -Barry Shein, Boston University