i get the source from boost cvs,and compiled it with bjam "-sTOOLS=vc-8_0" install,and then i get libboost_serialization-vc80-mt-gd-1_34.lib,but when i compile demo.cpp of serialization example,it complains about cannot find libboost_serialization-vc80-mt-gd-1_33.lib,someone can tell why this happen,thanks advanced 2006/1/31, Rene Rivera <grafik.list@redshift-software.com>:

Thomas Witt wrote:

...

AFAICS there seems to be strong support for moving gcc-2.95 and vc6 to "Marked Deprecated" and somebody needs to fight Alisdair over Borland (volunteers? any?).

As one of the few people using, and for a time testing, CW-8.3 I would also recommend putting it in the deprecated category, possibly even unsupported ;-)

--grafik _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Jeff Garland wrote:

Deprecated: intel8_x

It seems nobody is running tests for intel 8 anymore. So, technically, it belongs into the Unsupported category. Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com

Jeff, Jeff Garland wrote:

I like your breakdown although we might need another category like 'experimental' to describe newer compilers that are partially supported or might be supported in the future -- although maybe it's the same as unsupported.

See below.

Anyway, here's how I'd categorize the current set of compilers on the regression page:

Supported; vc7.1 vc8.x intel9_x cw9_4 gcc3.x gcc4.x tru64cxx71-xx

FWIW we just added QNX to this list.

Deprecated: intel8_x tru64cxx65-xx

Unsupported: borland 5_6_x cw8_x dmc gcc2.95.x sunpro vc6 vc7

I know -- that's a pretty aggressive cut in supported compilers, but I think it's time to let boost developers focus on new libraries instead of porting.

Hmm… our disagreement might be mostly about terminology. First of all I was never really happy with the category names but I failed to find better ones. Thinking about it again. The reason might be that we have to deal with two different issues when we talk about compiler support. The easy part are outdated compilers. For those it's easy to say we don't care (that's basically the meaning of unsupported and also in some way for deprecated). The hard part are compilers that just aren't compliant enough to support all of boost without heroic efforts by library writers. This category of compilers is the reason for the weasel wording used to describe the fully supported category. The intend is to say we make a reasonable effort, document the limitations and provide regression tests until these compilers reach the unsupported stage due to obsoleteness. As far as your list of unsupported compilers goes. I do feel uncomfortable with just dropping most of them without first deprecating them. This does not mean we should put effort into improving support for them 1.34 we just should not break them incidentally. As far as sunpro goes I'd like to see that one in fully/partially supported. Thomas -- Thomas Witt witt@acm.org

...

As far as sunpro goes I'd like to see that one in fully/partially supported.

Me too, and there was a message last week in the Sun forums that gives hope that one day this may happen. But for now, the OSL4 sunpro cannot compile a single boost lib. So until we see some sort of upgrade it's not reasonable to expect us to even bother...

Since SunPro 5.3 is the compiler I am using at work I made sure Boost.Test works on it. But I do agree this compiler doesn't worse an effort to support. Gennadiy

...

Since SunPro 5.3 is the compiler I am using at work I made sure Boost.Test works on it. But I do agree this compiler doesn't worse an effort to support.

Sun C++ 5.3 was released in 2001, and has been declared End Of Life. Only limited support is available for it. I am surprised that you are able to get any of BOOST to work with it. You should get the current release, Sun Studio 11 (C++ 5.8). See another post by me in this thread for details.

You tell me ;) Actually believe it not but at some point couple years ago I had big chunk of boost ported for this compiler. Gennadiy

"AlisdairM" <alisdair.meredith@uk.renaultf1.com> wrote in message news:drn7hn$8a8$1@sea.gmane.org...

Jeff Garland wrote:

...

I understand, but that just means 1.34 will be delayed for fixes to these outdated relics and new lousy compilers. We would be better making a clean break now and letting folks with old compilers stick with 1.33.1.

[...]

I will happily assist library maintainers hunting down and eradicating support for older Borland compilers, so long as the most recent is supported (until such time that 'most recent' is reasonably conforming and no longer auto-deprecated when a new compiler is released)

Sorry I do not follow you logic. Why do we need to support old borland compiler with new boost release? Lets support new one. So new compiler users have 1.34 boost support. Old compiler users will keep using 1.33.1. Gennadiy

AlisdairM wrote:

Jeff Garland wrote:

...

I understand, but that just means 1.34 will be delayed for fixes to these outdated relics and new lousy compilers. We would be better making a clean break now and letting folks with old compilers stick with 1.33.1.

That is harsh for Borland users. The new compiler was released AFTER 1.33.1, with which needs to update several workarounds and then config file before compiling as well as BCB6.

