Hello guys, Unfortunately, during the period I was off, the team descoped compiling Qpid-dispatch on Windows due to time constraints and arrival of tasks with higher priorities. So Neither Alexandre nor myself will be able to work on this anymore at least in the near future. Nevertheless, the issues I reported are all the issues I could find. Sorry for the inconvenience,Adel
> Subject: Re: [Qpid-dispatch] timespec not defined on Windows > To: [email protected] > From: [email protected] > Date: Thu, 28 Apr 2016 09:04:47 -0400 > > > On 04/28/2016 05:16 AM, Alexandre Trufanow wrote: > > Hi guys, > > > > I'm taking over Adel's work on porting the dispatcher, I have a few > > additional comments to make. > > > >>>> *@Chuck,* > >>>> I took a look at Qpid C++ broker model but the main issue is it is > >>>> C++ > >>>> oriented whereas the dispatcher is mainly C. I tried to switch the > >>>> compiler > >>>> of Visual studio to C++ and got a lot of errors. So I prefer to stay > >>>> on a > >>>> full C approach for the time being to gain time. > >>> > >>> > >>> For dispatch that makes sense. We want to keep the main dispatch > >>> codebase in portable C and minimise the platform-specific variations. > >>> > > > > To make things clear, the idea is to use the C++ compiler of MSVC instead > > of the C one. This is the strategy used by proton for compiling on windows, > > as C99 support is much better with the C++ compiler. Unfortunately, this > > approach adds some ugliness to the code (notably extern "C" {} blocks in > > the header files). This does have advantages though, such as support for > > the inline keyword. > > > >>>> > >>>> *@Alan,* > >>>> I am actually in the phase of discovering what are the issues to make > >>>> the > >>>> dispatcher compile and run on Windows. So I haven't really focused on > >>>> finding the best alternatives. > >>>> Nevertheless, I took a quick look at the libuv and its implementation > >>>> and I > >>>> find it very similar to what I was going to code on Windows. So it is > >>>> worth > >>>> checking. My other alternative was to use an adapted in-house code. > >>> > >>> > >>> Great. I'm going to give libuv a shot, if it works it might kill > >>> several birds with one stone (Linux, Posix, Darwin, Windows and > >>> Solaris) If it doesn't work we can fall back to per-platform solutions. > >>> However I'm keen to get an updated IO driver into dispatch with the > >>> goal that any IO driver we build for proton can slot in to dispatch > >>> without changing dispatch. That way we'll get wider testing & > >>> optimization of common IO code than if dispatch has its own. > >>> > > > > I agree that using libuv would allow for better IO compatibility. However in > > order to fully take advantage of this, it should be added as a dependency on > > Linux. It doesn't make sense to have two competing implementations of the > > OS specific code if one supports all platforms. > > > > @Ted: You have previously stated that you don't want to add any external > > dependencies for Linux, is adding libuv acceptable for you in this case? > > What I said was that I didn't want to introduce a Boost dependency in > Linux to support Windows. If libuv is an effective way to bring an > epoll driver into Linux, then I think that would be acceptable. This > would add value to both platforms. > > > > > For now I am working on the other parts of the code which are incompatible. > > > > Another thing which has come up is implicit conversion of int types. MSVC > > 2013 throws a lot of warnings related to implicit conversions between types > > (unsigned int, size_t, pointer math). A lot of these errors are probably > > fixed > > by changing types to size_t. > > > > Are there any places in the code where we should watch for the > > performance impact of these changes? Specifically some places such as > > qd_composite_t use uin32_t explicitly. > > The explicit uint32_t vales in qd_composite_t are matched to 32-bit > length and count fields defined in the AMQP specification. We should > take these instances on one-by-one. I'd be happy to help with this. I > do have access to the MSVC environment. > > > > > A > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
