Bug 50385 – [Qt] Make platform managing of OSAllocator better than r73106

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Csaba Osztrogonác]

.

[Csaba Osztrogonác]

Created attachment 75375 [details]
proposed fix

[Csaba Osztrogonác]

Patrick, Jocelyn, could you verify if the win case is good for all win/wince platform?

[Geoffrey Garen]

Comment on attachment 75375 [details]
proposed fix

EWS bots are green, so r=me.

Thanks!

[Laszlo Gombos]

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.

[Geoffrey Garen]

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?

[Laszlo Gombos]

(In reply to comment #5)
> This patch came out of a discussion I started by email, so I'll paste that here for context:

Thanks Geoffrey.

> > 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.

[Geoffrey Garen]

> 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.

[Patrick R. Gansterer]

(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.

[WebKit Commit Bot]

Comment on attachment 75375 [details]
proposed fix

Clearing flags on attachment: 75375

Committed r73179: <http://trac.webkit.org/changeset/73179>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Geoffrey Garen]

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.