Perhapse it would be useful to ship updates that will update Boost.Config and Boost.Build to support the newer compilers.

If 1.34 does not support Borland either you are really hurting these people, as they have a shiny new improved compiler, but no Boost support and three choices:

Boost currently (partially) supports the Borland compiler. If support for the new compiler isn't there, it would be useful to submit a patch to update Boost.Config correctly. I know that the Octonion/Quaternion library failed to compile on older versions due to a strange preprocessor bug. It has been mentioned that the new version fixes a lot of preprocessor issues, so can these libraries be compiled properly now?

I will happily assist library maintainers hunting down and eradicating support for older Borland compilers, so long as the most recent is supported (until such time that 'most recent' is reasonably conforming and no longer auto-deprecated when a new compiler is released)

I would say that dropping VC6 and GCC2.95 are good choices as these are already supported in the older versions of Boost, so the issue outlined above doesn't apply to these compilers. However, dropping support for the Borland compilers (even though I hasven't used them for a long while now) is a different matter, because it applies to the entire compiler chain. I don't agree that Boost should drop all support for the Borland compilers. For those libraries that do support Borland compilers, it would make sense to drop support for BCB5 as this is similar to dropping support for VC6. - Reece

Jeff Garland wrote:

I'm ok with supporting the new Borland compiler if we get someone to regression test it.

That is my key concern, and I believe testing resources will be in place for the 1.34 testing cycle. So long as the newer compiler is supported, my concern for BCB6 is the same as for VC6 and GCC2.95 - one version notice of 'deprecation'.

I don't see the issue this way. The main problem for library authors is that any new code changes might break the fragile workarounds that keep regression tests working for Borland. Then a note needs to go in some documentation to explain this feature isn't available, etc. So with every change we are 'walking on eggshells'. It's this time that I want poured into new library development instead.

I understand. I wish I wasn't in the position of asking for this stuff ;?) I am very happy for new libraries to only target conforming (or close) compilers - although if I find easy patches you can be sure I will be trying to submit them <g> I still haven't entirely given up on finding workarounds for the graph library ...

I don't agree. If at some future point Borland comes up with a new compiler that is better I think we would welcome it and support it vigorously.

I think you misunderstood me here. The point is that every time Borland produce a new compiler, there is no 'old version' of *Boost* for customers to fall back on for legacy support. They need a new config, and some workarounds updating to check for the new compiler version. It doesn't help Borland has some of the nastiest configs, with 3 different standard library suppliers in the last 3 releases, a public beta compiler with a higher version number than the actively maintained product line, a brief flirt with a Linux compiler, and at least one version supporting two different Standard Libraries requiring distinct workarounds. I look forward to retiring a lot of these older workarounds as much (if not more) than anyone! -- AlisdairM

Loïc Joly wrote:

While I hate this compiler, and I understand why maintaining it has a huge cost, I think that maybe for one of two years, this can still have some impact.

Can't people still working with this just use 1.33.x version of boost? That won't suddenly stop working. The same goes for the other compilers in the list. And yes, we use Borland 5.6.4 and so we've just been proposed to be dropped, but given that some libraries already have stopped supporting it, such as ublas, spirit (that ships with boost) and it was also mentioned a while back that the new filesystem lib won't, the we have trouble moving forward because we make use of these libraries. Cheers Russell

AlisdairM wrote:

Borland is still a moving target. The IS no supported version of boost for the current compiler, and if support is dropped now there will never be one.

Borland 5.8.x isn't on the list of anything. I thought that could be added in to the list of 'supported' compilers as it now is under development and support again by Borland. Cheers Russell

Jeff Garland wrote:

I have no problem with moving up to the 5.8.x series compiler and supporting it to keep a Borland option alive. The only problem is at the moment we have no regression tester for it at the moment. And from what I've read on this list it isn't much better than the old compiler. So even this is alot of work for a compiler not many will likely be using.

That is true, at the moment, that the 5.8.x isn't much better in terms of compliance (but does have quite a few bug fixes from code-gen point of view etc). Now that C++Builder has active support again (as opposed to the rumoured support that there was with BCB6), Borland will start to update the compiler in terms of compliance with the next release (which I think is due out later this year). They do now use Dinkum for the STL rather than an old version of STLPort so hopefully that will help with some of the workarounds. Cheers Russell

I personally don't see the problem in saying that in order to get VC6 (and GCC2.95) support for boost use version 1.33, and have VC6 be unsupported in version 1.34.

