Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
On May 24, 2009, at 10:38 PM, Adam Barth wrote: On Sun, May 24, 2009 at 10:08 PM, Maciej Stachowiak m...@apple.com wrote: I don't think it should be discounted. It might be helpful to clarify why you think ifdefs are a bad solution. When I made changes that affect several ports, I try to be good WebKit citizen and update all the ports, but the situation we have today makes that a pain. For example, consider the case of adding a method to ChromeClient. I understand that I have to add the method to a bunch of port-specific subclasses, but theses classes are stored in slightly different locations (WebCoreSupport or WebKitSupport?), have different naming conventions (WebChromeClient or ChromeClientGtk?), and have different names spaces (using namespace WebCore or not?). All these issues combine to ensure that I've screwed it up, and I don't really have a way to test because I can't building the XYZ port. I just have to check in my change and pray. Anyway, that's my rant. Are patches welcome for homogenizing some of these idiosyncrasies? I would be in favor, though in general we leave the WebKit layer up to port owners. Maybe others would like to chime in. I think one key step here will be to have a try server integrated with the buildbots, so that it's at least practical to test such patches. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
On May 24, 2009, at 10:51 PM, Peter Kasting wrote: On Sun, May 24, 2009 at 10:08 PM, Maciej Stachowiak m...@apple.com wrote: I don't think it should be discounted. It might be helpful to clarify why you think ifdefs are a bad solution. Generally they make it more difficult to read the code (which is what I spend 99% of the time doing) without really making it easier to find what's in the build (which I only spend 1% of the time doing anyway). The reason for this latter is because there's a lot of files that look like they're included but I actually don't care about, while if you go the #include foo_bar_gtk.cc route to handle port-specific implementations, it can make it harder for your IDE to determine that foo_bar_gtk.cc is an important file (e.g. by doing open foo_bar_gtk.cc in its command line). (This depends on the IDE, of course.) I would prefer to optimize for reading the code for my port, which generally means as few #ifdefs as possible, and pushing as much logic into the build system as possible (by including or not including various files). It implies things like preferring per- port subclasses to port-specific members in the parent class, preferring to not include files rather than #ifdef their contents away... basically, the opposite of all the decisions WebKit looks to have taken :D I'll agree that a bunch of #ifdefs in the middle of code can be hard to read. In general though, I'm not sure that optimizing for only thinking about one port is the right approach. Ideally, we should both make it easy to work on only port-level stuff, *and* make it practical for people doing core work with port-specific implications to do what they need to do. I would even argue we should prioritize ease of core work over ease of port-specific work, if we should ever face that tradeoff. I don't think this is a big deal for most things, and I think the cases where it is a big deal have been dealt with well when they've come up in the past (from what I've seen as a third party -- usually Darin Fisher or someone else on the team is running into them), so don't take this as a disgruntled complaint against the current system. It's just my preference. Now, the thing I _would_ like to change is to switch from pathless #includes to ones with relative paths -- but that's a totally different thread. That I definitely wouldn't like. It would make it much more painful to move files. What is the benefit? Maybe UI am missing something. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
Hi Maciej, On May 25, 2009, at 12:33 AM, Maciej Stachowiak wrote: On May 24, 2009, at 10:38 PM, Adam Barth wrote: On Sun, May 24, 2009 at 10:08 PM, Maciej Stachowiak m...@apple.com wrote: I don't think it should be discounted. It might be helpful to clarify why you think ifdefs are a bad solution. When I made changes that affect several ports, I try to be good WebKit citizen and update all the ports, but the situation we have today makes that a pain. For example, consider the case of adding a method to ChromeClient. I understand that I have to add the method to a bunch of port-specific subclasses, but theses classes are stored in slightly different locations (WebCoreSupport or WebKitSupport?), have different naming conventions (WebChromeClient or ChromeClientGtk?), and have different names spaces (using namespace WebCore or not?). All these issues combine to ensure that I've screwed it up, and I don't really have a way to test because I can't building the XYZ port. I just have to check in my change and pray. Anyway, that's my rant. Are patches welcome for homogenizing some of these idiosyncrasies? I would be in favor, though in general we leave the WebKit layer up to port owners. Maybe others would like to chime in. Personally, I'd be in favor of some defined conventions that ports are at least suggested to follow. I don't think homogenizing the Web(Kit | Core)Support layer would be a big problem for porters, and I think it's definitely worth doing if it makes it easier for you guys to make changes to the ports. In hindsight, while we used WebKitSupport for the wx port, I think WebCoreSupport is probably the better choice, or perhaps even WebCoreClients would be more appropriate. Regarding the file names, I think most ports use the convention of WhateverClientPort. I think actually the Apple ports are the only ones using the WebWhateverClient convention. While I can go either way, I do like the WhateverClientPort convention, myself. Regardless, if we decide on a particular convention or guideline, I will happily update the wx port to use it! :-) I think one key step here will be to have a try server integrated with the buildbots, so that it's at least practical to test such patches. I definitely second this, it would be enormously helpful! :-) Thanks, Kevin Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
On Mon, May 25, 2009 at 12:49 AM, Maciej Stachowiak m...@apple.com wrote: Now, the thing I _would_ like to change is to switch from pathless #includes to ones with relative paths -- but that's a totally different thread. That I definitely wouldn't like. It would make it much more painful to move files. What is the benefit? Maybe UI am missing something. Massively decreased compile time. We've measured and the time taken to search the various #include paths is large. Occasionally this pathless solution can also cause issues when there are multiple headers with the same name in the project (we ran into this a number of times over the course of Chromium development). On the Chromium side, we follow the Google style guide, which mandates paths on #includes, and we've rearranged our entire source layout a number of times. It doesn't turn out to be a huge problem and the compile-speed benefits are well worth it. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
On 2009-05-25, at 13:19, Peter Kasting wrote: On Mon, May 25, 2009 at 12:49 AM, Maciej Stachowiak m...@apple.com wrote: Now, the thing I _would_ like to change is to switch from pathless #includes to ones with relative paths -- but that's a totally different thread. That I definitely wouldn't like. It would make it much more painful to move files. What is the benefit? Maybe UI am missing something. Massively decreased compile time. We've measured and the time taken to search the various #include paths is large. Xcode and GCC on Mac OS X avoid this issue by building a map of header files in the project and their locations on disk, so the compiler doesn't have to walk the header entire search path every time you include a file. It's unfortunate if other compilers aren't smart enough to work well with this incredibly common approach to #includes and header search paths. - Mark smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
On May 23, 2009, at 9:38 AM, David Kilzer wrote: Another aspect of this proposal is how to handle source files that have #if ENABLE(FEATURE)/#endif guards around all of their source code, for example: Bug 25756: Explicit guards for ENABLE_GEOLOCATION https://bugs.webkit.org/show_bug.cgi?id=25756 There are essentially two options here: 1. Add #if/#endif guards to entire source files, but include every file in every build system. 2. Make each build system smart enough to exclude source files that implement a feature, thus pushing the policy decision down (up?) into the build system (which is where most of the decisions are made today anyway). I think #2 is a much cleaner way to handle this since it removes clutter from the code (at the cost of duplicating knowledge of which files go with with features into each build system). Does anyone else have an opinion on this? I know there is a potential compile time tradeoff, but in some ways it would be nicer if all build systems built the same set of files, and we ifdef'd the contents. That would put the policy decisions all in one place (the port header). Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
nbsp;Well , It seems we're on thenbsp;similar problem. I posted a question in lib change questions, for I found migrating webkit on other platformnbsp; or replacing some libs is very time-costing. nbsp; So, if all the work can be fixed through building, it must be a big promotion.___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
On Sun, May 24, 2009 at 12:19 AM, Maciej Stachowiak m...@apple.com wrote: On May 23, 2009, at 9:38 AM, David Kilzer wrote: There are essentially two options here: 1. Add #if/#endif guards to entire source files, but include every file in every build system. 2. Make each build system smart enough to exclude source files that implement a feature, thus pushing the policy decision down (up?) into the build system (which is where most of the decisions are made today anyway). I know there is a potential compile time tradeoff, but in some ways it would be nicer if all build systems built the same set of files, and we ifdef'd the contents. That would put the policy decisions all in one place (the port header). It seems like build systems will already differ insofar as they include various explicitly platform-specific files (foo_bar_gtk.cc) so differing more doesn't seem to hurt much. My bias is always against #ifdefs so I feel more like David Kilzer does -- option #2 feels a lot cleaner to me. On the other hand my experience is much more with Chromium ports instead of WebKit ports so my opinion should probably be discounted :) PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
On May 24, 2009, at 9:28 PM, Peter Kasting wrote: On Sun, May 24, 2009 at 12:19 AM, Maciej Stachowiak m...@apple.com wrote: On May 23, 2009, at 9:38 AM, David Kilzer wrote: There are essentially two options here: 1. Add #if/#endif guards to entire source files, but include every file in every build system. 2. Make each build system smart enough to exclude source files that implement a feature, thus pushing the policy decision down (up?) into the build system (which is where most of the decisions are made today anyway). I know there is a potential compile time tradeoff, but in some ways it would be nicer if all build systems built the same set of files, and we ifdef'd the contents. That would put the policy decisions all in one place (the port header). It seems like build systems will already differ insofar as they include various explicitly platform-specific files (foo_bar_gtk.cc) so differing more doesn't seem to hurt much. We could actually avoid that by having all ports include FooBar.cpp in the build, and that file conditionally #includes the appropriate port- specific implementation. My bias is always against #ifdefs so I feel more like David Kilzer does -- option #2 feels a lot cleaner to me. ifdefs can be messy, but at least the conditional logic becomes explicit in the code, instead of being buried in various build systems. I think the the only serious downside is the potential to increase compile time. On the other hand my experience is much more with Chromium ports instead of WebKit ports so my opinion should probably be discounted :) I don't think it should be discounted. It might be helpful to clarify why you think ifdefs are a bad solution. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
On Sun, May 24, 2009 at 10:08 PM, Maciej Stachowiak m...@apple.com wrote: I don't think it should be discounted. It might be helpful to clarify why you think ifdefs are a bad solution. When I made changes that affect several ports, I try to be good WebKit citizen and update all the ports, but the situation we have today makes that a pain. For example, consider the case of adding a method to ChromeClient. I understand that I have to add the method to a bunch of port-specific subclasses, but theses classes are stored in slightly different locations (WebCoreSupport or WebKitSupport?), have different naming conventions (WebChromeClient or ChromeClientGtk?), and have different names spaces (using namespace WebCore or not?). All these issues combine to ensure that I've screwed it up, and I don't really have a way to test because I can't building the XYZ port. I just have to check in my change and pray. Anyway, that's my rant. Are patches welcome for homogenizing some of these idiosyncrasies? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
Another aspect of this proposal is how to handle source files that have #if ENABLE(FEATURE)/#endif guards around all of their source code, for example: Bug 25756: Explicit guards for ENABLE_GEOLOCATION https://bugs.webkit.org/show_bug.cgi?id=25756 There are essentially two options here: 1. Add #if/#endif guards to entire source files, but include every file in every build system. 2. Make each build system smart enough to exclude source files that implement a feature, thus pushing the policy decision down (up?) into the build system (which is where most of the decisions are made today anyway). I think #2 is a much cleaner way to handle this since it removes clutter from the code (at the cost of duplicating knowledge of which files go with with features into each build system). Does anyone else have an opinion on this? Dave From: Maciej Stachowiak m...@apple.com To: WebKit Development webkit-dev@lists.webkit.org Sent: Thursday, April 30, 2009 4:12:54 PM Subject: [webkit-dev] Proposal for a new way to handle porting #ifdefs I think our set of porting macros has become somewhat confused. Originally, our idea was that a port represents primarily adaptation to a particular platform. However, over time it has become clear that most of what is decided by a port is not platform adaptation, but rather policy decisions. For example, ports decide to have different features enabled, or to use different sets of system functionality on the same underlying OS. In addition, I think the catchall top-level PLATFORM create confusion, because it is not totally clear if they are policy decisions, platform adaptation decisions, or what. Third, it seems wrong that the policy choices of every port are represented as a bunch of ifdef tomfoolery inside a single Platform.h file. And fourth, many ports often run on the same OS, but with a different set of choices - for example on Mac OS X it is possible to build the Mac, Chromium, Gtk, Qt and Wx ports (at least). Therefore, I propose that we change as follows: 1) Strictly separate platform adaptation (mandatory to run on a given OS, compiler, or CPU at all) from policy choices (what features to enable, what optional libraries to use). 2) Phase out PLATFORM macros completely - each use should be converted to a policy choice, or a platform adaptation decision. 3) Instead of ports being defined by a top-level PLATFORM macro, I propose that each port should have its own header file to define policy decisions. For example, I'd propose that the system Mac OS X WebKit should use PortCocoa.h, and the WebKit used by Safari for Windows should use PortWinCG.h. There may also be a PortIPhone.h. These port definition headers would live in their own top-level WebKit module. Each one would be completely owned by whoever is generally considered the owner of a given port. Because related ports on different platforms may wish to share policy choices, it's ok for Port headers to include shared headers for some choices. For example, all Apple-maintained ports may include PortApple.h. We could go even further and have PortDefault.h to make default choices of what features are enabled, that ports would have to explicitly override. 4) Platform adaptation macros would still be defined in Platform.h based on sniffing the environment, this would include things like the compiler, the underlying OS, available libc functions, and so forth. Platform adaptation macros would be: OS() - underlying operating system; only to be used for mandated low-level services like virtual memory, not to choose a GUI toolkit Examples: OS(UNIX) - Any Unix-like OS OS(DARWIN) - Underlying OS is the base OS X environment OS(FREEBSD) - FreeBSD OS(WIN) - Any version of Windows OS(WINCE) - The embedded version of Windows COMPILER() - the compiler being used to build the project Examples: COMPILER(GCC) - GNU Compiler Collection COMPILER(MSVC) - Microsoft Visual C++ COMPILER(RVCT) - ARM compiler HAVE() - specific system features (headers, functions or similar) that are present or not Examples: HAVE(MMAP) - mmap() function is available HAVE(ERRNO_H) - errno.h header is available HAVE(MADV_FREE) - madvise(MADV_FREE) is available Policy decision macros would be: USE() - use a particular third-party library or optional OS service Examples: USE(SKIA) - Use the Skia graphics library USE(CG) - Use CoreGraphics USE(V8) - Use the V8 JavaScript implementation USE(CFNET) - Use CFNetwork networking USE(NSURL_NET) - Use NSURLConnection-based networking USE(APPKIT) - Use AppKit views and events USE(GTK) - Use Gtk+ USE(QT) - Use Qt USE(QUICKTIME) - Use the QuickTime media engine USE(QTKIT) - Use the QuickTime media engine via the Mac QTKit API USE(QUICKTIME_WIN) - Use
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
I think you may want to look at openembedded and use their way to control those things, rather then a new idea. You can build webkit there too. Most of what you said most is a minor part to me, may be to others. rgds joe --- On Tue, 5/5/09, Maciej Stachowiak m...@apple.com wrote: From: Maciej Stachowiak m...@apple.com Subject: Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs To: mbe...@pleyo.com Cc: webkit-dev@lists.webkit.org Date: Tuesday, May 5, 2009, 11:19 PM On May 4, 2009, at 5:21 AM, Mario Bensi wrote: We pursued the same goal for a couple of years. Since our porting targets are various middleware CE platforms, we had to identify and adapt WebKit needs at a better grained level than platform. In order to do this we collected all dependencies in a Browser Abstraction Layer (BAL directory). The configuration is handled by a Base directory (definition of types, platform specifications) and we use CMake to define platform specificities (and it's a great cross- platform tool). Sure the BAL model has still improvements ahead of it, but it has the merit of existing, being widely tester on a quite wide range of targets, configurations and libraries. My understanding is that BAL injects a platform abstration layer under the platform abstraction layer that is the WebCore/platform directory. Also, I gather that BAL tries to do more things via runtime indirection and subclasses with virtual methods instead of WebCore's compile-time approach. To me, those aspects sound like they may not be good fits for our goals. But I would be glad to hear more details about BAL, and how it would compare to my proposal. Regards, Maciej Regards Mario Le Friday 01 May 2009 01:12:54 Maciej Stachowiak, vous avez écrit : I think our set of porting macros has become somewhat confused. Originally, our idea was that a port represents primarily adaptation to a particular platform. However, over time it has become clear that most of what is decided by a port is not platform adaptation, but rather policy decisions. For example, ports decide to have different features enabled, or to use different sets of system functionality on the same underlying OS. In addition, I think the catchall top-level PLATFORM create confusion, because it is not totally clear if they are policy decisions, platform adaptation decisions, or what. Third, it seems wrong that the policy choices of every port are represented as a bunch of ifdef tomfoolery inside a single Platform.h file. And fourth, many ports often run on the same OS, but with a different set of choices - for example on Mac OS X it is possible to build the Mac, Chromium, Gtk, Qt and Wx ports (at least). Therefore, I propose that we change as follows: 1) Strictly separate platform adaptation (mandatory to run on a given OS, compiler, or CPU at all) from policy choices (what features to enable, what optional libraries to use). 2) Phase out PLATFORM macros completely - each use should be converted to a policy choice, or a platform adaptation decision. 3) Instead of ports being defined by a top-level PLATFORM macro, I propose that each port should have its own header file to define policy decisions. For example, I'd propose that the system Mac OS X WebKit should use PortCocoa.h, and the WebKit used by Safari for Windows should use PortWinCG.h. There may also be a PortIPhone.h. These port definition headers would live in their own top-level WebKit module. Each one would be completely owned by whoever is generally considered the owner of a given port. Because related ports on different platforms may wish to share policy choices, it's ok for Port headers to include shared headers for some choices. For example, all Apple-maintained ports may include PortApple.h. We could go even further and have PortDefault.h to make default choices of what features are enabled, that ports would have to explicitly override. 4) Platform adaptation macros would still be defined in Platform.h based on sniffing the environment, this would include things like the compiler, the underlying OS, available libc functions, and so forth. Platform adaptation macros would be: OS() - underlying operating system; only to be used for mandated low- level services like virtual memory, not to choose a GUI toolkit Examples: OS(UNIX) - Any Unix-like OS OS(DARWIN) - Underlying OS is the base OS X environment OS(FREEBSD) - FreeBSD OS(WIN) - Any version of Windows OS(WINCE) - The embedded version of Windows COMPILER() - the compiler being used to build the project Examples: COMPILER(GCC) - GNU Compiler Collection COMPILER(MSVC) - Microsoft Visual C++ COMPILER(RVCT) - ARM compiler HAVE() - specific
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
The goal of Origyn Web Browser Abstraction Layer (OWBAL) is to clarify what is platform dependant and what is not. In BAL directory you find some modules which split sources per family of feature: Database: all files needed for HTML5 Database and Storage. Events: all events definitions (input events) Filesystem: methods to access the filesystem Geolocation: methods to implement the html5 geolocation ImageDecoder: Interface of ImageDecoder and all implementation (GIF, JPEG, PNG, BMP, ICO) Media: Implementation of backend for HTML5 video/audio tag Network: Implementation of network resource Types: Base Type used by WebCore Facilities: misceleanous facilities implementation Fonts: Font engine implementation Graphics: Graphic primitive implementation (drawline, ...) Internationalization: I18N implementation Memory: memory management implementation SVG: SVG (graphic part, the parser is in WebCore) implementation Timer: timer implementation Widgets: widget implementation Each Module, when needed, splits WebCore and WTF source for the compilation. All files in BAL have the prefix BC for BAL Concretization and for the suffix the implementation name ( SDL, Gtk, Qt... ). This is done to avoid confusion between files in the BAL and WebCore. For example if you have a file ScrollView.cpp in WebCore, in BAL for SDL implementation it will be : BCScrollViewSDL.cpp This way any filename self documents its target implementation. We have a 2 others directories used for the BALification process: * Base: where stand definition of type and all configuration ( Platform.h, ... ). This makes a single place of information. *cmake: all definitions needed by cmake (our build mechanism) such as library check, header include, definitions by option. you can find this description here : http://www.sand- labs.org/owb/wiki/OwbalDescription Mario Le Tuesday 05 May 2009 17:19:33 Maciej Stachowiak, vous avez écrit : On May 4, 2009, at 5:21 AM, Mario Bensi wrote: We pursued the same goal for a couple of years. Since our porting targets are various middleware CE platforms, we had to identify and adapt WebKit needs at a better grained level than platform. In order to do this we collected all dependencies in a Browser Abstraction Layer (BAL directory). The configuration is handled by a Base directory (definition of types, platform specifications) and we use CMake to define platform specificities (and it's a great cross- platform tool). Sure the BAL model has still improvements ahead of it, but it has the merit of existing, being widely tester on a quite wide range of targets, configurations and libraries. My understanding is that BAL injects a platform abstration layer under the platform abstraction layer that is the WebCore/platform directory. Also, I gather that BAL tries to do more things via runtime indirection and subclasses with virtual methods instead of WebCore's compile-time approach. To me, those aspects sound like they may not be good fits for our goals. But I would be glad to hear more details about BAL, and how it would compare to my proposal. Regards, Maciej Regards Mario Le Friday 01 May 2009 01:12:54 Maciej Stachowiak, vous avez écrit : I think our set of porting macros has become somewhat confused. Originally, our idea was that a port represents primarily adaptation to a particular platform. However, over time it has become clear that most of what is decided by a port is not platform adaptation, but rather policy decisions. For example, ports decide to have different features enabled, or to use different sets of system functionality on the same underlying OS. In addition, I think the catchall top-level PLATFORM create confusion, because it is not totally clear if they are policy decisions, platform adaptation decisions, or what. Third, it seems wrong that the policy choices of every port are represented as a bunch of ifdef tomfoolery inside a single Platform.h file. And fourth, many ports often run on the same OS, but with a different set of choices - for example on Mac OS X it is possible to build the Mac, Chromium, Gtk, Qt and Wx ports (at least). Therefore, I propose that we change as follows: 1) Strictly separate platform adaptation (mandatory to run on a given OS, compiler, or CPU at all) from policy choices (what features to enable, what optional libraries to use). 2) Phase out PLATFORM macros completely - each use should be converted to a policy choice, or a platform adaptation decision. 3) Instead of ports being defined by a top-level PLATFORM macro, I propose that each port should have its own header file to define policy decisions. For example, I'd propose that the system Mac OS X WebKit should use PortCocoa.h, and the WebKit used by Safari for Windows should use PortWinCG.h. There may also be a PortIPhone.h. These port definition headers
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
On 5-May-09, at 10:49 AM, Darin Adler wrote: On May 4, 2009, at 7:45 PM, George Staikos wrote: 1) In some cases some things apply to more than one OS so we have: #if OS(x) || OS(y) || OS(z) ... I think we should use: #if OS(x,y,z) How? Macros don’t have overloading with the same macro but different numbers of parameters. Hm I guess variable argument macros are not supported everywhere we need them. Oh well. On 5-May-09, at 11:16 AM, Maciej Stachowiak wrote: On May 4, 2009, at 7:45 PM, George Staikos wrote: I really like this and it goes in the direction that I was hoping for as well. Hopefully we can get the WINCE port merged upstream before we make this change. :-) Some comments I have: 1) In some cases some things apply to more than one OS so we have: #if OS(x) || OS(y) || OS(z) ... I think we should use: #if OS(x,y,z) I think using the || operator is more clear, except perhaps in cases where there is a well-defined OS family, such as the Unix- like family of operating systems, or the Windows family. In that case, the OS family should get is own macro. Well my idea probably won't work anyway given that not enough compilers we need to support can handle it. 1b) WINCE actually includes plenty of WIN but in some cases does things differently. How to make this distinction without lots of and ||? Perhaps we need another basic OS macro besides WINCE and WIN, which would refer to only full/desktop versions of Windows. Or maybe WIN should mean desktop Windows, and some new macro could represent the facilities that are common to Windows and Windows CE. Then it's just a matter of using the right ifdefs in the right place. So something like this (for example) in Platform.h? #if OS(WINMOBILE) #define WTF_OS_WINCE 1 #endif #if OS(WINCE) || OS(WINDESKTOP) #define WTF_OS_WIN 1 #endif Then OS(WIN) would mean any Windows flavour, and OS(WINCE) would mean any flavour of Windows CE. Again, fully support these changes and perhaps some more too. Just give us a bit of time to find the right way to merge the WINCE stuff in first please! I wouldn't expect us to start changing things next week, but since generally I've heard support for these changes, I would expect in a month or two at most we'll likely start on deploying them. Most likely we will come up with a system that allows gradual migration. At some point, we'll likely require new code to use new-style macros only and not the old PLATFORM stuff. Great! Well I'm ready to start packaging things up. Will try to get the first (and most relevant) parts ready this week. -- George Staikos Torch Mobile Inc. http://www.torchmobile.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
1b) WINCE actually includes plenty of WIN but in some cases does things differently. How to make this distinction without lots of and ||? There are various design patterns that may be used to alleviate macros, such as subclassing and use of delegates. Each case will probably require a specific solution, but many of the patterns should be reusable. 2) We use PLATFORM(TORCHMOBILE) across multiple OS for things that are not necessarily platform specific but specific to our browsers. I guess this is similar to PLATFORM(CHROMIUM). Honestly I don't like filling the code with these but we all do it, including MAC. MAC tends to win the default right now. I'm not sure how best to handle this yet but I foresee a big mess if we aren't careful. I think Maciej said that part of this plan is to break up PLATFORM(MAC) into smaller pieces. I haven't looked at the Torch Mobile source code, but I suspect the same thing may need to be done in this case as well. When porting, it's very easy to lump features, library/framework dependencies (I'm thinking of CFNetwork vs. libcurl vs. libsoup), and true platform-specific code into a single macro. Part of this effort will be to clean that up. Dave From: George Staikos stai...@kde.org To: WebKit Development webkit-dev@lists.webkit.org Sent: Monday, May 4, 2009 7:45:41 PM Subject: Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs I really like this and it goes in the direction that I was hoping for as well. Hopefully we can get the WINCE port merged upstream before we make this change. :-) Some comments I have: 1) In some cases some things apply to more than one OS so we have: #if OS(x) || OS(y) || OS(z) ... I think we should use: #if OS(x,y,z) 1b) WINCE actually includes plenty of WIN but in some cases does things differently. How to make this distinction without lots of and ||? 2) We use PLATFORM(TORCHMOBILE) across multiple OS for things that are not necessarily platform specific but specific to our browsers. I guess this is similar to PLATFORM(CHROMIUM). Honestly I don't like filling the code with these but we all do it, including MAC. MAC tends to win the default right now. I'm not sure how best to handle this yet but I foresee a big mess if we aren't careful. 3) I'm not sure that USE() really applies equally as you described. In some cases it applies to basically the whole system API used (QT), but in others it's just a support library (QUICKTIME). Again, fully support these changes and perhaps some more too. Just give us a bit of time to find the right way to merge the WINCE stuff in first please! On 30-Apr-09, at 7:12 PM, Maciej Stachowiak wrote: I think our set of porting macros has become somewhat confused. Originally, our idea was that a port represents primarily adaptation to a particular platform. However, over time it has become clear that most of what is decided by a port is not platform adaptation, but rather policy decisions. For example, ports decide to have different features enabled, or to use different sets of system functionality on the same underlying OS. In addition, I think the catchall top-level PLATFORM create confusion, because it is not totally clear if they are policy decisions, platform adaptation decisions, or what. Third, it seems wrong that the policy choices of every port are represented as a bunch of ifdef tomfoolery inside a single Platform.h file. And fourth, many ports often run on the same OS, but with a different set of choices - for example on Mac OS X it is possible to build the Mac, Chromium, Gtk, Qt and Wx ports (at least). Therefore, I propose that we change as follows: 1) Strictly separate platform adaptation (mandatory to run on a given OS, compiler, or CPU at all) from policy choices (what features to enable, what optional libraries to use). 2) Phase out PLATFORM macros completely - each use should be converted to a policy choice, or a platform adaptation decision. 3) Instead of ports being defined by a top-level PLATFORM macro, I propose that each port should have its own header file to define policy decisions. For example, I'd propose that the system Mac OS X WebKit should use PortCocoa.h, and the WebKit used by Safari for Windows should use PortWinCG.h. There may also be a PortIPhone.h. These port definition headers would live in their own top-level WebKit module. Each one would be completely owned by whoever is generally considered the owner of a given port. Because related ports on different platforms may wish to share policy choices, it's ok for Port headers to include shared headers for some choices. For example, all Apple-maintained ports may include PortApple.h. We could go even further and have PortDefault.h to make default choices of what features are enabled, that ports would have to explicitly override. 4) Platform adaptation
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
On May 4, 2009, at 7:45 PM, George Staikos wrote: 1) In some cases some things apply to more than one OS so we have: #if OS(x) || OS(y) || OS(z) ... I think we should use: #if OS(x,y,z) How? Macros don’t have overloading with the same macro but different numbers of parameters. 3) I'm not sure that USE() really applies equally as you described. In some cases it applies to basically the whole system API used (QT), but in others it's just a support library (QUICKTIME). But why is this distinction important? Does it need to “apply equally”? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
On May 4, 2009, at 7:45 PM, George Staikos wrote: I really like this and it goes in the direction that I was hoping for as well. Hopefully we can get the WINCE port merged upstream before we make this change. :-) Some comments I have: 1) In some cases some things apply to more than one OS so we have: #if OS(x) || OS(y) || OS(z) ... I think we should use: #if OS(x,y,z) I think using the || operator is more clear, except perhaps in cases where there is a well-defined OS family, such as the Unix-like family of operating systems, or the Windows family. In that case, the OS family should get is own macro. 1b) WINCE actually includes plenty of WIN but in some cases does things differently. How to make this distinction without lots of and ||? Perhaps we need another basic OS macro besides WINCE and WIN, which would refer to only full/desktop versions of Windows. Or maybe WIN should mean desktop Windows, and some new macro could represent the facilities that are common to Windows and Windows CE. Then it's just a matter of using the right ifdefs in the right place. 2) We use PLATFORM(TORCHMOBILE) across multiple OS for things that are not necessarily platform specific but specific to our browsers. I guess this is similar to PLATFORM(CHROMIUM). Honestly I don't like filling the code with these but we all do it, including MAC. MAC tends to win the default right now. I'm not sure how best to handle this yet but I foresee a big mess if we aren't careful. The idea in my proposal is that catchalls like PLATFORM(CHROMIUM), PLATFORM(MAC) and PLATFORM(TORCHMOBILE) would all be phased out, and replaced with macros that describe specific policy decisions. Anyone could make a PortFoo.h header that makes their preferred set of policy choices, but in the code itself the macros would say how and why something is different, rather than who chose to make it different. This may take time for ports that made heavy use of catchall macros, since in some cases it may be necessary to reverse-engineer the original intent of a port variation, or it may not even have been clearly thought out why particular things should be different. It took us some time to get rid of the older APPLE_CHANGES macro that we used to apply to almost any change we made. Again, fully support these changes and perhaps some more too. Just give us a bit of time to find the right way to merge the WINCE stuff in first please! I wouldn't expect us to start changing things next week, but since generally I've heard support for these changes, I would expect in a month or two at most we'll likely start on deploying them. Most likely we will come up with a system that allows gradual migration. At some point, we'll likely require new code to use new-style macros only and not the old PLATFORM stuff. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
On May 4, 2009, at 5:21 AM, Mario Bensi wrote: We pursued the same goal for a couple of years. Since our porting targets are various middleware CE platforms, we had to identify and adapt WebKit needs at a better grained level than platform. In order to do this we collected all dependencies in a Browser Abstraction Layer (BAL directory). The configuration is handled by a Base directory (definition of types, platform specifications) and we use CMake to define platform specificities (and it's a great cross- platform tool). Sure the BAL model has still improvements ahead of it, but it has the merit of existing, being widely tester on a quite wide range of targets, configurations and libraries. My understanding is that BAL injects a platform abstration layer under the platform abstraction layer that is the WebCore/platform directory. Also, I gather that BAL tries to do more things via runtime indirection and subclasses with virtual methods instead of WebCore's compile-time approach. To me, those aspects sound like they may not be good fits for our goals. But I would be glad to hear more details about BAL, and how it would compare to my proposal. Regards, Maciej Regards Mario Le Friday 01 May 2009 01:12:54 Maciej Stachowiak, vous avez écrit : I think our set of porting macros has become somewhat confused. Originally, our idea was that a port represents primarily adaptation to a particular platform. However, over time it has become clear that most of what is decided by a port is not platform adaptation, but rather policy decisions. For example, ports decide to have different features enabled, or to use different sets of system functionality on the same underlying OS. In addition, I think the catchall top-level PLATFORM create confusion, because it is not totally clear if they are policy decisions, platform adaptation decisions, or what. Third, it seems wrong that the policy choices of every port are represented as a bunch of ifdef tomfoolery inside a single Platform.h file. And fourth, many ports often run on the same OS, but with a different set of choices - for example on Mac OS X it is possible to build the Mac, Chromium, Gtk, Qt and Wx ports (at least). Therefore, I propose that we change as follows: 1) Strictly separate platform adaptation (mandatory to run on a given OS, compiler, or CPU at all) from policy choices (what features to enable, what optional libraries to use). 2) Phase out PLATFORM macros completely - each use should be converted to a policy choice, or a platform adaptation decision. 3) Instead of ports being defined by a top-level PLATFORM macro, I propose that each port should have its own header file to define policy decisions. For example, I'd propose that the system Mac OS X WebKit should use PortCocoa.h, and the WebKit used by Safari for Windows should use PortWinCG.h. There may also be a PortIPhone.h. These port definition headers would live in their own top-level WebKit module. Each one would be completely owned by whoever is generally considered the owner of a given port. Because related ports on different platforms may wish to share policy choices, it's ok for Port headers to include shared headers for some choices. For example, all Apple-maintained ports may include PortApple.h. We could go even further and have PortDefault.h to make default choices of what features are enabled, that ports would have to explicitly override. 4) Platform adaptation macros would still be defined in Platform.h based on sniffing the environment, this would include things like the compiler, the underlying OS, available libc functions, and so forth. Platform adaptation macros would be: OS() - underlying operating system; only to be used for mandated low- level services like virtual memory, not to choose a GUI toolkit Examples: OS(UNIX) - Any Unix-like OS OS(DARWIN) - Underlying OS is the base OS X environment OS(FREEBSD) - FreeBSD OS(WIN) - Any version of Windows OS(WINCE) - The embedded version of Windows COMPILER() - the compiler being used to build the project Examples: COMPILER(GCC) - GNU Compiler Collection COMPILER(MSVC) - Microsoft Visual C++ COMPILER(RVCT) - ARM compiler HAVE() - specific system features (headers, functions or similar) that are present or not Examples: HAVE(MMAP) - mmap() function is available HAVE(ERRNO_H) - errno.h header is available HAVE(MADV_FREE) - madvise(MADV_FREE) is available Policy decision macros would be: USE() - use a particular third-party library or optional OS service Examples: USE(SKIA) - Use the Skia graphics library USE(CG) - Use CoreGraphics USE(V8) - Use the V8 JavaScript implementation USE(CFNET) - Use CFNetwork networking USE(NSURL_NET) - Use NSURLConnection-based networking USE(APPKIT) - Use AppKit views and events USE(GTK) - Use Gtk+
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
We pursued the same goal for a couple of years. Since our porting targets are various middleware CE platforms, we had to identify and adapt WebKit needs at a better grained level than platform. In order to do this we collected all dependencies in a Browser Abstraction Layer (BAL directory). The configuration is handled by a Base directory (definition of types, platform specifications) and we use CMake to define platform specificities (and it's a great cross- platform tool). Sure the BAL model has still improvements ahead of it, but it has the merit of existing, being widely tester on a quite wide range of targets, configurations and libraries. Regards Mario Le Friday 01 May 2009 01:12:54 Maciej Stachowiak, vous avez écrit : I think our set of porting macros has become somewhat confused. Originally, our idea was that a port represents primarily adaptation to a particular platform. However, over time it has become clear that most of what is decided by a port is not platform adaptation, but rather policy decisions. For example, ports decide to have different features enabled, or to use different sets of system functionality on the same underlying OS. In addition, I think the catchall top-level PLATFORM create confusion, because it is not totally clear if they are policy decisions, platform adaptation decisions, or what. Third, it seems wrong that the policy choices of every port are represented as a bunch of ifdef tomfoolery inside a single Platform.h file. And fourth, many ports often run on the same OS, but with a different set of choices - for example on Mac OS X it is possible to build the Mac, Chromium, Gtk, Qt and Wx ports (at least). Therefore, I propose that we change as follows: 1) Strictly separate platform adaptation (mandatory to run on a given OS, compiler, or CPU at all) from policy choices (what features to enable, what optional libraries to use). 2) Phase out PLATFORM macros completely - each use should be converted to a policy choice, or a platform adaptation decision. 3) Instead of ports being defined by a top-level PLATFORM macro, I propose that each port should have its own header file to define policy decisions. For example, I'd propose that the system Mac OS X WebKit should use PortCocoa.h, and the WebKit used by Safari for Windows should use PortWinCG.h. There may also be a PortIPhone.h. These port definition headers would live in their own top-level WebKit module. Each one would be completely owned by whoever is generally considered the owner of a given port. Because related ports on different platforms may wish to share policy choices, it's ok for Port headers to include shared headers for some choices. For example, all Apple-maintained ports may include PortApple.h. We could go even further and have PortDefault.h to make default choices of what features are enabled, that ports would have to explicitly override. 4) Platform adaptation macros would still be defined in Platform.h based on sniffing the environment, this would include things like the compiler, the underlying OS, available libc functions, and so forth. Platform adaptation macros would be: OS() - underlying operating system; only to be used for mandated low- level services like virtual memory, not to choose a GUI toolkit Examples: OS(UNIX) - Any Unix-like OS OS(DARWIN) - Underlying OS is the base OS X environment OS(FREEBSD) - FreeBSD OS(WIN) - Any version of Windows OS(WINCE) - The embedded version of Windows COMPILER() - the compiler being used to build the project Examples: COMPILER(GCC) - GNU Compiler Collection COMPILER(MSVC) - Microsoft Visual C++ COMPILER(RVCT) - ARM compiler HAVE() - specific system features (headers, functions or similar) that are present or not Examples: HAVE(MMAP) - mmap() function is available HAVE(ERRNO_H) - errno.h header is available HAVE(MADV_FREE) - madvise(MADV_FREE) is available Policy decision macros would be: USE() - use a particular third-party library or optional OS service Examples: USE(SKIA) - Use the Skia graphics library USE(CG) - Use CoreGraphics USE(V8) - Use the V8 JavaScript implementation USE(CFNET) - Use CFNetwork networking USE(NSURL_NET) - Use NSURLConnection-based networking USE(APPKIT) - Use AppKit views and events USE(GTK) - Use Gtk+ USE(QT) - Use Qt USE(QUICKTIME) - Use the QuickTime media engine USE(QTKIT) - Use the QuickTime media engine via the Mac QTKit API USE(QUICKTIME_WIN) - Use the QuickTime media engine via its Windows API ENABLE() - turn on a specific feature of WebKit Examples: ENABLE(ACCESSIBILITY) - Enable support for assistive technologies (currently wrongly a HAVE) ENABLE(XSLT) - Include XSLT support
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
I really like this and it goes in the direction that I was hoping for as well. Hopefully we can get the WINCE port merged upstream before we make this change. :-) Some comments I have: 1) In some cases some things apply to more than one OS so we have: #if OS(x) || OS(y) || OS(z) ... I think we should use: #if OS(x,y,z) 1b) WINCE actually includes plenty of WIN but in some cases does things differently. How to make this distinction without lots of and ||? 2) We use PLATFORM(TORCHMOBILE) across multiple OS for things that are not necessarily platform specific but specific to our browsers. I guess this is similar to PLATFORM(CHROMIUM). Honestly I don't like filling the code with these but we all do it, including MAC. MAC tends to win the default right now. I'm not sure how best to handle this yet but I foresee a big mess if we aren't careful. 3) I'm not sure that USE() really applies equally as you described. In some cases it applies to basically the whole system API used (QT), but in others it's just a support library (QUICKTIME). Again, fully support these changes and perhaps some more too. Just give us a bit of time to find the right way to merge the WINCE stuff in first please! On 30-Apr-09, at 7:12 PM, Maciej Stachowiak wrote: I think our set of porting macros has become somewhat confused. Originally, our idea was that a port represents primarily adaptation to a particular platform. However, over time it has become clear that most of what is decided by a port is not platform adaptation, but rather policy decisions. For example, ports decide to have different features enabled, or to use different sets of system functionality on the same underlying OS. In addition, I think the catchall top-level PLATFORM create confusion, because it is not totally clear if they are policy decisions, platform adaptation decisions, or what. Third, it seems wrong that the policy choices of every port are represented as a bunch of ifdef tomfoolery inside a single Platform.h file. And fourth, many ports often run on the same OS, but with a different set of choices - for example on Mac OS X it is possible to build the Mac, Chromium, Gtk, Qt and Wx ports (at least). Therefore, I propose that we change as follows: 1) Strictly separate platform adaptation (mandatory to run on a given OS, compiler, or CPU at all) from policy choices (what features to enable, what optional libraries to use). 2) Phase out PLATFORM macros completely - each use should be converted to a policy choice, or a platform adaptation decision. 3) Instead of ports being defined by a top-level PLATFORM macro, I propose that each port should have its own header file to define policy decisions. For example, I'd propose that the system Mac OS X WebKit should use PortCocoa.h, and the WebKit used by Safari for Windows should use PortWinCG.h. There may also be a PortIPhone.h. These port definition headers would live in their own top-level WebKit module. Each one would be completely owned by whoever is generally considered the owner of a given port. Because related ports on different platforms may wish to share policy choices, it's ok for Port headers to include shared headers for some choices. For example, all Apple-maintained ports may include PortApple.h. We could go even further and have PortDefault.h to make default choices of what features are enabled, that ports would have to explicitly override. 4) Platform adaptation macros would still be defined in Platform.h based on sniffing the environment, this would include things like the compiler, the underlying OS, available libc functions, and so forth. Platform adaptation macros would be: OS() - underlying operating system; only to be used for mandated low-level services like virtual memory, not to choose a GUI toolkit Examples: OS(UNIX) - Any Unix-like OS OS(DARWIN) - Underlying OS is the base OS X environment OS(FREEBSD) - FreeBSD OS(WIN) - Any version of Windows OS(WINCE) - The embedded version of Windows COMPILER() - the compiler being used to build the project Examples: COMPILER(GCC) - GNU Compiler Collection COMPILER(MSVC) - Microsoft Visual C++ COMPILER(RVCT) - ARM compiler HAVE() - specific system features (headers, functions or similar) that are present or not Examples: HAVE(MMAP) - mmap() function is available HAVE(ERRNO_H) - errno.h header is available HAVE(MADV_FREE) - madvise(MADV_FREE) is available Policy decision macros would be: USE() - use a particular third-party library or optional OS service Examples: USE(SKIA) - Use the Skia graphics library USE(CG) - Use CoreGraphics USE(V8) - Use the V8 JavaScript implementation USE(CFNET) - Use CFNetwork networking USE(NSURL_NET) - Use NSURLConnection-based networking
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
This looks great to me. It will definitely make ports more maintainable. For thoroughness sake, it would be good to add a bit about what should be a USE define versus a setting. For example, the EditingBehavior enum in Settings.h could just as easily be a USE define. I think it makes sense in this case to have it be runtime settable because then we can write layout tests that test both Windows and Mac editing behaviors. Ojan On Thu, Apr 30, 2009 at 4:12 PM, Maciej Stachowiak m...@apple.com wrote: I think our set of porting macros has become somewhat confused. Originally, our idea was that a port represents primarily adaptation to a particular platform. However, over time it has become clear that most of what is decided by a port is not platform adaptation, but rather policy decisions. For example, ports decide to have different features enabled, or to use different sets of system functionality on the same underlying OS. In addition, I think the catchall top-level PLATFORM create confusion, because it is not totally clear if they are policy decisions, platform adaptation decisions, or what. Third, it seems wrong that the policy choices of every port are represented as a bunch of ifdef tomfoolery inside a single Platform.h file. And fourth, many ports often run on the same OS, but with a different set of choices - for example on Mac OS X it is possible to build the Mac, Chromium, Gtk, Qt and Wx ports (at least). Therefore, I propose that we change as follows: 1) Strictly separate platform adaptation (mandatory to run on a given OS, compiler, or CPU at all) from policy choices (what features to enable, what optional libraries to use). 2) Phase out PLATFORM macros completely - each use should be converted to a policy choice, or a platform adaptation decision. 3) Instead of ports being defined by a top-level PLATFORM macro, I propose that each port should have its own header file to define policy decisions. For example, I'd propose that the system Mac OS X WebKit should use PortCocoa.h, and the WebKit used by Safari for Windows should use PortWinCG.h. There may also be a PortIPhone.h. These port definition headers would live in their own top-level WebKit module. Each one would be completely owned by whoever is generally considered the owner of a given port. Because related ports on different platforms may wish to share policy choices, it's ok for Port headers to include shared headers for some choices. For example, all Apple-maintained ports may include PortApple.h. We could go even further and have PortDefault.h to make default choices of what features are enabled, that ports would have to explicitly override. 4) Platform adaptation macros would still be defined in Platform.h based on sniffing the environment, this would include things like the compiler, the underlying OS, available libc functions, and so forth. Platform adaptation macros would be: OS() - underlying operating system; only to be used for mandated low-level services like virtual memory, not to choose a GUI toolkit Examples: OS(UNIX) - Any Unix-like OS OS(DARWIN) - Underlying OS is the base OS X environment OS(FREEBSD) - FreeBSD OS(WIN) - Any version of Windows OS(WINCE) - The embedded version of Windows COMPILER() - the compiler being used to build the project Examples: COMPILER(GCC) - GNU Compiler Collection COMPILER(MSVC) - Microsoft Visual C++ COMPILER(RVCT) - ARM compiler HAVE() - specific system features (headers, functions or similar) that are present or not Examples: HAVE(MMAP) - mmap() function is available HAVE(ERRNO_H) - errno.h header is available HAVE(MADV_FREE) - madvise(MADV_FREE) is available Policy decision macros would be: USE() - use a particular third-party library or optional OS service Examples: USE(SKIA) - Use the Skia graphics library USE(CG) - Use CoreGraphics USE(V8) - Use the V8 JavaScript implementation USE(CFNET) - Use CFNetwork networking USE(NSURL_NET) - Use NSURLConnection-based networking USE(APPKIT) - Use AppKit views and events USE(GTK) - Use Gtk+ USE(QT) - Use Qt USE(QUICKTIME) - Use the QuickTime media engine USE(QTKIT) - Use the QuickTime media engine via the Mac QTKit API USE(QUICKTIME_WIN) - Use the QuickTime media engine via its Windows API ENABLE() - turn on a specific feature of WebKit Examples: ENABLE(ACCESSIBILITY) - Enable support for assistive technologies (currently wrongly a HAVE) ENABLE(XSLT) - Include XSLT support ENABLE(OBJC_MAC_API) - Include Objective C API based on NSViews (current WebKit Mac) ENABLE(OBJC_DOM_API) - Include Objective C DOM bindings (may apply to other ObjC toolkits than AppKit) ENABLE(JSC) - Enable use of the JavaScriptCore implementation (inconsistent with V8 because JSC is a
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
Maciej, This sounds good, and sounds like it could clean things up a lot. In the breakdown below you don't explicitly mention what would happen to h/w specific macros like PLATFORM_X86, though you do mention 'CPU' in your email, OOI are you thinking something like?: CPU() Examples: CPU(X86) CPU(X86_64) cheers, G. On Apr 30, 2009, at 4:12 PM, Maciej Stachowiak wrote: I think our set of porting macros has become somewhat confused. Originally, our idea was that a port represents primarily adaptation to a particular platform. However, over time it has become clear that most of what is decided by a port is not platform adaptation, but rather policy decisions. For example, ports decide to have different features enabled, or to use different sets of system functionality on the same underlying OS. In addition, I think the catchall top-level PLATFORM create confusion, because it is not totally clear if they are policy decisions, platform adaptation decisions, or what. Third, it seems wrong that the policy choices of every port are represented as a bunch of ifdef tomfoolery inside a single Platform.h file. And fourth, many ports often run on the same OS, but with a different set of choices - for example on Mac OS X it is possible to build the Mac, Chromium, Gtk, Qt and Wx ports (at least). Therefore, I propose that we change as follows: 1) Strictly separate platform adaptation (mandatory to run on a given OS, compiler, or CPU at all) from policy choices (what features to enable, what optional libraries to use). 2) Phase out PLATFORM macros completely - each use should be converted to a policy choice, or a platform adaptation decision. 3) Instead of ports being defined by a top-level PLATFORM macro, I propose that each port should have its own header file to define policy decisions. For example, I'd propose that the system Mac OS X WebKit should use PortCocoa.h, and the WebKit used by Safari for Windows should use PortWinCG.h. There may also be a PortIPhone.h. These port definition headers would live in their own top-level WebKit module. Each one would be completely owned by whoever is generally considered the owner of a given port. Because related ports on different platforms may wish to share policy choices, it's ok for Port headers to include shared headers for some choices. For example, all Apple-maintained ports may include PortApple.h. We could go even further and have PortDefault.h to make default choices of what features are enabled, that ports would have to explicitly override. 4) Platform adaptation macros would still be defined in Platform.h based on sniffing the environment, this would include things like the compiler, the underlying OS, available libc functions, and so forth. Platform adaptation macros would be: OS() - underlying operating system; only to be used for mandated low- level services like virtual memory, not to choose a GUI toolkit Examples: OS(UNIX) - Any Unix-like OS OS(DARWIN) - Underlying OS is the base OS X environment OS(FREEBSD) - FreeBSD OS(WIN) - Any version of Windows OS(WINCE) - The embedded version of Windows COMPILER() - the compiler being used to build the project Examples: COMPILER(GCC) - GNU Compiler Collection COMPILER(MSVC) - Microsoft Visual C++ COMPILER(RVCT) - ARM compiler HAVE() - specific system features (headers, functions or similar) that are present or not Examples: HAVE(MMAP) - mmap() function is available HAVE(ERRNO_H) - errno.h header is available HAVE(MADV_FREE) - madvise(MADV_FREE) is available Policy decision macros would be: USE() - use a particular third-party library or optional OS service Examples: USE(SKIA) - Use the Skia graphics library USE(CG) - Use CoreGraphics USE(V8) - Use the V8 JavaScript implementation USE(CFNET) - Use CFNetwork networking USE(NSURL_NET) - Use NSURLConnection-based networking USE(APPKIT) - Use AppKit views and events USE(GTK) - Use Gtk+ USE(QT) - Use Qt USE(QUICKTIME) - Use the QuickTime media engine USE(QTKIT) - Use the QuickTime media engine via the Mac QTKit API USE(QUICKTIME_WIN) - Use the QuickTime media engine via its Windows API ENABLE() - turn on a specific feature of WebKit Examples: ENABLE(ACCESSIBILITY) - Enable support for assistive technologies (currently wrongly a HAVE) ENABLE(XSLT) - Include XSLT support ENABLE(OBJC_MAC_API) - Include Objective C API based on NSViews (current WebKit Mac) ENABLE(OBJC_DOM_API) - Include Objective C DOM bindings (may apply to other ObjC toolkits than AppKit) ENABLE(JSC) - Enable use of the JavaScriptCore implementation (inconsistent with V8 because JSC is a WebKit feature but V8 is an external dependency, even though they serve similar purposes)
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
On Apr 30, 2009, at 4:50 PM, Ojan Vafai wrote: This looks great to me. It will definitely make ports more maintainable. For thoroughness sake, it would be good to add a bit about what should be a USE define versus a setting. For example, the EditingBehavior enum in Settings.h could just as easily be a USE define. I think it makes sense in this case to have it be runtime settable because then we can write layout tests that test both Windows and Mac editing behaviors. Good point. (Although in this case the alternative to a runtime setting would be an ENABLE define, not a USE define, since both of the possible behaviors are implemented by code in WebKit, not third-party dependencies.) - Maciej Ojan On Thu, Apr 30, 2009 at 4:12 PM, Maciej Stachowiak m...@apple.com wrote: I think our set of porting macros has become somewhat confused. Originally, our idea was that a port represents primarily adaptation to a particular platform. However, over time it has become clear that most of what is decided by a port is not platform adaptation, but rather policy decisions. For example, ports decide to have different features enabled, or to use different sets of system functionality on the same underlying OS. In addition, I think the catchall top-level PLATFORM create confusion, because it is not totally clear if they are policy decisions, platform adaptation decisions, or what. Third, it seems wrong that the policy choices of every port are represented as a bunch of ifdef tomfoolery inside a single Platform.h file. And fourth, many ports often run on the same OS, but with a different set of choices - for example on Mac OS X it is possible to build the Mac, Chromium, Gtk, Qt and Wx ports (at least). Therefore, I propose that we change as follows: 1) Strictly separate platform adaptation (mandatory to run on a given OS, compiler, or CPU at all) from policy choices (what features to enable, what optional libraries to use). 2) Phase out PLATFORM macros completely - each use should be converted to a policy choice, or a platform adaptation decision. 3) Instead of ports being defined by a top-level PLATFORM macro, I propose that each port should have its own header file to define policy decisions. For example, I'd propose that the system Mac OS X WebKit should use PortCocoa.h, and the WebKit used by Safari for Windows should use PortWinCG.h. There may also be a PortIPhone.h. These port definition headers would live in their own top-level WebKit module. Each one would be completely owned by whoever is generally considered the owner of a given port. Because related ports on different platforms may wish to share policy choices, it's ok for Port headers to include shared headers for some choices. For example, all Apple-maintained ports may include PortApple.h. We could go even further and have PortDefault.h to make default choices of what features are enabled, that ports would have to explicitly override. 4) Platform adaptation macros would still be defined in Platform.h based on sniffing the environment, this would include things like the compiler, the underlying OS, available libc functions, and so forth. Platform adaptation macros would be: OS() - underlying operating system; only to be used for mandated low- level services like virtual memory, not to choose a GUI toolkit Examples: OS(UNIX) - Any Unix-like OS OS(DARWIN) - Underlying OS is the base OS X environment OS(FREEBSD) - FreeBSD OS(WIN) - Any version of Windows OS(WINCE) - The embedded version of Windows COMPILER() - the compiler being used to build the project Examples: COMPILER(GCC) - GNU Compiler Collection COMPILER(MSVC) - Microsoft Visual C++ COMPILER(RVCT) - ARM compiler HAVE() - specific system features (headers, functions or similar) that are present or not Examples: HAVE(MMAP) - mmap() function is available HAVE(ERRNO_H) - errno.h header is available HAVE(MADV_FREE) - madvise(MADV_FREE) is available Policy decision macros would be: USE() - use a particular third-party library or optional OS service Examples: USE(SKIA) - Use the Skia graphics library USE(CG) - Use CoreGraphics USE(V8) - Use the V8 JavaScript implementation USE(CFNET) - Use CFNetwork networking USE(NSURL_NET) - Use NSURLConnection-based networking USE(APPKIT) - Use AppKit views and events USE(GTK) - Use Gtk+ USE(QT) - Use Qt USE(QUICKTIME) - Use the QuickTime media engine USE(QTKIT) - Use the QuickTime media engine via the Mac QTKit API USE(QUICKTIME_WIN) - Use the QuickTime media engine via its Windows API ENABLE() - turn on a specific feature of WebKit Examples: ENABLE(ACCESSIBILITY) - Enable support for assistive technologies (currently wrongly a HAVE) ENABLE(XSLT) - Include XSLT
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
On Apr 30, 2009, at 5:02 PM, Gavin Barraclough wrote: Maciej, This sounds good, and sounds like it could clean things up a lot. In the breakdown below you don't explicitly mention what would happen to h/w specific macros like PLATFORM_X86, though you do mention 'CPU' in your email, OOI are you thinking something like?: CPU() Examples: CPU(X86) CPU(X86_64) Yes, pretty much. And we can have hierarchies of CPU defines for families of related instruction sets should that ever be useful. Not sure it will be. Endianness would be another example of a potential platform adaptation macro, and possibly also pointer size, although the latter is detectable from code fairly simply and so perhaps not worth the effort. - Maciej cheers, G. On Apr 30, 2009, at 4:12 PM, Maciej Stachowiak wrote: I think our set of porting macros has become somewhat confused. Originally, our idea was that a port represents primarily adaptation to a particular platform. However, over time it has become clear that most of what is decided by a port is not platform adaptation, but rather policy decisions. For example, ports decide to have different features enabled, or to use different sets of system functionality on the same underlying OS. In addition, I think the catchall top-level PLATFORM create confusion, because it is not totally clear if they are policy decisions, platform adaptation decisions, or what. Third, it seems wrong that the policy choices of every port are represented as a bunch of ifdef tomfoolery inside a single Platform.h file. And fourth, many ports often run on the same OS, but with a different set of choices - for example on Mac OS X it is possible to build the Mac, Chromium, Gtk, Qt and Wx ports (at least). Therefore, I propose that we change as follows: 1) Strictly separate platform adaptation (mandatory to run on a given OS, compiler, or CPU at all) from policy choices (what features to enable, what optional libraries to use). 2) Phase out PLATFORM macros completely - each use should be converted to a policy choice, or a platform adaptation decision. 3) Instead of ports being defined by a top-level PLATFORM macro, I propose that each port should have its own header file to define policy decisions. For example, I'd propose that the system Mac OS X WebKit should use PortCocoa.h, and the WebKit used by Safari for Windows should use PortWinCG.h. There may also be a PortIPhone.h. These port definition headers would live in their own top-level WebKit module. Each one would be completely owned by whoever is generally considered the owner of a given port. Because related ports on different platforms may wish to share policy choices, it's ok for Port headers to include shared headers for some choices. For example, all Apple-maintained ports may include PortApple.h. We could go even further and have PortDefault.h to make default choices of what features are enabled, that ports would have to explicitly override. 4) Platform adaptation macros would still be defined in Platform.h based on sniffing the environment, this would include things like the compiler, the underlying OS, available libc functions, and so forth. Platform adaptation macros would be: OS() - underlying operating system; only to be used for mandated low-level services like virtual memory, not to choose a GUI toolkit Examples: OS(UNIX) - Any Unix-like OS OS(DARWIN) - Underlying OS is the base OS X environment OS(FREEBSD) - FreeBSD OS(WIN) - Any version of Windows OS(WINCE) - The embedded version of Windows COMPILER() - the compiler being used to build the project Examples: COMPILER(GCC) - GNU Compiler Collection COMPILER(MSVC) - Microsoft Visual C++ COMPILER(RVCT) - ARM compiler HAVE() - specific system features (headers, functions or similar) that are present or not Examples: HAVE(MMAP) - mmap() function is available HAVE(ERRNO_H) - errno.h header is available HAVE(MADV_FREE) - madvise(MADV_FREE) is available Policy decision macros would be: USE() - use a particular third-party library or optional OS service Examples: USE(SKIA) - Use the Skia graphics library USE(CG) - Use CoreGraphics USE(V8) - Use the V8 JavaScript implementation USE(CFNET) - Use CFNetwork networking USE(NSURL_NET) - Use NSURLConnection-based networking USE(APPKIT) - Use AppKit views and events USE(GTK) - Use Gtk+ USE(QT) - Use Qt USE(QUICKTIME) - Use the QuickTime media engine USE(QTKIT) - Use the QuickTime media engine via the Mac QTKit API USE(QUICKTIME_WIN) - Use the QuickTime media engine via its Windows API ENABLE() - turn on a specific feature of WebKit Examples: ENABLE(ACCESSIBILITY) - Enable support for assistive technologies (currently wrongly a HAVE) ENABLE(XSLT) - Include XSLT support
