ryan@sjuphil.uucp (Patrick M. Ryan) (12/15/89)
Is it just my imagination or is the version of Make which comes
with MSC 5.1 a pitiful imitation of the real Unix Make? There are some
pretty fundamental things it doesn't seem to do, such as assuming
'makefile' as the default makefile name. The built-in macros are
few and far between. It insists on making the objects in the order
in which they appear in the file instead of letting the user specify
an object to be made and starting the dependency checking from there.
I have seem PD implementations of Make on PCs which work exactly the
same as the Unix make. Why did Microsoft limit their version so much?
I have heard that MSC 6.0 is due out sometime in the near future.
Has anyone heard of any plans to rectify this situation?
Thanks
--
pat ryan
ryan%sjuphil.sju.edu@bpa.bell-atl.com
{princeton|rutgers|liberty|bpa}!sjuphil!ryan
pmr@bootes.gsfc.nasa.govkaleb@mars.jpl.nasa.gov (Kaleb Keithley) (12/16/89)
In article <1989Dec15.021527.18711@sjuphil.uucp> ryan@sjuphil.uucp (Patrick M. Ryan) writes: > > Is it just my imagination or is the version of Make which comes >with MSC 5.1 a pitiful imitation of the real Unix Make? There are some >pretty fundamental things it doesn't seem to do, such as assuming >'makefile' as the default makefile name. The built-in macros are >few and far between. It insists on making the objects in the order >in which they appear in the file instead of letting the user specify >an object to be made and starting the dependency checking from there. > I have seem PD implementations of Make on PCs which work exactly the >same as the Unix make. Why did Microsoft limit their version so much? > I have heard that MSC 6.0 is due out sometime in the near future. >Has anyone heard of any plans to rectify this situation? > I can't speak for Microsoft's plans for MSC 6.0, but if you get QuickC 2.0 or 2.01, it comes with NMAKE.EXE (New Make?) that more closely emulates UN*X make. If I had to guess, I think M'soft will distribute NMAKE with 6.0 whenever it hits the streets. Chewey, get us outta here! kaleb@mars.jpl.nasa.gov (818)354-8771 Kaleb Keithley
fredex@cg-atla.UUCP (Fred Smith) (12/16/89)
In article <1989Dec15.021527.18711@sjuphil.uucp> ryan@sjuphil.uucp (Patrick M. Ryan) writes: > > Is it just my imagination or is the version of Make which comes >with MSC 5.1 a pitiful imitation of the real Unix Make? > I have seem PD implementations of Make on PCs which work exactly the >same as the Unix make. Why did Microsoft limit their version so much? No it is NOT your imagination. Microsoft's Make utility is largely a wortless piece of code--good for nothing except taking up disk space (unless you work from within QuickC, which needs the damn thing for doing builds). There have been reasonably good Make clones around for a long time. I saw one at least four years ago which was shipped with Mark Williams C compiler (to say nothing of several commercial makes and a bunch of shareware/PD ones). Fred
Bob.Stout@p6.f506.n106.z1.fidonet.org (Bob Stout) (12/16/89)
MSC 6.0 wil include NMAKE rather than MS's old make. NMAKE is currently supplied with all MS languages released since and including QC 2.0. It's much better (but then what isn't?)
sdawalt@wright.EDU (Shane Dawalt) (12/17/89)
in article <1989Dec15.021527.18711@sjuphil.uucp>, ryan@sjuphil.uucp (Patrick M. Ryan) says: > > Is it just my imagination or is the version of Make which comes > with MSC 5.1 a pitiful imitation of the real Unix Make? I do not use MSC, however, I have heard plenty of talk about MSC's make vs. Borland's make. (Borland follows the Unix convention.) There are many people wondering why their MSC make files will not produce the correct results under Borland's make. I suspect that Microsoft may have relaxed the strict rule flow of Unix so that non-Unix users could simply list their files in any order and make would run without problems ... then you have the Unix people wondering why MSC's make is so "strange." :-) Shane sdawalt@cs.wright.edu
martin@mwtech.UUCP (Martin Weitzel) (12/18/89)
In article <884@thor.wright.EDU> sdawalt@wright.EDU (Shane Dawalt) writes: >in article <1989Dec15.021527.18711@sjuphil.uucp>, ryan@sjuphil.uucp (Patrick M. Ryan) says: >> >> Is it just my imagination or is the version of Make which comes >> with MSC 5.1 a pitiful imitation of the real Unix Make? > > I do not use MSC, however, I have heard plenty of talk about MSC's >make vs. Borland's make. (Borland follows the Unix convention.) There >are many people wondering why their MSC make files will not produce the >correct results under Borland's make. I suspect that Microsoft may have >relaxed the strict rule flow of Unix so that non-Unix users could simply ^^^^^^^^^^^^^^^^^^^^^^^^ >list their files in any order and make would run without problems ... then ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sorry, I also don't know MSC, but I don't quite understand this: Under UNIX I *can* list my rules in any order that I want! The places, where the order matters, are in the '.SUFFIXES:'-line and in a few special cases the order of the dependencies after a ':' is important. In both cases it is essential that the order matters, because the order resolves some ambiguities, that would otherwise exist. >you have the Unix people wondering why MSC's make is so "strange." :-) Or does the smiley face mean, that I should reverse the meaning of your words, to put it right? -- <<< MW -- email: see header -- voice: 49-(0)6151-6 56 83 >>>
hollen@eta.megatek.uucp (Dion Hollenbeck) (12/18/89)
From article <8176@cg-atla.UUCP>, by fredex@cg-atla.UUCP (Fred Smith): > In article <1989Dec15.021527.18711@sjuphil.uucp> ryan@sjuphil.uucp (Patrick M. Ryan) writes: >> >> Is it just my imagination or is the version of Make which comes >>with MSC 5.1 a pitiful imitation of the real Unix Make? >> I have seem PD implementations of Make on PCs which work exactly the >>same as the Unix make. Why did Microsoft limit their version so much? > > > No it is NOT your imagination. Microsoft's Make utility is largely a wortless > piece of code--good for nothing except taking up disk space (unless you work > from within QuickC, which needs the damn thing for doing builds). > > There have been reasonably good Make clones around for a long time. I saw one > at least four years ago which was shipped with Mark Williams C compiler (to say > nothing of several commercial makes and a bunch of shareware/PD ones). > > Fred Speaking of GOOD Make utilities, may I recommend OPUS Make by Don Kneller. This is an updated, improved, commercial version of his previous NDMAKE. NDMAKE is shareware and I have been using it for about 2 years now. I have moved many makefiles over from UNIX and they run without modification. NDMAKE has additional features not found in UNIX make and OPUS has many more. This is a solid product worth having if you do any developoment which is at all real (as opposed to playing at home for fun and learning). You can contact Donald Kneller at ...ucbvax!ucsfcgl!kneller (at least this is the last address I had for him). Just a satsified user who could not do without NDMAKE. The product is wonderful and support has been grand and timely. Don't pass this one up. Dion Hollenbeck (619) 455-5590 x2814 Megatek Corporation, 9645 Scranton Road, San Diego, CA 92121 uunet!megatek!hollen or hollen@megatek.uucp
fredex@cg-atla.UUCP (Fred Smith) (12/19/89)
In article <884@thor.wright.EDU> sdawalt@wright.EDU (Shane Dawalt) writes: > I suspect that Microsoft may have >relaxed the strict rule flow of Unix so that non-Unix users could simply >list their files in any order and make would run without problems ... then >you have the Unix people wondering why MSC's make is so "strange." :-) > > Shane > >sdawalt@cs.wright.edu It seems to me, if I understand you, that you have it backwards. in Unix's make you can list the targets in any old order you please, and as long as you tell make which target to build (and define properly the dependencies) it will know how to do so. It either builds, or acts as if it had built, a dependency tree which, once built, can simply be traversed in-order, building each target as necessary. When done all things required for building the main target will have been built,so that it can then build said target. What MSC's make does is to move the dependency order work from the program to the PROGRAMMER. It is necessary for the objects to be listed in the makefile top to bottom in dependency order. If the first listed target depends on the third one, then you are out of luck, because the stupid thing doesn't know how to build the third one until it has completely finished processing the first `and second ones. It then will NOT go back and do the first, because it is simply traversing the makefile in first to last order. Fred
u-gclapp%ug.utah.edu@cs.utah.edu (Glenn Clapp) (12/19/89)
Why the heck would anyone want to use the stripped down and funky MSC make? YUK Big Time! I got so fed up with the limitations of MSC 5.1 make that I switched to nmake. What the heck is nmake you ask? Well, it is a *full blown* make that comes with (now get this) Microsoft's QuickC 2.0 Now put that on your hard disk and smoke it! -Glenn
dave@motto.UUCP (David Brown) (12/20/89)
My biggest problem is not with Microsoft's make, per se, but with the command line limits on utilities such as the linker. What I would like to do is something like OBJS = file1.obj \ file2.obj \ ... file200.obj ... prog.exe: $(OBJS) link $(OBJS), prog, ... However, even if I get around the 512 byte limit in macros by having multiple macros (OBJ1, OBJ2, ...), link won't accept so long a command line. I'm forced to keep a separate response file for the link, which means maintaining another list of all the object names. I tried the PDMAKE that was posted here recently. It solves the macro limit problem, but I'm still stuck with the link command line limit. What do the rest of you do if you have a lot of object files to make? ----------------------------------------------------------------------------- | David C. Brown | uunet!mnetor!motto!dave | | Motorola Canada, Ltd. | 416-499-1441 ext 3708 | | Communications Division | Disclaimer: Motorola is a very big company | -----------------------------------------------------------------------------
rs@tnoibbc.UUCP (Rob Schoenmaker) (12/20/89)
In article <78@motto.UUCP> dave@motto.UUCP (David Brown) writes: >However, even if I get around the 512 byte limit in macros by having >multiple macros (OBJ1, OBJ2, ...), link won't accept so long a command >line. I'm forced to keep a separate response file for the link, which >means maintaining another list of all the object names. > >I tried the PDMAKE that was posted here recently. It solves the macro >limit problem, but I'm still stuck with the link command line limit. > >What do the rest of you do if you have a lot of object files to make? > I use Polytron's PolyMake which can generate a response file for you, like this : test.exe: $(OBJS) link $(LFLAGS) <@< $[s," +\n",$**] $@ $(LIBS) < -- Rob Schoenmaker: TNO - IBBC USENET : rs@tnoibbc : lange kleiweg 5 UUCP : ..!hp4nl!tnoibbc!rs : 2288 GH Rijswijk : the Netherlands VOICE : +31 15 606410
sdawalt@wright.EDU (Shane Dawalt) (12/21/89)
in article <8178@cg-atla.UUCP>, fredex@cg-atla.UUCP (Fred Smith) says: > > In article <884@thor.wright.EDU> sdawalt@wright.EDU (Shane Dawalt) writes: >> I suspect that Microsoft may have >>relaxed the strict rule flow of Unix so that non-Unix users could simply ^^^^^^^ >>list their files in any order and make would run without problems ... then >>you have the Unix people wondering why MSC's make is so "strange." :-) >> >> Shane >> >>sdawalt@cs.wright.edu > > What MSC's make does is to move the dependency order work from the program > to the PROGRAMMER. It is necessary for the objects to be listed in the makefile > top to bottom in dependency order. Perhaps I did not choose the best wording (I can almost see everyone nodding their heads), but when I stated "strict rule flow of Unix [make]," the implication was a recursive, top-down ordering of rules in the makefile as is required for Unix make. Microsoft make starts at the top and works down the rule list one at a time. That's terrific for non-Unix people; just list the files in the makefile (source first, executable last) and ya have it made. On the other hand, the concept of a make utility is not realized with this type of makefile format. Shane email: sdawalt@cs.wright.edu
Bob.Stout@p6.f506.n106.z1.fidonet.org (Bob Stout) (12/21/89)
In an article of <19 Dec 89 19:53:27 GMT>, (David Brown) writes: >My biggest problem is not with Microsoft's make, per se, but with the >command line limits on utilities such as the linker. > >What do the rest of you do if you have a lot of object files to make? The technique I sometimes use when compiling libraries (i.e. it only works if all the objects are together in one subdirectory by themselves) is to run a program which generates a linker response file for me by listing all the available .OBJ's and adding the extra verbage expected by the linker. This is the same technique used in the CXL windowing library, although I wrote my own for inclusion with my Microsoft library. If you'd like I can post the source.
efowler@milton.acs.washington.edu (Eric Fowler) (01/21/90)
I have been trying to write a simple program that reads strings from an open file, then sorts them into a binary tree structure(this just for own curiosity, not for any good reason:-)). The procedure checks each string against the string in the appropriate field at the appropriate node, then (as appropriate)either increments an integer field and returns control(the strings matched), moves "left"/"right" (one string is smaller, the pointer that way is not NULL), or sets the pointer to the value returned by a function that mallocs memory for the structure and the string field contained therein, puts the input string into the string field, and returns a pointer to the new structure. Naturally, the function which compares the strings, checks the pointers, and calls the function to return the pointer to the new structure is recursive. Now, when this is called, it runs perfectly for a variable length of time, that is, it varies according to:(1)whether it is on a mainframe or PC; (longer on the PC, sometimes terminating successfully);(2)whether the output is directed to the screen or a file(longer if it goes to a file);(3)which file it is fed for input. All of the input files are ASCII text files, of modest size. Given very small files, it will terminate normally at EOF. Given larger files, it dies, usually with an error indicating a memory problem(DYNIX: "segmentation error:core dumped", BSD Tahoe:"bus error", DOS said something like this too). Furthermore, the dbx debugger accuses "malloc" of forcing an exit. It is clear even to me that there is a memory allocation problem here (no kidding! :-)). What is not clear is what is going wrong, and how I can fix it. No way is the stack getting too big-the files are not that large, and it will go much further with some input files than others, that is, it will build a tree to depth 8 or 10 with one input file, but bomb at depth 2 or 3 with others. (Any given file with the same output redirection generates id- entical output every time it is run, however). Also unclear is how the screen I/O can screw up the stack. It is apparent that the stack is being corrupted, but I don't know how. Any help appreciated. Thanks. =Eric