Rene Rivera wrote:

Douglas Gregor wrote:

...

The source code for Boost 1.33.0 is now frozen. Please do not check in any changes to the Boost source code without my explicit permission. You may still update parts of Boost that do not affect the regression tests in any way, until we have our final freeze of the entire tree at 11PM EST on Wednesday.

Two things...

1. It figures that shortly before the code is frozen the CW serialization test *all* start breaking.

I did make a change in the hope of getting the last CW serialization failures to pass. I was extremely coginizant of the 11PM EDT and make the final changes before that deadline. At this point the only pending fixes would be some endian issue with a couple of compilers - e.g. acc . This only effects one demo and is not really an issue with the serializaiton library per se. My only concern is that as far as I know - all test has been in debug mode.

From personal experience I suspect that this is not complete

2. Are we allowed to change status/expected-results.xml? To at minimum document the rest of the CW failures.

I believe documentation has a later due date. RObert Ramey

Douglas Gregor wrote:

On Jul 24, 2005, at 11:40 PM, Rene Rivera wrote:

...

1. It figures that shortly before the code is frozen the CW serialization test *all* start breaking.

If you and Robert can find a solution that doesn't shake things up too much, preferably one that's BOOST_WORKAROUNDed for this compiler, I'll allow it.

Thanks. I checked in a minor change to get things compiling again. And thankfully it was already in a BOOST_WORKAROUND guard :-) Bad new for Robert is that the code change he did doesn't seem to help the previous failures for CW. That is the failures to register the indirect polymorphic pointer types with the archive type map. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

On Jul 25, 2005, at 10:06 AM, Robert Ramey wrote:

I'm pretty satisfied with the way things are. I feel we've done all we can for now.

Okay.

c) The only thing left that might be addressable are issues with endian.hpp on some platforms such as acc. Also a very minor issue as far as I'm concerned. But I do think that if a header such as endian.hpp evolves into a defacto boost library component, an attempt should be made to have it supported on all platforms. May the serialization demo that uses it is the only test of it.

We should solve this post-release. Doug

David Abrahams wrote:

"Robert Ramey" <ramey@rrsd.com> writes:

...

b) I was very disappointed that Comeau couldn't be made to work. The library does in fact build with this platform. But due to some sort of interaction with the Boost Test library, the tests won't link and can't be run. For all I know it would work with user code. I realize that Comeau isn't on the "required" list so its not a release issue

Did you know that Comeau doesn't support dynamic linking (at least last I checked)? You might need to force static linking to get your tests to work.

I brought an issue up regarding Comeau over this past weekend. Using como-win32, when one goes to build Boost libraries after the install, most libraries attempt to build dll versions along with lib versions. This fails with Comeau, because it does not support building dlls. Furthermore because some libraries ( date_time and program_options ) also set BOOST_ALL_DYN_LINK when building their dll versions, and because config/platform/win32.hpp sets BOOST_HAS_DECLSPEC even with como-win32 and como-win32 does not support this extension in strict Ansi mode, which is set during the build process for that compiler, the errors which come up in that case are numerous and fill the output. I realize that not too much work has done with Comeau as far as the Boost build process is concerned but I think that something should be done to circumvent dll builds of libraries for Comeau in the normal Boost build process. There are other issues when attempting to build libraries with como-win32 but I will bring them up elsewhere.

Rene Rivera wrote:

Edward Diener wrote:

...

I realize that not too much work has done with Comeau as far as the Boost build process is concerned but I think that something should be done to circumvent dll builds of libraries for Comeau in the normal Boost build process.

Must have missed the first mention :-\ The attached patch to tools/build/v1/boost-base.jam prevents DLLs (and other shared objects) from getting built with como. Unfortunately this will cause regression testing to break as the test Jamfiles are not designed to handle dependent targets not getting built. So if Doug thinks it's important to fix this for release I can investigate further to make testing work under these conditions.

I did not mean that the change should take place in Boost build for 1.33 but I think it needs to take place for the future for those who try to use Comeau. I will bring up other Comeau issues in the Boost build NG.

