Re: two make questions
I would like to thank everybody who replied to my post, and especially to Chad David and Chuck Robey. Thanks to your help I have now the system working as I need (with the exception of speed, but that is another issue :) I have another p?make related question, though. I've searched the archives, but cannot find an answer: what is the actual relation between our (FreeBSD) make, and pmake? It looks like our make is an old fork, is that right? Also, is there a package of our make? Does it build on other OSes? I need to run my newly created Makefiles on one sorry RedHat box, and the pmake package just doesn't cut it. So, since I couldn't find any other rpm on redhat.com, what are my chances should I, say, want to use /usr/ports/Mk/* on Linux? (Not that this is actually the case, my Makefiles are pretty simple.) -- begin 666 nonexistent.vbs FreeBSD 4.7-RC 10:44AM up 13 days, 17:58, 16 users, load averages: 0.10, 0.09, 0.08 end To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: two make questions
# [EMAIL PROTECTED] / 2002-10-01 04:52:14 -0700: Thus spake Roman Neuhauser [EMAIL PROTECTED]: I have another p?make related question, though. I've searched the archives, but cannot find an answer: what is the actual relation between our (FreeBSD) make, and pmake? It looks like our make is an old fork, is that right? Also, is there a package of our make? Does it build on other OSes? I need to run my newly created Makefiles on one sorry RedHat box, and the pmake package just doesn't cut it. So, since I couldn't find any other rpm on redhat.com, what are my chances should I, say, want to use /usr/ports/Mk/* on Linux? (Not that this is actually the case, my Makefiles are pretty simple.) Just about all `make' implementations in use today are mutually incompatible; pmake and gmake are no exceptions. If you want to write portable makefiles, you have to settle for the lowest common denominator, which is POSIX. Though it pains me to say it, if you just care about RedHat and FreeBSD, you might as well write your makefile for gmake and install gmake on FreeBSD from ports. Heh, I'm not going to rewrite the Makefiles when the last remaining RH in house is going to be converted. It's just that it might be two months before I get to it. :] -- begin 666 nonexistent.vbs FreeBSD 4.7-RC 1:56PM up 13 days, 21:11, 16 users, load averages: 0.00, 0.01, 0.00 end To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: two make questions
Thus spake Roman Neuhauser [EMAIL PROTECTED]: I have another p?make related question, though. I've searched the archives, but cannot find an answer: what is the actual relation between our (FreeBSD) make, and pmake? It looks like our make is an old fork, is that right? Also, is there a package of our make? Does it build on other OSes? I need to run my newly created Makefiles on one sorry RedHat box, and the pmake package just doesn't cut it. So, since I couldn't find any other rpm on redhat.com, what are my chances should I, say, want to use /usr/ports/Mk/* on Linux? (Not that this is actually the case, my Makefiles are pretty simple.) Just about all `make' implementations in use today are mutually incompatible; pmake and gmake are no exceptions. If you want to write portable makefiles, you have to settle for the lowest common denominator, which is POSIX. Though it pains me to say it, if you just care about RedHat and FreeBSD, you might as well write your makefile for gmake and install gmake on FreeBSD from ports. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: two make questions
On Tue, Oct 01, 2002 at 10:58:33AM +0200, Roman Neuhauser wrote: I need to run my newly created Makefiles on one sorry RedHat box, and the pmake package just doesn't cut it. So, since I couldn't find any other rpm on redhat.com, what are my chances should I, say, want to use /usr/ports/Mk/* on Linux? (Not that this is actually the case, my Makefiles are pretty simple.) One of the projects I'm working on is a build system much like FreeBSD's and instead of restricting our features we simply ported pmake from FreeBSD. The Solaris port took me about 10 minutes, while the win32 port was a little more involved (it would be easier without fork() :)), so I doubt a RH port will be difficult (I hesitate to even call it a port). You can either keep your makefiles very simple (good luck!), or you can port pmake and just move the whole system over. Good luck. -- Chad David[EMAIL PROTECTED] www.FreeBSD.org [EMAIL PROTECTED] ACNS Inc. Calgary, Alberta Canada To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: two make questions
# [EMAIL PROTECTED] / 2002-10-01 09:22:50 -0600: On Tue, Oct 01, 2002 at 10:58:33AM +0200, Roman Neuhauser wrote: I need to run my newly created Makefiles on one sorry RedHat box, and the pmake package just doesn't cut it. So, since I couldn't find any other rpm on redhat.com, what are my chances should I, say, want to use /usr/ports/Mk/* on Linux? (Not that this is actually the case, my Makefiles are pretty simple.) One of the projects I'm working on is a build system much like FreeBSD's and instead of restricting our features we simply ported pmake from FreeBSD. The Solaris port took me about 10 minutes, while the win32 port was a little more involved (it would be easier without fork() :)), so I doubt a RH port will be difficult (I hesitate to even call it a port). for someone who doesn't really know C (as in: I can read some, but finding out how to make a FreeBSD program work on Linux?)? You can either keep your makefiles very simple (good luck!), or you can port pmake and just move the whole system over. looks like i'll have to wait till i have the time to reinstall the server. -- begin 666 nonexistent.vbs FreeBSD 4.7-RC 5:25PM up 14 days, 40 mins, 18 users, load averages: 0.06, 0.12, 0.10 end To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: two make questions
# [EMAIL PROTECTED] / 2002-09-28 17:20:56 -0400: On Fri, 27 Sep 2002, Roman Neuhauser wrote: yup. or the fact that /usr/share/doc/psd/12.make/paper.ascii.gz documents conditionals in the form #keyword instead of .keyword (that might work, i haven't tried, but shouldn't the tutorial be updated? even if the # forms work they surely look deprecated from the fact that i haven't seen a single use in the system makefiles) Well, what you ought to use is the make(1) man page, which is reasonably decent. The # command introducers don't work because # is the comment introducer. I didn't say (or mean) I got confused by the discrepancy. I read ports' Makefiles (and those in /usr/ports/Mk) quite often, and anyone can quite easily tell contents of the whole /usr/share/doc/psd directory is pretty old, so I had no difficulty figuring out the case. But outdated, misleading documentation can be worse than no documentation IMO. The tutorial should be fixed. hm, i don't think i made myself clear with the previous para. how about this: is the pmake tutorial mentioned above carved in stone or are updates allowed? That's a political question, and probably should be asked on current. The answer you're going to get, though, is to go ahead and write up your changes, and see what kind of a reception they get. You won't get anyone to agree to give you permission to make changes until they see what those changes are. sure. I wasn't suggesting I wanted to commit (don't have commit access, either) any unreviewed changes. -- begin 666 nonexistent.vbs FreeBSD 4.7-RC 11:05AM up 12 days, 18:20, 13 users, load averages: 0.00, 0.03, 0.00 end To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: two make questions
On Fri, 27 Sep 2002, Roman Neuhauser wrote: yup. or the fact that /usr/share/doc/psd/12.make/paper.ascii.gz documents conditionals in the form #keyword instead of .keyword (that might work, i haven't tried, but shouldn't the tutorial be updated? even if the # forms work they surely look deprecated from the fact that i haven't seen a single use in the system makefiles) Well, what you ought to use is the make(1) man page, which is reasonably decent. The # command introducers don't work because # is the comment introducer. hm, i don't think i made myself clear with the previous para. how about this: is the pmake tutorial mentioned above carved in stone or are updates allowed? That's a political question, and probably should be asked on current. The answer you're going to get, though, is to go ahead and write up your changes, and see what kind of a reception they get. You won't get anyone to agree to give you permission to make changes until they see what those changes are. Chuck Robey | Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: two make questions
If memory serves me right, Chuck Robey wrote: hm, i don't think i made myself clear with the previous para. how about this: is the pmake tutorial mentioned above carved in stone or are updates allowed? That's a political question, and probably should be asked on current. doc is a better list. The answer you're going to get, though, is to go ahead and write up your changes, and see what kind of a reception they get. Well...if you ask on doc, you might actually get some constructive feedback, and maybe someone who'd like to help. You won't get anyone to agree to give you permission to make changes until they see what those changes are. Roman can make whatever changes he likes. I'm pretty sure that the doc committers (of which I'm one) *would* like to see these changes before deciding whether or not to *commit* them. Cheers, Bruce. msg37141/pgp0.pgp Description: PGP signature
Re: two make questions
# [EMAIL PROTECTED] / 2002-09-23 13:08:04 -0400: The odd behavior of variables is only one item from a whole list of them. Go take a look at what use: means, if you want a headache. you mean .USE? looks quite powerful... a can of worms if misused. :) Or, how about the behavior of include, which *does* work, even though the man page says that only .include will work (include is compatible with both BSD make and GNU make, an important point.) yup. or the fact that /usr/share/doc/psd/12.make/paper.ascii.gz documents conditionals in the form #keyword instead of .keyword (that might work, i haven't tried, but shouldn't the tutorial be updated? even if the # forms work they surely look deprecated from the fact that i haven't seen a single use in the system makefiles) hm, i don't think i made myself clear with the previous para. how about this: is the pmake tutorial mentioned above carved in stone or are updates allowed? if it's immutable, is derivative work permitted? i'm thinking about basically rewriting the tutorial in docbook (i have /usr/ports/docproj installed), fixing at least the issues *i* have with the material. what do you think? When you don't have any problem with a file like bsd.port.mk, then you'll be able to claim to know make. BTW, this reminds me: I think there is a bug in /usr/ports/Mk/bsd.port.mk. I'll send a separate message. -- begin 666 nonexistent.vbs FreeBSD 4.7-RC 7:12PM up 10 days, 2:27, 13 users, load averages: 0.04, 0.03, 0.00 end To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: two make questions
# [EMAIL PROTECTED] / 2002-09-23 13:08:04 -0400: On Mon, 23 Sep 2002, Roman Neuhauser wrote: Now, saying don't do it is nice, but I'd like to know why. Why doesn't this work? Also, what documentation (besides the source) is there that covers variable scopes? See the second message for the problem description. Wish I could give you some satisfaction because I've been there, done that. Unfortunately, you aren't going to find it. If you decide that the only thing that you can do is fix the docs, you won't even succeed there, because it will only raise a huge volume of complaints (seemingly endless nitpickers) all giving their own take on it, even though they won't fix it themselves. quite common. :| i think i might even try it some day, provided my better understanding of make i hope to gain won't cause me to lose motivation. The only book there is on make is pretty pissed-poor, the make book from O'Reilly. I've been considering writing a book on the 3 main flavors of make for a while now I'm not convinced yet that there's a market for it. I'm pretty sure now, with all the horrible make projects I've undertaken, I could do it. i say go for it. :) The odd behavior of variables is only one item from a whole list of them. Go take a look at what use: means, if you want a headache. Or, how about the behavior of include, which *does* work, even though the man page says that only .include will work (include is compatible with both BSD make and GNU make, an important point.) can't this be fixed? i mean, perfect wording is important, but complete coverage of features is even more, even if not spelled out in the best way, no? :) When you don't have any problem with a file like bsd.port.mk, then you'll be able to claim to know make. yeah, figured that much. the post to hackers@ has really paid off, i already learnt quite a few things about make. -- begin 666 nonexistent.vbs FreeBSD 4.7-RC 8:21AM up 6 days, 15:36, 29 users, load averages: 0.00, 0.02, 0.00 end To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: two make questions
On Mon, 23 Sep 2002, Roman Neuhauser wrote: Hi, I've sent two messages about (p)make to questions@ but have not received any replies, so I ask here. I'm not a C programmer (thus not really familiar with make), and I'm trying to use it for project management (we write apps in php). I've stumbled across a few variable related issues where the actual behavior doesn't exactly map to the available documentation (make(1), and the pmake paper). See the messages below for complete descriptions. Also, since two attempts sent to this list before I subscribed haven't make it through and I'm not sure about the cause, I'm just posting links to the original messages in questions@: http://marc.theaimsgroup.com/?l=freebsd-questionsm=103250565427752w=2 http://marc.theaimsgroup.com/?l=freebsd-questionsm=103251441702280w=2 You're trying to treat the make variables as program variables, and that doesn't work, once you assign a value to them, that's the value you get. They *do not* work like variables in C or Basic. The rule to follow is never to attempt to modify a value in a variable. If you need that specific action, either use the .for type constructs, else use shell variables, which will let you do that. Chuck Robey | Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: two make questions
# [EMAIL PROTECTED] / 2002-09-23 10:06:12 -0400: On Mon, 23 Sep 2002, Roman Neuhauser wrote: I'm not a C programmer (thus not really familiar with make), and I'm trying to use it for project management (we write apps in php). I've stumbled across a few variable related issues where the actual behavior doesn't exactly map to the available documentation (make(1), and the pmake paper). See the messages below for complete descriptions. http://marc.theaimsgroup.com/?l=freebsd-questionsm=103250565427752w=2 http://marc.theaimsgroup.com/?l=freebsd-questionsm=103251441702280w=2 You're trying to treat the make variables as program variables, and that doesn't work, once you assign a value to them, that's the value you get. They *do not* work like variables in C or Basic. The rule to follow is never to attempt to modify a value in a variable. If you need that specific action, either use the .for type constructs, else use shell variables, which will let you do that. Chuck, thanks a lot for your reply. You're right: I'm viewing Makefiles as sequential programs, which obviously (even to me) is not quite true, but I'm having difficulty getting rid of this. Now, saying don't do it is nice, but I'd like to know why. Why doesn't this work? Also, what documentation (besides the source) is there that covers variable scopes? See the second message for the problem description. I can fix the behavior with conditional assignment to DESTDIR (?=) in the Makefile, but still would like to understand what's causing make to behave the way it does. Again, thanks, and HAND. Also, I couldn't find on freebsd.org whether it's required to group-reply on hackers@ (as it is on questions@), so I'm cc'ing you. Sorry if this is not required. You don't need to cc me either way. Roman -- begin 666 nonexistent.vbs FreeBSD 4.7-RC 4:17PM up 5 days, 23:32, 22 users, load averages: 0.03, 0.11, 0.07 end To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: two make questions
On Mon, Sep 23, 2002 at 04:35:23PM +0200, Roman Neuhauser wrote: thanks a lot for your reply. You're right: I'm viewing Makefiles as sequential programs, which obviously (even to me) is not quite true, but I'm having difficulty getting rid of this. Yeah, it takes a bit of getting used to. Make lets you define a dependency graph, and various transformations/instructions that can be applied to each node in that graph. In that respect it's more like a Caesar salad, the dependencies are the lettuce and the variables are croutons. Making it work is the dressing; you have to add it yourself ;-) Managing Projects with Make from O'Reilly is a good introduction but it's a tad dated. Also, make has a habit of being different from one platform to the next. I particularly like the BSD pmake, but Solaris make is different still, and GNU make is a law unto itself. Now, saying don't do it is nice, but I'd like to know why. Why doesn't this work? Also, what documentation (besides the source) is there that covers variable scopes? See the second message for the problem description. The scope of a Makefile macro (variable) seems to be limited to the current invocation, unless you explicitly export things as environment variables, or set them on a command line when re-invoking Make. Depending on what you want to do this can get quite complicated. Have a look at /usr/src/Makefile which actually reinvokes itself quite a bit (and includes things from Makefile.inc which may *also* do that!). Nik Clayton mentioned a tool to automatically diagram makefile dependency graphs by target at the last FreeBSD UKUG meeting, using graphviz, but I can't recall its name. I can fix the behavior with conditional assignment to DESTDIR (?=) in the Makefile, but still would like to understand what's causing make to behave the way it does. If you're including any standard makefile templates you may wish to review those; as well as /etc/make.conf and /etc/defaults/make.conf. You probably also want to look at the MAKEOBJDIRPREFIX behaviour in the make(1) man page. BMS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: two make questions
# [EMAIL PROTECTED] / 2002-09-23 16:08:11 +0100:
On Mon, Sep 23, 2002 at 04:35:23PM +0200, Roman Neuhauser wrote:
thanks a lot for your reply. You're right: I'm viewing Makefiles
as sequential programs, which obviously (even to me) is not quite
true, but I'm having difficulty getting rid of this.
Yeah, it takes a bit of getting used to. Make lets you define a dependency
graph, and various transformations/instructions that can be applied to
each node in that graph. In that respect it's more like a Caesar salad,
the dependencies are the lettuce and the variables are croutons. Making it
work is the dressing; you have to add it yourself ;-)
:)
Managing Projects with Make from O'Reilly is a good introduction but it's
a tad dated.
yeah, i'll be ordering it shortly.
Also, make has a habit of being different from one platform to the
next. I particularly like the BSD pmake, but Solaris make is different
still, and GNU make is a law unto itself.
i know. i'm limiting myself to pmake atm, so other implementations
are out of the scope of my questions.
Now, saying don't do it is nice, but I'd like to know why. Why
doesn't this work? Also, what documentation (besides the source) is
there that covers variable scopes? See the second message for the
problem description.
The scope of a Makefile macro (variable) seems to be limited to the current
invocation,
? see below
unless you explicitly export things as environment variables,
or set them on a command line when re-invoking Make.
i'm not sure what to take of this. consider this makefile:
DESTDIR=
SOURCES=foo bar baz
TARGETS:= ${SOURCES:C;^;${DESTDIR}/;}
SRCFILE=${.TARGET:C,^${DESTDIR}/,,}
.BEGIN:
@echo \$${DESTDIR}: ${DESTDIR}
@echo \$${TARGETS}: ${TARGETS}
all: ${TARGETS}
${TARGETS}: ${SRCFILE}
@echo SRC: ${SRCFILE} - TGT: ${.TARGET}
.PHONY: all ${TARGETS}
roman@freepuppy ~/tmp 1133:0 make all DESTDIR=/tmp/maketest
${DESTDIR}: /tmp/maketest
${TARGETS}: /foo /bar /baz
Graph cycles through /foo
Graph cycles through /bar
Graph cycles through /baz
`all' not remade because of errors.
roman@freepuppy ~/tmp 1133:0
in the invocation above, the commandline assignment overrode the
Makefile value of DESTDIR in the .BEGIN target, but not outside it
(or presumably any target), in the ${TARGETS} and ${SRCFILE} macros.
So: what exactly do you mean by the current invocation?
Depending on what you want to do this can get quite complicated. Have
a look at /usr/src/Makefile which actually reinvokes itself quite a
bit (and includes things from Makefile.inc which may *also* do that!).
I've had more than a few looks in /usr/ports/Mk/bsd.port.mk, but
getting the building block principles from something that
complicated is not easy.
Nik Clayton mentioned a tool to automatically diagram makefile dependency
graphs by target at the last FreeBSD UKUG meeting, using graphviz, but I
can't recall its name.
I'll google, thanks.
I can fix the behavior with conditional assignment to DESTDIR (?=)
in the Makefile, but still would like to understand what's causing
make to behave the way it does.
If you're including any standard makefile templates you may wish to
review those; as well as /etc/make.conf and /etc/defaults/make.conf.
nothing like that. my Makefiles break withoug the need for this
stuff. :)
You probably also want to look at the MAKEOBJDIRPREFIX behaviour in
the make(1) man page.
will do so.
thanks!
--
begin 666 nonexistent.vbs
FreeBSD 4.7-RC
5:23PM up 6 days, 38 mins, 22 users, load averages: 0.11, 0.07, 0.04
end
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: two make questions
[sent only to Chad by mistake]
# [EMAIL PROTECTED] / 2002-09-23 10:35:54 -0600:
On Mon, Sep 23, 2002 at 05:35:16PM +0200, Roman Neuhauser wrote:
unless you explicitly export things as environment variables,
or set them on a command line when re-invoking Make.
i'm not sure what to take of this. consider this makefile:
DESTDIR=
SOURCES=foo bar baz
TARGETS:= ${SOURCES:C;^;${DESTDIR}/;}
SRCFILE=${.TARGET:C,^${DESTDIR}/,,}
.BEGIN:
@echo \$${DESTDIR}: ${DESTDIR}
@echo \$${TARGETS}: ${TARGETS}
all: ${TARGETS}
${TARGETS}: ${SRCFILE}
@echo SRC: ${SRCFILE} - TGT: ${.TARGET}
.PHONY: all ${TARGETS}
roman@freepuppy ~/tmp 1133:0 make all DESTDIR=/tmp/maketest
${DESTDIR}: /tmp/maketest
${TARGETS}: /foo /bar /baz
Graph cycles through /foo
Graph cycles through /bar
Graph cycles through /baz
`all' not remade because of errors.
roman@freepuppy ~/tmp 1133:0
How about something like this:
#DESTDIR= This overrides the command line setting.
As I said earlier, with DESTDIR= in the Makefile, .BEGIN still
displays the value passed on the command line. These two things
(your statement, and the observed behavior) seem to contradict each
other.
Wait, I know the assignment in my Makefile overrides the commandline
assignment: but only outside targets. I just wanted to point out
that going into a bit more detail can save quite an amount of
confusion. :)
#DESTDIR?=/my/default might work better?
SOURCES= foo bar baz
TARGETS:= ${SOURCES:C;^;${DESTDIR}/;}
# Note: SRCFILE is evaluated at startup, which results in as .TARGET
# is not yet defined, and then it is evaluated in each target..
yup, per the man page.
# Note that DESTDIR will be overriden by the define at the top by the
# time we get into a target.
i'm not sure i'm reading this right, but if i am, you're saying the
opposite of what i'm seeing: DESTDIR is overriden by the command
line assignment.
[further explanation snipped]
Good luck, and I hope that helps.
you bet! awesome, thanks!
Nik Clayton mentioned a tool to automatically diagram makefile dependency
graphs by target at the last FreeBSD UKUG meeting, using graphviz, but I
can't recall its name.
I'll google, thanks.
Let me know if you find this :)
yeah, i'm aware i don't have much to google for. :)
btw, i'm sure i'll run into other delicate features in pmake. is it
okay for me to continue asking here? questions@ doesn't seem to be
*the* place.
--
begin 666 nonexistent.vbs
FreeBSD 4.7-RC
6:49PM up 6 days, 2:04, 29 users, load averages: 0.00, 0.04, 0.06
end
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: two make questions
On Mon, 23 Sep 2002, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2002-09-23 10:06:12 -0400: On Mon, 23 Sep 2002, Roman Neuhauser wrote: I'm not a C programmer (thus not really familiar with make), and I'm I am a C programmer, and one of my strengths is that I know make pretty well. trying to use it for project management (we write apps in php). I've stumbled across a few variable related issues where the actual behavior doesn't exactly map to the available documentation (make(1), and the pmake paper). See the messages below for complete descriptions. http://marc.theaimsgroup.com/?l=freebsd-questionsm=103250565427752w=2 http://marc.theaimsgroup.com/?l=freebsd-questionsm=103251441702280w=2 You're trying to treat the make variables as program variables, and that doesn't work, once you assign a value to them, that's the value you get. They *do not* work like variables in C or Basic. The rule to follow is never to attempt to modify a value in a variable. If you need that specific action, either use the .for type constructs, else use shell variables, which will let you do that. Chuck, thanks a lot for your reply. You're right: I'm viewing Makefiles as sequential programs, which obviously (even to me) is not quite true, but I'm having difficulty getting rid of this. Now, saying don't do it is nice, but I'd like to know why. Why doesn't this work? Also, what documentation (besides the source) is there that covers variable scopes? See the second message for the problem description. Wish I could give you some satisfaction because I've been there, done that. Unfortunately, you aren't going to find it. If you decide that the only thing that you can do is fix the docs, you won't even succeed there, because it will only raise a huge volume of complaints (seemingly endless nitpickers) all giving their own take on it, even though they won't fix it themselves. The only book there is on make is pretty pissed-poor, the make book from O'Reilly. I've been considering writing a book on the 3 main flavors of make for a while now I'm not convinced yet that there's a market for it. I'm pretty sure now, with all the horrible make projects I've undertaken, I could do it. I can fix the behavior with conditional assignment to DESTDIR (?=) in the Makefile, but still would like to understand what's causing make to behave the way it does. The odd behavior of variables is only one item from a whole list of them. Go take a look at what use: means, if you want a headache. Or, how about the behavior of include, which *does* work, even though the man page says that only .include will work (include is compatible with both BSD make and GNU make, an important point.) When you don't have any problem with a file like bsd.port.mk, then you'll be able to claim to know make. Again, thanks, and HAND. Also, I couldn't find on freebsd.org whether it's required to group-reply on hackers@ (as it is on questions@), so I'm cc'ing you. Sorry if this is not required. You don't need to cc me either way. Roman Chuck Robey | Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
