From: Ulrich Eckhardt (eckhardt_at_[hidden])
Date: 2005-03-01 18:50:41
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
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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk