On 8/30/15 6:34 AM, Niall Douglas wrote:
Note that as AFIO is standalone capable, simply entering its directory and typing:
./standalone_alltests_gcc.sh ./test_all
should "just work" if you have a Filesystem TS on your system. If not, it'll auto-configure including Boost.Filesystem.
I realize I might be in the minority here - but I'm very much opposed to this design approach. It has been used in boost.build and probably some libraries. By design approach - I mean the practice of the library designer trying to implement what he "thinks" the user wants without advising or consulting the user so that "it just works". So in this case, I add the files to my system and run some tests. They figure out internally what other libraries to use and make things "just work". Now I recommend to some one else he use the library and he does the same thing. But in his case the system works somehow differently than it does on mine. Now we have to spend a huge amount of time trying to track down the source of the difference. Another example is I install the library and "it just works" then I move on to something else and some months later I change or remove my boost installation. compiled programs with static libraries continue to work until I rebuild one - which now works in a slightly different way. It's a huge amount effort tracking down the source and fixing this problem. moral of the story: Do not make the operation of a library implicitly dependent on some environmental feature. better alternative: a) list the requirements of the library. b) If it can depend one of several ways of doing things - list those explicitly. c) require that the user make an explicit choice. If he declines to do so, trap this condition and display error as soon as possible - do not implement code so that "it just works". d) If you can't bring yourself to do the above - require that the user explicitly specify "let system decide" or something like that. At least this will not inflict this design error on the rest of us. Robert Ramey