I believe this is very important point: By saying that particular compiler isn't supported in release a.b we saying just that. Anyone is free to use existent working version of the library for this compiler. But for future development we do not want to support this anymore. So we drop it from regression testing and get read of all workarounds. Getting said that, my position is that there is no since anymore to produce/support workarounds for the ancient compilers. We should just make a clear break and move toward more conformant ones. Gennadiy

Reece Dunn <msclrhd <at> hotmail.com> writes:

Loïc Joly wrote:

...

Thomas Witt a écrit :

...

...

vc6

I know that this compiler, however old, still has a wide usage in the industry. For instance, my previous work place (a 130000 employees company) used it almost exclusively, and most of its partners did so. In my new workplace, we switched 1/2 months ago, but still need to support it.

I agree that there are still a lot of companies that are still using VC6, mostly because of the effort that would be involved migrating to VC7 or VC7.1. However, Microsoft dropped regular updates over a year ago and have now dropped *all* support for this compiler.

Well, MS has a commercial interest in promoting its newest IDEs, but the sad reality is that VC6 is still in wide use today. I think the following (ongoing) poll in CodeProject gives much interesting info: Poll: Which IDE are you using for Visual C++ development? http://www.codeproject.com/script/survey/detail.asp?survey=537 Current results show that **39%** of respondents still cling to VC6 rather than 7.x or 8.0. Many of them do so out of necessity, because they can't assume porting some project to a newest IDE --and, curiously enough, some like VC6 IDE better !! So, we are not talking about a dead compiler or a couple of die-hard users. My proposal is that vc6 is marked deprecated but some care is taken not to break things gratuitously --in particular, foundation libs like config, test and core components as for instance shared_ptr. On the other hand, it is perfectly reasonable to assume that new libs won't support vc6, and that existing libs will add features not available to vc6 users. Retaining some sort of support for older compilers involves some work, but it is not such a gigantic effort IMHO, and the aforementioned poll shows there's still a potential vc6 users target to care about. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

On Tue, 31 Jan 2006 13:40:29 +0100, Sebastian Redl wrote

Joaquin M Lopez Munoz wrote:

...

Current results show that **39%** of respondents still cling to VC6 rather than 7.x or 8.0. Many of them do so out of necessity, because they can't assume porting some project to a newest IDE --and, curiously enough, some like VC6 IDE better !!

So there are lots of people using VC6 in order to support legacy projects. Is there any good reason why these legacy projects need support from a new Boost release? A lot of arguments here sound as if people are afraid that Boost will completely remove everything that ever worked with the old compiler. But if 1.34 drops support for compilers, there is no doubt that 1.33 will still be available for download.

Yes -- past releases remain available for download. We might need to draft some language on the web-site somewhere to point users of old compilers to a particular release.

Those that simply like VC6 better I have no pity for. I have been using 6, 7 and 7.1 and I definitely see no significant advantages to the old IDE - rather the other way round. IntelliSense in VC6 was horribly broken, for example. That's not to mention the compiler itself.

For me it comes down to this. Boost is a project about the future of C++, not the past. If we don't spend our energy working on the future then, well, it will be like the past. We need to spend more time and energy focusing on the future now... Jeff

Jeff Garland wrote:

Anyway, here's how I'd categorize the current set of compilers on the regression page:

Supported; vc7.1 vc8.x intel9_x cw9_4 gcc3.x gcc4.x tru64cxx71-xx

Deprecated: intel8_x tru64cxx65-xx

Unsupported: borland 5_6_x cw8_x dmc gcc2.95.x sunpro vc6 vc7

Even ACE is dropping support for vc6 and vc7 in the upcoming version 5.5 along with KAI C++, Visual Age 5, CBuilderX.

I know -- that's a pretty aggressive cut in supported compilers, but I think it's time to let boost developers focus on new libraries instead of porting.

For me it comes down to this. Boost is a project about the future of C++, not the past. If we don't spend our energy working on the future

Yes. Jeff Garland wrote: then, well, it

will be like the past. We need to spend more time and energy focusing on the future now...

Right let ACE worry about the past :) KevinH -- Kevin Heifner heifner @ ociweb.com http://heifner.blogspot.com Object Computing, Inc. (OCI) www.ociweb.com

Aleksey Gurtovoy <agurtovoy@meta-comm.com> writes:

...

Unsupported -----------

No regression testing is done. (Library authors might still support these toolsets for their libraries on a case by case basis.)

We can't actually _prevent_ somebody from running regression tests for an "unsupported" toolset, nor do I think that we want to. I'd say if one has the resources to run the tests and interested in seeing / posting the results (however pitiful), they should go right ahead. IMO "unsupported" status just makes an individual developer's decision to ignore these results uncontroversial.

I agree. -- Dave Abrahams Boost Consulting www.boost-consulting.com