components.list unconditionally lists test and sample components

RESOLVED WORKSFORME

Status

RESOLVED WORKSFORME
9 years ago
8 months ago

People

(Reporter: rflint, Assigned: benjamin)

Tracking

Trunk
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

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
(Assignee)

Comment 1

9 years ago
Created 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
Assignee: nobody → benjamin
Status: NEW → ASSIGNED
Attachment #411256 - Flags: review?(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.
Attachment #411256 - Flags: review?(ted.mielczarek) → review-
(Assignee)

Comment 3

9 years ago
Created 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

The change in print-manifest-dirs.py was necessary because it fails when building from a relative srcdir.
Attachment #413353 - Flags: review?(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.
Attachment #413353 - Flags: review?(ted.mielczarek) → review+

Updated

9 years ago
Duplicate of this bug: 531017
Attachment #411256 - Attachment is obsolete: true
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
}
Flags: in-testsuite-
Shouldn't this be landed ?
(Assignee)

Comment 8

9 years ago
Landing this requires updating Talos at least, which I don't have time to work on, so no.
Created attachment 430281 [details] [diff] [review]
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.
Attachment #430281 - Flags: review?(benjamin)
(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 ?
(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.
(Assignee)

Updated

9 years ago
Attachment #430281 - Flags: review?(benjamin) → review+
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.
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).

Updated

8 years ago
Duplicate of this bug: 574552

Updated

8 years ago
Depends on: 568691
I guess that now components.list is gone, this bug can be closed. What should it be marked ? WORKSFORME ? INVALID ?
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME

Updated

8 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.