I'm going to disagree with part of what you say:
> someone else adding conflicting recipes (disabling the warning would make
this unnoticeable)
But they wouldn't be *conflicting* recipes. The whole point of this
discussion is to remove warnings for *identical* recipes. The enhancement
request is indeed arguable, but it's not about conflicting recipes.
> accidental copy/paste
Yes, a case can be made that people might want to be alerted to the fact
that they have redundant recipes as a result of accidental copy/paste or
similar. This is a reasonable subject for debate/discussion.
> I handled 'mkdir' stuff by adding mkdir to all the recipes. It's not
ideal but it works.
Well, no, it isn't and it doesn't. We're getting well away from the initial
subject but I'll give the background anyway:
Depending on platform, mkdir in recipes is somewhere between broken and
inelegant. I've written this up in detail for my employer but the short
version is that mkdir is a particularly complex case in parallel builds due
to race conditions when creating shared parent directories. In the end
there's only one threadsafe, portable, and clean way of making directories
and that's to hand the job to make via an order-only dependency:
$(list-of-required-directories):
mkdir $@
target: | <parent-directory>
Directory creation in recipes is subject to random failure in -j scenarios
but you can get away with it on GNU platforms such as Linux because GNU
mkdir has a builtin retry mechanism. Thus, on GNU platforms it's merely
inelegant while on non-GNU platforms it's unsafe.
It's worth noting that the above can be made simpler by use of
.SECONDEXPANSION:
target: | $$(@D)
David
On Tue, Sep 25, 2018 at 7:56 AM Brian Vandenberg <phantall+gnum...@gmail.com>
wrote:
> On the one hand that might seem convenient, but that would open the
> door to mistakes being introduced that you would undoubtedly want to
> avoid, eg:
>
> * accidental copy/paste
> * someone else adding conflicting recipes (disabling the warning would
> make this unnoticeable)
>
> I handled 'mkdir' stuff by adding mkdir to all the recipes. It's not
> ideal but it works.
>
> -brian
> On Mon, Sep 17, 2018 at 7:23 PM David Boyce <invalid.nore...@gnu.org>
> wrote:
> >
> > URL:
> > <https://savannah.gnu.org/bugs/?54675>
> >
> > Summary: avoid redundant recipe warning for identical
> recipes
> > Project: make
> > Submitted by: boyski
> > Submitted on: Tue 18 Sep 2018 01:23:09 AM UTC
> > Severity: 3 - Normal
> > Item Group: Enhancement
> > Status: None
> > Privacy: Public
> > Assigned to: None
> > Open/Closed: Open
> > Discussion Lock: Any
> > Component Version: SCM
> > Operating System: None
> > Fixed Release: None
> > Triage Status: None
> >
> > _______________________________________________________
> >
> > Details:
> >
> > I'm wondering whether it might be reasonable to skip the redundant-recipe
> > warnings if the recipes are identical anyway. Test case:
> >
> > % cat makefile
> > .PHONY: all
> > all:
> > foo:; touch $@
> > foo:; touch $@
> >
> > % make
> > makefile:5: warning: overriding recipe for target 'foo'
> > makefile:4: warning: ignoring old recipe for target 'foo'
> > make: Nothing to be done for 'all'.
> >
> > It looks like this might be avoidable with a strcmp in read.c around
> line 2113
> > (in current SCM) though I'm not in a position to try it now.
> >
> > This comes up because I have various macros and helper makefiles which
> > generate rules to create directory paths. The recipe to create a
> directory
> > will in all cases be "mkdir $@" in my use case but when multiple macros
> end up
> > generating identical rules these spurious warnings are still printed. Of
> > course it can be programmed around but I wonder whether it's worth
> giving the
> > warning at all here.
> >
> >
> >
> >
> >
> >
> > _______________________________________________________
> >
> > Reply to this item at:
> >
> > <https://savannah.gnu.org/bugs/?54675>
> >
> > _______________________________________________
> > Message sent via Savannah
> > https://savannah.gnu.org/
> >
> >
> > _______________________________________________
> > Bug-make mailing list
> > Bug-make@gnu.org
> > https://lists.gnu.org/mailman/listinfo/bug-make
>
> _______________________________________________
> Bug-make mailing list
> Bug-make@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-make
>
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
