Re: [boost] New getting started guide
-----Original Message----- From: boost-bounces@lists.boost.org on behalf of Daryle Walker I don't think Boost, are any part of it, should _require_ an install procedure. It should be possible for any user to just take the actual header and source files and use any build system s/he has. ---- Sorry to interrupt but what do you mean here? Any non-trivial library of source code needs to be built. Something sufficiently complex will be tied to a build system. You're not making any sense to me... Are you suggesting that all of boost source should be compiled by #include directives?! I must've missed some context in this discussion.
Sohail Somani wrote:
-----Original Message----- From: boost-bounces@lists.boost.org on behalf of Daryle Walker
I don't think Boost, are any part of it, should _require_ an install procedure. It should be possible for any user to just take the actual header and source files and use any build system s/he has.
----
Sorry to interrupt but what do you mean here? Any non-trivial library of source code needs to be built.
Most non-trivial libraries do, yes.
Something sufficiently complex will be tied to a build system.
That's the point under debate; most C or C++ systems consist of a selection of header files and source files, which "just" need to be compiled and linked with suitable compiler settings. That can be done by various build systems, with a little effort, by and large. In the past, when the Boost build systems have failed in various odd ways, I've thrown together a quick Makefile for pieces that I needed. (Unfortunately the platform on which I currently do most of my work -- Solaris, using Sun's compiler and standard library -- doesn't support much of Boost. Sun's support for boost seems to be dependent on us being able to use a binary-incompatible standard library implementation, which is not viable when needing to link with third-party proprietary libraries.)
You're not making any sense to me... Are you suggesting that all of boost source should be compiled by #include directives?!
My guess is that was not the suggestion. -- James
James Dennett skrev:
(Unfortunately the platform on which I currently do most of my work -- Solaris, using Sun's compiler and standard library -- doesn't support much of Boost. Sun's support for boost seems to be dependent on us being able to use a binary-incompatible standard library implementation, which is not viable when needing to link with third-party proprietary libraries.)
Maybe Sun need to switch to use stlport as their default standard library for the next compiler release. This would signal which library is considered more compliant and most relevant for library vendors. Special flags should be for backward compliance, not the other way around. ------ Bjørn
2006/11/28, Bjørn Roald <bjorn@4roald.org>:
James Dennett skrev:
(Unfortunately the platform on which I currently do most of my work -- Solaris, using Sun's compiler and standard library -- doesn't support much of Boost. Sun's support for boost seems to be dependent on us being able to use a binary-incompatible standard library implementation, which is not viable when needing to link with third-party proprietary libraries.)
Maybe Sun need to switch to use stlport as their default standard library for the next compiler release. This would signal which library is considered more compliant and most relevant for library vendors. Special flags should be for backward compliance, not the other way around.
We're (at Sun) discussing this suggestion. Maybe -library=stlport4 will be on by default in the next release. But this won't help in that case quickly. There are a lot of third-party library developers who supplies libraries in a binary format and link it with very old std library implementation. -- Simon Atanasyan
Simon Atanasyan wrote:
2006/11/28, Bjørn Roald <bjorn@4roald.org>:
James Dennett skrev:
(Unfortunately the platform on which I currently do most of my work -- Solaris, using Sun's compiler and standard library -- doesn't support much of Boost. Sun's support for boost seems to be dependent on us being able to use a binary-incompatible standard library implementation, which is not viable when needing to link with third-party proprietary libraries.)
Maybe Sun need to switch to use stlport as their default standard library for the next compiler release. This would signal which library is considered more compliant and most relevant for library vendors. Special flags should be for backward compliance, not the other way around.
We're (at Sun) discussing this suggestion. Maybe -library=stlport4 will be on by default in the next release.
I would welcome such a move.
But this won't help in that case quickly. There are a lot of third-party library developers who supplies libraries in a binary format and link it with very old std library implementation.
Indeed. But the sooner there's a move towards a relatively standards-conforming library, the sooner those developers will move too (even if it will take years). There are probably changes that could be made even without breaking binary compatibility: for example, I'm not aware of any backwards compatibility issues if the member template functions in the Rogue Wave stdlib were enabled with a future release of Sun's compilers. (Of course I could be missing a technical point, or a contractual one, or other.) On the other hand, enabling piecemeal functionality like this without the extensive effort you've put into making Boost work with the Sun CC + STLPort4 toolset probably wouldn't help all that much with getting Boost to work with Sun CC + Rogue Wave's stdlib. -- James
On 11/27/06 1:44 AM, "Sohail Somani" <s.somani@fincad.com> wrote:
-----Original Message----- From: boost-bounces@lists.boost.org on behalf of Daryle Walker
I don't think Boost, are any part of it, should _require_ an install procedure. It should be possible for any user to just take the actual header and source files and use any build system s/he has.
----
Sorry to interrupt but what do you mean here? Any non-trivial library of source code needs to be built. Something sufficiently complex will be tied to a build system.
I thought that Boost would be one of the exceptions; that a build system wouldn't be mandatory. We have kept that ideal for the most part.
You're not making any sense to me... Are you suggesting that all of boost source should be compiled by #include directives?! I must've missed some context in this discussion.
All the *.hpp headers would be compiled by #inclusion, of course. I meant that any required *.cpp source files can be incorporated into a project however the user wants, without being forced to use some sort of "officially blessed" extra-lingual tool. (A non-Boost example would be the special preprocessor Qt uses.) All the Boost tools should remain secondary to the goals of providing C++ libraries. I don't want Boost.Python starting a "slippery slope". -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker <darylew@hotmail.com> writes:
All the *.hpp headers would be compiled by #inclusion, of course. I meant that any required *.cpp source files can be incorporated into a project however the user wants, without being forced to use some sort of "officially blessed" extra-lingual tool. (A non-Boost example would be the special preprocessor Qt uses.) All the Boost tools should remain secondary to the goals of providing C++ libraries. I don't want Boost.Python starting a "slippery slope".
I don't know what you're talking about. Boost has never (or at least, not for many years) officially supported the approach you're suggesting of "no separate compilation for all libraries", so incompatibility with it is not a change or a start down a slippery slope: we're already at the bottom of that slope. If the technique worked for you, great; you've been lucky. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (6)
-
Bjørn Roald -
Daryle Walker -
David Abrahams -
James Dennett -
Simon Atanasyan -
Sohail Somani