On Mon, 2012-11-19 at 01:15 +0100, Carl-Daniel Hailfinger wrote:
> We enable programmer compilation based on the following criteria:
> - Default off unless explicitly enabled (dediprog)
> - Default on unless explicitly disabled (dummy)
> - Default on if technically possible on target machine (linux_spi)
> - Default on if the required libs+headers are available (ft2232_spi)
> 
> The last criterion is what causes pains to no end, at least with the
> current Makefile infrastructure. Yes, we (I) can maintain it, but in the
> long run we either need a separate configure script (which may or may
> not work in all envorinments where GNU make works, especially exotic
> platforms like Windows), or we switch to something like CMake (which
> doesn't have the required features in ancient versions AFAIK), or we use
> two chained Makefiles (which would not meet my definition of "fun").
> Now why is the last criterion such a PITA? All other criteria have a
> hard fail/success test, i.e. if a required lib/header is missing, we
> stop compilation. However, this criterion has a soft fail/success test,
> i.e. if you enable a feature and the required libraries/headers are
> missing, the feature simply will be silently disabled. That sort of
> violates the principle of least surprise, and it's the reason why our
> current Makefile uses nasty tricks with external files to avoid
> reloading itself.
> 
> I would like to switch ft2232_spi to "Default on if technically possible
> on target machine" and spit out an improved error message in case the
> headers are missing.

I would say people don't have libftdi-dev installed by default. Moving
ft2232_spi (and the not-yet merged usbblaster_spi) to that "default on
if technically possible" -class would mean compile without extra options
will fail on a platform for which libftdi is available. Did I understand
this right? 

Switching to default "off" would affect less users and IMO would be
better choice if there is no easy fix. I don't quite see why the 4th
option is so troublesome in the first place, but haven't studied the
makefile that close. Maybe it does something backwards?

Kyösti


_______________________________________________
flashrom mailing list
[email protected]
http://www.flashrom.org/mailman/listinfo/flashrom

Reply via email to