Wow - that's news to me. On my local system I tweaked my Jamfile for testing to include a requirement<como><*><runtime-link>static and seems that most serializaiton is starting to work. Robert Ramey David Abrahams wrote:

"Robert Ramey" <ramey@rrsd.com> writes:

...

b) I was very disappointed that Comeau couldn't be made to work. The library does in fact build with this platform. But due to some sort of interaction with the Boost Test library, the tests won't link and can't be run. For all I know it would work with user code. I realize that Comeau isn't on the "required" list so its not a release issue

Did you know that Comeau doesn't support dynamic linking (at least last I checked)? You might need to force static linking to get your tests to work.

Do you remember how many machines were affected? At the moment, only "mslater" reports these failures, the tests of Andreas Huber are ok. I can't reproduce the problems on my machine(s), either!

Sorry my mail went down a few days ago and has only just come back so I didnt see this. Heres a copy of a mail I just sent dave about this issue. Martin ----------------------------------------------------------------------- Hi Dave, Thats strange, it seems to be coming from compressed pair which I seem to remember mentioned with problems on the dev list not too long ago and hasn't changed in nearly 2 months. Unfortuantely my email went down a couple of days ago so I haven't been keeping track. Another run is due to complete soon (within the hour I hope) so if its still there i'll check into my end and see if I can turn something up. If it helps I never do an incremental test run they always start from scratch. Also I just remembered that the box its running on isn't vanilla vc7.1, we had to install a hotfix (http://www.kbalertz.com/kb_883655.aspx) to get around internal compiler errors where we were including a lot of boost headers. Possibly I should just not test on this machine, and at the least i'll put a note in my comment.html about it. Martin -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.9.5/58 - Release Date: 25/07/2005

--- Douglas Gregor <doug.gregor@gmail.com> wrote:

...

I just noticed a trivial but nasty problem in one of the Boost.Python tests. Python stipulates a certain include order. pointer_vector.cpp doesn't adhere to the requirements. This leads to failures on some platforms (at least Tru64/cxx). It would set a bad example to release the code as is. Would it be OK to check in the simple fix below?

Looks harmless. Go ahead.

Thanks! I committed the change to the trunk. Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Hartmut Kaiser wrote:

Douglas Gregor wrote:

...

The source code for Boost 1.33.0 is now frozen. Please do not check in any changes to the Boost source code without my explicit permission. You may still update parts of Boost that do not affect the regression tests in any way, until we have our final freeze of the entire tree at 11PM EST on Wednesday.

I don't know how to handle the Wave failures which recently appeared on vc-8_0 without changing anything in the code base. Moreover the vc-8_0 tests now fail on a different test site (gonzalo), were they used to pass on other sites not providing results for this compiler anymore.

VC8 is still a beta product and subject to change from Microsoft. While it is great that Boost has made an effort to track and support it as much as possible, I personally do not think it is the responsibility of Boost to support a product that is still beta and is still changing. Perhaps when VC8 is officially released, and as Boost keeps tracking how well various libraries support it, a point release could be put out which supports it officially . But it does seem foolish to have to worry about officially supporting a moving target which is not yet a finished product.

Pavel Vozenilek wrote:

Wave executable could have feature for use in makefiles or makefile generators.

Often the header dependencies are generated by compiler running in special mode outputting only dependency information.

For example: --------------------------------- cc -M -I... -D... foo.c

generates output like:

foo.o : foo.c foo.h stdlib.h

This output is then fed into makefile to correctly deal with rebuilts. ---------------------------------

Wave could get this functionality too: invoking wave.exe may be faster or more convenient than running full compiler or a makedepend utility.

Most likely output consisting from only space separated dependent headers (no *.obj, no foo.c itself) is the best ouput as the text is futher manipulated.

Other possible options could be:

* ignore system headers (some compilers have -MM option for this) * ignore STL/Boost headers * ignore the <windows.h> and other MS specific headers * ignore specified directories or names fitting certain pattern * ignore read only headers

It should be fairly simple to write a tool based on the Wave library implementing all or some of your suggestions. All of the required information is available from the library by having appropriate callbacks. Do think it's better to implement these in aseparate tool or is it beter to add them as additional options to the wave driver executable? Do you have a concrete use case for your suggestions? Regards Hartmut

Damien Fisher wrote:

I was actually thinking of writing this exact tool using wave earlier today, so count me in as someone who would find it *very* useful.

You might like to play around with "gcc -M" (which enables this feature for gcc).

Yeah, I've seeen this (the Intel compiler has similar capabilities). Are you still interested in writing such a tool? I'm asking because I probably won't have so much time for this during the next couple of weeks. Nevertheless I'd be ready to help to get you started. BTW: There is a Wave sample (list_includes) which allows to list all the include files found during preprocessing, AFAIR I've even added this as an option to the wave driver executable. One final remark. You'll have to to know, though, that the generated output of such a Wave based tool will be very specific to the environment it is used in, i.e. it will list only files 'visible' to the preprocessor. For instance in the following example the file something.h won't be listed as long as the constant BLABLA isn't defined. #ifdef BLABLA #include <something.h> #endif Regards Hartmut

I'm not sure I quite understand what you are asking for here...could you give an example? On 7/28/05, Stefan Seefeld <seefeld@sympatico.ca> wrote:

What would make such a tool even more useful than a replacement for 'gcc -M' would be if it could generate dependencies for sets of files, i.e. with the possibility of internal caching such that it doesn't have to reparse a file twice if not necessary. But that may require quite some work, for example to determine a 'state' dependent on values of all the defined macros.

Regards, Stefan _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Damien Fisher wrote:

I was actually thinking of writing this exact tool

Me too, except I was going to ask someone else to write it ;-)

