[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 #65438] Sort print-targets output.

[Dmitry Goncharov]

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


> I doubt most users will be able to map the output they see onto the input
make reads except in simple situations.  When you start having lots of include
files etc. it becomes hard to follow.

i was looking for some useful simple deterministic sorting criteria. This
order was the simplest and possibly useful.
i also considered printing all targets from a makefile before printing targets
from another makefile. However, this requires that make remembers
makefile:lineno of the rules without recipes. This additional requirement
caused me to reject the idea.


> Question: why not just _actually_ sort the output so the results are ordered
by pathname of the target instead of by order discovered?
I also considered sorting by pathname and could not see user benefits to
justify the extra code.
Would be good if those gentlemen who wanted the feature gave their input.

Another option is to abandon the patch and choose names in the test such that
the targets are hashed in the same order on both little and big endian.
Do you know why the current impl has to hash differently on little and big
endian?


___

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 #2, bug #65438 (group make):

I think the term "sort" isn't really correct here: from the user's point of
view they simply see the output in a different, and deterministic, but still
more or less random, order than they did before.  I doubt most users will be
able to map the output they see onto the input make reads except in simple
situations.  When you start having lots of include files etc. it becomes hard
to follow.

Question: why not just _actually_ sort the output so the results are ordered
by pathname of the target instead of by order discovered?


___

Reply to this item at:

  

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

[bug #65438] Sort print-targets output.

[Dmitry Goncharov]

Additional Item Attachment, bug #65438 (group make):

File name: sv65438_fix.diff   Size:6 KB


File name: sv65438_test.diff  Size:3 KB



AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-04b18e1179b14c0ef710c8e9c8e59d1e4bcd7bd0.tar.gz


___

Reply to this item at:

  

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

[bug #65438] Sort print-targets output.

[Dmitry Goncharov]

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

Sort print-targets output.

print-targets prints the targets in the order they ended up hashed in the
table.
The hashing routine hashes differently on big and little endian machines.
The result is that the test fails on big endian machines.

This is an example of the difference.

$ cat work/options/print-targets/t001.diff
*** t001.base   Wed Feb 14 21:41:32 2024
--- t001.logWed Feb 14 21:41:32 2024
***
*** 1,5 
  submake
- .x.z
- always
  all
  goodfile
--- 1,5 
  submake
  all
+ always
  goodfile
+ .x.z


The patch in the attachment sorts the targets by the order in which make
entered those files.
This gets the tests fixed on big endian.
Another benefit is that the sorted output is, in my opinion, friendlier to
humans.



This is the output in make's source code directory produced by make with this
patch.



Makefile
all
all-recursive
am--refresh
../Makefile.in
../configure
../src/config.h.in
../aclocal.m4
../m4/00gnulib.m4
../m4/acinclude.m4
../m4/alloca.m4
../m4/asm-underscore.m4
../m4/c-bool.m4
../m4/dospaths.m4
../m4/eaccess.m4
../m4/extensions.m4
../m4/findprog-in.m4
../m4/getloadavg.m4
../m4/gettext.m4
../m4/gnulib-common.m4
../m4/gnulib-comp.m4
../m4/host-cpu-c-abi.m4
../m4/iconv.m4
../m4/intlmacosx.m4
../m4/largefile.m4
../m4/lib-ld.m4
../m4/lib-link.m4
../m4/lib-prefix.m4
../m4/longlong.m4
../m4/nls.m4
../m4/po.m4
../m4/progtest.m4
../m4/sig_atomic_t.m4
../m4/warn-on-use.m4
../m4/zzgnulib.m4
../configure.ac
src/stamp-h1
config.status
distclean-hdr
build.cfg
tests/config-flags.pm
install-binPROGRAMS
make
uninstall-binPROGRAMS
clean-binPROGRAMS
installcheck-binPROGRAMS
src/ar.o
src/arscan.o
src/commands.o
src/default.o
src/dir.o
src/expand.o
src/file.o
src/function.o
src/getopt.o
src/getopt1.o
src/guile.o
src/hash.o
src/implicit.o
src/job.o
src/load.o
src/loadapi.o
src/main.o
src/misc.o
src/output.o
src/read.o
src/remake.o
src/rule.o
src/shuffle.o
src/signame.o
src/strcache.o
src/variable.o
src/version.o
src/vpath.o
src/warning.o
src/config.h
src/w32/.dirstamp
src/w32/.deps/.dirstamp
src/w32/compat/posixfcn.o
src/w32/compat/.deps/.dirstamp
src/w32/subproc/misc.o
src/posixos.o
src/remote-cstms.o
src/vms_exit.o
src/vms_export_symbol.o
src/vms_progname.o
src/vmsfunctions.o
src/vmsify.o
src/.dirstamp
src/.deps/.dirstamp
src/w32/pathstuff.o
src/w32/w32os.o
src/w32/compat/dirent.o
src/w32/compat/.dirstamp
src/w32/subproc/sub_proc.o
src/w32/subproc/w32err.o
src/w32/subproc/.dirstamp
src/w32/subproc/.deps/.dirstamp
src/remote-stub.o
mostlyclean-compile
distclean-compile
src/.deps/ar.Po
/usr/include/stdc-predef.h
../src/makeint.h
/usr/lib/gcc/x86_64-linux-gnu/11/include/stdbool.h
../src/../src/mkcustom.h
lib/alloca.h
/usr/lib/gcc/x86_64-linux-gnu/11/include/stddef.h
../src/gnumake.h
/usr/include/x86_64-linux-gnu/sys/types.h
/usr/include/features.h
/usr/include/features-time64.h
/usr/include/x86_64-linux-gnu/bits/wordsize.h
/usr/include/x86_64-linux-gnu/bits/timesize.h
/usr/include/x86_64-linux-gnu/sys/cdefs.h
/usr/include/x86_64-linux-gnu/bits/long-double.h
/usr/include/x86_64-linux-gnu/gnu/stubs.h
/usr/include/x86_64-linux-gnu/gnu/stubs-64.h
/usr/include/x86_64-linux-gnu/bits/types.h
/usr/include/x86_64-linux-gnu/bits/typesizes.h
/usr/include/x86_64-linux-gnu/bits/time64.h
/usr/include/x86_64-linux-gnu/bits/types/clock_t.h
/usr/include/x86_64-linux-gnu/bits/types/clockid_t.h
/usr/include/x86_64-linux-gnu/bits/types/time_t.h
/usr/include/x86_64-linux-gnu/bits/types/timer_t.h
/usr/include/x86_64-linux-gnu/bits/stdint-intn.h
/usr/include/endian.h
/usr/include/x86_64-linux-gnu/bits/endian.h
/usr/include/x86_64-linux-gnu/bits/endianness.h
/usr/include/x86_64-linux-gnu/bits/byteswap.h
/usr/include/x86_64-linux-gnu/bits/uintn-identity.h
/usr/include/x86_64-linux-gnu/sys/select.h
/usr/include/x86_64-linux-gnu/bits/select.h
/usr/include/x86_64-linux-gnu/bits/types/sigset_t.h
/usr/include/x86_64-linux-gnu/bits/types/__sigset_t.h
/usr/include/x86_64-linux-gnu/bits/types/struct_timeval.h
/usr/include/x86_64-linux-gnu/bits/types/struct_timespec.h
/usr/include/x86_64-linux-gnu/bits/pthreadtypes.h
/usr/include/x86_64-linux-gnu/bits/thread-shared-types.h
/usr/include/x86_64-linux-gnu/bits/pthreadtypes-arch.h
/usr/include/x86_64-linux-gnu/bits/atomic_wide_counter.h
/usr/include/x86_64-linux-gnu/bits/struct_mutex.h
/usr/include/x86_64-linux-gnu/bits/struct_rwlock.h
/usr/include/x86_64-linux-gnu/sys/stat.h
/usr/include/x86_64-linux-gnu/bits/stat.h
/usr/include/x86_64-linux-gnu/bits/struct_stat.h
/usr/include/x86_64-linux-gnu/bits/statx.h
/usr/include/linux/stat.h
/usr/include/linux/types.h
/usr/include/x86_64-linux-gnu/asm/types.h
/usr/include/asm-generic/types.h
/usr/include/asm-generic/int-ll64.h
/usr/include/x86_64-linux-gnu/asm/bitsperlong.h
/usr/include/asm-generic/bitsperlong.h
/usr/include/linux/posix_types.h
/usr/include/linux/stddef.h
/usr/include/x86_64-linux-gnu/asm/posix_types.h
/usr/include/x86_64-linux-gnu/asm/posix_types_64.h

[bug #65438] Sort print-targets output.

[Dmitry Goncharov]

URL:
  

 Summary: Sort print-targets output.
   Group: make
   Submitter: dgoncharov
   Submitted: Sat 09 Mar 2024 03:34:40 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


___

Follow-up Comments:


---
Date: Sat 09 Mar 2024 03:34:40 AM UTC By: Dmitry Goncharov 
.







___

Reply to this item at:

  

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