Re: [Boost-build] Did anyone try building Boost for WindowsMobilewithout STLPort?

Subject: Re: [Boost-build] Did anyone try building Boost for WindowsMobilewithout STLPort?
From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2009-12-10 14:24:27

"Max Motovilov" <max_at_[hidden]> wrote in message 
news:hfrcrs$k0m$1_at_ger.gmane.org...
>> I'd be interested in those extensions. Are they available publicly?
>
> Not at the moment, because in the rush to deadline [(TM):)] I did not 
> attempt a clean separation of pure extension code from the proprietary 
> code that properly belongs to my client. I really ought to, but it'll have 
> to wait until the deadlines are met.

Sure, no problem.

> I understand that David Deakins @ VeecoFTC is pursuing similar goals as 
> well. He even pointed me to his proposed extensions to STLPort but [I am 
> ashamed to say that] I still did not review those to see how much overlap 
> they have with what I've been developing.

I guess everybody trying to run Boost on WinCE has come across one of 
David's posts or his test runner results for WiMo5. He's hard to miss. His 
patches have been applied to the 5.2 branch of STLport. I'm using the latest 
version of that branch (which should eventually become the 5.2.2 release).

> At any rate, I am suddenly faced with a few problems within STLPort itself 
> (failures to properly clean up its global data structures when a DLL is 
> unloaded) that really suggest trying a pure MS STL build.

Thanks, I'll keep that in mind. Although I guess we'll not be forced to 
unload DLLs.

>> I'm currently in the process of setting up Boost + StlPort for WinCe 
>> myself. So, I'd be interested what problems you've run into.
>
> Heh. The extreme complexity of the Boost.Build system, first of all :) 
> Without David's configuration files I'd be floundering for much longer.

Yeah, he must have gone to hell and back to figure out that configuration. 
I'd probably have given up long ago without the knowledge that David has 
already done it.

> After that, there were a few conspicuous POSIX APIs missing that were easy 
> to either stub or replace using the wcelibcex functionality (for some 
> reason, the latter mostly provides renamed POSIX APIs so an extra layer of 
> headers is required for forwarding).

:-), I have come across wcelibcex today and will implement such headers next 
week. Curious, how they provide a lot of POSIX functions, but all with those 
pesky prefixes. I wonder what the was rationale for those!

> That took care of the header-only libs that I use and of the regex. I also 
> needed filesystem and there I had to implement a number of Win32 APIs 
> missing from CE as well as remap some of the returned errors (now probably 
> unnecessary with trunk code as Beman Dawes recently accepted my patches) 
> and in some instances, add char* versions for the existing wchar_t* APIs.

Ok.

>> FWIW, I've tried and failed. The main problem lies in the fact that a few 
>> standard headers (e.g. <locale>) are simply not available in the MS std 
>> lib that comes for CE. Many of the Boost libs fail to build because they 
>> include one of those headers. I haven't even attempted to use any of the 
>> header-only libraries.
>
> That's true about <locale> -- but I have not yet investigated which of the 
> dependencies could be either rid of by configuration settings or stubbed 
> out. Was hoping that someone did :)

I guess it all depends on what Boost libraries you plan to use. Among 
others, we want to use date_time, filesystem and regex. IIUC, then these in 
one way or another depend on <locale>.

Thanks & Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.