Re: Help required in gnumake

[Greg Chicares]

"Paul D. Smith" wrote:

ps> %% beginner beginner <address@hidden> writes:
ps> 
ps>   bb>       But as mentioned by [gc] wtiting the same as
ps>   bb> ifneq ($(DEF_OBJDIR),$(OBJDIR_UNOPT))
ps>   >>> ifneq ($(MCC_FLAGS),)
ps>   >>>       @echo test
ps>   >>>       DEF_CC_FLAGS=$(MCC_FLAGS)
ps>   >>> @echo Test1
ps> 
ps>   bb> i.e. putting tab in front of DEF_CC_FLAGS then we will not get any
ps>   bb> error but I am getting a strange error.

[previous context, desnipped from my original reply]
gc> This line
gc>   DEF_CC_FLAGS=def
gc> is a shell command that sets an environment variable.

ps> By putting a TAB in front of the DEF_OBJDIR=..\obj (btw, you should try
ps> to use only forward-slashes in makefiles: this works with virtually
ps> every Windows command as well), you have changed it from a line
ps> interpreted by make (the setting of a make variable DEF_OBJDIR) to a
ps> part of the command script, and thus a line passed to the shell.

Yes, we're saying the same thing, though the context
got lost somewhere in the snipping. Similarly:

[previous context, desnipped]
gc> But make reads environment variables when it starts
gc> up, so this shell command doesn't affect the variable's
gc> value in this rule, which is empty by default:

ps> If you were on a UNIX system, this would cause a shell variable
ps> DEF_OBJDIR to be set and then the shell would exit, which would lose the
ps> setting... so this is basically a no-op.  I'm not sure why Greg
ps> suggested it since it's not really useful.

I rewrote bb's makefile to make it syntactically
valid, just to illustrate this underlying problem...
then gave a semantically valid alternative that
moved all conditional variable assignment before
the target definition, in accordance with:

ps> In short there is _NO WAY_ to intersperse make variable settings in the
ps> middle of a command script the way you were doing [1].  You will have to
ps> move them all to before or after the target definition.