bugmake - Bugs: bug #63840, make allows match-anything rules...

 
 

bug #63840: make allows match-anything rules to match files with the default suffixes

Submitter:  Dmitry Goncharov <dgoncharov>
Submitted:  Sun 26 Feb 2023 07:59:52 PM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  None Privacy:  Public
Assigned to:  None Open/Closed:  Open
Component Version:  4.4 Operating System:  None
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 11 Feb 2024 04:17:14 AM UTC, comment #5: 


> Sorry for the delay in examining this bug.


Thank you for looking at this.

...

> However, I tend to agree with you that this is perhaps too much "inside baseball" for the default behavior.


i also think, this is too much to be useful. E.g. in your example should not .SUFFIXES: also list .h?

> I think you are mostly correct in your determination of the problem with one exception: when the .SUFFIXES list is cleared explicitly, then we should not create any dummy pattern rules and thus these match-anything rules SHOULD be matched.


Well, this bug report (and the attached patch) was only intended to ensure that when -r is specified, match-anything rule are not eligible for .c, .h, etc files.

For the reasons presented in comment 3, i like the current behavior, that when .SUFFIXES is cleared, then match-anything rules are still not eligible for .c, .h, etc files. i feel, this behavior is more suitable for match-anything rules. In the end, match-anything rules were created to build binaries which have no suffixes (like 'cp'), not .c files. Maybe we can update the manual to say that match-anything rules do not build files with built-in list of known suffixes, whether .SUFFIXES is cleared or not?



> What we should probably do is not clear the .SUFFIXES list by default when -r is given, but instead simply not create the default rules associated with those suffixes.


Would not that contradict the manual?
E.g. if the makefile contains


.c.o:
        $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<


and -r is specified, then make should take '.c.o' as a target name, rather than as a suffix rule.
If .SUFFIXES is not cleared, then will make take '.c.o' as a target name or as a suffix rule?

> I have a simple patch that does that; if you agree that's OK I'll push it along with your tests.


i'd need to see the patch to comment. Do you think you can post the patch?

Dmitry Goncharov <dgoncharov>
Sat 10 Feb 2024 07:46:35 PM UTC, comment #4: 

Sorry for the delay in examining this bug.  I understand what you are saying.  A counter-argument would be that if you wanted to use "-r" and also provide match-anything rules, that you should also be assigning proper suffixes via ".SUFFIXES" to ensure that your source files are handled properly:

hello.c:
%: %.o; $(info $@ from $<)

# this should be added since you have a match-anything rule
.SUFFIXES: .c


However, I tend to agree with you that this is perhaps too much "inside baseball" for the default behavior.
I think you are mostly correct in your determination of the problem with one exception: when the .SUFFIXES list is cleared explicitly, then we should not create any dummy pattern rules and thus these match-anything rules SHOULD be matched.

What we should probably do is not clear the .SUFFIXES list by default when -r is given, but instead simply not create the default rules associated with those suffixes.

I have a simple patch that does that; if you agree that's OK I'll push it along with your tests.

Paul D. Smith <psmith>
Group administrator
Mon 27 Feb 2023 03:18:22 AM UTC, comment #3: 


> If you use -r then you've removed all the implicit rules in the makefile, including suffix rules, and so I don't necessarily agree with the idea that even in this case we should still treat these suffixes as special when considering match-anything rules.   

                                                                                                                                 
My opinion is that, removal of the built-in rules is all about relieving make from doing extra work.  This helps performance, troubleshooting and reduces -d output. imo, the current behavior, when -r causes match-anything rules to be eligible does the opposite of -r should do, which is it increases the amount of work, rather then reduces it. i also think, presence or absence of built-in rules, including suffix rules, is orthogonal to whether match-anything rules are eligible for files with specific data.                                   
                                                                                                                                 
Looks like i did not convey it well enough in the original description. It is removal of the built-in rules that causes match-anything rules to be eligible. It is not clearing of the default suffixes that causes this behavior. If you clear the list of the default suffixes, match-anything rules are still not eligible for the files with the (now cleared) default suffixes.                 
                                                                                                                                 
