Re: [boost] [afio] running tests

Subject: Re: [boost] [afio] running tests
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2015-08-30 12:33:29

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Robert Ramey
> Sent: 30 August 2015 17:15
> To: boost_at_[hidden]
> Subject: Re: [boost] [afio] running tests
> 
> 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.

+1

Boost.Build has proved this for me (and for many others judging by the stream of queries). 

For me, there have been more occasions when it 'just doesn't work' than when it does.  Finding out
why usually proves more difficult than explicitly having to specify several things in the first
place.

Examples of typical specification can ease that burden.

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]