Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remake should set REMAKEFLAGS (for -X and -x) and not MAKEFLAGS #26

Open
rocky opened this issue Jul 24, 2015 · 5 comments
Open

remake should set REMAKEFLAGS (for -X and -x) and not MAKEFLAGS #26

rocky opened this issue Jul 24, 2015 · 5 comments

Comments

@rocky
Copy link
Owner

rocky commented Jul 24, 2015

From make-4.1/NEWS +102

====> Version 4.0 (09 Oct 2013)

  • New variable: $(GNUMAKEFLAGS) will be parsed for make flags, just like
    MAKEFLAGS is. It can be set in the environment or the makefile, containing
    GNU make-specific flags to allow your makefile to be portable to other
    versions of make. Once this variable is parsed, GNU make will set it to the
    empty string so that flags will not be duplicated on recursion.

...

Behavior of MAKEFLAGS and MFLAGS is more rigorously defined. All simple
flags are grouped together in the first word of MAKEFLAGS. No options that
accept arguments appear in the first word. If no simple flags are present
MAKEFLAGS begins with a space. Flags with both short and long versions
always use the short versions in MAKEFLAGS. Flags are listed in
alphabetical order using ASCII ordering. MFLAGS never begins with "- ".

Given this, when -X or --debugger is parsed, that value should not be set in MAKEFLAGS or MFLAGS.

And as with issue #25, debugger commands, "step", "next", "finish" and "continue" would modify the REMAKEFLAGS environment variable.

@liugang
Copy link

liugang commented Jul 25, 2015

Maybe use MAKEFLAGS is fine, gnu make pass MAKEFLAGS to sub process, and always keep the values, but GNUMAKEFLAGS will be setted to empty "".

if we want to remove X from MAKEFLAGS, we need to do this work after "fork", before run execvp

Am I right?

  /* Decode the switches.  */
  decode_env_switches (STRING_SIZE_TUPLE ("GNUMAKEFLAGS"));

  /* Clear GNUMAKEFLAGS to avoid duplication.  */
  define_variable_cname ("GNUMAKEFLAGS", "", o_env, 0);
/* The table of command switches.
   Order matters here: this is the order MAKEFLAGS will be constructed.
   So be sure all simple flags (single char, no argument) come first.  */

static const struct command_switch switches[] =

@rocky
Copy link
Owner Author

rocky commented Jul 25, 2015

Am I right?

I think so. But I have a hard time understanding you. (I fully realize English is probably not your native language and your understanding of English is phenomenal compared to my knowledge of Chinese.)

If you go back to commit 6ee1f82 you'll see I stripped out the X option, and that now should probably get put back in. I think that should stay as is and not, say, extend to also remove the "x" option (another remake addition) since that would cause tracing into a recursive make to stop working.

In the "step" function, I think you can just add:

define_variable_cname ("GNUMAKEFLAGS", "X", o_env, 0);

to that function. With these changes though, I don't think you'll have to make any changes between the fork() and execvp() in file job.c.

@rocky
Copy link
Owner Author

rocky commented Jul 25, 2015

If you do work on this and make a pull request, see what I wrote about a "topic" branch. Do this on you repo in a separate branch (e.g. issue26) and then make the pull request to the corresponding name here, which should be something other than "master".

@rocky rocky changed the title remake should set GNUMAKEFLAGS (for -X and -x) and not MAKEFLAGS remake should set REMAKEFLAGS (for -X and -x) and not MAKEFLAGS Jul 27, 2015
@rocky
Copy link
Owner Author

rocky commented Jul 27, 2015

Commit 9eddd02 does sort of what I was describing in the previous two comments. However I couldn't get this to work by setting a new variable REMAKEFLAGS which would work analogously to MAKEFLAGS, so I co-opted MAKEFLAGS which is wrong and will mess up whatever values others have put into it.

But the interesting part is that with those changes, "step" will debug into a Makefile, while "next", "finish", and "continue" don't.

Also note that I don't ask you to do anything that I wouldn't do for myself. That is why this is in git branch "GNUMAKEFLAGS-step" rather than "master".

@vicshen
Copy link

vicshen commented Feb 9, 2020

I find a problem when -X is used. The variable is not passed correctly in sub-make invocation.
Is it same one in this issue?

Makefile:
SYS = 1

a1 :
echo "SYS in a1: ${SYS}"
$(MAKE) a2

a2 :
echo "SYS in a2: ${SYS}"

remake without "-X" is correct. (version: 4.2.1+dbg-1.4)
% remake SYS=2 a1
echo "SYS in a1: 2"
SYS in a1: 2
/home/jianshen/install/remake-4.2/bin/remake a2
remake[1]: Entering directory '/tmp/t1'
echo "SYS in a2: 2"
SYS in a2: 2
remake[1]: Leaving directory '/tmp/t1'

remake with "-X" is not correct. (SYS in a2 should be 2)
% remake -X SYS=2 a1
Reading makefiles...
Updating makefiles...
Updating goal targets...
-> (/tmp/t1/Makefile:3)
a1:
remake<0> c
echo "SYS in a1: 2"
SYS in a1: 2
/home/jianshen/install/remake-4.2/bin/remake a2
remake[1]: Entering directory '/tmp/t1'
echo "SYS in a2: 1"
SYS in a2: 1
remake[1]: Leaving directory '/tmp/t1'

Old version 3.82+dbg0.9 is fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants