To avoid having too many special conditions in the tools scripts, we should make the GObject API unit tests build similarly to the CMake build. I prefer to adapt the autotools build, because it uses legacy naming conventions. For instance, "unittests" used to make sense for the WebKit1 GObject API unit tests, because they were the only unit tests that we built. Now we should output test binaries to "WebKit1GObjectAPITests" and "WebKit2GObjectAPITests".
Created attachment 220120 [details] Patch
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Comment on attachment 220120 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=220120&action=review Looks good! Just a small suggestion: > Tools/Scripts/run-gtk-tests:362 > - if "unittests" in test_program or "WebKit2APITests" in test_program: > + if "WebKit1GObjectAPITest" in test_program or "WebKit2GObjectAPITest" in test_program: Perhaps simplify to if 'GObjectAPITest' in test_program ?
Comment on attachment 220120 [details] Patch I'm fine with the change, but why GObject? I really prefer WebKit1GTKAPITest and WebKit2GTKAPITest, not only because it's shorter but mainly because I think it's more accurate, since this is the WebKit GTK+ API. Since we are mostly rewriting the whole makefiles, maybe it's a good opportunity to move the tests to Tools/TestWebKitAPI/Tests/WebKit[N]Gtk ?
(In reply to comment #4) > (From update of attachment 220120 [details]) > I'm fine with the change, but why GObject? I really prefer WebKit1GTKAPITest and WebKit2GTKAPITest, not only because it's shorter but mainly because I think it's more accurate, since this is the WebKit GTK+ API. Since we are mostly rewriting the whole makefiles, maybe it's a good opportunity to move the tests to Tools/TestWebKitAPI/Tests/WebKit[N]Gtk ? The API is a series of exposed GObjects. Some of them are GTK+ widgets, but others are not. I usually call this API the "GObject API," similarly to how we call the GObject DOM API. I'm definitely okay with moving the API tests to a more appropriate location.
(In reply to comment #5) > The API is a series of exposed GObjects. Some of them are GTK+ widgets, but others are not. I usually call this API the "GObject API," similarly to how we call the GObject DOM API. I'm definitely okay with moving the API tests to a more appropriate location. Oh, I'm also okay with most names as long as they are better than "unittests!" :) With your suggestion, perhaps we could output Programs/TestWebKitAPI/WebKit2GTK and so on.
(In reply to comment #5) > (In reply to comment #4) > > (From update of attachment 220120 [details] [details]) > > I'm fine with the change, but why GObject? I really prefer WebKit1GTKAPITest and WebKit2GTKAPITest, not only because it's shorter but mainly because I think it's more accurate, since this is the WebKit GTK+ API. Since we are mostly rewriting the whole makefiles, maybe it's a good opportunity to move the tests to Tools/TestWebKitAPI/Tests/WebKit[N]Gtk ? > > The API is a series of exposed GObjects. Some of them are GTK+ widgets, but others are not. I usually call this API the "GObject API," similarly to how we call the GObject DOM API. I'm definitely okay with moving the API tests to a more appropriate location. GObject DOM bindings don't use GTK+ at all. I always say WebKit GTK+ API, and I think it's more accurate. You can also think about it as the public API of WebKitGTK+.
(In reply to comment #6) > (In reply to comment #5) > > > The API is a series of exposed GObjects. Some of them are GTK+ widgets, but others are not. I usually call this API the "GObject API," similarly to how we call the GObject DOM API. I'm definitely okay with moving the API tests to a more appropriate location. > > Oh, I'm also okay with most names as long as they are better than "unittests!" :) With your suggestion, perhaps we could output Programs/TestWebKitAPI/WebKit2GTK and so on. Looks good to me.
Committed r161182: <http://trac.webkit.org/changeset/161182>
See https://bugs.webkit.org/show_bug.cgi?id=126342 which tracks moving the unit tests.