Re: [webkit-dev] Subject: Windows CE port in WebKit: status, future work
Hi Ossy, removing Windows CE code sounds ok to me, since it shouldn't be a big deal to restore it from SVN if it becomes useful again. If it's ok, I'll check the source code and post a patch in one of the next weeks? -- Patrick On 29.08.2014, at 13:42, Osztrogonác Csaba o...@inf.u-szeged.hu wrote: Hi, Patrick Gansterer írta: On 31.01.2014, at 22:10, Anders Carlsson ander...@apple.com wrote looks like the last legitimate commit to the Windows CE port was on November 3rd November 2013, almost 3 months ago. What's the minimum upstream interval for downstream fixes to show ongoing activity? I also seem to remember that there's no version of MSVC for Windows CE that can handle the C++11 features that we now use in WebKit. (Correct me if I'm wrong on this!) Windows Embedded Compact 2013 updated the compiler for CE. With this in mind, does it make sense to keep the Windows CE port in the tree or should we remove it? Does it hurt somebody in the daily workflow? If yes, where exactly? I'm still working on getting rid of WebKit/wince by merging it into WebKit/win (with only a few #if WINCE) to reduce the impact of the WinCE port, but it's hard if there is nobody who finds time for reviewing patches. :-/ (e.g. webkit.org/b/119518 or webkit.org/b/123803 waiting for months - but I don't want to blame somebody by this!) The last commit from WinCE maintainer was on 20th November 2013, 9 months ago - https://trac.webkit.org/changeset/159534 Since then other contributors landed 41 changes touched WinCE files: https://trac.webkit.org/search?q=wincenoquickjump=1changeset=on Do we have any benefit if we keep these crufts in the trunk? br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DerivedSources.make: Another try?
On 19.03.2014, at 17:35, Brent Fulgham bfulg...@apple.com wrote: Hi All, I’m arriving to this conversation a bit late, but had a few comments: On Mar 16, 2014, at 11:06 AM, Patrick Gansterer par...@paroga.com wrote: DerivedSources.make depends heavily on UNIX command line tools (cat, sed, sort, ...) which are not part of a clean Windows installation and don't provide Windows like installers. The point is if we want to make cygwin (with all of its pro and cons) a requirement. At the moment the minimal requirements for building on Windows are GNU Win32 GPerf, Win flex-bision, Perl, Python and Ruby (which provide nice native Windows installers). Bugs like 48166 suggest that also not all Apple folks are happy with cygwin. To paraphrase Churchill, Cygwin is the worst form of UNIX abstraction, except for all the others. We find that it is a whole lot easier to get a Windows build system up and running using Cygwin than trying to piece together a set of disparate GNU tools built and hosted by different parties. I don't agree that cygwin is as worse as native UNIX. If you do not follow a specific workflow all the time, there are many problems if you switch between cygwin and non-cygwin on Windows (e.g. line endings). If your machine is for WebKit development only, then it might not be a big point for you, but if you have to switch between different projects all the time (which have different dependencies on tools) you will feel the difference of having only one native systems. I would not want to move from a system where I can direct people to download and run our Cygwin installer, to one where I have to point out a dozen different GNU Win32 packages to manually install and setup. You need exactly two installations for the used GNU tools: GPerf [1] and Win flex-bison [2]. Stuff like Perl, Python, Ruby is likely to be installed on a developer machine anyway. I would be much more interested in a system where we did not need these external tools. For example, driving the entire build system through just CMake with Perl or Python (or Ruby) would be interesting. A first step is to start deducing the amount of the tools we use. E.g. Darin removed some usage of cat [3] already. Unfortunately, we still have strong need for a number of UNIX-y tools, such as Flex, Bison, and GPerf. This is a common problem for all projects I am aware of that involve language implementations. [1] http://gnuwin32.sourceforge.net/downlinks/gperf.php [2] http://sourceforge.net/projects/winflexbison/files/latest/download [3] https://trac.webkit.org/changeset/165705 -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DerivedSources.make: Another try?
It might be possible to achieve, but it will remove a lot of the benefits from CMake. You have two options: a) Invoke make on DerivedSources.make and add a lot of custom target for that to CMake b) Parse the DerivedSources.make and create CMake rules out of it Since (b) would require a kind of Makefile parser it does not seam like a good idea. (a) should be easy to implement compared to (a), but you lose the whole dependency tracking on file level of CMake and detecting the involved tools (e.g. gperf) can not be done with CMake as easy as before. This becomes a problem on platforms where the tools are not in the executable path (Windows). Other problems by removing the build system abstraction provided by CMake would cause problems during parallel builds using the correct amount of cores (MS nmake for example has no -j at all). So I'd like to ask the question once again: Why not switch Xcode and Windows to CMake? There are (very outdated) patches at [1] and [2] for Windows. I'd be willing to bring them up to date, if there is someone to review them. [1] https://bugs.webkit.org/show_bug.cgi?id=72816 [2] https://bugs.webkit.org/show_bug.cgi?id=115944 -- Patrick On 16.03.2014, at 07:46, Darin Adler da...@apple.com wrote: Hi folks. Long ago I tried to make the “derived sources” part of building WebKit use a makefile, something for gnu make that we could use on multiple platforms. In WebCore, at least, we are using this DerivedSources.make from the Xcode project and the Windows project, but not for other build systems. I was hoping we could change that so that everyone uses DerivedSources.make. The build systems would do the main job of compiling code and header dependency and all that, but for the trickier, more project-specific job of running our scripts to make various types of derived sources we could just share one makefile. With GTK moving from automake to CMake, it’s possible we have the opportunity to achieve this just by making the CMake build system use DerivedSources.make instead of rules inside CMake itself. Is there an expert on our use of CMake who is interested in trying this project? Side question: With the recent GTK port developments, is it time to remove our automake files entirely? — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DerivedSources.make: Another try?
On 16.03.2014, at 16:10, Darin Adler da...@apple.com wrote: On Mar 16, 2014, at 3:01 AM, Patrick Gansterer par...@paroga.com wrote: a) Invoke make on DerivedSources.make and add a lot of custom target for that to CMake I’d like to see what this would look like before deciding it’s a bad idea. In the easiest case it's a simple add_custom_command() in CMake for every make target call. I don’t know what “a lot of custom targets” means and I’d like to see what that would be like; we should simply invoke make unconditionally on DerivedSources.make before doing the rest of CMake. This will remove all benefits CMake provides over simple make (platform abstraction, better dependency tracking, ...). For sure it's doable, but I'm not a big fan of kicking out CMake in favor of simple make. So once again the question: What are the blockers (beside that someone has to do the work) for migrating the remaining build systems to CMake? -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DerivedSources.make: Another try?
On 16.03.2014, at 16:28, Darin Adler da...@apple.com wrote: On Mar 16, 2014, at 8:18 AM, Patrick Gansterer par...@paroga.com wrote: On 16.03.2014, at 16:10, Darin Adler da...@apple.com wrote: On Mar 16, 2014, at 3:01 AM, Patrick Gansterer par...@paroga.com wrote: a) Invoke make on DerivedSources.make and add a lot of custom target for that to CMake I’d like to see what this would look like before deciding it’s a bad idea. In the easiest case it's a simple add_custom_command() in CMake for every make target call. Maybe we can do this even more simply. Invoke gnu make as a separate step before CMake kicks in, or make this just one add_custom_command. We should not think of DerivedSources.make as a set of custom per-file build commands, otherwise the connection between the two will be really complicated. Maybe I should have be more precise: You need a add_custom_command() for every make all on the different DerivedSources.make. (like it's implemented in the Windows build system) I don’t know what “a lot of custom targets” means and I’d like to see what that would be like; we should simply invoke make unconditionally on DerivedSources.make before doing the rest of CMake. This will remove all benefits CMake provides over simple make (platform abstraction, better dependency tracking, …). Could you be more concrete about specific benefits for the things in DerivedSources.make? Like an example of some build rule that benefits from better platform abstraction or dependency tracking? Are there examples where the CMake clone of DerivedSources.make is much simpler for some build rules? I’m not sure that platform abstraction has much value for the platform-independent derived sources build rules. I’m also not sure we get significantly better dependency tracking for the rules in that file. I’m sure both of those are great for other parts of the build process. The big point is Windows. ATM we require a complete cygwin installation (with all the connected problems) for building on Windows. The CMake only Windows ports don't need that. They work with the native Win32 versions of all tools (bison, gperf, perl, python, ...). If we move to make only, we introduce this dependency for the CMake ports building on Windows (WinCE + GTK). In general I don't think that the CMake rules will be simpler, more or less the same as for make. The dependency tracking is interesting for use in an IDE, where CMake provides then the possibility to e.g. to a regeneration of only one idl file. For sure not the most important use case to support, but very handy features if you need it sometime. For sure it's doable, but I'm not a big fan of kicking out CMake in favor of simple make. Yes, I can tell you are really attached to it! Yes, since it solved many platform-specific problems for me. This worked only by using it as the basis for the whole build system and not only for some parts. But maybe I'm already too attached to it. :-) So once again the question: What are the blockers (beside that someone has to do the work) for migrating the remaining build systems to CMake? I understand your question, and I believe there is an answer. We tried CMake here at Apple for the Xcode project a while back and had many, many problems turning it into something we could use. Please don't get me wrong (I don't want to complain!), but it's some kind of sad that this happens without a public discussion. E.g. I never got any feedback on my patches I created to address the points Apple people brought up as their CMake requirements (e.g. WTF, JSC, WebCore and WebKit must be built separate). But this project, removing all the duplicate make steps, is far, far smaller and has immediate benefits. We have not been having problems with DerivedSources.make over the last few years. If you work on UNIX only I can agree. Setting up the build environment for WebKit on Windows is not the most straight forward thing. But the kind of Windows support this more a political decision. ;-) IMHO it's sad to see a step away from CMake platform abstraction, but if it's vitale for the project I can life with it too. Since the code is still in the SVN history, there should be no big problem in getting back to it once again. But from the technical point of getting it working, it's not such a big deal if you go with a solution like in the Windows port (own project for generating derived sources with Makefiles + project level dependencies). -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DerivedSources.make: Another try?
On 16.03.2014, at 17:37, Darin Adler da...@apple.com wrote: On Mar 16, 2014, at 9:12 AM, Patrick Gansterer par...@paroga.com wrote: The big point is Windows. So the core issue isn’t really about CMake at all! It’s that the base Windows tool set doesn’t include GNU make or an equivalent. How different is this from other dependencies we have on Windows such as perl and python? Is it a lot easier to get CMake than to get GNU make? It's not directly about the GNU make, since it can be replace more or less easy with nmake (wich does not use more than one core). It's more about all of other UNIX commands (e.g. cat), which make the Makefile depend on cygwin. Perl/Python have native Win32 installations, which will be found by CMake during the configure step when installed at the usual path. Maybe CMake is not much easier to get and install, but it behaves more like a usual Windows executable IMHO. See e.g. [1] for some old bug about Stop using Cygwin. I wonder if there are any options for improving the Windows situation that don’t involve moving both Apple ports over to CMake. Maybe we can move only the Windows port to CMake? Since it has not such strong requirements on the build process as the Mac port (AFAIK from previous discussions). Could also wait to hear from experts like Mark Rowe about what the latest Apple experiences with CMake were. [1] https://bugs.webkit.org/show_bug.cgi?id=48166 -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DerivedSources.make: Another try?
On 16.03.2014, at 18:50, Filip Pizlo fpi...@apple.com wrote: This discussion about DerivedSources is too abstract for me. If the only thing that DerivedSources.make looks for is python, perl, and ruby, then there has got to be a way for cmake to pass arguments to DerivedSources to tell it where to find those binaries. DerivedSources.make depends heavily on UNIX command line tools (cat, sed, sort, ...) which are not part of a clean Windows installation and don't provide Windows like installers. The point is if we want to make cygwin (with all of its pro and cons) a requirement. At the moment the minimal requirements for building on Windows are GNU Win32 GPerf, Win flex-bision, Perl, Python and Ruby (which provide nice native Windows installers). Bugs like 48166 suggest that also not all Apple folks are happy with cygwin. On Mar 16, 2014, at 9:59 AM, Patrick Gansterer par...@paroga.com wrote: On 16.03.2014, at 17:37, Darin Adler da...@apple.com wrote: On Mar 16, 2014, at 9:12 AM, Patrick Gansterer par...@paroga.com wrote: The big point is Windows. So the core issue isn’t really about CMake at all! It’s that the base Windows tool set doesn’t include GNU make or an equivalent. How different is this from other dependencies we have on Windows such as perl and python? Is it a lot easier to get CMake than to get GNU make? It's not directly about the GNU make, since it can be replace more or less easy with nmake (wich does not use more than one core). It's more about all of other UNIX commands (e.g. cat), which make the Makefile depend on cygwin. Perl/Python have native Win32 installations, which will be found by CMake during the configure step when installed at the usual path. Maybe CMake is not much easier to get and install, but it behaves more like a usual Windows executable IMHO. See e.g. [1] for some old bug about Stop using Cygwin. I wonder if there are any options for improving the Windows situation that don’t involve moving both Apple ports over to CMake. Maybe we can move only the Windows port to CMake? Since it has not such strong requirements on the build process as the Mac port (AFAIK from previous discussions). Could also wait to hear from experts like Mark Rowe about what the latest Apple experiences with CMake were. [1] https://bugs.webkit.org/show_bug.cgi?id=48166 -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DerivedSources.make: Another try?
On 16.03.2014, at 19:32, Darin Adler da...@apple.com wrote: On Mar 16, 2014, at 11:06 AM, Patrick Gansterer par...@paroga.com wrote: DerivedSources.make depends heavily on UNIX command line tools (cat, sed, sort, …) I’m not sure what heavily means here. This seems really easy to fix. I agree that heavily might not be the optimal word. It’s a 15 minute project for me to replace the 4 uses of cat, and the 2 uses of sed with perl. I’ll do that right now. I don’t see any uses of the command line sort. I did i quick scan of the Makefile, but the sort I found is a make function, sorry! What are the other command line tools? rm does not exist on Windows and scripts can not uses shebang. One additional point is the preprocessor problem: Some scripts require a C preprocessor run to generate the correct output. CMake passes cl.exe to all scripts. See [1]. On 16.03.2014, at 19:53, Darin Adler da...@apple.com wrote: On Mar 16, 2014, at 11:53 AM, Darin Adler da...@apple.com wrote: On Mar 16, 2014, at 11:06 AM, Patrick Gansterer par...@paroga.com wrote: At the moment the minimal requirements for building on Windows are GNU Win32 GPerf, Win flex-bision, Perl, Python and Ruby (which provide nice native Windows installers). Any alternatives for getting good quality make installed like these other dependencies? Wait, you didn’t list CMake itself. Is that really the whole list? I listed only the additional dependencies beside CMake and Visual Studio. [2] is from the time where we did not require Ruby. [1] http://trac.webkit.org/browser/trunk/Source/cmake/OptionsCommon.cmake?rev=165173#L12 [2] http://trac.webkit.org/wiki/WinCE#Build -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DerivedSources.make: Another try?
On 16.03.2014, at 22:08, Darin Adler da...@apple.com wrote:
On Mar 16, 2014, at 12:01 PM, Patrick Gansterer par...@paroga.com wrote:
rm does not exist on Windows and scripts can not uses shebang.
OK, I think I’ll scrub the rm commands out. Perl can do rm easily.
What does shebang have to do with the makefile?
You can not run a script by ./script on Windows and you need to invoke it
with perl ./script
One additional point is the preprocessor problem: Some scripts require a C
preprocessor run to generate the correct output. CMake passes cl.exe to
all scripts. See [1].
Sorry, I read [1] and couldn’t figure out what this means.
Sorry for not being more precise (maybe not so clear when you're not familiar
with CMake in WebKit).
Could you give me a specific example of a script and explain what “passing
cl.exe” means?
E.g. at [1] the following line calls makeprop.pl with the --preprocessor
argument cl.exe /nologo /EP:
COMMAND ${PERL_EXECUTABLE} -I${WEBCORE_DIR}/bindings/scripts
${WEBCORE_DIR}/css/makeprop.pl --defines
${FEATURE_DEFINES_WITH_SPACE_SEPARATOR} --preprocessor
${CODE_GENERATOR_PREPROCESSOR}
grep for CODE_GENERATOR_PREPROCESSOR in the CMakeLists.txt and *.cmake files
should show up all other uses.
[1]
https://trac.webkit.org/browser/trunk/Source/WebCore/CMakeLists.txt?rev=165704#L3102
--
Patrick
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DerivedSources.make: Another try?
On 16.03.2014, at 22:23, Darin Adler da...@apple.com wrote:
On Mar 16, 2014, at 2:19 PM, Patrick Gansterer par...@paroga.com wrote:
On 16.03.2014, at 22:08, Darin Adler da...@apple.com wrote:
What does shebang have to do with the makefile?
You can not run a script by ./script on Windows and you need to invoke it
with perl ./script”
OK. Do we do that in DerivedSources.make? I couldn’t find any examples, but
there might be some.
https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/DerivedSources.make?rev=165676#L77
E.g. at [1] the following line calls makeprop.pl with the --preprocessor
argument cl.exe /nologo /EP:
COMMAND ${PERL_EXECUTABLE} -I${WEBCORE_DIR}/bindings/scripts
${WEBCORE_DIR}/css/makeprop.pl --defines
${FEATURE_DEFINES_WITH_SPACE_SEPARATOR} --preprocessor
${CODE_GENERATOR_PREPROCESSOR}
grep for CODE_GENERATOR_PREPROCESSOR in the CMakeLists.txt and *.cmake files
should show up all other uses.
I see.
As I understand it, this is something we do in our CMake files. Not a feature
of CMake, just something needed for the non-cygwin configuring on Windows
that we only did to the CMake copy of the rules from DerivedSources.make, not
to the original rules in DerivedSources.make.
Exactly. We need to extend DerivedSources.make files with this additional
argument for the preprocessor. (the --preprocessor stuff was in the scripts
before adding the CMake build system)
--
Patrick
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Subject: Windows CE port in WebKit: status, future work
On 31.01.2014, at 22:10, Anders Carlsson ander...@apple.com wrote looks like the last legitimate commit to the Windows CE port was on November 3rd November 2013, almost 3 months ago. What's the minimum upstream interval for downstream fixes to show ongoing activity? I also seem to remember that there’s no version of MSVC for Windows CE that can handle the C++11 features that we now use in WebKit. (Correct me if I’m wrong on this!) Windows Embedded Compact 2013 updated the compiler for CE. With this in mind, does it make sense to keep the Windows CE port in the tree or should we remove it? Does it hurt somebody in the daily workflow? If yes, where exactly? I'm still working on getting rid of WebKit/wince by merging it into WebKit/win (with only a few #if WINCE) to reduce the impact of the WinCE port, but it's hard if there is nobody who finds time for reviewing patches. :-/ (e.g. webkit.org/b/119518 or webkit.org/b/123803 waiting for months - but I don't want to blame somebody by this!) -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Use ICU in WebKit code
On 05.10.2013, at 19:13, Brent Fulgham wrote: The WinCairo port is as close to the AppleWin port as possible. It uses ICU and I have no intention of changing that. The WinCE port is maintained by Patrick Gangsterer. I believe that this port does not want to use ICU, preferring to use the limited subset of i18n features provided by the operating system. That's correct, but I think that changing the current API to ICU and implement some stub functions instead is a good idea. Can we put the source code of this dummy-ICU somewhere into the tree? See also the discussion about a reduced ICU at [1], but this would require a big copy of the ICU code in the tree, which I don't see as a good idea. I have heard from a number of people, mainly using WebKit in resource constrained environments, who prefer to omit ICU due to its relatively large footprint. But many of their concerns about library size might be satisfied by rebuilding ICU with settings that omit the large encoding database. This makes sense if their use cases do not need these features. If you use WebKit e.g. as a simple english-only GUI without text-input there is no need for ICU, expect to compile the remaining code. So a dummy-ICU would be everything you need for this use-case and reduces the required resources -Brent Sent from my iPad On Oct 4, 2013, at 11:48 PM, Dirk Schulze dschu...@adobe.com wrote: On Oct 5, 2013, at 7:37 AM, Darin Adler da...@apple.com wrote: Any thoughts on this? I am not sure what the status of the WinCE port is, but I’d like to hear from the maintainers of that port on the port status and their view on this strategy. Do you really mean WinCE or WinCairo? I thought that WinCE was discontinued a long time ago and already removed. Probably I was wrong. Greetings, Dirk -- Patrick [1] https://lists.webkit.org/pipermail/webkit-dev/2013-June/025018.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Use ICU in WebKit code
On 07.10.2013, at 18:28, Darin Adler wrote: On Oct 7, 2013, at 1:34 AM, Patrick Gansterer par...@paroga.com wrote: On 05.10.2013, at 19:13, Brent Fulgham wrote: The WinCairo port is as close to the AppleWin port as possible. It uses ICU and I have no intention of changing that. The WinCE port is maintained by Patrick Gangsterer. I believe that this port does not want to use ICU, preferring to use the limited subset of i18n features provided by the operating system. That's correct, but I think that changing the current API to ICU and implement some stub functions instead is a good idea. Can we put the source code of this dummy-ICU somewhere into the tree? Sure, seems fine to have it in the WebKit tree, presumably alongside or inside WTF. It’s really the same thing as what’s in wtf/unicode right now with some different function names. Mostly it would be moving that code inside functions with new names. What we need is a road map. I know how to change WebKit to use ICU directly, and how to test that both on my own Mac and the EWS and buildbot machines, but I don’t know how to test and figure out exactly how many of these stub functions are needed, even for a port with a buildbot but especially for one without. Patrick, to state the obvious, if it really is only the WinCE port that would this, then I think it’s a project we need your help on. I'd suggest that you do your thing by kicking out the WTF-Unicode and replace it by the ICU functions. Maybe you can think about where the dummy functions can live and I'll do the rest. I don't want to block anyone with this, but it would be great if someone feels responsible for reviewing my patches then. :-) -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Invalid file committed on the Webkit tree for windows
Since WinCairo has no working Buildbot there is no easy way to get such version. You must be able to fix small build problems on your own at the moment. Feel free to create bugs at https://bugs.webkit.org/ (with patch to fix it) if you see such problems. -- Patrick On 24.09.2013, at 15:47, Van Den Berghe, Vincent wrote: Indeed it has been corrected. It’s all my fault: I made the mistake of getting the webkit “trunk” to get the latest version. Sadly, the trunk rarely builds correctly under Windows, which is something I realized recently. For example, the latest version (156328 as I’m writing this) doesn’t build correctly, and has compile errors like this for WebCore: ..\platform\graphics\GraphicsContext3DPrivate.cpp(78): error C3861: 'client': identifier not found ..\platform\graphics\GraphicsContext3DPrivate.cpp(79): error C2227: left of '-platformLayerWillBeDestroyed' must point to class/struct/union/generic type What do you guys do if you want the latest and greatest successfully-built Wincairo-Webkit? Vincent From: Brent Fulgham [mailto:bfulg...@apple.com] Sent: Friday, September 20, 2013 6:08 PM To: Konstantin Tokarev Cc: Van Den Berghe, Vincent; webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Invalid file committed on the Webkit tree for windows This appears to have been corrected in r156161. Thanks, -Brent On Sep 20, 2013, at 2:20 AM, Konstantin Tokarev annu...@yandex.ru wrote: 20.09.2013, 13:16, Van Den Berghe, Vincent vincent.vandenber...@bvdinfo.com: Hello, When doing an SVN update to get the latest WebKit tree on Windows, I get the following error: Failed to run the WC DB work queue associated with 'C:\cygwin\home\vvdb\WebKit\LayoutTests\fast\hidpi\resources', work item 193377 (file-install LayoutTests/fast/hidpi/resources/image?test.png 1 0 1 1) Can't move 'C:\cygwin\home\vvdb\WebKit\.svn\tmp\svn-9BDA1924' to 'C:\cygwin\home\vvdb\WebKit\LayoutTests\fast\hidpi\resources\image?test.png': The filename, directory name, or volume label syntax is incorrect. The reason is that “image?test.png' is not a valid filename on Windows. What’s worse, after this error the “svn cleanup” doesn’t work anymore because SVN tries to undo something that can’t be done by definition. The only way to restore the local tree to a valid state is either (1) restore it from a backup, or (2) find the entry in .svn/wc.db (which is an sqlite database) and remove it manually. There should be a way for these kinds of problems to be prevented or corrected as soon as possible (being able to “svn update” is kind of a fundamental thing). I can’t even patch because my tree is invalid L. You can use git mirror instead of svn to be resistant to such issues when they happen. -- Regards, Konstantin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
Hi Roger, did you have some time to look at my example in the meantime? -- Patrick Am 11.04.2013 um 00:30 schrieb Roger Fong: Hi Patrick, A few questions I have about the CMake system, being someone who's never used it before. -I would like to keep all of the unified properties settings that the VS2010 property sheets hierarchy provided. Can we still maintain that through CMake easily? -How does CMake handle different build targets. Would I have to open up different project files per configuration? -If I'm understanding things correctly the main differences with using CMake would be: 1. If a project configuration is changed run CMake / I guess whenever you update the source as well (just to be safe). We would want to change any build scripts to use CMake: perhaps build-webkit is the really the only one we have to worry about in the OpenSource tree. 2. If you're working on Windows, open up the solution with Visual Studio and do work as usual, unless you want to add files in which case you go through the CMake scripts again before moving on. Would all the project filters and solution dependencies would still be in tact? Or is the solution file something that we would maintain that would hook into the generated projects?. -I'm assuming there's a CMake flag for specifying which version of visual studio to generate project files for? Our opensource bots run VS2005 and our internal run VS2010 currently, and seeing as we're not ready to use only VS2010 yet we would need to be able to specify which. If my above concerns can be resolved and the example you posted works fine for us (I'll try to take a look at it soon), it's probably okay to start checking in stuff to get ready for the move to CMake. I don't think we really have the resources to get things hooked up on our end in the immediate future, but perhaps in the coming months. Also if we do end up switching over I would highly push for all other ports besides Mac to adopt CMake and require any new ports to use it as well. Thanks, Roger On Apr 9, 2013, at 9:34 AM, Patrick Gansterer par...@paroga.com wrote: Hi, On Mon, 08 Apr 2013 18:10:29 -0700, Mark Rowe wrote: On 2013-04-08, at 17:45, Patrick Gansterer par...@paroga.com wrote: Hmm, I'll try to set up an example for WTF + JavaScriptCore. Maybe you can have a look at it then to check if I understand the concept correctly before I move on to WebCore + WebKit? Sounds good. I pushed a quick dirty example to [1], which shows a possible solution for WTF and JavaScriptCore. You can test it with the following steps. The helper directory contains then all built files. * Create a directory helper * Copy all files from Source/cmake to helper/cmake * Copy all files (including the support libraries) from WebKitLibraries to helper/WebKitLibraries * Create an independent directory and run the following commands in it: $ cmake path/to/WebKit/Source/WTF/wtf -DPORT=WinApple -DHELPER_DIR=path/to/helper $ cmake --build . --target package * You get a WTF.zip, which should be extracted in the directory helper * Create an additional independent directory and run the following commands in it: $ cmake path/to/WebKit/Source/JavaScriptCore -DPORT=WinApple -DHELPER_DIR=path/to/helper $ cmake --build . --target package * Yout get a JavaScriptCore.zip with the DLL I would be great if someone can verify that this solution will work for the internal builds at Apple. If I get positive feedback I'll can implement this for WebCore and WebKit too. Is there someone who will review my patches for this? Do you think it's possible to directly switch to CMake at Apple instead of upstreaming the VS2010 files? IHMO the whole work can be done in a few days, if someone at Apple is willing to work with me on it. [1] https://github.com/paroga/webkit -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] C++11 (was Re: on coding-style)
Am 13.04.2013 um 03:22 schrieb Benjamin Poulain: On Fri, Apr 12, 2013 at 6:15 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 12, 2013, at 4:09 PM, Karen Shaeffer shaef...@neuralscape.com wrote: As others have said, we are definitely eager to use C++11 across the board but are limited by compiler support requirements. One thing that it would be useful to know: what are the compilers and minimum required versions used for in-tree ports? Perhaps we could record this so we can regularly evaluate which features are safe to use and what the blockers are to wholesale adoption, if any. I think the worse thing we support right now is supporting MSVC 2005 (for compiler support) and Windows XP (for library support). From the CMake thread, I got that MSVC 2010 will soon be the oldest version supported. Is that correct? The oldest support compiler (with the most bugs) with an buildslave is the cl 14 for ARM. It comes from Visual Studio 2005 for Windwos CE. It would be great if we can try to keep it compiling with it until a newer version is available. The next version should support all C++11 features available in the desktop version [1] and will be available with Windows Embedded 2013 in Q2 [2]. I already try to keep the impact at an minimum for the trunk, but it's hard if you have a very bad compiler. E.g. the current trunk does not compile [3] due to a compiler bug (some problems with resolving friend classes correctly). [1] http://blogs.msdn.com/b/windows-embedded/archive/2012/11/14/windows-embedded-compact-v-next-uncovered.aspx [2] http://www.blogcdn.com/www.engadget.com/media/2012/11/windowsembeddedrolloutroadmapweb.jpg [3] http://build.webkit.org/builders/WinCE%20Release%20%28Build%29/builds/33715/steps/compile-webkit/logs/stdio -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
Am 11.04.2013 um 00:30 schrieb Roger Fong: Hi Patrick, A few questions I have about the CMake system, being someone who's never used it before. -I would like to keep all of the unified properties settings that the VS2010 property sheets hierarchy provided. Can we still maintain that through CMake easily? The main idea in CMake is, that it does not know anything about Visual Studio sheets. This is required to use other generators as well (e.g. a -G Ninja). What you usually do with VS property sheets is done with CMake variables, where you store your compiler, linker or whatever flags. -How does CMake handle different build targets. Would I have to open up different project files per configuration? In the default configuration CMake has 4 configurations: Debug, Release, MinSizeRelease and RelWithDebInfo. This allows in 99% direct production builds out of Visual Studio. Makefile generators (including Ninja) do not have this configuration and instead expect a -DCMAKE_BUILD_TYPE=config when running CMake. If you need additional configurations (e.g. the current Production configs) the CMake-way is to do this with an additional CMake variable defined via command line. So if you want a production build you just add a -DBUILD_FOR_PRODUCTION=ON to the initial call to cmake. Then you can do stuff like if (BUILDFOR_PRODUCTION) list(APPEND LINNKER_FLAGS ...) endif () to get the job done. -If I'm understanding things correctly the main differences with using CMake would be: 1. If a project configuration is changed run CMake / I guess whenever you update the source as well (just to be safe). We would want to change any build scripts to use CMake: perhaps build-webkit is the really the only one we have to worry about in the OpenSource tree. Importent is that you do not change the VS files any more. Only the CMake files should be changed then. CMake adds an additional project into the Visual Studio solution (ZERO_CHECK), which detects modified CMake files and runs cmake if something has changed. Since adding/removing a source files results in a change of the CMake file everything is done automatically. build-wekit has already support for CMake, so you only need to remove the VS code. :-) 2. If you're working on Windows, open up the solution with Visual Studio and do work as usual, unless you want to add files in which case you go through the CMake scripts again before moving on. Would all the project filters and solution dependencies would still be in tact? Or is the solution file something that we would maintain that would hook into the generated projects?. You can do this in VS as well: You only need to open the CMakeLists.txt in Visual Studio and add i there. Pressing the build button then generates new VS project, as mentioned before. -I'm assuming there's a CMake flag for specifying which version of visual studio to generate project files for? Our opensource bots run VS2005 and our internal run VS2010 currently, and seeing as we're not ready to use only VS2010 yet we would need to be able to specify which. -G does the job. You can also use Makefile based generators with no extra work. IMHO it would be great to use -G Ninja an the buildbots, since it has a much better output when you only see the command line (and it's faster). If my above concerns can be resolved and the example you posted works fine for us (I'll try to take a look at it soon), it's probably okay to start checking in stuff to get ready for the move to CMake. Many thanks. Please let me know if you see additional problems so we can address them as soon as possible. I don't think we really have the resources to get things hooked up on our end in the immediate future, but perhaps in the coming months. Please let me know when I can help somewhere. Also if we do end up switching over I would highly push for all other ports besides Mac to adopt CMake and require any new ports to use it as well. IMHO we can enforce new ports to use CMake already. Does anybody know if it's possible for the Qt port to switch to CMake? I know that QtWebKit is part of the Qt source distribution, which does not require CMake. Maybe somebody can tell me if the following would work for Qt: Use the CMake builds as e.g. EFL does at the moment and add an additional target for auto-generation of the qmake files. This qmake files then only have a list of header and source files, since code-generators (e.g. for IDL) are run by CMake. Am 11.04.2013 um 00:39 schrieb Brent Fulgham: On Apr 10, 2013, at 3:30 PM, Roger Fong roger_f...@apple.com wrote: 2. If you're working on Windows, open up the solution with Visual Studio and do work as usual, unless you want to add files in which case you go through the CMake scripts again before moving on. Would all the project filters and solution dependencies would still be in tact? Or is the solution file something that we
Re: [webkit-dev] Buildsystem cleanup
Hi, On Mon, 08 Apr 2013 18:10:29 -0700, Mark Rowe wrote: On 2013-04-08, at 17:45, Patrick Gansterer par...@paroga.com wrote: Hmm, I'll try to set up an example for WTF + JavaScriptCore. Maybe you can have a look at it then to check if I understand the concept correctly before I move on to WebCore + WebKit? Sounds good. I pushed a quick dirty example to [1], which shows a possible solution for WTF and JavaScriptCore. You can test it with the following steps. The helper directory contains then all built files. * Create a directory helper * Copy all files from Source/cmake to helper/cmake * Copy all files (including the support libraries) from WebKitLibraries to helper/WebKitLibraries * Create an independent directory and run the following commands in it: $ cmake path/to/WebKit/Source/WTF/wtf -DPORT=WinApple -DHELPER_DIR=path/to/helper $ cmake --build . --target package * You get a WTF.zip, which should be extracted in the directory helper * Create an additional independent directory and run the following commands in it: $ cmake path/to/WebKit/Source/JavaScriptCore -DPORT=WinApple -DHELPER_DIR=path/to/helper $ cmake --build . --target package * Yout get a JavaScriptCore.zip with the DLL I would be great if someone can verify that this solution will work for the internal builds at Apple. If I get positive feedback I'll can implement this for WebCore and WebKit too. Is there someone who will review my patches for this? Do you think it's possible to directly switch to CMake at Apple instead of upstreaming the VS2010 files? IHMO the whole work can be done in a few days, if someone at Apple is willing to work with me on it. [1] https://github.com/paroga/webkit -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
Am 08.04.2013 um 21:26 schrieb Roger Fong: Unfortunately this would cause a lot of complication in our internal build setup that we currently don’t really have the resources to deal with right now. Please don't get me wrong, but I only get a some internal problems answer always. Can someone please give some more detailed answer on the internal requirements. I'm willing to do the work for the Windows ports, but I need more information. How is the Windows port built at Apple? Is it possible to switch it to a CMake generated project? My last deeper discussion with aroben (!) is already a long time ago, but his answer was that beside installing CMake on the machines building the code, there is no real blocker. Is this still valid or was this never right. It would be nice to unite all the build systems at some point in the future but we’re going to push this one off for now. Yes, but we need to start at some point. Only dreaming about it is not enough. I'm willing to do the work, but I need at least some information. I don't want to do the work if it is not accepted as in https://bugs.webkit.org/show_bug.cgi?id=73100. Also we’re planning on getting rid of the VS2005 eventually. Eventually? How long do we want to maintain two VS versions in the tree? Am 08.04.2013 um 22:34 schrieb Roger Fong: I wasn’t aware that the build worked without a VS2010 pThreads build. I was running into issues because of the pThreads dll having embedded manifest problems earlier. Did you do anything special to circumvent that issue? I committed many patches to get rid of pthread as a whole on Windows in the past. Maybe I use a special flag which disables the remaining pthread calls on Windows. It won’t take much to switch it over but the problem was originally that I couldn’t get it to build without a newer compile of the pthreads library. Thus we were waiting for the pthreads folks to release a newer pthreads dll before doing the switch over. Why not just remove the remaining pthread calls on Windows (if there are) and disable USE(PTHREADS)? I'm willing to do the work here too, to get rid of pthreads on Windows. -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
Am 09.04.2013 um 00:58 schrieb Mark Rowe: On 2013-04-08, at 15:44, Patrick Gansterer par...@paroga.com wrote: Am 08.04.2013 um 21:26 schrieb Roger Fong: Unfortunately this would cause a lot of complication in our internal build setup that we currently don’t really have the resources to deal with right now. Please don't get me wrong, but I only get a some internal problems answer always. Can someone please give some more detailed answer on the internal requirements. I'm willing to do the work for the Windows ports, but I need more information. How is the Windows port built at Apple? Is it possible to switch it to a CMake generated project? The biggest complicating factor is that when each project builds it only has access to its own source, and the built products from earlier projects. This was mentioned the last time you suggested switching to CMake for the Windows build: https://lists.webkit.org/pipermail/webkit-dev/2012-April/020291.html. I know the last thread, so please don't hurt me if I ask dumb questions, but how does it work at the moment? ;-) What is the root directory of a checkout? E.g. if I checkout only Source/JavaScriptCore how can I access the vsprops files from WebKitLibraries/win? Is there a checkout of this global files for the individual targets too? If there is a checkout of the whole tree for every target, how do you make sure that the files from the previous build are use (and not from the checkout)? Maybe someone can explain the details a little bit more, so I can understand the requirements? Beside this, is there a general problem with CMake for the Windows port? For the Mac port there is the problem, that CMake is not an executable provided by the system (maybe i can some time...). Since many other tools are require separate installation on Windows anyway there should be no problem in installing CMake too? -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Buildsystem cleanup
Am 09.04.2013 um 02:29 schrieb Mark Rowe: On 2013-04-08, at 17:16, Patrick Gansterer par...@paroga.com wrote: Am 09.04.2013 um 00:58 schrieb Mark Rowe: On 2013-04-08, at 15:44, Patrick Gansterer par...@paroga.com wrote: Am 08.04.2013 um 21:26 schrieb Roger Fong: Unfortunately this would cause a lot of complication in our internal build setup that we currently don’t really have the resources to deal with right now. Please don't get me wrong, but I only get a some internal problems answer always. Can someone please give some more detailed answer on the internal requirements. I'm willing to do the work for the Windows ports, but I need more information. How is the Windows port built at Apple? Is it possible to switch it to a CMake generated project? The biggest complicating factor is that when each project builds it only has access to its own source, and the built products from earlier projects. This was mentioned the last time you suggested switching to CMake for the Windows build: https://lists.webkit.org/pipermail/webkit-dev/2012-April/020291.html. I know the last thread, so please don't hurt me if I ask dumb questions, but how does it work at the moment? ;-) What is the root directory of a checkout? E.g. if I checkout only Source/JavaScriptCore how can I access the vsprops files from WebKitLibraries/win? WebKitLibraries/win/tools is treated as its own project. It is built first so that the other WebKit projects can use the files that it installs. You can see a Makefile at WebKitLibraries/win/tools/WinTools.make that does the installation. So having an additional top level directory with all shares CMake files is possible? How are the ENABLE_* feature defines handled? Are they part of this files too? Is there a checkout of this global files for the individual targets too? No. But they are installed via a previous build, so mainly the same. ;-) If there is a checkout of the whole tree for every target, how do you make sure that the files from the previous build are use (and not from the checkout)? Only a subset of the tree is available. For instance, when preparing to build JavaScriptCore the relevant source is fetched using “svn export https://svn.webkit.org/repository/webkit/trunk/Source/JavaScriptCore”. The resulting directory is then provided to the build machine. Hmm, I'll try to set up an example for WTF + JavaScriptCore. Maybe you can have a look at it then to check if I understand the concept correctly before I move on to WebCore + WebKit? Beside this, is there a general problem with CMake for the Windows port? For the Mac port there is the problem, that CMake is not an executable provided by the system (maybe i can some time...). Since many other tools are require separate installation on Windows anyway there should be no problem in installing CMake too? Making the CMake executable available shouldn’t be a problem. Do the projects generated by CMake suffer from the same problem with absolute paths as CMake’s Xcode projects? I’m not sure whether that would be a problem for us on Windows, but it’s good to understand any limitations ahead of time. What is the concrete problem with the absolute paths? It's true that you can't copy a generated vcproj to an other location, but that shouldn't be required when you have installed CMake on that machine. And since the CMake executable is required by the generated build files (in the background for platform abstraction) it makes not much sense in a CMake workflow anyway. You usually just run cd build_dir cmake path/to/source cmake --build . and get all your files built. -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Buildsystem cleanup
Hi, since the Chromium code is getting removed step by step I think that the GYP build system won't have a shiny future in the WebKit repository. In the GYP vs. CMake match CMake gets an additional point: There is no WebKit port working with GYP, but at least 3 with CMake. Accordantly to [1] GTK will give CMake a try too. Adopting the Mac port does not seam to be an easy task in the near future, because of the very specific build requirements. But what about the Windows ports? I updated the patch at [2] to work with a more recent revision. Are there any chances to use CMake instead of the VS solution files? At the moment it becomes even worst, since there are VS2005 and VS2010 files in the tree, which duplicated many files. The patch at [2] is only an initial example, since a complete implementation would require more changes in the code. If CMake becomes an option, I'm willing to provide an complete patch with all CMake files. -- Patrick [1] https://lists.webkit.org/pipermail/webkit-dev/2013-April/024399.html [2] https://bugs.webkit.org/show_bug.cgi?id=72816 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
Hi, Am 31.01.2013 um 09:25 schrieb Mark Rowe: CMake was originally considered a non-starter for chromium since the XCode and VS projects it produced didn't look or feel like native projects. However, we've since switched to ninja for most things so I'm less sure how important this is now. I've never been a huge fan of the CMake syntax but I haven't used it enough to really have an informed opinion. Generating well-structured Xcode projects is still something that is important for any meta build system that we would consider adopting for the Mac. It would be substantially more challenging for us to support an alternative system for building our production builds. If there are substantial advantages to using ninja for engineering builds then we may wish to support both to get the best behavior in each environment. The non-natively structured Xcode projects is one thing that turned me off CMake when I looked at it in the past. I’m not sure if this has improved since then. If not, then I don’t think CMake is worth spending much time on. If you want to commit the generated projects CMake isn't an option anyway, since it uses absolute paths and also requires a cmake binary on the machine used for compiling (to support all CMake features across all generators). This tight integration is usually a big win, since the CMakeLists.txt files are part of the build system they can be changed directly in the IDE and update the project without invoking external tools. Only for my personal interest: What do you mean exactly with non-natively structured Xcode projects? CMake aims to support a native IDE feel as far as possible. Would be great if you explain that to me (off-list) to get CMake improved for XCode? Regarding (b) The generated project invokes only tools that are part of the default Mac OS X install: invoking tools that are checked into the WK repo is also possible, right, since we invoke scripts now? So, hypothetically, could we check in a copy of the ninja binary and build with that? Checking in binaries isn’t an option for us, and isn’t a particularly scalable approach anyway given the number of platforms that WebKit can build on. If we require an external tool as a dependency to build WebKit from source then we’d need to check in the source for the tool and build it prior to building WebKit proper. This obviously introduces more complexity so it would be preferable to keep the dependencies to a minimum. Maybe you can check in the ninja source and compile it during build. It only requires python (and hopefully installed build tools) to get built. -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa: On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger joc...@chromium.org wrote: Another option is to add a webkit-patch command for modifying the build files. That way, the syntax doesn't need to be overly human friendly. There was also some attempt to write a tool to add files automatically: https://bugs.webkit.org/show_bug.cgi?id=61772 I would expect that such a tool becomes easier if it would only modify one source of truth and generates all other artifacts such as Xcode projects from it. I don't want build file's syntax to be so human unfriendly that I need a tool for it. Often times, these syntax problems can be improved dramatically by simple changes. e.g. we had a similar discussion about TestExpectation syntax, and I'm much happier with the new syntax even though the new syntax is functionally equivalent to the old one, and two syntaxes are very similar. On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe mr...@apple.com wrote: I’ve experimented with this in the past and you’re right that it shouldn’t be particularly difficult to do. However, I suspect that the task would be similar in scope to defining an improved syntax for gyp. And if the syntax is the primary sticking point with gyp then it’d seem preferable to tackle initially. Yeah. In fact, we can just come up with whatever syntax we like and convert it to the existing gyp format if the syntax was the biggest issue. Do we want to define the whole build system (including information how to invoke the generators) with the new system, or is a simple list for the input files sufficient? IMHO adding a new generator build step happens very rarely. So maybe we can spit the input file list (mainly *.cpp and *.idl) into new files. Then GYP and CMake can read them and generate the build system out of them directly (like they to already today) instead of listing the files in the *.gpyi and *.cmake. This might work for other systems like qmake too. For XCode we can maybe have a template XCode project and generate the work XCode project with a script. This script then only need to fill in the files from the input file list into the template XCode project. Defining the feature flags can be done like Maciej suggested with Port.h files. -- Patrick___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak: On Jan 31, 2013, at 1:56 AM, Patrick Gansterer par...@paroga.com wrote: Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa: On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger joc...@chromium.org wrote: Another option is to add a webkit-patch command for modifying the build files. That way, the syntax doesn't need to be overly human friendly. There was also some attempt to write a tool to add files automatically: https://bugs.webkit.org/show_bug.cgi?id=61772 I would expect that such a tool becomes easier if it would only modify one source of truth and generates all other artifacts such as Xcode projects from it. I don't want build file's syntax to be so human unfriendly that I need a tool for it. Often times, these syntax problems can be improved dramatically by simple changes. e.g. we had a similar discussion about TestExpectation syntax, and I'm much happier with the new syntax even though the new syntax is functionally equivalent to the old one, and two syntaxes are very similar. On Thu, Jan 31, 2013 at 1:17 AM, Mark Rowe mr...@apple.com wrote: I’ve experimented with this in the past and you’re right that it shouldn’t be particularly difficult to do. However, I suspect that the task would be similar in scope to defining an improved syntax for gyp. And if the syntax is the primary sticking point with gyp then it’d seem preferable to tackle initially. Yeah. In fact, we can just come up with whatever syntax we like and convert it to the existing gyp format if the syntax was the biggest issue. Do we want to define the whole build system (including information how to invoke the generators) with the new system, or is a simple list for the input files sufficient? IMHO adding a new generator build step happens very rarely. So maybe we can spit the input file list (mainly *.cpp and *.idl) into new files. Then GYP and CMake can read them and generate the build system out of them directly (like they to already today) instead of listing the files in the *.gpyi and *.cmake. This might work for other systems like qmake too. For XCode we can maybe have a template XCode project and generate the work XCode project with a script. This script then only need to fill in the files from the input file list into the template XCode project. Defining the feature flags can be done like Maciej suggested with Port.h files. I think it would be better to adapt an existing meta build system to our needs than to make one from scratch, unless we find that completely impractical. In particular, gyp and cmake both know how to handle generated sources, and while it may not be super common to make a new type of generated source, it's bad for hackability of the project of doing so is super hard. We get a lot of hackability benefits from using various kinds of generated sources, many first introduced in the days when we had a lot fewer build systems. So in my mind, they are already ahead of a hypothetical simple system. Do you want to kick the requirements of the smaller ports from trunk or do you think that e.g. a qmake generate for GYP makes sense? AFAIK e.g. QtWebKit is shipped with Qt, which uses qmake as build system, where CMake/GYP is not an option. I completely agree that creating a new meta meta build system isn't a good idea, but sharing the common parts (which reduce the daily productivity) might be a step in the right direction. Using simple text files which contain the list of files (like the gpyi files already do today) isn't a new build system. It only offers the existing meta build systems (CMake, GYP, autotools, qmake) to use a common base. The remaining build systems can be ported to one of these systems or be adopted to use this file lists too. -- Patrick___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
Am 31.01.2013 um 21:07 schrieb Dirk Pranke: On Thu, Jan 31, 2013 at 11:48 AM, Hugo Parente Lima hugo.l...@openbossa.org wrote: On Wednesday, January 30, 2013 04:15:48 PM Maciej Stachowiak wrote: On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote: Thanks for sharing this. On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote: I wish we only had one build system (it were easy to add/remove/move files). I believe changes like http://trac.webkit.org/changeset/74849 are an unhealthy sign for the project. Adam is not the only person who has chosen to empty files instead of removing them. The pain of updating 8 build system is so great, we jump through hoops to avoid it. Which means it took us months to move JavaScriptCore/wtf to WTF, and will take us years to kill WebCore/platform. +1 This is a hard problem. It is a problem worth solving. Do you have more thoughts on this, particularly since you know quite well how both Xcode and gyp work? I suspect this is one of those things that it would be hard to achieve consensus on since there are so many stakeholders. But it may be fruitful to have a what if discussion about what this might look like. I think we can solve this problem if we agree that we want to. I think we haven't in the past mostly because we couldn't reach a consensus that it was worth solving enough to really try. I would love to see this fixed and would be glad to work on it. I think we should at least pursue this far enough to fully understand what our options are and what the costs and tradeoffs might be; does anyone disagree, and is anyone else willing to help pitch in? I think there are several possible ways we could solve this. One would be to switch to a common meta-build system. My understanding is that Apple's internal production build processes impose certain constraints here that I don't fully understand, but I know we've discussed the possibility of checking in generated project files as a workaround. Maybe there are other options as well to those constraints? I would love to discuss this further w/ someone from Apple ... It's far simplest for us if: (a) There is an Xcode project (or a Makefile) that builds the Mac port checked in to source control. (b) The generated project invokes only tools that are part of the default Mac OS X install. It may not be completely impossible to violate these requirements but it will require a lot of bureaucracy. (Also, just to get this out of the way, I don't think gyp needs to be the solution). Another alternative would be to write a script that did support at least the common use cases (add/move/delete files). There have been attempts in the past, but they have foundered on at least some perceived skepticism over how well this would work w/ XCode. That said, I don't think we've really pushed this to see. At some point this script might turn into a meta-meta-build system, which might be silly but also be the shortest path to the finish line. I suggest if there is interest in this we can start a new thread to discuss further ... My preference would be to use a common meta-build system with a comfortably human-readable and human-editable syntax, and checked in generated project files for those ports that need them. I think a key to making this work is to get Chromium and the Apple Mac port onto a common build system, which will probably require both Google and Apple ponying up at least one person to work on this project for a reasonable period of time. I think the plausible meta-build-systems to use would be CMake and Gyp, but in both cases it may be necessary to modify them to work well for everyone. I'd also like to add that I think a key related issue to common build system is common feature configuration. The many different ways ports control their feature flags is super confusing. I've long wanted to implement common configuration management, but have not had time. I have a patch trying to solve this issue for CMake based ports[1], the patch still on going, but even a change affecting just 2-3 ports using the same build system is a bit hard to get a consensus, so you can imagine how hard will be to get a consensus over all WebKit ports. [1] https://bugs.webkit.org/show_bug.cgi?id=103162 This is slightly off-topic, but I had thought that no one was actually using CMake; maybe I was mistaken and just none of the ports that build on webkit.org are? It looks like Blackberry and maybe a WinCE port uses CMake? Anyone else? EFL uses CMake too. 4 EFL bots @ http://build.webkit.org 1 WinCE bot @ http://build.webkit.org 1 EFL bot as EWS -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Wishes
Hi, Am 30.01.2013 um 22:28 schrieb Eric Seidel: I wish we only had one build system (it were easy to add/remove/move files). I've created CMake files for two different ports at [1] and [2] already, but did't get positive feedback from the port-maintainer. So I stopped working on it. If any port is still interested in switching to CMake I'd like to help creating the required files, but only with feedback of the port-maintainer. -- Patrick [1] https://bugs.webkit.org/show_bug.cgi?id=72816 [2] https://bugs.webkit.org/show_bug.cgi?id=73100 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] String::operator+= considered harmful
On Tue, 04 Sep 2012 22:26:52 -0700, Adam Barth wrote: On Tue, Sep 4, 2012 at 10:06 PM, Christophe Dumez christophe.du...@intel.com wrote: On Sep 5, 2012, at 2:22 AM, Adam Barth aba...@webkit.org wrote: Removing operator+= will likely require changes to a number of port-specific files. I'll do my best to remove these, but I might need some help from maintainers of individual ports. If you're interested in helping out, please let me know. I can help out for EFL port. I'll check for such += usage in our port-specific files today. Thanks! If the non-port-specifc calles have been fixed and compiling without the defined operator will fail ony in port-specific file, I'd like to help with fixing Windows (CE) problems. -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Procedure for adding new blogs to the WebKit Planet
Hi, On Thu, 02 Aug 2012 10:53:30 +0200, Martin Robinson wrote: Hi all, What's the procedure for adding a blog to the WebKit Planet? I often post material interesting to some of the WebKit community, but not suitable for Surfin' Safari since it is often specific to WebKitGTK+ or to just a subset of ports. Change http://trac.webkit.org/browser/trunk/Websites/planet.webkit.org/config.ini let it review. ;-) -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] [123877] trunk/Tools
But the author rewrite hook for commit-qu...@webkit.org does not work.
-- Patrick
On Fri, 27 Jul 2012 09:33:49 -0700, William Siegrist wrote:
Sorry about that, put the wrong address in the new hook. :( Should be
fixed now.
-Bill
On Jul 27, 2012, at 9:30 AM, Brady Eidson beid...@apple.com wrote:
Why did this get sent to webkit-dev instead of webkit-changes?
(Maybe a result of this morning's migration?)
~Brady
On Jul 27, 2012, at 9:22 AM, kbal...@webkit.org wrote:
Revision
123877
Author
kbal...@webkit.org
Date
2012-07-27 09:22:06 -0700 (Fri, 27 Jul 2012)
Log Message
[NRWT] should have a way to restrict pixel tests for individual
directories
https://bugs.webkit.org/show_bug.cgi?id=91754
Unreviewed attempt to fix the chaos I introduced.
* DumpRenderTree/qt/DumpRenderTreeQt.cpp:
(WebCore::DumpRenderTree::processLine):
Modified Paths
• trunk/Tools/ChangeLog
• trunk/Tools/DumpRenderTree/qt/DumpRenderTreeQt.cpp
Diff
Modified: trunk/Tools/ChangeLog (123876 = 123877)
--- trunk/Tools/ChangeLog 2012-07-27 14:15:24 UTC (rev 123876)
+++ trunk/Tools/ChangeLog 2012-07-27 16:22:06 UTC (rev 123877)
@@ -1,3 +1,13 @@
+2012-07-27 Balazs Kelemen kbal...@webkit.org
+
+[NRWT] should have a way to restrict pixel tests for
individual directories
+
https://bugs.webkit.org/show_bug.cgi?id=91754
+
+Unreviewed attempt to fix the chaos I introduced.
+
+* DumpRenderTree/qt/DumpRenderTreeQt.cpp:
+(WebCore::DumpRenderTree::processLine):
+
2012-07-27 YoungTaeck Song youngtaeck.s...@samsung.com
[WK2][EFL] Add an ACCELERATED_COMPOSITING implementation
for Efl WebKit2
Modified: trunk/Tools/DumpRenderTree/qt/DumpRenderTreeQt.cpp
(123876 = 123877)
--- trunk/Tools/DumpRenderTree/qt/DumpRenderTreeQt.cpp 2012-07-27
14:15:24 UTC (rev 123876)
+++ trunk/Tools/DumpRenderTree/qt/DumpRenderTreeQt.cpp 2012-07-27
16:22:06 UTC (rev 123877)
@@ -696,7 +696,7 @@
m_expectedHash = QString();
// single quote marks the pixel dump hash
int indexOfFirstSeparator = line.indexOf('\'');
-int indexOfSecondSeparator = line.indexOf('\'',
indexOfFirstSeparator);
+int indexOfSecondSeparator = line.indexOf('\'',
indexOfFirstSeparator + 1);
if (indexOfFirstSeparator -1) {
int indexOfPixelHash = indexOfFirstSeparator + 1;
___
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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Question about JITStackFrame
Hi, Am 24.07.2012 um 22:08 schrieb Patrick East: So I can see from JITStackFrame stackFrame = *reinterpret_castJITStackFrame*( args) that the args parameter is supposed to be the address of the JITStackFrame. If my understanding is correct, there needs to be some assembly code to setup the JITStackFrame before we call this. How and where is this supposed to be handled? Any help explaining this would be much appreciated! Since MSVC supports inline assembly only for x86, you need to create an additional assembly file. http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/create_jit_stubs might be a good staring point. http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/PlatformWinCE.cmake shows how the script is called. -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] [PATCH] Errors from build-webkit --debug --minimal
IMHO only setting up a bot won't help that much. Someone must keep it green. From my experience with the WinCE build slave (which has some common features turned of by default) I don't see many people caring about it. E.g. WinCE build slaves builds with JIT turned of, which leads to much redness of the bot. IMHO that's ok, since the bots exist to find failures with other configurations (even if EWS does much work in that area already), but most of the redness of the WinCE bot stays until I have the time to fix it [1]. BTW: It's not that much fun to fix all failures (and find the corresponding revision) if you pause for a few weeks. Do we have any defined responsibility, when someone breaks a port? Should the committer watch landing of the patch? (and ping the port maintainers if it has some port specific issues) Can we make the green/red status more meaningful, to make it easier to see if a patch cases real problems? (IMHO many bots are red by default this time and so don't provide quick information in the buildbot overview pages) -- Patrick [1] http://trac.webkit.org/search?q=paroga+ENABLE%28JIT%29 Am 25.06.2012 um 21:56 schrieb Eric Seidel: If someone wanted to set up a --minimal bot, I'm sure that would be welcome. We used to have a --qt --minimal bot at some point. http://trac.webkit.org/wiki/BuildBot On Mon, Jun 25, 2012 at 12:28 PM, Pablo Flouret pab...@motorola.com wrote: On Mon, 25 Jun 2012 12:03:12 -0700, Arthur O'Dwyer art...@push.am wrote: I'm trying to build WebKit by the simplest possible method. I checked out the SVN tree and did cd WebKit ; Tools/Scripts/build-webkit --debug --minimal. This produced compiler errors! I tried the same thing a while ago, and submitted patches to fix some of the issues, but what i was told is that there aren't really any bots building with --minimal, so it's not guaranteed to build. Last i remember, after you fix those issues you mention you're probably gonna come up against trickier ones in --web-audio, --geolocation, --netscape-plugin-api and --fullscreen-api (although i haven't checked recently). You can still run --minimal and enable the features that are giving you trouble (e.g. build-webkit --debug --minimal --javascript-debugger --geolocation ... etc.) Cheers, -- pablo flouret motorola | webkit / browser team ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [PATCH] Errors from build-webkit --debug --minimal
As already mentioned in my previous mail (maybe net clear enough): It's ok if someone breaks WinCE specific stuff, and it's nice that it's still accepted in trunk, but what I wanted to say is: WinCE bot has a different _feature_configuration_ (e.g. !ENABLE(JIT) isn't WinCE specific) and that's what breaks most of the time. BTW: My current main feature target is to merge the WinCE stuff directly into the windows, so it's more in the win directory. ;-) -- Patrick Am 25.06.2012 um 23:06 schrieb Adam Barth: Hopefully this email won't come off as rude, but it's not clear to me whether the WinCE port being actively developed. http://trac.webkit.org/wiki/WinCE says that the port is maintained by Torch Mobile, but http://www.torchmobile.com/ says Torch Mobile is focused on BlackBerry these days. Looking at the last year of commits to these directories: http://trac.webkit.org/log/trunk/Source/WebKit/wince http://trac.webkit.org/log/trunk/Source/WebCore/platform/wince The changes appear to be build fixes and patches that incidentally touch WinCE as part of project-wide maintenance. Patrick, it's clear that you're putting in the effort to keep the port building, but I suspect the reason folks from the community don't put much effort into keeping the WinCE bot green is because the port seems to be somewhat in a holding pattern. Adam On Mon, Jun 25, 2012 at 1:45 PM, Patrick Gansterer par...@paroga.com wrote: IMHO only setting up a bot won't help that much. Someone must keep it green. From my experience with the WinCE build slave (which has some common features turned of by default) I don't see many people caring about it. E.g. WinCE build slaves builds with JIT turned of, which leads to much redness of the bot. IMHO that's ok, since the bots exist to find failures with other configurations (even if EWS does much work in that area already), but most of the redness of the WinCE bot stays until I have the time to fix it [1]. BTW: It's not that much fun to fix all failures (and find the corresponding revision) if you pause for a few weeks. Do we have any defined responsibility, when someone breaks a port? Should the committer watch landing of the patch? (and ping the port maintainers if it has some port specific issues) Can we make the green/red status more meaningful, to make it easier to see if a patch cases real problems? (IMHO many bots are red by default this time and so don't provide quick information in the buildbot overview pages) -- Patrick [1] http://trac.webkit.org/search?q=paroga+ENABLE%28JIT%29 Am 25.06.2012 um 21:56 schrieb Eric Seidel: If someone wanted to set up a --minimal bot, I'm sure that would be welcome. We used to have a --qt --minimal bot at some point. http://trac.webkit.org/wiki/BuildBot On Mon, Jun 25, 2012 at 12:28 PM, Pablo Flouret pab...@motorola.com wrote: On Mon, 25 Jun 2012 12:03:12 -0700, Arthur O'Dwyer art...@push.am wrote: I'm trying to build WebKit by the simplest possible method. I checked out the SVN tree and did cd WebKit ; Tools/Scripts/build-webkit --debug --minimal. This produced compiler errors! I tried the same thing a while ago, and submitted patches to fix some of the issues, but what i was told is that there aren't really any bots building with --minimal, so it's not guaranteed to build. Last i remember, after you fix those issues you mention you're probably gonna come up against trickier ones in --web-audio, --geolocation, --netscape-plugin-api and --fullscreen-api (although i haven't checked recently). You can still run --minimal and enable the features that are giving you trouble (e.g. build-webkit --debug --minimal --javascript-debugger --geolocation ... etc.) Cheers, -- pablo flouret motorola | webkit / browser team ___ 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 ___ 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] CMake for Apple's Windows port
I'm very interested in that discussion, but I can't be physically there. :-( Is there any any possibility for me to attend it online or get a recording of it? -- Patrick Am 20.04.2012 um 06:08 schrieb Eric Seidel: We're discussing reducing the number of build-systems at the WebKit meeting tomorrow @ 10am. Interested parties should definitely be there. Especially ones who know something about CMake (since I know nothing). :) -eric On Thu, Apr 12, 2012 at 5:41 AM, Patrick Gansterer par...@paroga.com wrote: Hi, it's more than a year since the last discussion about the build system of Apple's Windows port. In the meantime I merged most of the general changes into the CMake files in the repository and have a working patch with a few CMake files at [1] as written in [2]. I don't think that it is ready to replace the existing vcproj files already, but I like to hear all points needed to do that. Adding CMake files for the WinCairo port (which uses the vcproj files too) will be very easy when the Apple version has been added. Here some benefits to the CMake version: 1) Shared build system: The shared files are already used by the Blackberry, EFL and WinCE port, so only the list of platform specific files needs to be maintained. 2) No dependency on cygwin [3]: The CMake build system searches for the Win32 version of the required executables (bison, gperf, flex, perl and python) like the WinCE port does already (see [4]). 3) Less Solution targets: Some of he current vcproj files only used for triggering Makefiles. The vcproj generates more native vcproj files, which e.g. allows clicking on one of the IDL files to generate the corresponding files. 4) Easy creation of Visual Studio 2010 project files [5]: Using CMake allows an easy transition to other (newer) Visual Studio versions, since every developer can choose his preferred version. 5) It's possibe to create Makefiles: The output of the windows buildbots shows much unwanted messages. Using Makefiles on the bots can produce cleaner logs and take advantage of all cores when used with JOM [7]. Would be great if people who use the current VS Solution can give the CMake version a try and provide some feedback about it. BTW: There is also a patch to switch Wx to CMake at [8], but it did not get a positive response. [1] https://bugs.webkit.org/show_bug.cgi?id=72816 [2] https://lists.webkit.org/pipermail/webkit-dev/2011-February/015831.html [3] https://bugs.webkit.org/show_bug.cgi?id=48166 [4] http://trac.webkit.org/wiki/WinCE#Build [5] https://bugs.webkit.org/show_bug.cgi?id=53445 [6] https://lists.webkit.org/pipermail/webkit-dev/2011-January/015815.html [7] http://qt-project.org/wiki/jom [8] https://bugs.webkit.org/show_bug.cgi?id=73100 -- Patrick ___ 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] CMake for Apple's Windows port
Am 12.04.2012 um 20:06 schrieb Dirk Pranke: Patrick, have you documented what all you need to install on a Win box in order to be able to run CMake and do the build? You need to install CMake and the same tools listed at http://trac.webkit.org/wiki/WinCE#Build and http://www.webkit.org/building/tools.html (but without cygwin). Am 12.04.2012 um 23:47 schrieb Mark Rowe: On 2012-04-12, at 14:28, Dirk Pranke dpra...@chromium.org wrote: Interesting. Can you comment further on why this is needed, instead of just checking out the whole repo? The short answer is that doing so would violate internal policies that we have about what sorts of files are acceptable in the source of production builds (for example, precompiled libraries are not acceptable). We also don't have any desire to shuffle multiple gigabytes of layout tests around machines that are only used for building. Is it possible to get a (detailed) list of requirements? It's hard for people don't knowing the internal Apple build process to work on it. Why isn't it possible to checkout only the Source directory? Since the current system has more than 1 VS solution too, I don't think it will be a problem to have more than one root CMakeLists.txt too. Is there a interest in getting rid of the Visual Studio files? Are there any points agains CMake we know already? I don't want to put (much) work into the CMake files for a simple No, thanks at the end. ;-) -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CMake for Apple's Windows port
Am 19.04.2012 um 03:46 schrieb Mark Rowe: Is it possible to get a (detailed) list of requirements? It's hard for people don't knowing the internal Apple build process to work on it. We don't have anything of this nature available for external consumption at this time. Does that mean that only Apple folk can work on it at the moment? Is it possible that someone at Apple have a deeper look into the current state to provide more information about the missing/bad/good parts? I'd like to put more work into it, but I need feedback from the people who use it. Why isn't it possible to checkout only the Source directory? Since the current system has more than 1 VS solution too, I don't think it will be a problem to have more than one root CMakeLists.txt too. That's the direction we're heading in for the Mac build system. If this can be made to work with CMake then that's wonderful. It's not the most elegant way, since root usually means root, but if it's a strong requirement it should be possible. -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] CMake for Apple's Windows port
Hi, it's more than a year since the last discussion about the build system of Apple's Windows port. In the meantime I merged most of the general changes into the CMake files in the repository and have a working patch with a few CMake files at [1] as written in [2]. I don't think that it is ready to replace the existing vcproj files already, but I like to hear all points needed to do that. Adding CMake files for the WinCairo port (which uses the vcproj files too) will be very easy when the Apple version has been added. Here some benefits to the CMake version: 1) Shared build system: The shared files are already used by the Blackberry, EFL and WinCE port, so only the list of platform specific files needs to be maintained. 2) No dependency on cygwin [3]: The CMake build system searches for the Win32 version of the required executables (bison, gperf, flex, perl and python) like the WinCE port does already (see [4]). 3) Less Solution targets: Some of he current vcproj files only used for triggering Makefiles. The vcproj generates more native vcproj files, which e.g. allows clicking on one of the IDL files to generate the corresponding files. 4) Easy creation of Visual Studio 2010 project files [5]: Using CMake allows an easy transition to other (newer) Visual Studio versions, since every developer can choose his preferred version. 5) It's possibe to create Makefiles: The output of the windows buildbots shows much unwanted messages. Using Makefiles on the bots can produce cleaner logs and take advantage of all cores when used with JOM [7]. Would be great if people who use the current VS Solution can give the CMake version a try and provide some feedback about it. BTW: There is also a patch to switch Wx to CMake at [8], but it did not get a positive response. [1] https://bugs.webkit.org/show_bug.cgi?id=72816 [2] https://lists.webkit.org/pipermail/webkit-dev/2011-February/015831.html [3] https://bugs.webkit.org/show_bug.cgi?id=48166 [4] http://trac.webkit.org/wiki/WinCE#Build [5] https://bugs.webkit.org/show_bug.cgi?id=53445 [6] https://lists.webkit.org/pipermail/webkit-dev/2011-January/015815.html [7] http://qt-project.org/wiki/jom [8] https://bugs.webkit.org/show_bug.cgi?id=73100 -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit-Windows build with VS2008
Hi, On Tue, 27 Mar 2012 17:14:55 +0530, M Rahaman wrote: When I build WebKit code for Windows using VS2008, there are several issues I am facing 1. We need to re-generate the webkit.sln file with VS2008 2. VS2008 has strict warning checking, because all the .vcproj has Treat warning as errors, the compilation fails. So the work around is to modify the .vcproj file to disable Treat warning as errors, 3. We also need to change Tools/Scripts/parallelcl to provide correct path for cl.exe (while building from Cygwin) So, I just want to know if other people working on Windows port also facing the same issue. It becomes even more problematic when I am updating my code I get svn conflict in my .vcproj files etc. because of #2 above. If everyone is facing the same issue, may be it is a better idea to commit this patch with the constraint that we will no more support VS2005. Want to know other's opinion on this.. Since every Visual Studio version uses it's own CRT (MSVCRT80.DLL for VS2005) and the code depends on additonal libraries (look into C:\Program Files\Common Files\Apple\Apple Application Support) which need the CRT too. Mixing different CRTs can cause strange errors, so it's not a good idea. IMHO it might be a better idea to get away from the vcproj files and move to a meta build system, so everybody can choose the VS version on it's own. I already did a big part of a CMake based system at [1] which also does not require the cygwin environment. It's possible to use the Win32 version of the different tools, like in the WinCE port [2]. [1] https://bugs.webkit.org/show_bug.cgi?id=72816 [2] http://trac.webkit.org/wiki/WinCE -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Git/SVN is slow
My git fetch transfer rates seam to depend on the time and day of the week. Last weekend I fetched with about 800 KiB/s, now I get about 250 KiB/s, but I reach only about 40 KiB/s during US working hours 1-2 weeks ago. The traceroute looks the same from Austria: 9 ae-11-11.car1.Vienna1.Level3.net (4.69.135.29) 1.870 ms 1.860 ms 0.867 ms 10 ae-6-6.ebr1.Frankfurt1.Level3.net (4.69.135.34) 12.836 ms 12.833 ms 12.923 ms 11 ae-61-61.csw1.Frankfurt1.Level3.net (4.69.140.2) 12.912 ms ae-91-91.csw4.Frankfurt1.Level3.net (4.69.140.14) 12.911 ms ae-71-71.csw2.Frankfurt1.Level3.net (4.69.140.6) 12.912 ms 12 ae-72-72.ebr2.Frankfurt1.Level3.net (4.69.140.21) 12.911 ms ae-62-62.ebr2.Frankfurt1.Level3.net (4.69.140.17) 12.901 ms ae-72-72.ebr2.Frankfurt1.Level3.net (4.69.140.21) 12.922 ms 13 ae-23-23.ebr2.London1.Level3.net (4.69.148.193) 21.908 ms ae-22-22.ebr2.London1.Level3.net (4.69.148.189) 21.898 ms ae-21-21.ebr2.London1.Level3.net (4.69.148.185) 21.897 ms 14 ae-44-44.ebr1.NewYork1.Level3.net (4.69.137.78) 90.846 ms ae-43-43.ebr1.NewYork1.Level3.net (4.69.137.74) 90.921 ms ae-42-42.ebr1.NewYork1.Level3.net (4.69.137.70) 90.917 ms 15 ae-81-81.csw3.NewYork1.Level3.net (4.69.134.74) 90.899 ms ae-91-91.csw4.NewYork1.Level3.net (4.69.134.78) 90.896 ms ae-81-81.csw3.NewYork1.Level3.net (4.69.134.74) 90.893 ms 16 ae-62-62.ebr2.NewYork1.Level3.net (4.69.148.33) 90.891 ms ae-72-72.ebr2.NewYork1.Level3.net (4.69.148.37) 90.882 ms ae-62-62.ebr2.NewYork1.Level3.net (4.69.148.33) 90.881 ms 17 ae-2-2.ebr4.SanJose1.Level3.net (4.69.135.185) 158.886 ms 158.877 ms 158.873 ms 18 ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2) 158.869 ms ae-71-71.csw2.SanJose1.Level3.net (4.69.153.6) 161.884 ms ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10) 159.883 ms 19 ae-11-70.car1.SanJose2.Level3.net (4.69.152.75) 159.880 ms ae-21-60.car1.SanJose2.Level3.net (4.69.152.11) 159.867 ms 159.857 ms 20 * * * 21 * * * 22 * * * - Patrick Am 15.03.2012 um 18:22 schrieb Levi Weintraub: Likewise, I lose everything past *.car1.sanjose2.level3.net. SVN updates are dog slow :( 6 pr01-xe-8-2-0.sjc07.net.google.com (72.14.218.230) 4.306 ms 4.966 ms * 7 xe-11-1-0.edge2.sanjose3.level3.net (4.79.40.153) 20.116 ms 3.031 ms 3.056 ms 8 ae-31-90.car1.sanjose2.level3.net (4.69.152.203) 4.316 ms ae-11-70.car1.sanjose2.level3.net (4.69.152.75) 4.239 ms ae-21-60.car1.sanjose2.level3.net (4.69.152.11) 4.545 ms 9 * * * 10 * * * 11 * * * On Thu, Mar 15, 2012 at 7:31 AM, Philip Rogers p...@google.com wrote: Bill, I'm currently pulling from svn.webkit.org at what feels like 5kbps, and poor http://build.webkit.org/console hits the page refresh before it's even able to render to the bottom :( Below is a traceroute to webkit.org: traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte packets 1 DD-WRT (192.168.2.1) 0.233 ms 0.297 ms 0.371 ms 2 10.1.10.1 (10.1.10.1) 2.446 ms 2.445 ms 2.518 ms 3 96.176.191.1 (96.176.191.1) 24.451 ms 25.398 ms 28.688 ms 4 xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.85.91.177) 14.588 ms 15.541 ms 15.733 ms 5 xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57) 16.563 ms 16.929 ms 16.946 ms 6 pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201) 17.967 ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.125) 14.599 ms 11.428 ms 7 4.28.24.77 (4.28.24.77) 15.973 ms 17.858 ms 17.307 ms 8 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 19.688 ms vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126) 14.891 ms vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 15.116 ms 9 ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.651 ms ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241) 13.767 ms ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.955 ms 10 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) 34.004 ms 36.807 ms 34.950 ms 11 ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77) 66.601 ms 65.766 ms 66.692 ms 12 ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202) 78.577 ms 78.007 ms 78.175 ms 13 ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109) 78.594 ms 78.520 ms ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142) 81.371 ms 14 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 71.989 ms ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138) 77.341 ms ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 77.662 ms 15 ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18) 80.375 ms ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2) 87.895 ms ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10) 77.137 ms 16 ae-31-90.car1.SanJose2.Level3.net (4.69.152.203) 77.660 ms ae-41-80.car1.SanJose2.Level3.net (4.69.152.139) 78.313 ms ae-21-60.car1.SanJose2.Level3.net (4.69.152.11) 77.746 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 *
Re: [webkit-dev] Moving to Git?
Am 08.03.2012 um 23:30 schrieb Alexis Menard: On Thu, Mar 8, 2012 at 7:10 PM, Maciej Stachowiak m...@apple.com wrote: It seems like there are a couple of different issues here that affect how we do version control. Currently we have an SVN primary repository, some contributors use SVN, and others use git via git-svn. It seems like there are two possible changes we can make, and it is not really clear to me which is being advocated: 1) Offer only a git repository; everyone uses git. 2) Use a git central repository; but some form of svn access is provided (is this even possible?) And then there is the status quo: 3) Continue doing what we're doing; central repository is svn, but anyone is free to use git and we try to make it convenient to do so. One interesting asymmetry here is that, while many git users proseltyze git and advocate total removal of svn support from our tools and infrastructure, no one seems to advocate completely removing git support. So I left that option off. There are also other distributed version control systems out there such as Mercurial or Bazaar, but no one seems much in favor of using them for WebKit, so those options are also left off. If we are to assess these options in a deeper way than just everyone saying what they personally like, we need to identify the pros and cons of options (1) and (2) relative to (3). That's assuming (2) is even possible. It seems like there are at least a few factors to consider: A) Future quality of life for current git users. B) Future quality of life for current svn users. C) Benefits of the master repository being either git or svn, regardless of what clients are supported. (For example, many folks seem to think human-understandable revision identifiers is a benefit of the master being SVN). D) Cost to the project of maintaining support for two different version control systems. Git advocates on this thread have mostly focused on convincing svn users how much they'd like using git instead. It seems at least some svn users do not believe their quality of life would improve by switching to git, including some who have actually tried git. No one has really identified what benefits there would be to git users if a change is made. Could someone describe those? To the global infrastructure : - Local history for git. svn log access to the server every time you call that command. Will improve the load of the server. - Performance of checkouts/pull as data are send compressed from the server. *) Easier way to setup local mirrors (for buildbots). See discussion at https://lists.webkit.org/pipermail/webkit-dev/2012-March/019699.html To git user : - Using git push rather than having to use git-svn (which you need to keep in sync). - Simplified workflow, we don't need to mess with git-svn. - Companies who fork (we all do) can simplify their workflow a bit regarding branches. To svn user : - Conflict resolving much easier and performant than svn (we have drivers for changelogs and the default one are much better than svn). - Local history/blaming/... - Proper diff coloration (though I'm sure you guys have some magic scripts using colordiff). - The staging area, upload what you want/need and keep some work local - Smaller checkouts The real downside is for the svn users to learn a bit git workflow. I'm forgetting stuff for sure. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The Purpose of Core Builders
Some of my thought on this, since I have the same problems with my WinCE bot: 1) Is there any real benefit in the CoreBuilders concept (since it's not used as intended as Eric already wrote)? 2) When we still want the CoreBuilder concept: Can we make the core/non-core transition without any SVN change? What about improving the buildbot-master, so that it dertiminates the core/non-core on the fly, by checking the last x builds? I don't like the idea of adding and removing the the bots to the core list all the time. 3) It's hard for non full time contributes to get informed about broken bots, if you don't watch the buildbot site the whole day. a) Maybe we can tell the buildbot to write a mail to the build slave maintainer, when the bot is broken. (It happened more than once that my bot was red for days, because I didn't get informed about it). b) I agree that keeping all bots green is not the task of the committer, but maybe someone should trigger the port maintainer to fix it. I have no idea about a general working rule, but as of my experience the committer simply don't see the problem. E.g. WinCE bot builds the interpreter version of JSC, which is a core feature and not port specific, but the commit author didn't see the break. - Patrick Am 09.11.2011 um 06:48 schrieb Adam Barth: I wrote up a wiki page that I hope answers your questions: http://trac.webkit.org/wiki/Core%20Builders Adam On Tue, Nov 8, 2011 at 5:09 PM, Brent Fulgham bfulg...@webkit.org wrote: A week or two ago, Adam Barth elected to remove my WinCairo build bot from the list of core builders. In the check-in comment, he noted that the WinCairo bot rarely built, and was never green. I do not agree with either of these statements -- the WinCairo build bot had been green for a number of weeks after I activated tests (instead of just building), and the bot generally builds properly (and has done so for the past couple of years). I admit to being lax in keeping the bot green over the past few weeks, which was an unusual case due to external factors. I generally attempt to maintain the bot every day, but was not able to keep close tabs on it for most of October. The build failures (which I fixed this afternoon) took all of five minutes to correct, and were due to additions to symbol export files that were not applied to the WinCairo version of these files. Surely these small errors could have been corrected by the committer -- which is surely the point of the build bots? While I understand that a Red bot is annoying, I feel that removing the bot simply masked the problem. At the very least, I would hope that in the future that the build bot owners should be notified if a third party makes the arbitrary decision to remove a bot from the core set. The information is clearly provided in the build bot configuration page. Thanks, -Brent ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] What is an active port? [WAS: Do you maintain OS(WINCE)?]
Hi, I completely agree with all of your points. I also don't think that it's your task to keep every part time port working with every change. IMO most of the is active questions come with a when do we remove the old code/port from trunk question. That's not very cool to hear after the hard upstreaming work. But that's only my personal view. More interesting questing is: How do part time maintainers get informed about fundamental changes? I'd prefer cc'ing on a bug which might break a build. So it's possible for the maintainer to try to build with the patch locally and implement the missing parts. At least for me it's easier to fix compiler errors than answering questions about a possible build break on webkit-dev. ;-) - Patrick Am 14.09.2011 um 21:08 schrieb Geoffrey Garen: Hi Patrick. On Tue, Sep 13, 2011 at 2:38 PM, Patrick Gansterer par...@paroga.com wrote: How do we measure an active port??? I maintain a buildbot for WinCe and usually fix problems with the port within hours. Unfortunately I don't get paid to work on WebKit the whole day and so I can't make such big steps forward like other ports do. In my effort to establish the threads exist baseline abstraction, I've gotten a few responses similar to this one: I maintain port X, but I'm the only one, and I have limited time…. Here are my current thoughts, based on that experience: * A long list of #ifdefs in core WebKit code makes reading and understanding the code difficult, especially if the #ifdefs select among a matrix of fundamentally different ways of doings things. * A long tail of ports makes fundamental improvements to the engine difficult and time consuming. Fundamental improvements are likely to break a port, and port maintainers may not be available in a timely fashion to adopt a fundamental improvement. (For example, it has been about a week since I started the threads exist project.) * We have a significant number of ports (maybe 5) that are either (a) maintained by only one person working part-time or (b) not maintained at all in WebKit trunk, but periodically upstreamed to WebKit trunk by downstream clients to make their future merges easier. * Single-part-time-maintainer ports seem to keep up at a reasonable pace with simple build fixes like adding new files to projects, but not with major architectural changes. * Single-part-time-maintainer ports get very little, if any, testing outside of automated regression tests, so it's hard to know if the code actually works, who uses it, or what its requirements are. When I ask if a port is active, I guess what I mean is, Can I go ahead and make this core WebKit improvement, and assume that port maintainers will keep up, or do I need to stop what I'm doing and wait for them, or worry that they will roll out some or all of my patch instead of doing the harder work of upgrading their port? I also mean, Is this port actively used, and is the opportunity cost of upgrading it justified? I think the right solution here is for port maintainers, in cases of nontrivial work, to take on the job of upgrading their ports to match core engine changes, instead of core engineers taking on that job. And, in cases where a port upgrade isn't available in a timely fashion for some reason, WebKit should move forward and break the port (core builder or not). This proposal might seem unkind, but I think it's the best thing for moving WebKit forward in the long run. On Tue, Sep 13, 2011 at 2:38 PM, Patrick Gansterer par...@paroga.com wrote: So PLEASE: When do we call a port active? It's not cool to get the question about removal every few months! I hope that the plan I've outlined above will make active ports much more well-known to core WebKit contributors, since port maintainers will be working with core contributors to upgrade their ports. Regards, Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do you maintain OS(WINCE)?
Hi, Am 13.09.2011 um 21:37 schrieb Adam Roben: On Sep 13, 2011, at 12:07 PM, Leandro Pereira wrote: Antonio, On 09/13/2011 04:00 PM, Antonio Gomes wrote: I believe it was maintained by Torch Mobile, and, according to George Staikos, it is not part of the plans any more (Torch was acquired by RIM). AFAIR, Patrick Gansterer (paroga) is still working on the WinCE port. He usually informally reviews CMake-related changes. I believe this is correct. He also maintains a buildbot: http://build.webkit.org/builders/WinCE%20Release%20%28Build%29 Yes, that's correct. How do we measure an active port??? I maintain a buildbot for WinCe and usually fix problems with the port within hours. Unfortunately I don't get paid to work on WebKit the whole day and so I can't make such big steps forward like other ports do. Other active ports (e.g. wx) don't even have a buildbot and get maintained too. Some configuration like BREWMP or HAIKU don't have buildbot and I can't see any build fixes or _upstraeming_ activity for them within the last months. So PLEASE: When do we call a port active? It's not cool to get the question about removal every few months! -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do you maintain OS(WINCE)?
I'm not sure if you refer to [1] or want to improve [2]. If I look at [1] I see Yong Li at the WinCE port too. That's correct for the knowledge of the code, but does not represent any current work done. Some guideline about how to maintain the list might be helpful too. [1] http://trac.webkit.org/wiki/WebKit%20Team [2] http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/committers.py Patrick Am 13.09.2011 um 23:44 schrieb Kenneth Rohde Christiansen: We already have a list of reviewers and committers and it should mention which port people work on. Kenneth On Tue, Sep 13, 2011 at 11:41 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Sep 13, 2011 at 2:38 PM, Patrick Gansterer par...@paroga.com wrote: Yes, that's correct. How do we measure an active port??? I maintain a buildbot for WinCe and usually fix problems with the port within hours. Unfortunately I don't get paid to work on WebKit the whole day and so I can't make such big steps forward like other ports do. Other active ports (e.g. wx) don't even have a buildbot and get maintained too. Some configuration like BREWMP or HAIKU don't have buildbot and I can't see any build fixes or _upstraeming_ activity for them within the last months. So PLEASE: When do we call a port active? It's not cool to get the question about removal every few months! Maybe we should have a wiki page with a list of ports and the point of contact. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Senior Engineer Application and Service Frameworks, Nokia Danmark A/S Phone +45 4093 0598 / E-mail kenneth.christiansen at gmail.com http://codeposts.blogspot.com ﹆﹆﹆ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do you maintain OS(WINCE)?
I'm not sure if it's that easy. ;-) We have different CPU(), OS(), PLATFORM() and USE() defines and they can be combined in many different ways, even if some ports are already handled via an simple PLATFORM(XY) macro. Patrick Am 14.09.2011 um 00:06 schrieb Leandro Pereira: On 09/13/2011 06:45 PM, Eric Seidel wrote: We don't even have a way to view what ports exist! There is a ports.py file, in the same spirit there is a committers.py file, even though it does contain only a fraction of all the ports. Were it better maintained, one could add references to each contributor in committers.py. Being machine-readable, a post-commit hook that updates a page in the Wiki can be added to provide the same info in a human-readable format. Sheriffbot could also be teached about this. Leandro ___ 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] NEW XML Parser
The new XML parser isn't finished yet (see webkit.org/b/64396). An ENABLE_NEW_XML=1 preprocessor definition should work, but you need to hack this into your build system on your own at the moment. Some build system don't contain the required source file, so there might be more work needed. So I'm not sure if you really want to do this in the current state. - Patrick Am 05.09.2011 um 08:08 schrieb Sireesha Janakiraman: Hello all, I am newbie to webkit. I am trying to use new xml parser for one of use case. I see ENABLE(NEW_XML) check to get the new functionality , but it is not defined in configure script. Is there a way I can use new_xml parser in webkit. Regards, Siree ___ 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] Request for Update to Windows Development Environment
Hi, Am 13.07.2011 um 22:38 schrieb Brent Fulgham: Can we please move away from VS2005 in the near future? What can we (outside of Apple) do to help make this possible? I've created already a CMake based version of AppleWindows port. I've compiled it with VS2010, but it should work with the other version too. The main reason why I din't created a patch with my changes is, that the Windows port has some uncool dependencies. E.g. the QuickTime project needs a different include path, because it's not compatible with the Core* libraries. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] msys support/WinCE support
On Mon, 11 Jul 2011 21:30:44 -0700, Brent Fulgham bfulg...@gmail.com wrote: Is the WinCE port still active? I don't know about your other questions, but Patrick Gansterer (paroga) maintains the WinCE port. I believe it is active. Correct, I still maintain the WinCE port and provide the buildbot for it. There is code in old-run-webkit-tests attempting to support msys configurations. (Which appears to be used by the WinCE port?) WinCE port does not use any testing scripts at the moment. :-( Is this an active configuration? Or can we remove msys support when transitioning to new-run-webkit-tests. Feel free to remove all WinCE code of it. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] IDL generation: [Conditional=XXX] vs. #if defined(ENABLE_XXX)
IMO [Conditional=XXX] does not generate correct output (only tried JSC). It adds top many header includes. Example with DOMWindow.idl: The line attribute [Conditional=DATABASE] SQLExceptionConstructor SQLException; adds #include JSSQLException.h independently of ENABLE_DATABASE. The lines #if defined(ENABLE_DATABASE) ENABLE_DATABASE attribute SQLExceptionConstructor SQLException; #endif generate the #include only if ENABLE_DATABSE is true. If we add JSSQLException.h unconditionally we also need to generate the corresponding IDL all the time. I see three possible solutions: 1) Always generate all IDL files. 2) Change all [Conditional=XXX] to #if define(ENABLE_XXX). 3) Add the correct #if ENABLE(XXX) around the header includes. BTW: Should we unify the #if defined(ENABLE_XXX) and [Conditional=XX] in all IDL files? - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] IDL generation: [Conditional=XXX] vs. #if defined(ENABLE_XXX)
Does this cause a concrete problem? That's the only problem I had, when I compiling with !ENABLE(DATABASE). IMO we don't require a new buildslave for this. Instead that's a more general problem. I think we will see the same problem for ENABLE(SVG) on the Qt minimal bot when we change the #if ENABLE_SVG to [Conditional=SVG]. I guess there are some configurations that don't build? Yes, but they are usually easy to fix. (see !ENABLE(SVG_ANIMATION) fix with http://trac.webkit.org/changeset/90106) IMHO the problem with the IDL generation is a more general, because it can happen not only with one configuration. - Patrick Am 03.07.2011 um 11:29 schrieb Adam Barth: Does this cause a concrete problem? I guess there are some configurations that don't build? Generally, configurations without buildbot won't actually build. The Qt minimal bot helps keep us honest in this regard, but I suspect there are lots of configurations that don't actually build. Adam On Sun, Jul 3, 2011 at 2:12 AM, Patrick Gansterer par...@paroga.com wrote: IMO [Conditional=XXX] does not generate correct output (only tried JSC). It adds top many header includes. Example with DOMWindow.idl: The line attribute [Conditional=DATABASE] SQLExceptionConstructor SQLException; adds #include JSSQLException.h independently of ENABLE_DATABASE. The lines #if defined(ENABLE_DATABASE) ENABLE_DATABASE attribute SQLExceptionConstructor SQLException; #endif generate the #include only if ENABLE_DATABSE is true. If we add JSSQLException.h unconditionally we also need to generate the corresponding IDL all the time. I see three possible solutions: 1) Always generate all IDL files. 2) Change all [Conditional=XXX] to #if define(ENABLE_XXX). 3) Add the correct #if ENABLE(XXX) around the header includes. BTW: Should we unify the #if defined(ENABLE_XXX) and [Conditional=XX] in all IDL files? - Patrick ___ 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] IDL generation: [Conditional=XXX] vs. #if defined(ENABLE_XXX)
Am 03.07.2011 um 17:33 schrieb Alexey Proskuryakov: I see three possible solutions: 1) Always generate all IDL files. 2) Change all [Conditional=XXX] to #if define(ENABLE_XXX). 3) Add the correct #if ENABLE(XXX) around the header includes. (1) used to be the preferred solution. It's so much nicer to not have tons of #if checks at the top of cpp files. IMHO it's not so important how _generated_ files look, because we shouldn't need to open them. The conditionals support for attributes was added in [1]. [2] is a Qt build fix from the original author and used (1). [3] fixed build-webkit --minimal with (3). (1) might simplify the build system, since we don't need condition for the IDL files, but I don't think this is a strong argument since we have the conditions for the implementations (CPP) anyway. On windows (1) also generates many warning LNK4221: no public symbols found; archive member will be inaccessible warnings (e.g. see logfiles of WinCE buildbot) and compiling empty files (after preprocessor) takes unnecessary time. After deeper looks into our version history I personally prefer fixing the CodeGenerator (like abarth wrote). Any opinions about changing all #if define(ENABLE_XXX) in the IDL files to [Conditional=XXX] ? [1] http://trac.webkit.org/changeset/44116 [2] http://trac.webkit.org/changeset/44126 [3] http://trac.webkit.org/changeset/85868 - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Writing a new XML parser with no external libraries
I had the same idea a year ago, and got only negative feedback. My main intention was/is the performance of the parser (see [1]). I improved the performance of it a lot in the meantime (see dependencies of [2]) [2] tries to remove this UTF-8 - UTF-16 - UTF-8 overhead. The patch isn't perfect at the moment (some LayoutTest don't work, and it bypasses the whole DocumentWriter stuff). So if someone really want to replace it, it would be great to check the performance against libxml2 with applied [2]. Comment #1 at [2] shows that the current libxml2 implementation is about 6% faster than the HTML parser (same data, only different mime types). So if we really want to add a new XML parser, someone should convert the HTML parser to work with the encoding of the document (or at least UTF-8) to add the required common code first, before adding a second parser with the same performace problem (sorry for that, i don't want to say that out parser is bad, i only see room for improvement). libxml2 has security bugs reasonably often, and creates the need for an extra upstream update to pull those fixes. Isn't libxml2 a system library and _the system_ responsible for security issues in it? [1] https://bugs.webkit.org/show_bug.cgi?id=43085 [2] https://bugs.webkit.org/show_bug.cgi?id=52036 - Patrick Am 29.06.2011 um 07:10 schrieb Dirk Schulze: Am 29.06.2011 um 05:42 schrieb TAMURA, Kent: I'm a little negative of developing a new XML parser. I'm afraid that the new parser introduces a lot of security/stability problems which existing parsers already resolved. I feel the same. Writing a new parser from scratch means introducing a lot of new security bugs, parsing errors and maybe bigger performance lost at the beginning. Speaking from the SVG side, we fail at least three tests on the W3C SVG Test Suite because of parsing bugs if libxml2 on MacOS. All of these bugs are fixed in later versions of libxml2. Updating libxml2 more often on MacOS would help a lot. With the new parser we won't loose support XSLT and XLink support? Dirk ___ 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] Progressing on the Android port
Am 13.05.2011 um 23:07 schrieb Lucas De Marchi: Humn... now I see what you're saying. I don't know if it's worth because that would give the user the option to turn it on. Not all options work with every port and doing so will result in a build break. So what we did is let all options turned off by default, without giving the option to turn it on. This is done by letting the #define ENABLE_BLA in cmakeconfig.cmake. The macro ENABLE(BLA) will expand to 0 in this case. If it doesn't (like you said about GLIB, IMO that is a bug). We should have some usual defaults, so not every port needs to define all of them. E.g. SVG will work with nearly every port. The OptionsXXX.cmake files should only override the defaults provided by OptionsCommon.cmake. I don't think it's a good idea to maintain new/removed defines for every port. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Building WebkitGTK on Mac OSX 10.6
This is not the right mailing list for discussion of how to use WebKit or work around bugs. This mailing list is for people involved in the development of WebKit to work together. For an GTK-specific issue I suggest webkit-gtk mailinglist. See http://www.webkit.org/contact.html. - Patrick Am 30.03.2011 um 11:21 schrieb Piotr Sarnacki: Hey, I try to build WebkitGTK and on various revisions I get errors similar to that one: https://gist.github.com/894025 I have version 2.28 of glib and installed all of the dependencies from sources, cause I use homebrew for installing packages (usually latest ones). Should I try some older revisions? And if yes, which one should I try? Cheers! Piotr Sarnacki ___ 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
[webkit-dev] bugid in ChangeLog
Hi, Sometimes folks commit changes without bug numbers. If those changes breaks things it's hard to find the correct context for the change. Can we make the bug number a requirement for a commit when it has a corresponding bug? IMHO it would be great if the style bot and the reviewer complain about missing bug numbers. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] bugid in ChangeLog
Am 26.03.2011 um 19:30 schrieb Brent Fulgham: I don't want to have a bug report for everything either, but I do agree that my failure to include it in the changelog for the FontPlatformData change was a stupid oversight. I'll make sure to avoid that mistake in the future! I didn't want to blame you directly! :-) Am 26.03.2011 um 21:32 schrieb Ryosuke Niwa: On Sat, Mar 26, 2011 at 10:41 AM, Darin Adler da...@apple.com wrote: On Mar 26, 2011, at 3:24 AM, Patrick Gansterer wrote: Sometimes folks commit changes without bug numbers. If those changes breaks things it's hard to find the correct context for the change. Can we make the bug number a requirement for a commit when it has a corresponding bug? IMHO it would be great if the style bot and the reviewer complain about missing bug numbers. I don’t think we should require a bug report for every commit. I think Patrick is saying that we should require to have the corresponding bug number if there is one, not that every commit should have a bug number. Correct! I don't think we need a bug id for every commit (e.g. a simple build fix). But if we already upload a patch to bugzilla we should make the bug number a requirement in the ChangeLog. IMHO there's no extra cost to do this. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] jsc compilation error
I'm experiencing a link failure when attempting to compile the jsc for an embedded platform. If you write a mail to this list: Please provide more information! What is embedded platform? Which architecture? Which port? BTW: This is more a question for webkit-help and not form webkit-dev. See http://webkit.org/contact.html. Linking CXX executable jsc_sb CMakeFiles/jsc_sb.dir/__/jsc.cpp.o:(.gnu.linkonce.d._ZTI12GlobalObject+0x8): undefined reference to `typeinfo for JSC::JSGlobalObject' collect2: ld returned 1 exit status make[2]: *** [JavaScriptCore/shell/jsc_sb] Error 1 make[1]: *** [JavaScriptCore/shell/CMakeFiles/jsc_sb.dir/all] Error 2 make: *** [all] Error 2 Seams like you're using CMake. In current trunk only EFL and WinCE are supported. Did you tried your CMake files on an other machine/system/compiler version? The basic CMake files work, since EFL and WinCE build bots work. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to add a new file to mac build system?
Please have a look at [1] and [2]. You need to run build-webkit first. BTW: If provide error messages instead of fails to compile only, it's easier for other people to help you. [1] http://webkit.org/building/build.html [2] http://webkit.org/building/debug.html - Patrick Won J Jeon: Thanks, Eric. I opened WebCore.xcodeproj file with XCode but it fails to compile the code and it hangs without success, whereas JavaScriptCore.xcodeproj doesn't have any problem to be compiled with XCode. Are there any known issues with XCode? Won On Mon, Jan 24, 2011 at 1:53 PM, Eric Seidel e...@webkit.org wrote: There is not a gyp-like build system for Apple's Mac build (yet). You generally need to use XCode to edit the WebCore.xcodeproj file. But if you're trying to build on a Mac you need XCode installed anyway. .pri and .pro are not related to the Apple Mac build. -eric On Mon, Jan 24, 2011 at 1:03 PM, Won J Jeon wjj...@gmail.com wrote: Hi all, I'd like to test some code by adding a new idl and its implementation to WebCore on Mac. How can I let the build system know the addition of such files? Is there any gyp-like build system on Mac? Can anyone explain what *.pri and *.pro files are and how I can use them? Regards, Won ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Done moving source files into Source
Congratulation! Adam Barth: If you own one of the files below, please consider moving it from the root directory to the Source directory: cmakeconfig.h.cmake CMakeLists.txt I'd like to move the CMake related files into Source, but they also require some files from the Tools directory (EWebLauncher, WinCELauncher). Maybe other build systems have the same problem. Can we move the code for the launchers into Sources too? Otherwise we need to keep the files in the root directory. :-( - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Done moving source files into Source
Adam Barth: Otherwise we need to keep the files in the root directory. :-( I'm not sure I understand the connection. For example, cmakeconfig.h.cmake seems to be entirely concerned with WebCore concepts (essentially which features are enabled): http://trac.webkit.org/browser/trunk/cmakeconfig.h.cmake Surely the launchers don't need to peer into these internal details of WebCore. Ok, cmakeconfig.h.cmake can be moved, but i see the problem with the following lines: http://trac.webkit.org/browser/trunk/CMakeLists.txt?rev=75908#L15 http://trac.webkit.org/browser/trunk/WebKit.pro?rev=75908#L13 The launchers only need the WebKit-API, but we have _one_ buildsystem, which builds _all_ targets (including launcher) and needs to know about them. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How can I call a javascript function from the hosting application
Hi, Brent Fulgham: Hi Patrick, On Jan 10, 2011, at 12:37 PM, Patrick Gansterer wrote: André Pedralho: Hi Fred, my bad! Sorry, it is only available in the Qt port. If you have a look at the Qt port you see the following: JSC::JSValue v = d-frame-script()-executeScript(ScriptSourceCode(scriptSource)).jsValue(); There's a Frame::script() method where get the ScriptController. I'm not that familiar with the Windows CE port, but in the regular Windows version you can access the script object via COM interface pointers. The project I link on my blog (http://whtconstruct.blogspot.com/2009/06/calljs-updated.html) shows some examples of using this. WinCE has no COM (or sth else) wrapper around the plain WebKit objects (yet). So you must call the WebKit methods directly. IMHO we should move this thread to webkit-help, if there are further posts. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How can I call a javascript function from the hosting application
André Pedralho: Hi Fred, my bad! Sorry, it is only available in the Qt port. If you have a look at the Qt port you see the following: JSC::JSValue v = d-frame-script()-executeScript(ScriptSourceCode(scriptSource)).jsValue(); There's a Frame::script() method where get the ScriptController. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] libxml2 override encoding support
Alex Milowski: On Tue, Jan 4, 2011 at 7:05 PM, Alexey Proskuryakov a...@webkit.org wrote: 04.01.2011, в 18:40, Alex Milowski написал(а): Looking at the libxml2 API, I've been baffled myself about how to control the character encoding from the outside. This looks like a serious lack of an essential feature. Anyone know about this above hack and can provide more detail? Here is some history: http://mail.gnome.org/archives/xml/2006-February/msg00052.html, https://bugzilla.gnome.org/show_bug.cgi?id=614333. Well, that is some interesting history. *sigh* I take it the work around is that data is read and decoded into an internal string which is represented by a sequence of UChar. As such, we treat it as UTF16 character encoded data and feed that to the parser, forcing it to use UTF16 every time. Too bad we can't just tell it the proper encoding--possibly the one from the transport--and let it do the decoding on the raw data. Of course, that doesn't guarantee a better result. Is there a reason why we can't pass the raw data to libxml2? E.g. when the input file is UTF-8 we convert it into UTF-16 and then libxml2 converts it back into UTF-8 (its internal format). This is a real performance problem when parsing XML [1]. Is there some (required) magic involved when detecting the encoding in WebKit? AFAIK XML always defaults to UTF-8 if there's no encoding declared. Can we make libxml2 do the encoding detection and provide all of our decoders so it can use it? [1] https://bugs.webkit.org/show_bug.cgi?id=43085 - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] libxml2 override encoding support
Darin Adler: On Jan 5, 2011, at 5:07 AM, Patrick Gansterer wrote: Is there a reason why we can't pass the raw data to libxml2? Because libxml2 does its own encoding detection which is not even close to what’s specified in HTML5, and supports far fewer encodings. If you make a test suite you will see. Can you point me to the place of the XML encoding rules? After a short look into the spec I didn't find something which applies to XML input encoding. AFAIK it's possible to teach libxml2 additional encodings. On the other hand, you could probably make a path that lets libxml2 do the decoding for the most common encodings when specified in a way that we know libxml2 detects correctly, after doing some testing to see if it handles everything right. That's something I'd like to do, but I need some time when I can do it. ;-) My first step was to improve the performance of libxml2 - WebKit. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Handling of feature dependencies
Eric Seidel: The more you turn off, the less the binary you create is WebKit. It tells servers its WebKit via its useragent, but then it doesn't have the features that pages have come to expect from WebKit -- this is bad for WebKit and bad for your users. Feature detection by user agent is bad (but common) and can be done in a better way. I don't think this is a reason to remove feature switches. A better course of action is to study the memory usage and reduce memory usage for all ports of WebKit, instead of just hacking off lumps. I think you'll find that things like the console don't use much memory at all. Example from WinCE5: There's a limit of 32MB per process, so every byte is important. IMHO console isn't a big player, but XSLT as an example also needs libxslt as additional dependency. SQLite for database is the same. Maybe the WebKit code does not need so much memory, but we don't need the third party libs (they are not system libraries on every platform :)). Obviously many devices have already shipped with full copies of WebKit. If you have a very low-memory/low-power device (more than a cell phone or a TV or a car or something that would run Qt -- all of these have numerous shipping example devices using WebKit), then WebKit is probably not what you want anyway. :) Sometimes WebKit is exactly the correct solution! If you want to maintain only _one_ version of your application I don't see a better way than using a standard compliant browser engine. A small HTML page works perfectly on a small device and on the high end computer. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit-WinCE finally merged
Hi all, I'm glad to say that WebKit-WinCE is finally merged and got a working build slave [1] today. Many, many thanks to the people from TorchMobile who did the original WinCE port and all the friends that reviewed my patches to make this possible. Thanks! It would be nice if we can try to keep it green when doing changes which affect WinCE ;-). [1] http://build.webkit.org/waterfall?show=WinCE%20Release%20(Build) - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] More thoughts on cleaning up the root directory
Hi, also thank you for leading the reorg. Adam Barth: Here's a snapshot of my current thinking on where the files and folders currently in the top-level directory might go. There are a bunch of build-system related files that are currently in the root. I'm not sure whether we should leave them in there or move them into Sources somewhere. I'm tempted to put them into Sources so that Sources is self-contained package of all the stuff you need to build WebKit. That said, having a top-level Makefile that kicks off the whole process also seems reasonable. If we keep a top level Makefile we also need to keep all == UNSURE == files. IMHO it's better to move all build related stuff into Sources. Then you only need the Sources directory to build WebKit. Sources/ automake/ cmake/ JavaScriptCore/ JavaScriptGlue/ Platform/ (was WebCore/platform) If you move WebCore/platform into Sources, you should also move all the platform stuff of WTF into this directory. I don't think this is a good idea, because this leads to WTF and WebCore namespace in one directory and that's confusing. Also the fact, that not all of the code in WebCore/platform is platform dependent, is a point against this move. PerformanceTests/ PageLoad/ (was PageLoadTests) SunSpider/ HTMLParser/ (was WebCore/benchmarks/parser) A XML parser benchmark will land soon (bug 51612), so Parser might be a better name instead of HTMLParser. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] !ENABLE(INSPECTOR)
Hi, Does anybody compile WebKit with inspector disabled? It's not possible with the current trunk (since weeks). I'm not sure what's the correct solution to fix this. The main problem is that Console.cpp (e.g. at [1]) uses ScriptCallStack and ScriptCallStackFrame, but this classes should go into a #if ENABLE(INSPECTOR) section IMHO. Otherwise they must not use any classes from InspectorValues (e.g. at [2]). Can someone fix this (or at least point me to the right solution)? [1] http://trac.webkit.org/browser/trunk/WebCore/page/Console.cpp?rev=71966#L171 [2] http://trac.webkit.org/browser/trunk/WebCore/inspector/ScriptCallStack.cpp?rev=71515#L77 - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] !ENABLE(INSPECTOR)
I filed bug 49500 (including patch). But I'm still interested if there is someone who maintains the ENABLE(INSPECTOR) option. Simon Fraser: Please file a bugzilla bug on this issue. Simon On Nov 13, 2010, at 8:15 AM, Patrick Gansterer wrote: Hi, Does anybody compile WebKit with inspector disabled? It's not possible with the current trunk (since weeks). I'm not sure what's the correct solution to fix this. The main problem is that Console.cpp (e.g. at [1]) uses ScriptCallStack and ScriptCallStackFrame, but this classes should go into a #if ENABLE(INSPECTOR) section IMHO. Otherwise they must not use any classes from InspectorValues (e.g. at [2]). Can someone fix this (or at least point me to the right solution)? [1] http://trac.webkit.org/browser/trunk/WebCore/page/Console.cpp?rev=71966#L171 [2] http://trac.webkit.org/browser/trunk/WebCore/inspector/ScriptCallStack.cpp?rev=71515#L77 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
