aking@BFLY-VAX.BBN.COM.UUCP (01/24/87)
I've been using the recently posted version of MAKE with the alcon compiler since it was posted several weeks ago. It sure beats clicking all over the place! However, there are two nagging problems which maybe others have experienced, and maybe someone has a solution to. 1) Compillations with errors (who ever has those?) continue blythely on, and produce binaries which appear to later phases of make to be just (or almost just) fine. Looks like either alcon doesn't return with an error code, or it doesn't get through gemdos to make. 2) Alternative efforts to redirect standard out to a file (so I don't have to babysit compilations) have failed. The developers' batch.prg isn't documented that I have found. Things like make make >listfile don't work. I've tried a few, but someone, please enlighten me. 3) When I make make, I get a make.prg which produces the error message: make: no memory for name Now that's the same blind alley that I encountered when I tried to make make on the earlier distribution of make, some 6 months or so ago. Currently I'm thinking its something wrong with my alcon (distribution 4/86) or gemstart (there was some net mail 3-4 months ago about malloc and Malloc). Has anybody put this one together?
bammi@cwruecmp.UUCP (01/25/87)
In article <8701241530.AA02029@ucbvax.Berkeley.EDU> aking@BFLY-VAX.BBN.COM (Allen King) writes: Sorry for repllying to the net, but any of the addresses listed in the headers to aking@BFLY-VAX do not work from us. Can i please request all people here to please append a .signature, that contain paths from known sites. >1) Compillations with errors (who ever has those?) continue blythely >on, and produce binaries which appear to later phases of make to be >just (or almost just) fine. Looks like either alcon doesn't return >with an error code, or it doesn't get through gemdos to make. The problem is with Alcyon. It does not return with an error code. Alan Pratt has promised to post the patches (allan??) >2) Alternative efforts to redirect standard out to a file (so I don't have >to babysit compilations) have failed. The developers' batch.prg isn't >documented that I have found. Things like > > make make >listfile > >don't work. I've tried a few, but someone, please enlighten me. > Depends where you issue this command from. If you do it from within BeckMeyers C-Shell, everything gets re-directed just as you'ed expect. If you issue this command with within Mark Williams's msh (not using their make) then you have to re-direct stderr too make make >& listfile Several of the Pc-Dos type shells that i have seen around just don't handle re-direction correctly. I am not sure what it does from the desktop, as i have never run it from there (why would you :-) >3) When I make make, I get a make.prg which produces the error message: > > make: no memory for name > >Now that's the same blind alley that I encountered when I tried to make make >on the earlier distribution of make, some 6 months or so ago. Currently >I'm thinking its something wrong with my alcon (distribution 4/86) or >gemstart (there was some net mail 3-4 months ago about malloc and Malloc). >Has anybody put this one together? I tried to reply to you several times when you described you problem in a mail message, but as i said above, i could never get thru. I did'nt hear anything after that, so i presumed that you had found the solution. As i recall i spotted two problems with the example you sent me: -The problem was with your definition of `isspace()' macro as you did'nt have <ctype.h> for some reason. The correct definition is that isspace() returns TRUE if the character is any of {space, tab, carrriage-return, line-feed, vertival tab or form-feed} I seem to recall that you had defined it as {space or tab} only, and that would cause problems in make. -The second problem problem was with gemstart.s. Yes, atari did release a totally ridiculus gemstart.s. As distributed, it gave only 1K or so bytes to the stack+heap. The fix is to change it so that it leaves around 16k or some more rational amount for the stack+heap. The line to change in gemstart.s is >> add.l #$500,d0 * d0=basepage+textlen+datalen+bsslen >> * (plus 1K of user stack) Change the $500 to read $4000 for 16K. If you are on CompuServe, there is a totally new version of Gemstart.s available in the developers section, that is much nicer. I hope the above fixes get make going for you. -- usenet: .....!decvax!cwruecmp!bammi jwahar r. bammi csnet: bammi@case arpa: bammi%case@csnet-relay compuServe: 71515,155
dclemans@mntgfx.UUCP (01/26/87)
The desktop .ttp dialog box doesn't do any I/O redirection processing. It just passes '<*' and '>*' arguments through directly. If you are running a program that has startup code to look for these kind of arguments and do it's own redirection they will work; otherwise not. (By startup code, I mean the assembly language code that sets up the environment to call the C main routine). The code generated by at least one compiler (I forget which one off hand) has the restriction that only redirection arguments at the start of the argument list will be handled; ones buried further down will be ignored. dgc