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

[Dmitry Goncharov]

Follow-up Comment #5, bug#63840 (group make):


> 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?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64806] "invalid output sync mutex" on windows

[Eli Zaretskii]

Follow-up Comment #34, bug#64806 (group make):

That weird problem is with a particular build of Windows port of GNU Make, and
it is not clear to me on what OS the error was seem.

But yes, it sounds like it's a separate issue.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[Paul D. Smith]

Follow-up Comment #4, bug#63840 (group make):

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.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64806] "invalid output sync mutex" on windows

[Gergely Pinter]

Follow-up Comment #33, bug#64806 (group make):

The original problem statement by Michael Davidsaver (comment #1 - comment
#11) suggested some apparent corruption of a command line argument that
carries the mutex handle number:

> make: *** invalid output sync mutex: �*V8�.  Stop.

I am afraid, what we discovered (closing a handle to be inherited before
starting a child) does not explain these strange strings in the error message,
thus probably the two phenomena are of different root cause.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64806] "invalid output sync mutex" on windows

[Eli Zaretskii]

Follow-up Comment #32, bug#64806 (group make):

I don't think I understand what you mean by "change management aspect", and
why the behavior discussed here doesn't have much to do with the original
problem report.  Please elaborate.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64806] "invalid output sync mutex" on windows

[Gergely Pinter]

Follow-up Comment #31, bug#64806 (group make):

Indeed, probably the smallest change would be just _not_ closing the handle in
_osync_clear()_ [w32os.c] i.e., relying on Windows to auto-close the handle
upon process termination, without any other change in the control flow (this
is the workaround mentioned in my comment #27).

Regarding change management aspect, I guess we can conclude that the behavior
analyzed in the recent discussion has not much to do with the original problem
statement, maybe another bug should be opened for this.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/