On Sunday 10 July 2005 12:13, John Maddock wrote:
I ported large parts of Boost 1.32 to embedded Visual C++ 4 some time ago. One of the major changes was because the included cross compilers reported _MSC_VER somewhere in between 1200 and 1202. IOW, a plethora of cases that checked ==1200 or >1200 failed to work for a few of them.
I already once submitted a patch, but it hasn't been incorporated yet, so here is one against CVS from this afternoon. The changes I made were mostly mechanical:
My mistake, I think I promised to apply that, but never got around to it.
Maybe also mine, as I didn't separate changes in a clear way - the compiler detection is just one of a few steps. Others have to do with the different native API, the restricted C standardlibrary and the disastrous C++ standardlibrary.
MSC_VER <= 1200 -> MSC_VER < 1300 MSC_VER == 1200 -> MSC_VER < 1300 MSC_VER >= 1300 -> MSC_VER > 1200
That last one is wrong, I assume you meant to type:
MSC_VER >= 1200 -> MSC_VER > 1200
I don't exactly remember what I was thinking, but I hope the changes are more right than this thinko. Thank you for proofreading.
Some other changes were that I corrected a few comments that spoke of only VC6, but there are too many of them - I didn't get them all. Another change was that I prepared the autolinking feature for evc4.
The autolink changes look OK, but do they they match the names that bjam produces (assuming you can compile at all with bjam with eVC++)?
No, preparing bjam or boost-build is another set of necessary changes, I just prepared the name-tag("evc4"). One problem with bjam is that the compilers all have different names like clmips.exe for the MIPS targets. However, this is reflected in the %CC% environment var after running the appropriate batch file, so the situation is not that bad. Another thing is that evc4 is a cross-compile environment. In fact I had boost build v1 patched so that one could compile for a limited set of targets, but it was pretty messy. Also, v1 seems to be mostly dead, so I was told to use v2, which was too much work at that time - I simply created a project-file for the eVC IDE that built the threads lib and was fine with it. Another problem is the fact that the runtime linker silently and mysteriously fails to find DLLs whose name is more than 32 characters and libboost_thread-evc4-mt-gdp-1.32.dll is just a few characters too large. Since evc4 offers no choice between singlethreaded and multithreaded, I'd just drop that '-mt', that way at least (didn't try others) the threads library works. I'll post more patches on the other necessary changes later. Uli