Re: [webkit-dev] Moving away from qmake
On Nov 12, 2007, at 1:26 PM, Timothy Hatcher wrote: We could add a script that would add/remove/rename files in all the project files for the various build systems. Yeah, that's what I had in mind, more than a meta-build-system. If we had that, it would remove 90% of the pain of multiple build systems. Adding new generated source files could still be an issue, though. Cheers, Maciej On Nov 12, 2007, at 1:19 PM, David D. Kilzer wrote: Kevin Ollivier [EMAIL PROTECTED] wrote: [...] The tricky part AFAICT would be XCode, though, because even if there is a scripted solution for this, it would probably need to be run on a Mac where we have access to AppleScript or some other scripting tool that can read and make changes to XCode projects... [...] Xcode project files are plain text as well. It's possible to update them via script (see WebKitTools/Scripts/sort-Xcode-project-file), but it requires a little more insight than just staring at the source. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
On Mon, Nov 12, 2007 at 03:34:48AM +, Alp Toker [EMAIL PROTECTED] wrote: An unforeseen benefit of the new build system is that it is modular, rather than monolithic, and has no dependency on GLib/GTK+ or any other framework. This means that it will now be possible to use JavaScriptCore as a standalone scripting engine independently of WebKit. Except that for the moment, JavaScriptCore is a little bit different if built for the Qt port or the Gtk+ port, so it couldn't be shared between both, which is pretty sad, actually. As for switching away from qmake, I'm all for it, though I have no problem having to use qmake for the Gtk+ port, since I'm already building both Qt and Gtk+ ports in one pass for the Debian packages. I'll only add this: it would be nice to avoid linking to indirectly used libraries where possible, though it may be challenging. (I'm using -Wl,--as-needed for that matter) Mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake (aka. modularising JavaScriptCore)
Mike Hommey wrote: On Mon, Nov 12, 2007 at 03:34:48AM +, Alp Toker [EMAIL PROTECTED] wrote: An unforeseen benefit of the new build system is that it is modular, rather than monolithic, and has no dependency on GLib/GTK+ or any other framework. This means that it will now be possible to use JavaScriptCore as a standalone scripting engine independently of WebKit. Except that for the moment, JavaScriptCore is a little bit different if built for the Qt port or the Gtk+ port, so it couldn't be shared between both, which is pretty sad, actually. I can go into the issues here a bit further, though it doesn't directly relate to the choice of build system. When it comes to platform-specific code in JavaScriptCore, the most obvious issue is the set of platform/language bindings. Luckily the fix for this is pretty obvious, and I've filed a bug: http://bugs.webkit.org/show_bug.cgi?id=15931 Eliminate Instance::createBindingForLanguageInstance() The other instance of platform specific code that I can see is Qt's use of Unicode functionality, while other ports tend to use ICU. I've actually been planning to port the Unicode abstraction to use GLib, since ICU is a very heavy dependency for non-desktop systems. (There is potential to shave up to 10M off the distribution size of the GTK+ port for mobile devices here.) This is however a thankless job that nobody else seems to be interested in doing and I've put it off till now: http://bugs.webkit.org/show_bug.cgi?id=15914 [GTK] Implement Unicode functionality using GLib So this would actually be a step away from re-usability as a shared library but a step towards a lower mobile memory footprint. There are a few other bits of Qt-specific code such as that in DateMath, but these do not seem significant, and if the other two issues were fixed I imagine the Qt developers would be happy to compromise on those. As long as ports work to avoid ICU for Unicode functionality, I don't think we're going to get around to genuinely sharing JavaScriptCore, and to be honest, I don't see this being a real problem. How many people will run Konqueror and Epiphany at the same time (for reasons other than testing)? Will those people who do regularly use both Konqueror and Epiphany miss the 1-2M that could have been shared given that the complete applications are taking at least 10M each? So while I think there is the possibility of having a standalone JavaScriptCore edition embedding into applications, I do not think there is any immediate hope of having a single JavaScriptCore library shared between ports. Lots of effort for minimal gain. The real benefit in having a standalone build profile for JavaScriptCore in my use case was that it made it far more practical to hack on the new CLR/JavaScript binding. This would have been really unpleasant if I had to build and link the whole of WebKit each time I made a change. I think that lowering the barrier for new JS bindings alone is a good cause for having a modular JavaScriptCore build target, but maybe I'm the only one developing new JS bindings right now? As for switching away from qmake, I'm all for it, though I have no problem having to use qmake for the Gtk+ port, since I'm already building both Qt and Gtk+ ports in one pass for the Debian packages. I'll only add this: it would be nice to avoid linking to indirectly used libraries where possible, though it may be challenging. (I'm using -Wl,--as-needed for that matter) Mike You and I have learnt how to deal with qmake, but I've recently discovered that casual contributors and potential adopters in GNOME are taking one look at the qmake build system and turning around. It also seems to be antagonising people who use source-based distributions like Gentoo and who would otherwise never have a reason to take an hour out of their lives building the whole of Qt. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
If we cannot reach a conclusion, the GTK+ port will most likely go ahead and switch to autotools. I'm one person with a highly niche port, but for what its worth I'd support a move to autotools. I'm doing a port to AROS, which currently means cross-building WebKit on Linux. I opted to use qmake because it was the easiest one to get set up in a hurry (I have a little GTK+ experience so I could see how to cobble together what I needed from the gtk-port stuff). Getting the cross-compile happening is a bit of a hack though, and qmake docs are rather thin. If qmake is as hard to get hold of as you say (I don't actually know, my distribution had it packaged), then I really don't want to put that on my developers. Besides, eventually we will want to be able to develop WebKit natively on AROS. Its highly non-POSIX, but we already have ports of most of the tools need to do configure stuff. Since QT is not something we'll ever need, a port isn't likely to appear. Also cross-building is something I already know how to do with autotools, which will mean less effort for me getting it set up. 2c. Cheers, Rob. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
I am working on a port of WebKit on Qt to a PowerPC platform. Please make sure that we don't break the Qt port in this switch. I am comfortable with autotools, so that is not a big deal for me. I am concerned, however, that this will cause a fork with the work being done by the Trolltech folks (since I think that they are primarily qmake-promoters). Can we get some feedback from Trolltech on their ability to accept a switch to autotools for Webkit/Qt so we can switch to one new engine for all these ports? Thanks, Charlie On Nov 12, 2007, at 7:14 AM, Robert Norris wrote: If we cannot reach a conclusion, the GTK+ port will most likely go ahead and switch to autotools. I'm one person with a highly niche port, but for what its worth I'd support a move to autotools. I'm doing a port to AROS, which currently means cross-building WebKit on Linux. I opted to use qmake because it was the easiest one to get set up in a hurry (I have a little GTK+ experience so I could see how to cobble together what I needed from the gtk-port stuff). Getting the cross-compile happening is a bit of a hack though, and qmake docs are rather thin. If qmake is as hard to get hold of as you say (I don't actually know, my distribution had it packaged), then I really don't want to put that on my developers. Besides, eventually we will want to be able to develop WebKit natively on AROS. Its highly non-POSIX, but we already have ports of most of the tools need to do configure stuff. Since QT is not something we'll ever need, a port isn't likely to appear. Also cross-building is something I already know how to do with autotools, which will mean less effort for me getting it set up. 2c. Cheers, Rob. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev Charles Woloszynski Innovative Concepts, Inc. Sr. Director, Advanced Networking Systems [EMAIL PROTECTED] (703) 893-2007 x506 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
Hello, Here is my experience with cmake, so I hope it may help you to decide which build system is the best for you. Its first advantage is that it is cross platform. So you can imagine in a long term approach to have a unified build system between GTK/Qt/Wx/Win and mac. Another advantage is that it is from my point of view quite simple to understand and to use for basic stuff like adding a library dependency to the build. Moreover there are many ready to use macro to ease this work. As an example, if you want to add a dependency with JPEG library, use FindJPEG module and it will store useful info in variables like JPEG_LIBRARIES. About documentation, well simply have a look at http://www.cmake.org/HTML/Documentation.html page, it should convince you. Another feature I like are curses interfaces for your project configuration (you can switch options, compiler flags and even compiler). And of course you do not have to rebuild the whole project each time you modify things. And if things are done correctly you do not even have to rebuild the whole project when you add a new feature. Imagine that you have built WebKit/GTK without SVG support and you want to add it. It can simply recompile svg missing .o and of course redo linking. Of course that's not true if you switch from a debug build option to a release build. Of course from time to time you may have to rebuild the whole project because you have modify things in cmake config files. Another insteresting features is that cmake allow you to create a build directory where will be stored all your object files. So your source tree remains clean. About drawbacks, the main is about cross-compilation. I know that cmake guys work on this issue but currently I still have to do ugly things when I cross compile webkit because of dftables. As a matter of fact dftables is also cross-compiled and when you try to run an ARM dftables exec on a x86 arch, it cannot work. But I hope I will be able to fix this soon. The more people are involved in Cmake process, the more we get chances to overcome these little issues. The other drawback you can have is that you will have to compile/install cmake when you are in a scratchbox environment. And if you want to give a try to cmake alternative, let me know, I can provide you files to compile WebCore/JavascriptCore with cmake. And I can also try to help you to meet your goal. Regards, De : Alp Toker [EMAIL PROTECTED] Date : 12 novembre 2007 04:34:48 HNEC À : [EMAIL PROTECTED] Objet : [webkit-dev] Moving away from qmake The existing qmake-based build system is shared by the GTK+ and Qt ports. Until recently, this arrangement has not been too problematic for the GTK+ porters, with the idea being that qmake makes life easier for developers at the expense of a little inconvenience for users (in the sense of application developers rather than end users). However, it has recently become clear that qmake is actually making life more difficult for developers. It turns out that the existing qmake build system fails to do basic dependency tracking, leaving both developers and users with crashy builds, with the only way to get a stable build being to do a full clean and rebuild after every update. In the last week I've had to explain why people's builds are crashing to maybe half a dozen people on WebKit and GNOME-related channels. Mark and I have attempted to fix the dependency tracking a number of times, but we've both found qmake to be poorly documented, and our attempts to fix it ended up breaking the build even more in certain configurations. My informal attempts to get assistance from the Trolltech guys doing the Qt port have gone unanswered. I have no doubt that we would be able to fix these issues in a matter of minutes using a better understood or documented build system. Moreover, it has turned out that the qmake build dependency is more than just a little inconvenience for users. It makes the GTK+ port inaccessible to a lot of developers. Using anything but the latest Linux distributions, including cross-compilation frameworks like Scratchbox, you have to build the whole of Qt just to get qmake, which takes over an hour and almost a gigabyte of disk space for me. That's at least 5 times as long as it takes to build the whole of JavaScriptCore, WebCore and WebKit. Even in distributions that ship a recent binary of qmake, it is often bundled into the same binary package as the rest of Qt, making it a seriously large dependency. Now that the GTK+ port is getting attention from beyond a core team of developers, I think such a heavy build dependency is no longer acceptable. If either the Wx or Qt porters are willing to share a new build system with the GTK+ port, they should speak up now. We're willing to consider any build system that does not incur a huge dependency (ruling out qmake) and that is actively maintained and does not have verbose XML makefiles (ruling out Bakefile and
Re: [webkit-dev] Moving away from qmake
On Monday 12 November 2007 14:00:31 Charles Woloszynski wrote: I am working on a port of WebKit on Qt to a PowerPC platform. Please make sure that we don't break the Qt port in this switch. I am comfortable with autotools, so that is not a big deal for me. I am concerned, however, that this will cause a fork with the work being done by the Trolltech folks (since I think that they are primarily qmake-promoters). Can we get some feedback from Trolltech on their ability to accept a switch to autotools for Webkit/Qt so we can switch to one new engine for all these ports? Trolltech is likely to continue to use the qmake based build system for now. That is because we are working on integrating WebKit into the build of Qt itself (which is built using qmake) and we need to be able to build WebKit without cygwin or bash installed on Windows. Simon signature.asc Description: This is a digitally signed message part. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
On 13/11/2007, at 00:00, Charles Woloszynski wrote: I am working on a port of WebKit on Qt to a PowerPC platform. Please make sure that we don't break the Qt port in this switch. I am comfortable with autotools, so that is not a big deal for me. I am concerned, however, that this will cause a fork with the work being done by the Trolltech folks (since I think that they are primarily qmake-promoters). Can we get some feedback from Trolltech on their ability to accept a switch to autotools for Webkit/Qt so we can switch to one new engine for all these ports? It would obviously be great if build systems could be shared between ports, but at the same time I don't think that this desire to share build systems should introduce obstacles to the adoption of WebKit ports in the wider open source community. The maintainers of the Qt and wxWidgets ports have a desire to keep their build systems similar to those used by the underlying toolkits of their port as it greatly simplifies their integration work. The same is true of the Apple ports and their build systems. While the introduction of another build system would introduce slightly more overhead for changes that require modifications be made to the build system, such changes are relatively infrequent and are typically simple additions or removals of files. The extra work required would be small in comparison to the benefit that the GTK+ port would gain from using a more native build system. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
Ok, thanks for the feedback. I have had some issues with the cross- compilation of WebKit (dftables being built for the cross-platform, not the native platform). Any chance I can get someone doing the WebKit Qt port to address this? I don't know qmake well enough to make the changes. The defect was there two weeks ago, and I don't think I've seen any changes in that area since... Charlie On Nov 12, 2007, at 8:19 AM, Simon Hausmann wrote: On Monday 12 November 2007 14:00:31 Charles Woloszynski wrote: I am working on a port of WebKit on Qt to a PowerPC platform. Please make sure that we don't break the Qt port in this switch. I am comfortable with autotools, so that is not a big deal for me. I am concerned, however, that this will cause a fork with the work being done by the Trolltech folks (since I think that they are primarily qmake-promoters). Can we get some feedback from Trolltech on their ability to accept a switch to autotools for Webkit/Qt so we can switch to one new engine for all these ports? Trolltech is likely to continue to use the qmake based build system for now. That is because we are working on integrating WebKit into the build of Qt itself (which is built using qmake) and we need to be able to build WebKit without cygwin or bash installed on Windows. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev Charles Woloszynski Innovative Concepts, Inc. Sr. Director, Advanced Networking Systems [EMAIL PROTECTED] (703) 893-2007 x506 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake (aka. modularising JavaScriptCore)
I refactored all the Unicode handling to run behind a abstract interface. So no direct ICU calls. Its a lot of little patches all over the place and a thankless job. Its a lot of work so email me if your interested. I was also looking at repacling icu with glib/pango. Its not clear you get everything you need from glib so I believe you have to bring in pango which does more than you want. Pango itself needs to be split into text metrics and glyph drawing. On Nov 12, 2007 3:28 AM, Alp Toker [EMAIL PROTECTED] wrote: Mike Hommey wrote: On Mon, Nov 12, 2007 at 03:34:48AM +, Alp Toker [EMAIL PROTECTED] wrote: An unforeseen benefit of the new build system is that it is modular, rather than monolithic, and has no dependency on GLib/GTK+ or any other framework. This means that it will now be possible to use JavaScriptCore as a standalone scripting engine independently of WebKit. Except that for the moment, JavaScriptCore is a little bit different if built for the Qt port or the Gtk+ port, so it couldn't be shared between both, which is pretty sad, actually. I can go into the issues here a bit further, though it doesn't directly relate to the choice of build system. When it comes to platform-specific code in JavaScriptCore, the most obvious issue is the set of platform/language bindings. Luckily the fix for this is pretty obvious, and I've filed a bug: http://bugs.webkit.org/show_bug.cgi?id=15931 Eliminate Instance::createBindingForLanguageInstance() The other instance of platform specific code that I can see is Qt's use of Unicode functionality, while other ports tend to use ICU. I've actually been planning to port the Unicode abstraction to use GLib, since ICU is a very heavy dependency for non-desktop systems. (There is potential to shave up to 10M off the distribution size of the GTK+ port for mobile devices here.) This is however a thankless job that nobody else seems to be interested in doing and I've put it off till now: http://bugs.webkit.org/show_bug.cgi?id=15914 [GTK] Implement Unicode functionality using GLib So this would actually be a step away from re-usability as a shared library but a step towards a lower mobile memory footprint. There are a few other bits of Qt-specific code such as that in DateMath, but these do not seem significant, and if the other two issues were fixed I imagine the Qt developers would be happy to compromise on those. As long as ports work to avoid ICU for Unicode functionality, I don't think we're going to get around to genuinely sharing JavaScriptCore, and to be honest, I don't see this being a real problem. How many people will run Konqueror and Epiphany at the same time (for reasons other than testing)? Will those people who do regularly use both Konqueror and Epiphany miss the 1-2M that could have been shared given that the complete applications are taking at least 10M each? So while I think there is the possibility of having a standalone JavaScriptCore edition embedding into applications, I do not think there is any immediate hope of having a single JavaScriptCore library shared between ports. Lots of effort for minimal gain. The real benefit in having a standalone build profile for JavaScriptCore in my use case was that it made it far more practical to hack on the new CLR/JavaScript binding. This would have been really unpleasant if I had to build and link the whole of WebKit each time I made a change. I think that lowering the barrier for new JS bindings alone is a good cause for having a modular JavaScriptCore build target, but maybe I'm the only one developing new JS bindings right now? As for switching away from qmake, I'm all for it, though I have no problem having to use qmake for the Gtk+ port, since I'm already building both Qt and Gtk+ ports in one pass for the Debian packages. I'll only add this: it would be nice to avoid linking to indirectly used libraries where possible, though it may be challenging. (I'm using -Wl,--as-needed for that matter) Mike You and I have learnt how to deal with qmake, but I've recently discovered that casual contributors and potential adopters in GNOME are taking one look at the qmake build system and turning around. It also seems to be antagonising people who use source-based distributions like Gentoo and who would otherwise never have a reason to take an hour out of their lives building the whole of Qt. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
On Nov 12, 2007, at 5:28 AM, Mark Rowe wrote: On 13/11/2007, at 00:00, Charles Woloszynski wrote: I am working on a port of WebKit on Qt to a PowerPC platform. Please make sure that we don't break the Qt port in this switch. I am comfortable with autotools, so that is not a big deal for me. I am concerned, however, that this will cause a fork with the work being done by the Trolltech folks (since I think that they are primarily qmake-promoters). Can we get some feedback from Trolltech on their ability to accept a switch to autotools for Webkit/Qt so we can switch to one new engine for all these ports? It would obviously be great if build systems could be shared between ports, but at the same time I don't think that this desire to share build systems should introduce obstacles to the adoption of WebKit ports in the wider open source community. The maintainers of the Qt and wxWidgets ports have a desire to keep their build systems similar to those used by the underlying toolkits of their port as it greatly simplifies their integration work. The same is true of the Apple ports and their build systems. While the introduction of another build system would introduce slightly more overhead for changes that require modifications be made to the build system, such changes are relatively infrequent and are typically simple additions or removals of files. The extra work required would be small in comparison to the benefit that the GTK+ port would gain from using a more native build system. As someone who adds and removes files frequently, I do find the build system proliferation to be a nontrivial cost. However, I think the worst build systems from this point of view are ones that aren't easily human-editable, which I think is mainly the Xcode and Visual Studio project files. If we add more build systems, it would be really helpful to put up a page that tells you what steps you should take if you add or remove files. Maybe we could even write a script to add a file to or remove a file from all build systems. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
On Nov 12, 2007, at 11:33 AM, Maciej Stachowiak wrote: On Nov 12, 2007, at 5:28 AM, Mark Rowe wrote: On 13/11/2007, at 00:00, Charles Woloszynski wrote: I am working on a port of WebKit on Qt to a PowerPC platform. Please make sure that we don't break the Qt port in this switch. I am comfortable with autotools, so that is not a big deal for me. I am concerned, however, that this will cause a fork with the work being done by the Trolltech folks (since I think that they are primarily qmake-promoters). Can we get some feedback from Trolltech on their ability to accept a switch to autotools for Webkit/Qt so we can switch to one new engine for all these ports? It would obviously be great if build systems could be shared between ports, but at the same time I don't think that this desire to share build systems should introduce obstacles to the adoption of WebKit ports in the wider open source community. The maintainers of the Qt and wxWidgets ports have a desire to keep their build systems similar to those used by the underlying toolkits of their port as it greatly simplifies their integration work. The same is true of the Apple ports and their build systems. While the introduction of another build system would introduce slightly more overhead for changes that require modifications be made to the build system, such changes are relatively infrequent and are typically simple additions or removals of files. The extra work required would be small in comparison to the benefit that the GTK+ port would gain from using a more native build system. As someone who adds and removes files frequently, I do find the build system proliferation to be a nontrivial cost. However, I think the worst build systems from this point of view are ones that aren't easily human-editable, which I think is mainly the Xcode and Visual Studio project files. If we add more build systems, it would be really helpful to put up a page that tells you what steps you should take if you add or remove files. Maybe we could even write a script to add a file to or remove a file from all build systems. I agree. That I can generate those automatically, along with standard makefiles, from a single text source is the reason I stick with qmake on my project. You sometimes have to jump through hoops with qmake, in order to capture complex dependencies or source file generation, but it does it well on all platforms I use, including Windows, and it lets me use the XCode gui on Mac, Visual Studio on Windows, emacs and Make on linux from the same build infrastructure. I've tried cmake, waf, cons, scons and several others that claim to be cross-platform build tools, and not found them capable enough, especially when it comes to targeting Windows development. Cheers, Steve ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
Le 12 nov. 07 à 20:55, Kevin Ollivier a écrit : I'm fairly sure this would be easy enough for MSVS because of its XML nature. In fact, I did things the opposite way (converted MSVS XML - Bakefile) when I first started adding in the wx port, so that we kept up-to-date with any changes to the common files. (As a side effect of this, the wx port files are grouped by category rather than just being a long list.) The tricky part AFAICT would be XCode, though, because even if there is a scripted solution for this, it would probably need to be run on a Mac where we have access to AppleScript or some other scripting tool that can read and make changes to XCode projects... (Bakefile can write XCode project files, but it can't read them in.) Though still, even if we couldn't automatically update the XCode Project file in all cases, we'd be left with making the same change at most twice, as I think every other build tool uses a plain text- based or XML format. Also, if the script wasn't able to update the XCode Project file for whatever reason, we could have it either spit out a warning or even add a warning into the ChangeLog entry that the XCode Project wasn't updated with the file change. Regards, Kevin Another interesting point for CMake is its ability to generate XCode project files (dunno if it is also able to generate MSVS files but if they are XMLs, I don't see why it shouldn't/couldn't) Jean-Charles -- Jean-Charles Verdié A question for you: www.pleyo.com Pleyo, CTO mobile: +33 (0)6 282 616 05 skype: jcverdie ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
On 13/11/2007, at 07:10, Jean-Charles VERDIE (Pleyo) wrote: Le 12 nov. 07 à 20:55, Kevin Ollivier a écrit : I'm fairly sure this would be easy enough for MSVS because of its XML nature. In fact, I did things the opposite way (converted MSVS XML - Bakefile) when I first started adding in the wx port, so that we kept up-to-date with any changes to the common files. (As a side effect of this, the wx port files are grouped by category rather than just being a long list.) The tricky part AFAICT would be XCode, though, because even if there is a scripted solution for this, it would probably need to be run on a Mac where we have access to AppleScript or some other scripting tool that can read and make changes to XCode projects... (Bakefile can write XCode project files, but it can't read them in.) Though still, even if we couldn't automatically update the XCode Project file in all cases, we'd be left with making the same change at most twice, as I think every other build tool uses a plain text- based or XML format. Also, if the script wasn't able to update the XCode Project file for whatever reason, we could have it either spit out a warning or even add a warning into the ChangeLog entry that the XCode Project wasn't updated with the file change. Another interesting point for CMake is its ability to generate XCode project files (dunno if it is also able to generate MSVS files but if they are XMLs, I don't see why it shouldn't/couldn't) Why is that useful? - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
Le 12 nov. 07 à 21:12, Mark Rowe a écrit : On 13/11/2007, at 07:10, Jean-Charles VERDIE (Pleyo) wrote: Le 12 nov. 07 à 20:55, Kevin Ollivier a écrit : I'm fairly sure this would be easy enough for MSVS because of its XML nature. In fact, I did things the opposite way (converted MSVS XML - Bakefile) when I first started adding in the wx port, so that we kept up-to-date with any changes to the common files. (As a side effect of this, the wx port files are grouped by category rather than just being a long list.) The tricky part AFAICT would be XCode, though, because even if there is a scripted solution for this, it would probably need to be run on a Mac where we have access to AppleScript or some other scripting tool that can read and make changes to XCode projects... (Bakefile can write XCode project files, but it can't read them in.) Though still, even if we couldn't automatically update the XCode Project file in all cases, we'd be left with making the same change at most twice, as I think every other build tool uses a plain text-based or XML format. Also, if the script wasn't able to update the XCode Project file for whatever reason, we could have it either spit out a warning or even add a warning into the ChangeLog entry that the XCode Project wasn't updated with the file change. Another interesting point for CMake is its ability to generate XCode project files (dunno if it is also able to generate MSVS files but if they are XMLs, I don't see why it shouldn't/couldn't) Why is that useful? I might be wrong but I think it's useful to be able to generate, from the same sources and using a CMake facility, an Xcode project (to work under XCode on Mac), a VS project, a CMakeFile for linux-based solutions, - Mark -- Jean-Charles Verdié A question for you: www.pleyo.com Pleyo, CTO mobile: +33 (0)6 282 616 05 skype: jcverdie ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
Apple needs to use native Xcode and VS projects to work with existing build systems. So generating an Xcode or VS project is not useful. On Nov 12, 2007, at 12:20 PM, Jean-Charles VERDIE (Pleyo) wrote: I might be wrong but I think it's useful to be able to generate, from the same sources and using a CMake facility, an Xcode project (to work under XCode on Mac), a VS project, a CMakeFile for linux- based solutions, — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
Kevin Ollivier [EMAIL PROTECTED] wrote: [...] The tricky part AFAICT would be XCode, though, because even if there is a scripted solution for this, it would probably need to be run on a Mac where we have access to AppleScript or some other scripting tool that can read and make changes to XCode projects... [...] Xcode project files are plain text as well. It's possible to update them via script (see WebKitTools/Scripts/sort-Xcode-project-file), but it requires a little more insight than just staring at the source. Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
We could add a script that would add/remove/rename files in all the project files for the various build systems. On Nov 12, 2007, at 1:19 PM, David D. Kilzer wrote: Kevin Ollivier [EMAIL PROTECTED] wrote: [...] The tricky part AFAICT would be XCode, though, because even if there is a scripted solution for this, it would probably need to be run on a Mac where we have access to AppleScript or some other scripting tool that can read and make changes to XCode projects... [...] Xcode project files are plain text as well. It's possible to update them via script (see WebKitTools/Scripts/sort-Xcode-project-file), but it requires a little more insight than just staring at the source. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
Hi David, On Nov 12, 2007, at 1:19 PM, David D. Kilzer wrote: Kevin Ollivier [EMAIL PROTECTED] wrote: [...] The tricky part AFAICT would be XCode, though, because even if there is a scripted solution for this, it would probably need to be run on a Mac where we have access to AppleScript or some other scripting tool that can read and make changes to XCode projects... [...] Xcode project files are plain text as well. It's possible to update them via script (see WebKitTools/Scripts/sort-Xcode-project-file), but it requires a little more insight than just staring at the source. Right, in fact, I actually wrote a fair chunk of the XCode backend for Bakefile, so I do remember the basics of the format, although my memory is a bit hazy. :-) But the issue I saw with that approach is that adding a file doesn't just mean inserting a file entry, XCode uses UUIDs to refer to files and creates hierarchies of UUIDs to manage folder hierarchies and the like. So to add a file to a certain project folder, you'd have to retrieve the UUID of the parent folder the file is to be inserted into, along with any parent folders for that folder to know which PBXGroup in the project file you should insert the new file's UUID into, and I don't know how we can get that info without parsing the file and folder listing out of the XCode project file. It seems there would be similar issues with adding/ removing a folder from the project file. In short, I'm not sure we could get away with making those changes reliably without parsing at least some chunks of the project file, if not most of it. (WebCore.xcodeproj/project.pbxproj, for example, largely consists of file references and folder organization.) However, I have to admit I haven't seriously thought about the matter before today, so it's possible I'm missing or overlooking something important. Any ideas of how we could do this more simply? Thanks, Kevin Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
Hi Alp, On Nov 11, 2007, at 7:34 PM, Alp Toker wrote: The existing qmake-based build system is shared by the GTK+ and Qt ports. Until recently, this arrangement has not been too problematic for the GTK+ porters, with the idea being that qmake makes life easier for developers at the expense of a little inconvenience for users (in the sense of application developers rather than end users). However, it has recently become clear that qmake is actually making life more difficult for developers. It turns out that the existing qmake build system fails to do basic dependency tracking, leaving both developers and users with crashy builds, with the only way to get a stable build being to do a full clean and rebuild after every update. In the last week I've had to explain why people's builds are crashing to maybe half a dozen people on WebKit and GNOME-related channels. Mark and I have attempted to fix the dependency tracking a number of times, but we've both found qmake to be poorly documented, and our attempts to fix it ended up breaking the build even more in certain configurations. My informal attempts to get assistance from the Trolltech guys doing the Qt port have gone unanswered. I have no doubt that we would be able to fix these issues in a matter of minutes using a better understood or documented build system. Moreover, it has turned out that the qmake build dependency is more than just a little inconvenience for users. It makes the GTK+ port inaccessible to a lot of developers. Using anything but the latest Linux distributions, including cross-compilation frameworks like Scratchbox, you have to build the whole of Qt just to get qmake, which takes over an hour and almost a gigabyte of disk space for me. That's at least 5 times as long as it takes to build the whole of JavaScriptCore, WebCore and WebKit. Even in distributions that ship a recent binary of qmake, it is often bundled into the same binary package as the rest of Qt, making it a seriously large dependency. Now that the GTK+ port is getting attention from beyond a core team of developers, I think such a heavy build dependency is no longer acceptable. If either the Wx or Qt porters are willing to share a new build system with the GTK+ port, they should speak up now. We're willing to consider any build system that does not incur a huge dependency (ruling out qmake) and that is actively maintained and does not have verbose XML makefiles (ruling out Bakefile and Ant-like build systems respectively). cmake and autotools are fair game here, for example. If we cannot reach a conclusion, the GTK+ port will most likely go ahead and switch to autotools. Work has already started to provide an autotools-based build system at http://git.ndesk.org/?p=javascriptcore-modular An unforeseen benefit of the new build system is that it is modular, rather than monolithic, and has no dependency on GLib/GTK+ or any other framework. This means that it will now be possible to use JavaScriptCore as a standalone scripting engine independently of WebKit. I hope I've accurately summarised the thoughts of all those involved here. (It's quite unfortunate that we might end up contributing to the current proliferation of build systems, but I think it's fair to say that the qmake dependency is right now the biggest single issue holding back development and acceptance of the GTK+ port. If other ports are willing to compromise in the same way as we are on a shared solution, this proliferation can still be avoided.) Unfortunately, I don't see room to compromise on my end because neither autotools or cmake will meet my needs without a fair amount more effort on my part (effort I'd rather spend putting into improving wxWebKit itself), and I pretty much get all of the other benefits you mentioned are obtained by switching away from qmake, so there's not really any plus for me. Honestly, I find the Bakefile build system to not be very verbose at all thanks to its use of templates, which allow me to group together settings needed by various components and reuse them easily. The largest files are the *Sources.xml files, but those are very light on XML tags and are mostly text files, and are easy to update and maintain, IMHO. Over the past couple weeks, I in fact did a lot of refactoring on the build system and it was quite quick to do and I'm really pleased with the results. I haven't yet found a (cross- platform) tool that lets me be as productive as Bakefile does, which is the bottom line for me as my time is limited. The one downside to Bakefile is that it's newer than other systems and over time I've bumped into a few rough edges, but most of those have gotten fixed. Even with having to make a few temporary workarounds, though, I find it saves me a lot of time in other areas that more than makes up for it. Anyway, I won't press the matter; I admit I don't have a Unix
