Created attachment 75375 [details]
Patrick, Jocelyn, could you verify if the win case is good for all win/wince platform?
Comment on attachment 75375 [details]
EWS bots are green, so r=me.
To me this seems like an opposite direction on where we want to go - this patch moves some logic from cross platform code into Qt specific build system; other ports would have to re-implement these guards now in their own port-specific mechanism.
This patch came out of a discussion I started by email, so I'll paste that here for context:
> I ran into some trouble today with the Qt build system. I wanted to use separate files to separate concerns about different OS's like so:
> OSAllocator.h // cross-platform header
> OSAllocatorPosix.cpp // used on POSIX OS's
> OSAllocatorWin.cpp // used on Windows
> This fits the convention we use in WebCore, and it avoids cluttering files with #ifdefs and discordant implementations.
> It worked fine for most ports, but not for Qt, because Qt uses the same build project for both Linux and Windows.
> Is there any way to make portions of Qt's build project conditional based on OS, or to use different projects on different OS's?
(In reply to comment #5)
> This patch came out of a discussion I started by email, so I'll paste that here for context:
> > This fits the convention we use in WebCore, and it avoids cluttering files with #ifdefs and discordant implementations.
I think the convention you referring to in WebCore is different as that is relevant for files specific to a single port (e.g. Gtk or Qt). Files in this patch could be shared between ports.
This was discussed in webkit-dev but I can not seems to find the thread anymore. The summary of the discussion is here - http://trac.webkit.org/wiki/Porting%20Macros%20plan.
> this patch moves some logic from cross platform code into Qt specific build system;
The old code wasn't cross-platform -- it just put the burden of selecting different code for different platforms on the .cpp file, instead of the platform's build project file.
> other ports would have to re-implement these guards now in their own port-specific mechanism
For minor platform differences, one or two port-specific #ifdefs in a shared file is the most expedient solution, and I agree, it's nice not to have to rewrite the whole file for each port.
However, in this case we have major platform differences -- for example, there is zero shared code between virtual memory allocation on Windows, POSIX, and Symbian.
In such a case, I don't see much benefit to artificially merging platform-specific implementations, and I do see some disadvantages:
* It doesn't match how major ports like Mac and Windows are organized.
* It doesn't match how WebCore is organized.
* It undermines the separation of concerns, and forces you to think about every permutation of ports for every line of port-specific code you write.
* Having to write an "#if OS(WINDOWS)" guard inside OSAllocatorWin.cpp is very surprising. The whole point of OSAllocatorWin.cpp is that you should only build it on Windows.
* It litters the code with #ifdefs, and often nested #ifdefs, which degrade readability.
* It increases build times.
(In reply to comment #2)
> Patrick, Jocelyn, could you verify if the win case is good for all win/wince platform?
I didn't compile the new OSAllocatorWin.cpp with WinCE, but I don't think _this_ change will cause any troubles for WinCE.
Comment on attachment 75375 [details]
Clearing flags on attachment: 75375
Committed r73179: <http://trac.webkit.org/changeset/73179>
All reviewed patches have been landed. Closing bug.
I talked this over with some other folks, and the rough consensus was:
- Separating completely different platform implementations into different .cpp files is good;
- Surrounding a file like OSAllocatorWin.cpp with "#if OS(WINDOWS)" is not terribly harmful, so we're willing to do it if it makes some build systems simpler;
- However, building more than one platform implementation file (for example, OSAllocatorWin.cpp and OSAllocatorPosix.cpp) in the same build system is not recommended practice.
Ultimately, this probably argues against the #ifdef changes in r73179. I don't think there's an immediate need to roll them out, however, going forward, I think Laszlo is right that we should keep platform-specific implementation files #ifdef'd.