"next" (step over) and "finish" (step out) and "continue) should not cause recursive make to stop

[rocky]

The debugger command, "step" should cause a recursive invocation of make to stop in the recursion. The debugger commands "next", "finish" and "continue" should not.

Gist https://gist.github.com/rocky/2bf8ee0000a1efd53929
has a sample Makefile that can be used to test this. Files that would probably change are step.h, next.h, continue.h, and finish.h in folder debugger/command/, Possibly the routine that sets up the GNUMAKEFLAGS environment variable could be common.

What I think is needed is to change "step", "next", "continue", "finish" to set GNUMAKEFLAGS to include "X" as appropriate.

[liugang]

Here is what I think is the more natural gdb-like way to address at least part of this. "step" is what is generally called "step into" while "next" is generally called "step over". So "step" should cause debugging into a recursive make, while "step over" should not.

That's a good idea. We are expecting this feature. Thanks Rocky!

[liugang]

remake-4.1+dbg1.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.

...  line 112

* 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 "- ".

remake-4.1+dbg1.1/NEWS +1068
====> Version 3.45

* The `-j' switch is now put in the MAKEFLAGS and MFLAGS variables when
  specified without an argument (indicating infinite jobs).
  The `-l' switch is not always put in the MAKEFLAGS and MFLAGS variables.

remake-4.1+dbg1.1/NEWS +1214
====> Version 3.12.

* The `MAKEFLAGS' and `MFLAGS' variables will be scanned for options after
  makefiles are read.

MFLAGS seems not used in last code

It may be just used to keep compatibility.
gnu make will always define it. so user can use it in their Makefile.
But gnu make won't parsed MFLAGS as options internal.
gnu make only parse MAKEFLAGS as options, because MAKEFLAGS and MFLAGS has some value.

remake-4.1+dbg1.1/main.c +1367

#if 0
  /* People write things like:
        MFLAGS="CC=gcc -pipe" "CFLAGS=-g"
     and we set the -p, -i and -e switches.  Doesn't seem quite right.  */
  decode_env_switches (STRING_SIZE_TUPLE ("MFLAGS"));
#endif

remake-4.1+dbg1.1/main.c +1972

#if 0
    decode_env_switches (STRING_SIZE_TUPLE ("MFLAGS"));
#endif

[rocky]

Please, let's keep each issue to one topic. If you have observations you want to report, please sent them to the remake mailing list which has more people looking at this and is more suitable.

The longer and more rambling the issues are, the more likely you are going to loose my attention.

Which brings me to the back to this issue:

We are expecting this feature.

I hope you are very patient (and young). I just started a new job and in the foreseeable future, I'm not going to time to work on this project. I wrote what I thought should be done so that others might be able to chip in. Or if in sometime in the future I need to come back to this, I'll have notes of where to start.

This project has for a while far exceeded my needs. If it doesn't meet yours, then you should get involved by working on it. I'll help others who make serious effort.

[liugang]

I think, you can release next version, because it is stable enough.:thumbsup:

We are both can start a new job, or work on other tasks.

For this "Wish list", it isn't easy to implement it, after I debug it.:disappointed:

for "next " command:

• remake executes next target;
• gdb executes one line, don't step in function.

for "step" command:

• remake executes one line of the target;
• gdb will step in a function.

We are discussing the "recursive make"
I think we can use the method in gdb: "set follow-fork-mode "

e.g.

• "set follow-fork-mode parent" don't cause recursive make to stop
• "set follow-fork-mode child" cause recursive make to stop

Tomorrow is our first day of a week, I have to work on my project, it is urgent, so I have less time on remake.

Sorry for my poor English, I have to query dictionary some times 😂 .

[rocky]

I didn't know about gdb's follow-fork-mode; that is an interesting idea. The whole command parsing in remake would need to be (and should be) redone. For now it's simpler to use "next", and in the future change that.

I start a new job tomorrow too. No need to apologize for your English. It is more about figuring out an way that we can communicate. And you are doing all of the work here, so I am grateful for that.