Junio C Hamano <gitster@xxxxxxxxx> writes:
>> +ifeq ($(strip $(CSPRNG_METHOD)),arc4random)
>> + BASIC_CFLAGS += -DHAVE_ARC4RANDOM
>> +endif
>> +
>> +ifeq ($(strip $(CSPRNG_METHOD)),arc4random-libbsd)
>> + BASIC_CFLAGS += -DHAVE_ARC4RANDOM_LIBBSD
>> + EXTLIBS += -lbsd
>> +endif
>> +
>> +ifeq ($(strip $(CSPRNG_METHOD)),getrandom)
>> + BASIC_CFLAGS += -DHAVE_GETRANDOM
>> +endif
>> +
>> +ifeq ($(strip $(CSPRNG_METHOD)),getentropy)
>> + BASIC_CFLAGS += -DHAVE_GETENTROPY
>> +endif
>> +
>> +ifeq ($(strip $(CSPRNG_METHOD)),rtlgenrandom)
>> + BASIC_CFLAGS += -DHAVE_RTLGENRANDOM
>> +endif
>> +
>> +ifeq ($(strip $(CSPRNG_METHOD)),openssl)
>> + BASIC_CFLAGS += -DHAVE_OPENSSL_CSPRNG
>> +endif
>
> Use of $(strip ($VAR)) looks a bit different from what everybody
> else does with ifeq in this Makefile. Was there a particular reason
> to use it that I am missing?
Another thought. As far as I can see on the C code side in the
later part of the patch, we are prepared to see multiple HAVE_* for
CSPRNG defined by the builders, and let us choose the best one for
them. I wonder if it makes sense to allow
make CSPRNG_METHOD='arc4random getentropy'
as a way to tell us that they have these two and want us to pick the
best one for them.
It does not add much value for human builders, but I suspect that it
would make it simpler when we need to add autoconf support.
If we do not allow multiple methods listed on the CSPRNG_METHOD
variable, the configure script will be forced to pick one in some
way when multiple methods are possible on the platform, either by
detecting all and picking one, or detecting serially from most
preferred and stopping at the first hit.
