buggy interaction between MAKEFLAGS += rR and CC ?= my_gcc

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

buggy interaction between MAKEFLAGS += rR and CC ?= my_gcc

Britton Kerin
MAKEFLAGS += rR still doesn't work as expected:

     $ cat Makefile

     MAKEFLAGS += rR

     CC ?= my_gcc

     debug:
             @echo 'origin of CC:' $(origin CC)
             @echo 'value of CC: ' $(CC)

     %.o: %.c
             $(CC) $< -o $@
     $ touch test.c
     $ make test.o
     test.c -o test.o
     make: test.c: Command not found
     make: *** [Makefile:11: test.o] Error 127
     $ make debug
     origin of CC: undefined
     value of CC:
     $ make -rR debug
     origin of CC: file
     value of CC:  my_gcc
     $ make -rR test.o
     my_gcc test.c -o test.o
     make: my_gcc: Command not found
     make: *** [Makefile:11: test.o] Error 127
     $

So although injecting rR into MAKEFLAGS does have an effect (CC etc. end up
undefined), it doesn't seem to happen in time to have the expected results
on e.g. subsequent conditional assignment.  In the above example, at the
time the conditional assignment happens, Make still considers CC to have
origin default, as can be seen by adding a line like:

      $(info origin of CC: $(origin CC))

 immediately above the conditional assignment line.

If assignment into MAKEFLAGS is going to be supported at all, it should
have exactly the effect that the corresponding command line options have.
In this case, that means CC etc. should be undefined (as with the undefine
directive) from the point rR is injected, not just empty with origin default.
So if when MAKEFLAGS += rR happens and CC has origin default, it should be
undefined.  It it's origin is file or command line or something it should be
left alone.

Britton

_______________________________________________
Help-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-make
Reply | Threaded
Open this post in threaded view
|

Re: buggy interaction between MAKEFLAGS += rR and CC ?= my_gcc

Paul Smith-20
On Thu, 2016-08-25 at 11:27 -0800, Britton Kerin wrote:
> If assignment into MAKEFLAGS is going to be supported at all, it
> should have exactly the effect that the corresponding command line
> options have. In this case, that means CC etc. should be undefined
> (as with the undefine directive) from the point rR is injected, not
> just empty with origin default.

GNU make only reparses the MAKEFLAGS variable after all makefiles have
been read in.

It doesn't re-parse MAKEFLAGS every time MAKEFLAGS is changed anywhere
in the makefile.

_______________________________________________
Help-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-make
Reply | Threaded
Open this post in threaded view
|

Re: buggy interaction between MAKEFLAGS += rR and CC ?= my_gcc

Paul Smith-20
Please be sure to keep the mailing list in the loop, thanks!

On Thu, 2016-08-25 at 11:55 -0800, Britton Kerin wrote:
> It should explicitly mention that setting it in a makefile won't set
> flags for that instance.

It does set them for that instance, just not until after all the
makefiles have been parsed.  So the new flags take effect after the
makefiles have been parsed and before make starts trying to build
targets.

As far as I know it should be possible to do any combination of things
that you want with the current behavior.  It will be more ugly than
using a simple ?= (for example) but it will be less ugly than testing
for command line flags and failing if they're not provided.

For example this:

  MAKEFLAGS += -rR

  CC ?= my_gcc

says, as far as I can tell, "use the user's version of CC from either
the command line or the environment, or if that's not set then use
my_gcc", which can be written like this:

  # In case you wanted it for other reasons...
  MAKEFLAGS += -rR

  ifneq (,$(filter default undefined,$(origin CC)))
  CC = my_gcc
  endif

You can turn this into a macro and use call or eval if you have a lot
of these.

_______________________________________________
Help-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-make
Reply | Threaded
Open this post in threaded view
|

Re: buggy interaction between MAKEFLAGS += rR and CC ?= my_gcc

Britton Kerin
On Fri, Aug 26, 2016 at 7:37 AM, Paul Smith <[hidden email]> wrote:

> Please be sure to keep the mailing list in the loop, thanks!
>
> On Thu, 2016-08-25 at 11:55 -0800, Britton Kerin wrote:
>> It should explicitly mention that setting it in a makefile won't set
>> flags for that instance.
>
> It does set them for that instance, just not until after all the
> makefiles have been parsed.  So the new flags take effect after the
> makefiles have been parsed and before make starts trying to build
> targets.

Yes, but for options like -rR that isn't good enough, since they have an
effect during the parse pass.  This means setting MAKEFLAGS in the
environment vs in the Makefile has a significantly different effect.
Perhaps this paragraph:

     The flags given to make. You can set this in the environment or a
     makefile to set flags.  See Communicating Options to a Sub-make.

could be rewritten:

     The flags given to make.You can set this in the environment or a
     makefile.  Be aware that in the latter case, the option setting won't
     take effect until the end of parse pass.  See ...

> As far as I know it should be possible to do any combination of things
> that you want with the current behavior.  It will be more ugly than
> using a simple ?= (for example) but it will be less ugly than testing
> for command line flags and failing if they're not provided.
>
> For example this:
>
>   MAKEFLAGS += -rR
>
>   CC ?= my_gcc
>
> says, as far as I can tell, "use the user's version of CC from either
> the command line or the environment, or if that's not set then use

That's not what it ends up doing though (I guess from what you
write below that you know that).

> my_gcc", which can be written like this:
>
>   # In case you wanted it for other reasons...
>   MAKEFLAGS += -rR
>
>   ifneq (,$(filter default undefined,$(origin CC)))
>   CC = my_gcc
>   endif
>
> You can turn this into a macro and use call or eval if you have a lot
> of these.

True.  It would be nice if there were some way to get the behavior of
-rR without those more complicated techniques, however.

The root of the problem is that the functionality of -rR *should* be a
per-Makefile thing, not a per-make-invocation thing.  A given
make file is either written to want the built-in rules, or not.  I suspect
that it's on command line because directives don't modify parsing
behavior in time either.  I took a quick look at the directive list and
didn't notice any that seemed like they would.

Britton

_______________________________________________
Help-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-make