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.
Comments? Flames?
Regards, Carl-Daniel