[config] evc4 port

[vividos]

This patch is a port for evc3/4 targeting Windows CE.
Reason for the changes in auto_link.hpp: STLport with
evc4 cannot be compiled in _STLP_DEBUG mode; the
compiler issues wrong ARM code and _STLP_DEBUG mode
cannot be used with evc4 ARM. I also introduced a new
file wince.hpp in boost/config/platform/, since the
defines in the _WIN32_WCE part got too big.

[John Maddock]

Logged In: YES 
user_id=14804

I notice that the patches are arm-specific, surely VC8 can
be used to target other processors?

John.

[vividos]

Logged In: YES 
user_id=124874

The only change I made is to rename "evc8" to "msvc8-arm",
but since I don't know exactly how to differentiate
processors in msvc8 I simply put "msvc8-arm". A possible
msvc8 porter has to decide that.

I updated the patch since I found another issue: there's no
static C runtime for Windows CE, so autolinking always
chooses "-gdp" now. Please disregard the first patch.

[Mateusz Loskot]

Logged In: YES 
user_id=736047

Hi,

Michael:
Thanks for your effor to make Boost more Windows
CE-friendly. Some time ago, I also started to use Boost with
eVC++/VC++8.

John:
VC++ 8.0 brings the whole set of compilers for Winodows CE
platform: clarm.exe, clmips.exe, etc.
Here is a list with preprocessor macros to check target arch:

http://www.smartphonedn.com/qa/checkos.html

Here is a table that explains how to map devie arch from
eVC++ 3/4 to VC++ 8.0:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnppcgen/html/migrating_evc_vs2005.asp

Also, biuld system should define appropriate symbols:
-D _ARM_ -D ARM -D _arm_
-D _MIPS_ -D MIPS -D _mips_
etc.

Cheers

[John Maddock]

Logged In: YES 
user_id=14804

Some more comments and questions:

Shouldn't 

#ifndef _CPPUNWIND
#  error C++ Exception handling is not switched on, which is
neccessary for Boost! Please add /GX to your compiler options.
#endif

be:

#ifndef _CPPUNWIND
#  define BOOST_NO_EXCEPTIONS   
#endif

I'm also concerned about hard coding the value of
_WIN32_WINNT: this is very bad manners at the very least!

Finally, shouldn't those C functions be defined in namespace
std?  I presume that the header needs to include <cstring>
as well otherwise I don't see how it can possibly compile.

John.

[msclrhd]

Logged In: YES 
user_id=761714

I am working on providing support for WinCE platforms by
extending the BBv2 msvc.jam toolset. See
http://www.reece-dunn.co.uk for the updates.

I am adding the -DARM, -DWINCE, etc. as required by the
platforms as well as adding -machine:ARM4, etc. to the
linker. It is still very much a work in progress, so help
getting this working would be very much appreciated.

- Reece

[John Maddock]

Logged In: YES 
user_id=14804

Thanks Reece that would be very useful, if you can put
together a better config setup than the one provided here
that would be great: it still doesn't look right to me, but
I don't have embedded VC8 to test with so I can't really tell.

John.

[msclrhd]

Logged In: YES 
user_id=761714

John, I agree with your comments about _CPPUNWIND and
_WIN32_WINNT. I thought that _WIN32_WINNT should *not* be
defined. Here are some comments:

[1] The check for WinCE uses _WIN32_WCE >= 400 -- shouldn't
this be _WIN32_WCE >= 0x0400?

[2] Report a warning if _WIN32_WCE < 400 or not defined!

[3] Issue an error/warning if any of the following are
defined: WIN32, WIN64, _WIN32_WINNT, _WIN32_WINDOWS and WINVER.

[4] Issue an error if any of the following are not defined:
WINCE, _WIN32_WCE and UNDER_CE.

[5] Ensure that WIN32_PLATFORM_PSPC (PocketPC) and
WIN32_PLATFORM_WFSP (SmartPhone) are not defined together.

[6] Ensure that _WIN32_WCE and UNDER_CE have compatible,
sensible values.

[7] I don't like the idea of always providing the C API
directly -- what if some other project (like ATL/WTL)
defines these!

[8] This should be merged with win32.hpp -- that already has
a _WIN32_WCE section and defines other things related to
Windows not present here.

[9] Do we want to distinguish between Win32/64/CE in
win32.hpp. If so, I suggest having:

-#define BOOST_PLATFORM "Win32"
+#if defined(WIN32)
+#  define BOOST_PLATFORM "Win32"
+#elif defined(WIN64)
+#  define BOOST_PLATFORM "Win64"
+#elif defined(WINCE)
+#  define BOOST_PLATFORM "WinCE"
+#else
+#  error Unrecognised Windows platform.
+#endif

- Reece

[vividos]

Logged In: YES 
user_id=124874

In response to user msclrhd:

[1] It's 400, check STLport's evc config if unsure.

[2] Reporting a warning when _WIN32_WCE < 400 is sensible,
since evc3 probably cannot use most of Boost. Checking if
_WIN32_WCE is defined at all is not sensible, since then
wince.hpp wouldn't be included at all. See win32.hpp.

[3, 4, 5, 6] Well, I'm not responsible for the user to mess
up his defines, so it's his problem. The only define used is
_WIN32_WCE.

[7] There are several other libraries that try to provide
missing C APIs. Do you have a suggestion how to solve this?

[8] I moved it out of win32.hpp since it got too large.
Check out the patched win32.hpp to see how the file relates
to wince.hpp

[9] Since the patch is only meant to be a port for evc4, I
didn't do this change.

I changed the patch so that it doesn't redefine _WIN32_WINNT
anymore. It seems that wasn't needed. I also now define
BOOST_NO_EXCEPTIONS when _CPPUNWIND isn't defined.

[vividos]

Logged In: YES 
user_id=124874

I updated the patch for the current 1.34 CVS branch. I
removed the wince.hpp again, since it mostly defined
standard C library functions that are missing on evc4, and I
think that sould be done with some other libs. I removed the
defining of BOOST_NO_EXCEPTIONS again when _CPPUNWIND is not
enabled, since that's already done in visualc.hpp. I also
removed the define for TLS_OUT_OF_INDEXES that's needed for
evc4 in Boost.Threads, since that should probably go there.

[John Maddock]

I'm closing this issue down because we now (finally!) have someone running the regression tests on the Windows Mobile 5 Platform, and making the appropriate patches to get Boost working there.