Subject: Re: [boost] [afio] running tests
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-08-30 12:14:52
On 8/30/15 6:34 AM, Niall Douglas wrote:
> Note that as AFIO is standalone capable, simply entering its
> directory and typing:
> 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
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
a) list the requirements of the library.
b) If it can depend one of several ways of doing things - list those
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk