WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
Bug 110579
[GTK] Build libWebCorePlatform.la as libPlatform.la, libWebCoreGtk.la as libPlatformGtk.la
https://bugs.webkit.org/show_bug.cgi?id=110579
Summary
[GTK] Build libWebCorePlatform.la as libPlatform.la, libWebCoreGtk.la as libP...
Zan Dobersek
Reported
2013-02-22 02:16:16 PST
[GTK] Remove libWebCorePlatform.la, building its sources into libPlatform.la
Attachments
Patch
(22.28 KB, patch)
2013-02-22 02:35 PST
,
Zan Dobersek
no flags
Details
Formatted Diff
Diff
Patch
(7.86 KB, patch)
2013-02-22 03:44 PST
,
Zan Dobersek
no flags
Details
Formatted Diff
Diff
Patch
(21.60 KB, patch)
2013-02-24 02:46 PST
,
Zan Dobersek
no flags
Details
Formatted Diff
Diff
Proposed patch
(10.22 KB, patch)
2013-03-01 11:04 PST
,
Zan Dobersek
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Zan Dobersek
Comment 1
2013-02-22 02:35:57 PST
Created
attachment 189730
[details]
Patch
Zan Dobersek
Comment 2
2013-02-22 03:44:57 PST
Created
attachment 189738
[details]
Patch Commit #2 from the platform-gtk branch I've set up on GitHub.
https://github.com/zdobersek/webkit/commits/platform-gtk
Will most likely not apply. The branch builds and works as a whole.
Martin Robinson
Comment 3
2013-02-22 12:34:43 PST
Comment on
attachment 189738
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=189738&action=review
Okay. This seems reasonable. This does mean that the amount of code that's compiled for both GTK+2 and GTK+3 is larger though, right? This might actually increase our buildtimes significantly.
> Source/WebCore/GNUmakefile.list.am:5306 > -webcore_platform_sources += \ > +platform_sources += \ > Source/WebCore/platform/animation/Animation.cpp \ > Source/WebCore/platform/animation/Animation.h \
I know this makes the diff smaller, but it's probably better to have these all defined in one place.
Zan Dobersek
Comment 4
2013-02-22 13:12:52 PST
(In reply to
comment #3
)
> (From update of
attachment 189738
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=189738&action=review
> > Okay. This seems reasonable. This does mean that the amount of code that's compiled for both GTK+2 and GTK+3 is larger though, right? This might actually increase our buildtimes significantly. >
Ugh, you're right. I'm not really in favor of this change anymore. I guess that in the larger scope it still makes sense to have the platform layer code split between the general library and the library built from GTK-specific sources. The former would be named libPlatform.la, the latter libPlatformGtk.la. They'd basically be what libWebCorePlatform.la and libWebCoreGtk.la are today, with build rules specified in Source/Platform/GNUmakefile.am[1]. Similarly, libWebCoreGtk2.la becomes libPlatformGtk2.la. This simplifies the work required really, for starters this bug could just cover moving the build rules to Source/Platform/GNUmakefile.am (or this could be done under
bug #110576
). Thoughts? [1] Again, I'd like to place the build rules there as this is where the files will be moved - hopefully soon enough that this work doesn't come out as way ahead of its time.
Zan Dobersek
Comment 5
2013-02-22 13:14:39 PST
Hi Carlos -- any objections to the newly outlined plan in
comment #4
? (Bugs #110579 and #110330 have more context if required.)
Martin Robinson
Comment 6
2013-02-22 13:15:56 PST
(In reply to
comment #4
)
> This simplifies the work required really, for starters this bug could just cover moving the build rules to Source/Platform/GNUmakefile.am (or this could be done under
bug #110576
). > > Thoughts?
Yeah! This sounds like a great idea. I think you should even consider moving the source lists to Source/Platform/GNUmakefile.am. You can skip making a Source/Platform/GNUmakefile.list.am. We created these files because we thought at some point gyp would generate them. I don't think this will happen now.
Zan Dobersek
Comment 7
2013-02-22 13:22:11 PST
(In reply to
comment #6
)
> (In reply to
comment #4
) > > > This simplifies the work required really, for starters this bug could just cover moving the build rules to Source/Platform/GNUmakefile.am (or this could be done under
bug #110576
). > > > > Thoughts? > > Yeah! This sounds like a great idea. I think you should even consider moving the source lists to Source/Platform/GNUmakefile.am. You can skip making a Source/Platform/GNUmakefile.list.am. We created these files because we thought at some point gyp would generate them. I don't think this will happen now.
I was planning on listing in Source/Platform only sources that are actually located there - those would at first be sources that are planned for moving in
bug #110330
. I think listing sources there that are still located in Source/WebCore would only be seen as a burden and perhaps source of confusion to people who are willing to add new files to the build system but would have to edit files in a sibling directory to do so.
Carlos Garcia Campos
Comment 8
2013-02-23 02:59:42 PST
(In reply to
comment #6
)
> (In reply to
comment #4
) > > > This simplifies the work required really, for starters this bug could just cover moving the build rules to Source/Platform/GNUmakefile.am (or this could be done under
bug #110576
). > > > > Thoughts? > > Yeah! This sounds like a great idea. I think you should even consider moving the source lists to Source/Platform/GNUmakefile.am. You can skip making a Source/Platform/GNUmakefile.list.am. We created these files because we thought at some point gyp would generate them. I don't think this will happen now.
I would still leave a .list.am file with only sources listing, I think it's useful for people from other ports who are not familiarized with autotools, since the only thing in the file is file listing, it's easier to add new files. It also makes easier to find the rules
Carlos Garcia Campos
Comment 9
2013-02-23 03:00:30 PST
(In reply to
comment #5
)
> Hi Carlos -- any objections to the newly outlined plan in
comment #4
? > (Bugs #110579 and #110330 have more context if required.)
As long as the gtk specific parts are in a different library that can be built again with gtk2 for the plugin process is fine with me.
Zan Dobersek
Comment 10
2013-02-24 00:51:08 PST
***
Bug 110576
has been marked as a duplicate of this bug. ***
Zan Dobersek
Comment 11
2013-02-24 02:46:46 PST
Created
attachment 189964
[details]
Patch
Zan Dobersek
Comment 12
2013-03-01 08:22:13 PST
Comment on
attachment 189964
[details]
Patch I've brought up the migration issue on the webkit-dev mailing list[1] and while the discussion is somewhat still ongoing there are two conclusions already drawn that affect this bug: - the platform layer code (to be built into libPlatform(Gtk).la) must in no way depend on WebCore, - the migration will be incremental, moving source files after it is determined they are independent of WebCore. Because of that I'd recommend that libPlatform.la and libPlatformGtk.la are set up as in the latest patch, but in no way stretching out to WebCore and used alongside libWebCorePlatform.la and libWebCoreGtk.la, respectively. The source files that are green-lit for the migration would then be moved under Source/Platform and listed in the appropriate build target list. This would allow for incremental migration without too much hassle in terms of build failures for the GTK port. Thoughts? [1]
https://lists.webkit.org/pipermail/webkit-dev/2013-February/024000.html
Zan Dobersek
Comment 13
2013-03-01 11:04:30 PST
Created
attachment 190993
[details]
Proposed patch Still needs changelogs and an updated bug title.
Martin Robinson
Comment 14
2013-03-01 11:09:40 PST
Comment on
attachment 190993
[details]
Proposed patch I'm slightly confused as to what is in libWebCoreGtk2 that isn't in libPlatformGtk2.
Zan Dobersek
Comment 15
2013-03-01 11:13:03 PST
What exactly is confusing?
Martin Robinson
Comment 16
2013-03-01 11:14:47 PST
(In reply to
comment #15
)
> What exactly is confusing?
I thought you were going to replace libWebCoreGtk2 with libPlatformGtk2. This patch doesn't remove any sources from the libWebCoreGtk2 source list and doesn't remove the convenience library itself.
Zan Dobersek
Comment 17
2013-03-01 11:24:57 PST
(In reply to
comment #16
)
> (In reply to
comment #15
) > > What exactly is confusing? > > I thought you were going to replace libWebCoreGtk2 with libPlatformGtk2. This patch doesn't remove any sources from the libWebCoreGtk2 source list and doesn't remove the convenience library itself.
As
comment #12
says, libPlatform and libPlatformGtk must be independent of WebCore. This isn't the case with libWebCoreGtk. Incremental changes seem to be preferred, so basically source files would only be migrated after they are cleared of any WebCore dependencies. This goes for both libPlatform and libPlatformGtk. The proposed patch sets up the Autotools build so the patches (migrating sources without violations) can start rolling into the tree, for both shared and GTK-specific source files. During this transition I imagine libWebCoreGtk used side by side with libPlatformGtk, with the former getting thinner and thinner as the work goes on until all the GTK-specific sources are cleared of layer violations and the library is removed. Same goes for libWebCorePlatform and libPlatform.
Zan Dobersek
Comment 18
2013-03-07 07:47:05 PST
It was agreed off-bugzilla some days ago that the libraries should be introduced separately and only when there are some files are actually built into them. I've got a patch ready that introduces libPlatformGtk.la while libPlatform.la will have to wait a bit longer. I'll upload a patch into a new bug.
Zan Dobersek
Comment 19
2013-03-18 02:44:51 PDT
The renaming indicated by the bug title isn't possible, rather than that I believen an incremental migration of source files is preferred. libPlatformGtk.la was already set up in
bug #111738
while libPlatform.la (containing platform layer code used by different ports) will be set up when required. Closing this as a WONTFIX.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug