Remove configuration options for futures that are not supported by the Gtk port - there's no need for them currently. They should be readded when the support for a specific feature is added and introduces a new dependency.
Created attachment 144361 [details] Patch
(In reply to comment #1) > Created an attachment (id=144361) [details] > Patch The only options I've left out due to some recent activity towards adding support are --enable-gamepad, --enable-indexed-database and --enable-filesystem.
Comment on attachment 144361 [details] Patch \o/
(In reply to comment #3) > (From update of attachment 144361 [details]) > \o/ Thanks for the quick review. I'll land this once I'm confirmed there's not an unstable release planned in the near future (two weeks or there about).
Comment on attachment 144361 [details] Patch Attachment 144361 [details] did not pass gtk-ews (gtk): Output: http://queues.webkit.org/results/12844244
(In reply to comment #5) > (From update of attachment 144361 [details]) > Attachment 144361 [details] did not pass gtk-ews (gtk): > Output: http://queues.webkit.org/results/12844244 Eek! Looks like files added to the build for the unsupported features will have to be removed.
Or we could leave them in and have the appropriate defines without a configure option, perhaps?
(In reply to comment #7) > Or we could leave them in and have the appropriate defines without a configure option, perhaps? Yeah, that seems like a sensible approach. We just want to remove the interface to the user for these features, not the actual option. The autogeneration of the build options should still be able to turn them on and off.
(In reply to comment #8) > (In reply to comment #7) > > Or we could leave them in and have the appropriate defines without a configure option, perhaps? > > Yeah, that seems like a sensible approach. We just want to remove the interface to the user for these features, not the actual option. The autogeneration of the build options should still be able to turn them on and off. It seems the solution to this would be to include all the files in the build, regardless of the feature that file partly implements is enabled or not. I'm not entirely sure this is even possible, but it would make sense that the build should work as expected that way, with all the source files included and the feature being actually built only if the macro is present in the cppflags. As your comments suggest, the option for feature-enabling should stay, but in my opinion not in the shape of AM conditionals. Perhaps it would be better then to first sort out the feature defines into a GNUmakefile.features.am (bug #87127)? If that, together with all the files being included in the build, is achieved, then they (AM conditionals used for including extra files into the build) are not really needed anymore.
(In reply to comment #9) > It seems the solution to this would be to include all the files in the build, regardless of the feature that file partly implements is enabled or not. I'm not entirely sure this is even possible, but it would make sense that the build should work as expected that way, with all the source files included and the feature being actually built only if the macro is present in the cppflags. > > As your comments suggest, the option for feature-enabling should stay, but in my opinion not in the shape of AM conditionals. Perhaps it would be better then to first sort out the feature defines into a GNUmakefile.features.am (bug #87127)? If that, together with all the files being included in the build, is achieved, then they (AM conditionals used for including extra files into the build) are not really needed anymore. I'm not exactly sure how it would look other than AM conditionals, but I guess I can just wait for the patch at #87127. One thing that concerns me though is if we do not remove the files from the build, this removes the benefit of disabling SVG for creating faster builds.
Handling SVG specially sounds like the practical solution.
(In reply to comment #11) > Handling SVG specially sounds like the practical solution. I'm not sure how removing the files from allows enabling and disabling features via the feature list autogeneration.
(In reply to comment #10) > One thing that concerns me though is if we do not remove the files from the build, this removes the benefit of disabling SVG for creating faster builds. I've done three builds with clean cache: 1. SVG disabled, files not included in the build - 27m:43s 2. SVG disabled, files included in the build - 28m:04s 3. SVG enabled - 35m:04s Seems the preprocessor does its job formidably and I think the time difference can be lived with.
(In reply to comment #1) > Created an attachment (id=144361) [details] > Patch As for this patch, I recommend splitting it up: - create new bug entries for the data-transfer-items and mhtml options, uploading a patch for each that removes the configuration option, AM conditonal and moves the files into the general build (after proper testing) - reupload a patch for other options here This seems somewhat contrary to what I was recommending in comment #9 (getting a GNUmakefile.features.am done), but I think these configuration options are safe to remove before that. They're unsupported and there's probably no one trying to enable them, so there's not much harm done in leaving them disabled with no option to enable for a short amount of time. But that said, I'd like some confirmation that a release is not just around the corner.
(In reply to comment #13) > (In reply to comment #10) > > One thing that concerns me though is if we do not remove the files from the build, this removes the benefit of disabling SVG for creating faster builds. > > I've done three builds with clean cache: > 1. SVG disabled, files not included in the build - 27m:43s > 2. SVG disabled, files included in the build - 28m:04s > 3. SVG enabled - 35m:04s Okay. At some point I moved all the files into the main list and then others moved them back out. Now you are moving them back in again. I don't really care where they are, as long as they stop moving. :)
(In reply to comment #14) > This seems somewhat contrary to what I was recommending in comment #9 (getting a GNUmakefile.features.am done), but I think these configuration options are safe to remove before that. They're unsupported and there's probably no one trying to enable them, so there's not much harm done in leaving them disabled with no option to enable for a short amount of time. But that said, I'd like some confirmation that a release is not just around the corner. I think it's safe to do these things as long as you are careful.
*** Bug 94500 has been marked as a duplicate of this bug. ***
*** Bug 94495 has been marked as a duplicate of this bug. ***
*** Bug 50954 has been marked as a duplicate of this bug. ***
The GNUmakefile.features.am was created and is now working OK, but this bug kind of fell off my radar. I'll upload an updated patch, IMO it should get another review as it's been over 3 months since the previous patch.
Created attachment 162448 [details] Patch
Comment on attachment 162448 [details] Patch Clearing flags on attachment: 162448 Committed r127760: <http://trac.webkit.org/changeset/127760>
All reviewed patches have been landed. Closing bug.