using wave earlier today, so count me in as someone who would find it *very* useful. You might like to play around with "gcc -M" (which enables this feature for gcc).

Just about every compiler can do this, VC being a notable exception; VC has the /showIncludes option which outputs messages to stderr. Jonathan

Felipe Magno de Almeida wrote:

On 7/26/05, Pavel Vozenilek <pavel_vozenilek@hotmail.com> wrote:

...

Hello Hartmut,

Wave executable could have feature for use in makefiles or makefile generators.

Wave could get this functionality too: invoking wave.exe may be faster or more convenient than running full compiler or a makedepend utility.

I think it would be a very useful feature to make it easier to create a better-portable build system. But I'm not certain if it wouldnt be better to write a new tool for this or include it in wave.

I don't know whether the build system may benefit from such a tool, even more as bjam already is capable of scanning the dependencies. But having the freedom to generate a data format fitting to whatever needs we may have is certainly an advantage. But you're probably right that we should start of with a separate tool. If it proves to be useful it may be incorporated into the wave driver executable later on as well. Regards Hartmut

On Jul 27, 2005, at 12:06 PM, Ralf W. Grosse-Kunstleve wrote:

--- Douglas Gregor <doug.gregor@gmail.com> wrote: Hi Dough,

You know, at my defense, the cake that came from the local grocery store said "Congratulations Dr. Dough" before my mother noticed and had them correct it :)

Coincidentally HP released a field-test (beta) version of the new Tru64 cxx compiler two days ago. The new compiler is based on EDG 304. Diagnostics from this front-end made it clear to us that a GCC-specific workaround in one of the Boost.Python tests should be universal. See the tiny patch below. Clearly this patch is not super critical since it is only for a test file, but assuming a time span of 6-12 months before the next Boost release, the problem may upset a fair number of people testing with new compilers. To eliminate this possibility, could we still check in the patch?

Unfortunately, no, it's too late to make any code changes. I'm hoping that it won't be 6-12 months before the next release so that this won't affect too many people. Doug

On Jul 27, 2005, at 1:53 PM, Hartmut Kaiser wrote:

I have two typos to fix in the Wave docs. Is it possible to check those in?

Yes, go ahead. Doug