[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [bug #61594] suggest new $(hash ...) function
From: |
rsbecker |
Subject: |
RE: [bug #61594] suggest new $(hash ...) function |
Date: |
Wed, 1 Dec 2021 08:41:05 -0500 |
On December 1, 2021 9:06 AM, Tim Murphy wrote:
> On Wed, 1 Dec 2021 at 12:37, Edward Welbourne <mailto:edward.welbourne@qt.io>
> wrote:
>> mailto:rsbecker@nexbridge.com (1 December 2021 13:08) wrote:
>>> I would suggest that adding cryptography to GNU Make would limit its
>>> reach. There are jurisdictions where it is questionable to import
>>> software containing any cryptography. In addition, there are numerous
>>> tools for doing what you want. Something along the lines, for example,
>>> of:
>>>
>>> $(shell git hash-object obj)
>>>
>>> Is a simple function that is already supported by GNU Make without
>>> having to introduce cryptography. This would make a lot more sense to
>> me to keep hashing out of GNU Make.
>> +1. It also leaves it to the make file author to decide which hash
>> function to use. If make took charge of that decision, it would be
>> stuck with the hash selected for all time, since it would have no way of
>> knowing how the resulting hashes have been used by diverse different
>> make files. An individual project's make files can make the transition
>> from using one hash to another, since it knows how it's been using the
>> hashes and how to ensure a clean transition when it comes to change the
>> hash function used.
> I have added such a function as a loadable library before - you might
> consider that if you can't get it done another way.
> https://github.com/tnmurphy/extramake
>
> look at hash.c. To try it :
>
> cd example && make -f http://example.mk
>
> I called the function siphash24 because that's what I used - and its'
> definitely not cryptographic. I had similar needs such as generating unique
> target names from many inputs
> where I didn't want the target name to be of unlimited length or to have
> illegal characters.
>
> $(shell) was useless as it is far too slow.
>
> I would suggest having $(hash) and $(<hash-alg>) - because then people who
> care about the algorithm will be able to choose it.
>
>
> FYI loadable modules are quite cool:
> SOURCES:=proga.c progb.c
> OBJECTS:=$(SOURCES:.c=.o)
>
>
> include ../http://xtra.mk
> XTRA_OUTPUTDIR:=.
> XTRA_SOURCE:=..
> -load $(XTRA_OUTPUTDIR)/hash$(XTRA_EXT)
>
> LIBVERSION:=$(siphash24 $(SOURCES))
> LIBNAME:=prog_$(LIBVERSION).so
> $(LIBNAME): $(OBJECTS)
> cc -o $@ $^ -shared
>
> $(OBJECTS) : %.o : %.c
> cc -c -o $@ -fPIC $^
> include ../http://hash.mk
>
> The above will build the $(siphash24) function (if it's not there already)
> and then use it.
I am fine with using loadable modules to add functionality to GNU Make. I will
probably contribute a change here so that it works on other platform(s) at some
point. I also get that $(shell) can be very slow on some platforms.
Randall