Open RemiLacroix-IDRIS opened 3 years ago
Hi, thanks for this feedback.
The underlying logic is that a feature can either be enabled (with --enable-feature
) or disabled (with --disable-feature
). By default, some are enabled (e.g. MPI) and some are disabled (e.g. arrayfire).
Having that enabled features result in an error if the needed libraries are not present would result in undesired errors for features that are on by default when the corresponding libraries are not present.
The only solution that comes to my mind would be to have a third value, e.g. yes/no/ifavailable
, and use ifavailable
as a default instead of yes
. In this manner, explicitly requested features could lead to a failure if the corresponding library is not present.
What do you think?
Giovanni
Hi,
The only solution that comes to my mind would be to have a third value, e.g.
yes/no/ifavailable
, and useifavailable
as a default instead ofyes
. In this manner, explicitly requested features could lead to a failure if the corresponding library is not present.
That would work perfectly.
Another solution would be to have an new option in the configure
script to switch from a warning mode to an error mode, something like --fail-on-missing-libs
.
Rémi
I like Giovanni suggestions of using three if available for default options
Hi,
We run into some issues lately because we missed that ArrayFire couldn't be used at configure and only discovered that much later.
We would have thought that when explicitly using one of the
--enable-af_*
options the configure script would throw an error instead of a warning.Is there any reason to keep this as a warning?
Best regards, Rémi