Re: [boost] Review: Config system

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-08-31 19:44:47

Aleksey makes some excellent points. On the other hand it is really useful
for developers who can handle the issues if they don't have to crawl through
all of their bug workarounds and disable them just to see how well a new
compiler works. The solution seems obvious to me: we specify a preprocessor
symbol which, when #defined, makes the appropriate assumption for
developers... shall we say, BOOST_DEVELOPER?

-Dave

----- Original Message -----
From: "Aleksey Gurtovoy" <alexy_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, August 31, 2001 6:28 PM
Subject: RE: [boost] Review: Config system

> Jens Maurer wrote:
> > On a different topic discussed here, unknown compiler versions
> > should be assumed to be fully compliant.  If they aren't,
> > people will complain here, and we will know thusly that a new
> > version of some compiler has appeared and we can make appropriate
> > corrections.
>
> Being a real-world _user_ of boost (as opposite to a developer) I strongly
> disagree. Using of boost libraries in your project is supposed to help you
> in your every-day professional life, not to make it harder. Switching to a
> new version of the compiler and getting _your own_ code to compile and
work
> is painful enough without being forced to deal with a sudden break of 3rd
> party libraries' code, even (and especially) if one these libraries is
> "boost". Although fortunately it's not a case for our team, I know that
many
> people in other companies have invested a considerable amount of efforts
to
> get their managers to allow them to use boost libraries in the production
> code, (validly) promising that it will boost (NPI) their productivity. I
> don't think that the "people will complain and we'll fix it" attitude is
> something that these users would appreciate ("What??! You said it'll take
1
> day, and it already took 3!! Some boost libraries don't compile, and you
> have no idea why, and you're waiting till they will fix it?? I knew that
the
> whole idea of using this open-source stuff in production code won't lead
to
> anything better than this!.."), and I think we should care about our
users.
> In most real-world situations "optimistic" config scheme will force you to
> deal with the whole "boost config" issue right away, as if it was the most
> important thing in porting your project, and certainly it isn't. And
suppose
> that a new version of the compiler is indeed fully complaint and you'd get
> the whole world of a new boost libraries' functionality available to you.
> Does it solve any of your today's porting problems? No! Could it solve any
> of your tomorrow (post-porting) problems? Not likely. Could it help you to
> solve the problems you'll be approaching in a week - may be, but
personally
> I will be much more willing to spend time on the issue when _I_, a user,
> decide to do it, not somebody else.
>
>
> Aleksey
>
> Info: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>