Example 5                                                                                                                        
                                                                                                                                 

$ ls
hello.c.o  makefile
$ cat makefile
.SUFFIXES:
hello.c:
%: %.o; $(info $@ from $<)
$ make-4.4
make-4.4: Nothing to be done for 'hello.c'.


Dmitry Goncharov <dgoncharov>
Sun 26 Feb 2023 09:15:33 PM UTC, comment #2: 

I'm not sure I get the change suggested.  If you use -r then you've removed all the implicit rules in the makefile, including suffix rules, and so I don't necessarily agree with the idea that even in this case we should still treat these suffixes as special when considering match-anything rules.

There do seem to be some bizarre behaviors here which need to be understood but I'm not sure the right answer is as simple as, "never consider match-anything rules for targets with the default suffix list even if -r is provided".

But maybe I didn't fully understand the issue being reported.

Paul D. Smith <psmith>
Group administrator
Sun 26 Feb 2023 08:05:16 PM UTC, comment #1: 

When the built-in rules are disabled, make allows match-anything rules to match files with the default suffixes.

Example 1 demonstrates how a match-anything pattern rule incorrectly matches a file with the default suffix when the built-in rules are disabled.


$ ls
hello.c.o  makefile
$ cat makefile
hello.c:
%: %.o; $(info $@ from $<)
$ make-4.4
make-4.4: Nothing to be done for 'hello.c'.
$ make-4.4 -r
hello.c from hello.c.o
make-4.4: 'hello.c' is up to date.



Example 2 demonstrates how a match-anything pattern rule incorrectly matches a file with a user defined suffix when the built-in rules are disabled.


$ ls
hello.c.x  makefile
$ cat makefile
hello.c:
%: %.x; $(info $@ from $<)
$ make-4.4
make-4.4: Nothing to be done for 'hello.c'.
$ make-4.4 -r
hello.c from hello.c.x
make-4.4: 'hello.c' is up to date.



Example 3 demonstrates how a single suffix rule incorrectly matches a file with the default suffix when the built-in rules are disabled.


$ ls
hello.c.o  makefile
$ cat makefile
.SUFFIXES:
.SUFFIXES: .o
hello.c:
.o:; $(info $@ from $<)
$ make-4.4
make-4.4: Nothing to be done for 'hello.c'.
$ make-4.4 -r
hello.c from hello.c.o
make-4.4: 'hello.c' is up to date.


Example 4 demonstrates how a single suffix rule incorrectly matches a file with a user defined suffix when the built-in rules are disabled.


$ ls
hello.c.x  makefile
$ cat makefile
.SUFFIXES:
.SUFFIXES: .x
hello.c:
.x:; $(info $@ from $<)
$ make-4.4
make-4.4: Nothing to be done for 'hello.c'.
$ make-4.4 -r
hello.c from hello.c.x
make-4.4: 'hello.c' is up to date.



When built-in rules are enabled, the default suffixes are entered as files on startup and then converted to dummy pattern rules. These dummy pattern rules prevent match-anything rules from matching files with the default suffixes.
When built-in rules are disabled, the default suffixes are not entered as files and not converted to dummy pattern rules. Because the dummy rules are missing make fails to recognize files with the default suffixes.

This patch enters the default suffixes as files whether built-in rules are enabled or not.



Dmitry Goncharov <dgoncharov>
Sun 26 Feb 2023 07:59:52 PM UTC, original submission:  

.

Dmitry Goncharov <dgoncharov>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #54396:  sv63840_fix.diff added by dgoncharov (7KiB - text/x-patch)
file #54397:  sv63840_test.diff added by dgoncharov (10KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Updated the item)
  • -email is unavailable- added by dgoncharov (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-02-26 psmith Component Version4.4.1 4.4
    2023-02-26 dgoncharov Attached File- Added sv63840_fix.diff, #54396
        Attached File- Added sv63840_test.diff, #54397

    Back to the top

    Powered by Savane 3.13-c373.
    Corresponding source code