|
Boost : |
From: Joel de Guzman (joel_at_[hidden])
Date: 2003-10-16 00:06:42
Beman Dawes <bdawes_at_[hidden]> wrote:
> At 10:02 PM 10/11/2003, Joel de Guzman wrote:
>
> >Now that VC7.1 is here, isn't it about time that we break free from the
> >chains (at least for new libraries in the horizon)?
>
> The problem is broader than just VC++. There were several gcc-2.95.3
> failures among the Linux regressions that Martin Wille reported recently.
> Do we ask Boost developers to put in effort fixing those regressions?
>
> I'd like to suggest that we only put effort into legacy compilers in
> proportion to the willingness of users to send us patches and help with
> resolving issues. Boost developers shouldn't be expected to support legacy
> compilers unless users are willing to help out. But when users are willing
> to help, Boost developers should try to respond if there are reasonable
> workarounds.
Among the compilers that Spirit supports right now, VC6 is the most
problematic, followed by VC7 and the third is Borland. As of Spirit v1.6.x,
these three problematic compilers were supported and compatibility is
maintained (sometimes with some help from users, especially with bug
reporting).
I'd sure appreciate some help from the community, especially the Borland
and VC6 specialists, in maintaining the Spirit code base to be compatible
with these compilers. As of now, the latest developmental code does not
compile on these compilers. There are other Spirit developers working on
the code, but not all have access to many compilers. Dan Nuffer, the author
of the ASTs and parse tree facilities, for example, is strictly a g++ guy. The
consequence is that the ASTs, from day one, do not compile on VC6.
Well, we all know that porting to VC6 is not a trivial task, especially for
template-heavy code such as Spirit. If the author of a particular module
has no access to VC6 and Borland, usually the task of porting falls on me.
Hartmut and the others are also very helpful, but there is no particular
individual responsible for maintaining compatibility with each compiler. In
a perfect world, we'll all be coding in pure ISO C++ and all is well. But in
reality, even a seemingly simple patch can wreak havoc that breaks the whole
code base.
We (Spirit developers) discussed this problem before. One solution, which is
not available to us right now, is to have a site where we can test compilers,
a boost-compiler-farm, if you will. The compiler farm at SourceForge is not
a solution because it targets only *nix platforms. So, I am asking now, how
is it possible to have a boost compiler farm, for boost developers, that can
target at least *nix and windows compilers?
Regards,
-- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk