bug-make
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]