A question about hasing in idutils

[Dmitry Goncharov]

Good morning.

The hash table from id utils from imported to gnu make.
This hash table hashes the same string to different brackets on little
and big endian.
Can you please shed some light why there needs to be this difference
in hashing on little and big endian?

regards, Dmitry

[bug #65438] Sort print-targets output.

[Dmitry Goncharov]

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


> Regarding the hashing vs. endianness, I don't know.

What do you think of changing hashing to produce the same result on little and
big endian?


> Regarding sorting, doesn't this basically mean just using strcmp (or a
small
> wrapper around it) as the sorting function?

strcmp directly cannot be used, because the qsort comparison routine takes
pointers to struct file.
The impl in the attached patch contains function filecmp. filecmp can be
reduced to


static int
filecmp (const void *slotx, const void *sloty)
{
  const struct file *x = *(const struct file **) slotx;
  const struct file *y = *(const struct file **) sloty;
  return strcmp (x->name, y->name);
}


> For justification I don't know that we really need one; if it's useful to
us
> to sort, we should sort even if users won't find it useful.  Someone
looking
> at the output by hand may find it useful although it seems just as likely
they
> will run the output through sort themselves if they want it sorted.

Moreover make should not reimplement all the abilities of gnu sort (for
example).
On the other hand, the user won't be able to produce the output in the order
proposed in the patch, unless make produces it.


> It's too bad we don't have a simple way to sort the output in the test
> framework.  It will be annoying if we choose "good" filenames and the test
> passes, but then we switch our hashing around and it breaks again.

i was thinking of the fact most users run and test make on little endian. This
results in occasional breakage like this one.
As long as there is this difference in hashing, such breakage is likely to
recur.



___

Reply to this item at:

  

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

[bug #65438] Sort print-targets output.

[Paul D. Smith]

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

Regarding the hashing vs. endianness, I don't know.  The hash.{c,h}
implementation we have was taken, basically verbatim, from the GNU idutils
program.

Regarding sorting, doesn't this basically mean just using strcmp (or a small
wrapper around it) as the sorting function?

For justification I don't know that we really need one; if it's useful to us
to sort, we should sort even if users won't find it useful.  Someone looking
at the output by hand may find it useful although it seems just as likely they
will run the output through sort themselves if they want it sorted.

It's too bad we don't have a simple way to sort the output in the test
framework.  It will be annoying if we choose "good" filenames and the test
passes, but then we switch our hashing around and it breaks again.


___

Reply to this item at:

  

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

[bug #54854] multi-target rules invoked too often with -j2

[Paul D. Smith]

Follow-up Comment #9, bug #54854 (group make):

Hopefully it will solve it!  That would be nice.  Cheers!


___

Reply to this item at:

  

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

[bug #54854] multi-target rules invoked too often with -j2

[Vassilis Virvilis]

Follow-up Comment #8, bug #54854 (group make):

Yep that's it.

I can't believe how I missed this part. So a simple &: would solve the issue
for me?

!!! Wow !!!

Definitely not my brightest moment.

Thanks a lot. Much appreciated.


___

Reply to this item at:

  

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

[bug #54854] multi-target rules invoked too often with -j2

[Paul D. Smith]

Follow-up Comment #7, bug #54854 (group make):

If you can rely on having GNU Make 4.3 or better, you can use grouped explicit
targets to get the same behavior make provides to pattern rules, with explicit
rules:

https://www.gnu.org/software/make/manual/html_node/Multiple-Targets.html

If you must support versions of GNU Make prior to 4.3 (released in 2020) then
you will have to use alternate methods.


___

Reply to this item at:

  

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

[bug #54854] multi-target rules invoked too often with -j2

[Vassilis Virvilis]

Follow-up Comment #6, bug #54854 (group make):

Thanks for taking the time to explain with a simple and easy to follow
example.

>From the looks of it I have to agree that this is a legitimate case and cannot
to lead to a broken build.

Unfortunately my case is a rule for a program that builds two real files (not
.PHONY). The problem is the second -j thread overwrites the output the first.
I agree that the solution is to restructure the rules in a way to avoid
behavior and this is what I have done but it took a while to figure it out.

Hopefully this thread will be findable by other people who may wonder about
the exact GNU Make behavior and possible workarounds.

Thanks again.




___

Reply to this item at:

  

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

[bug #54854] multi-target rules invoked too often with -j2

[Paul D. Smith]

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

Definitely there are a lot of valid uses.  Generally, any time where you want
to define the same recipe for lots of different targets but you don't want to
have to write them all out one at a time.

Your assertion that this construct is not common is just not true: this
appears all over the place in all sorts of makefiles.  In fact I just checked
a makefile generated by GNU's automake tool, and it uses the construct. 
Here's one simple example of an obvious way this might be used:

SUBDIRS := $(wildcard */.)

all: $(SUBDIRS)

$(SUBDIRS):
$(MAKE) -C $@

.PHONY: all $(SUBDIRS)


There's no reason this should give any sort of warning, even when used with
-j.


___

Reply to this item at:

  

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

[bug #54854] multi-target rules invoked too often with -j2

[Vassilis Virvilis]

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

[comment #3 comment #3:]
> If by "a warning (or a note)" you mean something printed by GNU Make,
instead of content in the documentation (this is already described there) then
no, we can't do that, because this behavior has many uses, and is used in many
situations and in many thousands of makefiles.  Generating messages would not
be appropriate.

I see.

How about adding the warning/note if -d is specified? This surely won't be as
disturbing and could still help if somebody debugs broken builds.

Is there any use case where this is the desired behavior? I can see builds
breaking because of this (multiple invocations of the same rule) but not any
valid ones. The condition to issue the warning shouldn't be very common (-j N
&& N > 1 && rule with multiple target is invoked with no patterns)

Finally I would like to note that there is a similar case where Make issues a
warning. I believe when -j is used with a submake $(MAKE) without a plus sign
(+). That warning was very helpful for me at least.

Thanks anyway.


___

Reply to this item at:

  

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