Boost logo

Boost :

From: Paul A Bristow (pbristow_at_[hidden])
Date: 2007-04-10 07:51:21


 

>-----Original Message-----
>From: boost-bounces_at_[hidden]
>[mailto:boost-bounces_at_[hidden]] On Behalf Of Konstantin
>Litvinenko
>Sent: 10 April 2007 12:20
>To: boost_at_[hidden]
>Subject: Re: [boost] Hybrid compilation model? was: [system]
>
> BD> I'll like to challenge Boosters to think about this
>problem a bit more,
> BD> and I'd love to see someone who understands the
>challenges take, say,
> BD> Boost.System and demonstrate how it could be packaged for either
> BD> header-only or compiled-library use. The important goal
>would be to
> BD> abstract what to done into a general set of guidelines (and any
> BD> configuration support needed). In other words, we don't
>so much need a
> BD> solution for Boost.System as for any Boost library that
>would benefit
> BD> from a hybrid computation model.
>
> Don't you see that the root of all these problems derived
>from statement
>"There are no one standart way do download, deploy, build
>procedure in C++
>world"? If boosters define such procedure and make all these
>things easy to
>do, than all, developers and users, will be happy. No need to
>think about
>complex configs to support hybrid models or other magic
>things. Developers
>will focus on library implementation, not on "how to make this header
>only?". Users will build apps without spending dozen of hours
>to figure out
>how to integrate libxxx into environment.

> I think we need infrastructure that removes all these issues.

Sorry, but I don't think this infrastructure exists, nor will it ever exist.
Nor will a Boost 'standard' way of building things become widely adopted.

I agree with Beman that we need to cater for both library and header-only.

It's more trouble for the library authors, but we should assume they are more expert ;-)

Paul

---
Paul A Bristow
Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
+44 1539561830 & SMS, Mobile +44 7714 330204 & SMS
pbristow_at_[hidden]

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk