[boost] patches for embedded VC4

From: Ulrich Eckhardt (eckhardt_at_[hidden])
Date: 2005-03-01 18:50:41

Hello!
I'm currently trying to port Boost to embedded Visual C++ 4. Attached are a 
patch against this afternoon's CVS and toolset definition for Boost build v1.

Some explanations for the patch:
---------------------------------

EVC4 comes with several different compilers, all of which are cross compilers 
for various architectures. Else, those compilers are mostly bug-to-bug 
compatible to the one that comes with VC6. One problem though is that e.g. 
the ARM compiler has _MSC_VER=1201 while the MIPS compiler has _MSC_VER=1202 
and the one for x86 has _MSC_VER=1200 (like VC6). 

The C++ standardlibrary is IMHO barely worth talking about, anything but the 
most primitive types of use require STLport, unfortunately in their yet 
unreleased version 5 (use 'cvs checkout -r STLPORT_5_0 STLport' in case you 
want to try). There are a change to boost/config/stdlib/stlport.hpp that is 
required for STLport 5.

If you look at the patch, you will see that most changes are explained by 
removing '#if _MSC_VER==1200' in favour of '#if _MSC_VER<1300'. At first 
glance those are not really equivalent, but there are some considerations 
that will make it sensible:
- if (which I doubt will ever happen) there come any updates to those 
compilers they will still have version numbers < 1300
- if VC6 and similar suffer a defect, chances are good that older compilers 
also suffer the same problems
- there is a line that generates an error anyways should you try to compile 
boost code with <1200, older compilers are simply not supported.

Another set of changes is that sometimes the use of '#pragma once' was made 
dependant on _MSC_VER>=1200, while other places used _MSC_VER>=1020. MS 
themselves use _MSC_VER>=1000. I think this pragma was already supported long 
before VC6, so the second alternative seems to be right. I replaced a few of 
such cases.

I noticed that some places use BOOST_WORKAROUND while others use _MSC_VER 
directly. For #pragma once that makes still sense, since you don't want to 
first include the header for the macro, but in other cases I'm not so sure. 
Is there a tendency to uniformly use BOOST_WORKAROUND? If so, and since I'm 
touching a lot of those checks already, should I replace those?

The change in boost/detail/lwm_win32.hpp is something where I don't claim I 
really understand what it does. Removing it breaks compilation, I don't know 
how to test if it really works.

The changes in boost/function/function_template.hpp are something that 
shouldn't break anything, except if the brackets where in fact an 
undocumented workaround for some other bug....

Working on this, I noticed that some files I checked out of CVS were write 
protected!? Is that just my setup, intentional or by accident? I didn't 
investigate further.

Some explanations on the toolset file:
---------------------------------------

This is far from complete. There are several architectures that aren't yet 
supported, some aren't even supported by STLport (yet). Lots of debug code 
are still present. This also requires changes to some other places, in 
particular the names of libraries need to be changed, for autolinking in the 
headers, for building in some part (I forgot which) of the build files.

Also, I found that MS Windows CE suffers from not being able to load DLLs with 
names longer than 31 chars, meaning that the normal boost naming conventions 
can't be used. This is a major bummer, but I don't see a workaround other 
than that.

I'm throwing this work in progress at the list so I can get feedback earlier. 
So, if there are issues, don't hesitate to bring them forth.

cheers

Ulrich Eckhardt