Lars Gullik Bjønnes wrote: > | Lars Gullik Bjønnes wrote: >>> Sure it is nice to compile on more than one compiler... but if the >>> result is muddier code then I am not sure about the gain. (and not >>> that I have not said that this is the case, just a thing to watch out >>> for. and we already see quite a bit of preprocessors tokens entering >>> code...) >> > | Sorry, Lars, but to quote Asger, that is just FUD. Try: > > So drop the last sentence of the parantesis. The rest stands.
I think that we're both keen that the code does not become muddied. Code muddied with preprocessor tokens usually means that a necessary abstraction isn't in place. If you look again at Asger's patch, you'll see that almost all of the remaining #ifdef _WIN32 kludges are caused by the lack of a LyX abstraction for named pipes and sockets and by the currently inadequate abstraction for external processes. I'd propose that giallo should be used for the named pipes and sockets, but not until after 1.4.0 is released. I.e., the lyxserver and lyxsocket should be disabled on LyX/Win 1.4.x. Reworking our existing child process code to move the *nix-specific code in ispell.C (that handles redirection of the child's stdin/out/err streams) behind our ForkedCall interface is easy enough. Thereafter, we'll need some Windows-specific code to do this and to tell us when a child process has exited without blocking until it has done so. I'm writing up some notes on what is needed and the available solution strategies at the moment. I'll post soon. -- Angus
