527458 - components.list unconditionally lists test and sample components

Status: RESOLVED WORKSFORME

(Firefox Build System :: General, defect)

Description

[Ryan Flint [:rflint] (ping via IRC for reviews)]

components.list picks up some components from test/sample directories that we don't ever ship, leading to a bunch of failed component load attempts in non-test builds. As an example, here's a list taken from the console spew of a Windows nightly:
tp-cmdline.js
nsProgressDialog.js
testdynamic.dll
MyService.dll
xpcomsample.dll
nsSample.js
httpd.js
reftest-cmdline.js

Comment 1

[Benjamin Smedberg]

Attachment: Customize FINAL_TARGET for samples and tests so that we still load them, but they are in different directories, rev. 1

Comment 2

[(not currently active) Ted Mielczarek]

Comment on attachment 411256 [details] [diff] [review]
Customize FINAL_TARGET for samples and tests so that we still load them, but they are in different directories, rev. 1

You'll need to fix xpcshell packaging:
http://mxr.mozilla.org/mozilla-central/source/testing/xpcshell/Makefile.in#69

as well as Mochitest packaging:
http://mxr.mozilla.org/mozilla-central/source/testing/mochitest/Makefile.in#118

It's sort of a mess. Also, I'm not exactly sure, but I think the packaged test builds still copy all the xpcshell binaries into the app dir (bug 486570, because bug 483202 wasn't fixed when we started running them). We might need to fix that before landing this.

Otherwise this looks good. I wish we didn't have all this stuff getting installed to dist/bin in general, but that's a larger thing to fix.

Comment 3

[Benjamin Smedberg]

Attachment: Customize FINAL_TARGET for samples and tests so that we still load them, but they are in different directories, rev. 2

The change in print-manifest-dirs.py was necessary because it fails when building from a relative srcdir.

Comment 4

[(not currently active) Ted Mielczarek]

Comment on attachment 413353 [details] [diff] [review]
Customize FINAL_TARGET for samples and tests so that we still load them, but they are in different directories, rev. 2

I wish the try server did packaged unit tests, so I could tell you to test it there.

Comment 6

[Serge Gautherie (:sgautherie)]

I just discovered this bug in SeaMonkey.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a1pre) Gecko/20091216 SeaMonkey/2.1a1pre] (comm-central-trunk-win32/1260970429) (W2Ksp4)

{
Failed to load XPCOM component: ...\components\tp-cmdline.js
Failed to load XPCOM component: ...\components\testdynamic.dll
Failed to load XPCOM component: ...\components\MyService.dll
Failed to load XPCOM component: ...\components\xpcomsample.dll
Failed to load XPCOM component: ...\components\nsSample.js
Failed to load XPCOM component: ...\components\httpd.js
Failed to load XPCOM component: ...\components\xpctest.dll
Failed to load XPCOM component: ...\components\reftest-cmdline.js
Failed to load XPCOM component: ...\components\testcrasher.dll
}

Comment 7

[Mike Hommey [:glandium]]

Shouldn't this be landed ?

Comment 8

[Benjamin Smedberg]

Landing this requires updating Talos at least, which I don't have time to work on, so no.

Comment 9

[Mike Hommey [:glandium]]

Attachment: Additional patch for xpcshell tests

After applying the already attached patch, a huge load of xpcshell tests fail because they fail to load the httpd.js component.
Fixing runxpcshelltests.py to point at the right place fixes this, *but* there is one remaining problem: test_load_httpd_js.js fails because, not loading the typelib, it doesn't know Components.interfaces.nsIHttpServer.

Comment 10

[Mike Hommey [:glandium]]

(In reply to comment #9)
> Fixing runxpcshelltests.py to point at the right place fixes this, *but* there
> is one remaining problem: test_load_httpd_js.js fails because, not loading the
> typelib, it doesn't know Components.interfaces.nsIHttpServer.

Question is: shouldn't component loading load the typelibs from distribution bundles ?

Comment 11

[Mike Hommey [:glandium]]

(In reply to comment #10)
> Question is: shouldn't component loading load the typelibs from distribution
> bundles ?

Answering to myself: when using the extensions manager, the typelibs are properly loaded.

Comment 12

[Mike Hommey [:glandium]]

In the end, I don't know how to fix test_load_httpd_js.js. Maybe removing it is enough. It is pretty much pointless, as a lot of other tests fail if httpd.js is not loadable.

Comment 13

[(not currently active) Ted Mielczarek]

Please don't remove it. It's a sort of meta-test, so that things fail obviously if core test harness functionality breaks. Without test_necko.xpt being loaded, I would expect other tests might fail (or at least, things will not work as expected).

Comment 15

[Mike Hommey [:glandium]]

I guess that now components.list is gone, this bug can be closed. What should it be marked ? WORKSFORME ? INVALID ?