-
-
Notifications
You must be signed in to change notification settings - Fork 73
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
GNU Make 4.1+dbg1.1: recipe with "make -f " got unexpected result #22
Comments
I downloaded the make source via apt-get and patch it, I added some debug info.
This is my patch --- make-dfsg-4.0.orig/main.c 2013-10-09 12:22:40.000000000 +0800
+++ make-dfsg-4.0/main.c 2015-07-21 09:48:48.195562772 +0800
@@ -153,7 +153,7 @@ int just_print_flag;
static struct stringlist *db_flags = 0;
static int debug_flag = 0;
-int db_level = 0;
+int db_level = DB_BASIC;
/* Synchronize output (--output-sync). */
@@ -688,7 +688,7 @@ expand_command_line_file (char *name)
static RETSIGTYPE
debug_signal_handler (int sig UNUSED)
{
- db_level = db_level ? DB_NONE : DB_BASIC;
+ db_level = db_level ? DB_BASIC : DB_BASIC;
}
#endif
@@ -746,6 +746,7 @@ decode_debug_flags (void)
}
}
+ db_level = DB_BASIC;
if (db_level)
verify_flag = 1;
@@ -1052,6 +1053,12 @@ main (int argc, char **argv, char **envp
PATH_VAR (current_directory);
unsigned int restarts = 0;
unsigned int syncing = 0;
+ printf("argc = %d\n", argc);
+ int ii = 0;
+ for (ii = 0; ii < argc ; ii++) {
+ printf("argv[%d] = %s\n", ii, argv[ii]);
+ }
+
#ifdef WINDOWS32
char *unix_path = NULL;
char *windows32_path = NULL;
@@ -2146,6 +2153,7 @@ main (int argc, char **argv, char **envp
if (! ISDB (DB_MAKEFILES))
db_level = DB_NONE;
+ printf("Galen: Updating makefiles....\n");
DB (DB_BASIC, (_("Updating makefiles....\n")));
/* Remove any makefiles we don't want to try to update.
@@ -2294,8 +2302,10 @@ main (int argc, char **argv, char **envp
remove_intermediates (0);
- if (print_data_base_flag)
- print_data_base ();
+ if (print_data_base_flag) {
+ printf("main(), print_data_base\n");
+ print_data_base ();
+ }
clean_jobserver (0);
@@ -2552,7 +2562,7 @@ main (int argc, char **argv, char **envp
/* Exit. */
die (makefile_status);
}
-
+ printf("exit................\n");
/* NOTREACHED */
exit (0);
}
@@ -2739,6 +2749,10 @@ decode_switches (int argc, char **argv,
register const struct command_switch *cs;
register struct stringlist *sl;
register int c;
+ int ii = 0;
+ for (ii = 0; ii < argc ; ii++) {
+ printf("argv[%d] = %s\n", ii, argv[ii]);
+ }
/* getopt does most of the parsing for us.
First, get its vectors set up. */
@@ -3405,8 +3419,11 @@ die (int status)
/* Remove the intermediate files. */
remove_intermediates (0);
- if (print_data_base_flag)
- print_data_base ();
+ printf("print_data_base_flag = %d\n", print_data_base_flag);
+ if (print_data_base_flag) {
+ printf("%s(), %d, print_data_base......\n", __FUNCTION__, __LINE__);
+ print_data_base ();
+ }
if (verify_flag)
verify_file_data_base ();
and I test remake 4.1 and remake 3.82. remake 4.1
remake 3.82
I found the difference:in function: decode_switches (int argc, char **argv, int env) remake 4.1 pass "argv[1] = -eiprtw" $ man make
|
From my first log, we also can see, remake pass it through evnironment MAKEFLAGS and MFLAGS
|
cat Makefile
cat Makefile1.mk
The MAKEFLAGS and MFLAGS of Make4.1+dbg1.1 is different form Make 3.82+dbg0.9 Make 4.1+dbg1.1
Make 3.82+dgb0.9
|
This is my gdb debug backtrace:
in function decode_switches(), it will call getopt_long to parse argv, "-Xpreaction" options is
Finally, Xpreaction will be parsed as :
"preti" will be sorted as "eiprt", "w" will append to it. it will be "eiprtw". now, do you know where eiprtw is from?
|
Thanks for investigating and reporting the problem. I will look at in more detail when I get a chance. The bug is that the weird behavior of the -X flag isn't deparsed correctly. |
I think commit 6ee1f82 now handles this properly. But please double check. Down the line, for all of these commits, I need to turn your examples into test code which get run along with the other tests. But that's another issue. |
Yes, this issue is resolved, but I think the commit will cause other issue, not compatible previous behavior. After I apply the commit, the MAKEFLAGS, MFLAGS will be --debuggerpreaction, I think it isn't right compare with the behavior of remake 3.82-dgb0.9
The behavior of remake 3.82-dgb0.9 is below:
MAKEFLAGS = X (without '-') pass environments MAKEFLAGS = X and MFLAGS = -X to child process $(MAKE), will cause child process remake enter debug mode, pass them to gnu make, gnu make can't recognize -X, and will ignore it. The form like below will cause child remake enter debug mode
The form like below, gnu make will ignore -X option.
so this commit 6ee1f82 will cause all $(MAKE) won't enter debug mode. Example: Our project will build many third-party libraris, pass -X to child $(MAKE) will cause
I found "setq MAKEFLAGS", "setq MFLAGS" can avoid child $(MAKE) to enter debug mode. but this need type many characters, can you add an another option in "set OPTION {on|off|toggle}" for this purpose?
|
In commit dbcc5de -X or --debugger are now short options only, and newly added You have a couple of misconceptions. If you have a Makefile: all:
make You are supposed to get whatever make resolves to. That's the way GNU make works and that what's supposed to happen. For example, you could have a It is common that inside a makefile you'll want to recursively run the same make program that was used as was used to invoke the makefile. What you are supposed to do is invoke with Lastly, I'll say that while compatibility is a good thing and generally desirably, it is and will sometimes be broken. make 3.82 isn't totally compatible with make 4.1 or else it would be the same thing as 3.82. I am not sure it is totally upward compatible either. Incompatibilities between make 3.82 and make 4.1 will be reflected in incompatibilities between remake 3.82 and remake 4.1. Specifically the behavior of |
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. Since that' a separate issue, I'm going to open that as a separate issue. Bugs which wander all over the place aren't helpful to others. And already I find most of what's written here a little difficult to follow. So unless the original problem, and only that one, isn't addressed, let's close this. |
I agree with you, this issue is fixed and should be close. Thanks, rocky. |
(Thanks - it's good to get confirmation.) |
* commit '1f7602b54d707d971245a2aea08e86715911dbf1^': Reinstate manpage. Document --target option Add install from source instructions and... Try using travis container architecture One more target comment Save and show breakoint mask Remove remnant of future REMAKEFLAGS Remove stray debug print Proof of concept for issue #25. It does this by setting MAKEFILE rather than REMAKEFILE though. Set long name in options string for -X or --debugger Can't support -X=... form. So split out into -X (--debugger) and --debugger-stop. In parsing options to set MAKEFLAGS, don't treat -X as short option. Github issue #22 debugger quit command was not leaving recursive make. Issue #24 Initialize global_argv; github issue #23 Fix expand option of debugger "target" command Github issue #21 GNU Make bug in enumeration values?
GNU Make 4.1+dbg1.1: recipe with "make -f " got unexpected result
but GNU Make 3.82+dbg0.9 works fine.
Test GNU Make 4.1+dbg1.1
ls
cat Makefile1.mk
cat Makefile2.mk
remake -X -f Makefile2.mk
ls
Here, We got file: all
Test GNU Make 3.82+dbg0.9
ls
cat Makefile1.mk
cat Makefile2.mk
remake -X -f Makefile2.mk
The text was updated successfully, but these errors were encountered: