cl@dlhpedg.co.uk (Charles Lambert) (01/11/88)
In article <3325@ulysses.homer.nj.att.com> gsf@ulysses.homer.nj.att.com (Glenn Fowler[eww]) writes: > [... speaking of nmake(1)...] Most problems involve the >property that old make actions are executed one line at a time by >separate shells whereas each nmake action is executed as a block by >a single shell. We recently acquired nmake from the AT&T Toolchest. Since we haven't got ksh(1), I converted it to run with Bourne shell (which doesn't provide inheritance of shell functions). Looking at the source, I couldn't decide for certain whether there should be one slave shell for the entire execution of nmake, or whether a separate shell should be spawned (and subsequently input-terminated) for each rule block. The alternate consequences are that the current directory and environment variables either have scope for the entire make (so one rule can alter the environment in which a subsequent rule executes) or only for one rule. Anyone able to enlighten me? ------------------ Charles Lambert ukc!datlog!dlhpedg!cl
gsf@ulysses.homer.nj.att.com (Glenn Fowler[eww]) (01/16/88)
In article <367@dlhpedg.co.uk>, cl@dlhpedg.UUCP writes: > ... whether there should be one slave shell for the entire execution > of nmake, or whether a separate shell should be spawned (and subsequently > input-terminated) for each rule block. ... by default nmake actions are executed in sub-shells using {...}& so environment changes (e.g., cd, export) affect the current action only the action for a target with the .FOREGROUND attribute is executed directly by the top level shell so in this case environment changes affect all actions that follow -- Glenn Fowler AT&T Bell Laboratories, Murray Hill {ihnp4,allegra}!ulysses!gsf (201)-582-2195
djm408@tijc02.UUCP (David Marks ) (01/26/88)
in article <367@dlhpedg.co.uk>, cl@dlhpedg.co.uk (Charles Lambert) says: > Summary: What is the scope of the slave environment? > > We recently acquired nmake from the AT&T Toolchest. Since we haven't got > ksh(1), I converted it to run with Bourne shell (which doesn't provide > inheritance of shell functions). Looking at the source, I couldn't decide > for certain whether there should be one slave shell for the entire execution > of nmake, or whether a separate shell should be spawned (and subsequently > input-terminated) for each rule block. The alternate consequences are that > the current directory and environment variables either have scope for > the entire make (so one rule can alter the environment in which a > subsequent rule executes) or only for one rule. > > Anyone able to enlighten me? > > ------------------ > Charles Lambert ukc!datlog!dlhpedg!cl One of the nice things about nmake(1), is that it runs all rule actions in the same shell, thereby saving the overhead of process creation for each rule/target it is going to execute. This should increase the speed of execution. Additionally, as you stated, the shell environment is preserved from one rule/target execution to another within the same nmake invocation. This makes nmamke makefiles leaner, as shell variables and functions only have to be set in one rule, and not by all rules that need to use them. The two major advantages of nmake(1) as I see it, are the single shell accross all rules, and the fact that it knows about multiple directories. If you modify it to spawn a shell for each rule excution, then you have defeated one of the main reasons to use nmake(1). ----------------------------------------------------------------------------- #include <standard/disclaimer.h> LIFE IS NOT A MALFUNCTION! David J. Marks Texas Instruments Ms 3520 Erwin Highway/P. O. Drawer 1255 Johnson City, TN. 37605 mcnc!rti!tijc02!djm408
ekrell@hector.UUCP (Eduardo Krell) (01/28/88)
In article <190@tijc02.UUCP> djm408@tijc02.UUCP (David Marks ) writes: >The two major advantages of nmake(1) as I see it, are the single shell accross >all rules, and the fact that it knows about multiple directories. What happened to: * Automatic dependency checking (ie, no need to specify #include dependencies) * A compiled Makefile (no need to re-parse every time) * Automatic generation of -D and -I flags * Built-in rules for archives, yacc & lex files, etc. * Metarules which act as rule template or "macros" etc. etc. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {ihnp4,ucbvax}!ulysses!ekrell ARPA: ekrell%ulysses@att.arpa