"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > There's no reason it shouldn't work. However, if we have > a lot of defines, it becomes a bit hard to maintain them > embedded in winegcc. Also, it would allow people to use > gcc directly instead of winegcc (for whatever reason). > It would be a wine/ header, and to be honest, I can't see > any fundamental reason why we can't have a few well defined > wine/ private headers. I'm on the fence on this issue, I > don't need the header myself, but I can see a decent > argument why you'd want to externalize these things out > of winegcc...
Sure, there are good arguments for both approaches. I was under the impression that Boaz was saying that the current way didn't work at all, in which case of course it needs to be changed. But otherwise it's just a winegcc implementation detail, and I see no compelling reason for changing it now, especially since winegcc is still going to need quite a bit of work. -- Alexandre Julliard [EMAIL PROTECTED]
