[bug #61226] Missing included files that have rules don't show as an error

[Dmitry Goncharov]

Follow-up Comment #10, bug #61226 (project make):

[comment #9 comment #9:]
> I will leave this issue open to think about how to best introduce a
backward-incompatible change that might help in this situation.

Do i understand it correctly, that as long as compatibility allows, you'd like
make to fail whenever make cannot include a makefile, as long as the included
makefile has a rule with a recipe, even empty?

i'd like to mention that en empty recipe in a force rule has the benefit of
avoiding a redundant implicit search. This helps performance and makes a
meaningful debug output, because it removes repetitive "Looking for an
implicit rule..." and "No implicit rules found..." for each .d file.
So, i prefer rules like


%.d:;
%.h:;



___

Reply to this item at:

  

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

[bug #61763] [PATCH] glob: Do not use realloc wrapper on FreeBSD

[Paul D. Smith]

Follow-up Comment #1, bug #61763 (project make):

Unfortunately the glob.c that comes from GNU make was copied from gnulib and
isn't really maintained by GNU make.  Doubly-unfortunately the glob.c that now
appears in the current gnulib is massively different AND cannot be used in any
environment that doesn't support a complete autoconf deployment (that is, a
full configure script with all the POSIX utilities that configure requires).

Since GNU make builds on, and is used by, DOS, Windows, and VMS users, none of
which have the ability to run configure natively, we're sort of between a rock
and a hard place.

We'll have to decide whether to keep the existing glob implementation, which
is extremely outdated and contains some known bugs as well as build issues
such as the one you raise, and tweak it, or replace it with the new
implementation and figure out how to handle the systems where configure can't
be invoked.

___

Reply to this item at:

  

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

Re: [PATCH] Fix nonzero detection in integer parsing

[Paul Smith]

On Thu, 2022-01-13 at 23:31 +0100, Jouke Witteveen wrote:
> I would like to draw attention to this patch again, since without
> it the intcmp function is misbehaving.

Thanks for reminding me: somehow the original got deleted from my inbox
without being applied.  I've now applied it to my Git repo and will
push shortly.

[bug #61226] A regression prevents generation of missing included dependency files.

[Paul D. Smith]

Follow-up Comment #9, bug #61226 (project make):

For now I decided to put back the original behavior (revert the main.c
changes).  I will leave this issue open to think about how to best introduce a
backward-incompatible change that might help in this situation.

I really don't like the idea of creating a distinction between an "empty"
recipe and a "non-empty" recipe.  Just to point out the description in "Rules
without Recipes or Prerequisites" is talking about *NO* recipe vs. some
recipe, not empty recipe vs non-empty recipe.  That is, the difference between
*FORCE:* and *FORCE:;*.  However as I mentioned before it's not actually
required that you don't have a recipe here: any recipe (or no recipe) that
doesn't update the target will serve just as well.  This text is not wrong,
although it could be argued that it's incomplete by not describing all the
other ways a target might be considered up to date in addition to a missing
recipe.

The text in "Including Other Makefiles" was confusing so I modified it to say
this:

> Only after it has failed to find a rule to remake the makefile, or it found
a rule but the recipe failed, will @code{make} diagnose the missing makefile
as a fatal error.


___

Reply to this item at:

  

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

[bug #61226] Missing included files that have rules don't show as an error

[Paul D. Smith]

Update of bug #61226 (project make):

  Item Group: Bug => Enhancement
 Summary: A regression prevents generation of missing included
dependency files. => Missing included files that have rules don't show as an
error


___

Reply to this item at:

  

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

Re: Invalid use of const pointer?

[Jon Forrest]

On 1/17/2022 1:20 PM, Paul Smith wrote:

On Sun, 2022-01-09 at 20:02 -0500, Joe Filion wrote:

If interested, I found another similar construct in another area of
the code. Don’t worry, this appears to be the last one.

On line 557 of implicit.c:
   p = strchr (nptr, '%');
nptr is a const pointer, but p is used as a non-const pointer later
on and modifies the string.


I see this line, but I don't see where p is used to modify the string.

Maybe I am missing something?  Can you show where the modification
happens, not just the strchr()?


I remember sending this, but I no longer remember what I was referring
to.

Please disregard.

Thanks,
Jon

Re: Invalid use of const pointer?

[Paul Smith]

On Sun, 2022-01-09 at 20:02 -0500, Joe Filion wrote:
> If interested, I found another similar construct in another area of
> the code. Don’t worry, this appears to be the last one. 
> 
> On line 557 of implicit.c:
>   p = strchr (nptr, '%');
> nptr is a const pointer, but p is used as a non-const pointer later
> on and modifies the string.

I see this line, but I don't see where p is used to modify the string.

Maybe I am missing something?  Can you show where the modification
happens, not just the strchr()?

Re: .SILENT: clobbered by .SILENT: with_target

[Paul Smith]

On Wed, 2022-01-12 at 14:22 -0900, Britton Kerin wrote:
> > You can see that this example mimics your .silent example. 
> > Your makefile provided a prerequisite to .SILENT. Make then knows
> > that .SILENT has a prerequisite.
> 
> I agree that it's consistent syntax, but semantically it's bad.  The
> expectation and the manual both imply that .SILENT: will have a
> global effect, and a  real union-of-effects would have .SILENT:
> meaning everything and .SILENT: some_target redundant.  The root of
> the problem is that the rule syntax has been recycled for an
> unrelated purpose, especially so for directives without
> prerequisites.

Another option you can consider is to add:

  MAKEFLAGS += --silent

to enforce silent mode.

This doesn't address the issue you raise but maybe it will help with
the problem you're trying to solve.