885778 - Get rid of make rules in toolkit/mozapps/extensions/test/{browser/,}Makefile.in

Status: REOPENED

(Toolkit :: Add-ons Manager, defect, P3)

Description

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

They're a mess.

Comment 1

[Nathan Froyd [:froydnj]]

I looked at this a little bit today.  I think the steps to take here are:

- rename all the addons to give them unique names
- install them as unpacked extensions in the appropriate test directories, which means we can use TEST_HARNESS_FILES

I don't know if folks will be unhappy that we are using unpacked extensions rather than proper .xpi files, though...maybe some of them could be kept as .xpi files, somehow?

Comment 2

[Nathan Froyd [:froydnj]]

Was thinking about this some more.  Would it be acceptable to either:

- install these as unpacked addons, per comment 1; or
- simply checkin the zipped-up files into the tree, and install those via TEST_HARNESS_FILES?  (I realize these are not quite as convenient to edit, but I doubt these addons really get touched that often...)

ni? Dave as somebody addon manager-related who might have an opinion.

Comment 3

[Dave Townsend [:mossop]]

(In reply to Nathan Froyd [:froydnj] [:nfroyd] from comment #2)
> Was thinking about this some more.  Would it be acceptable to either:
> 
> - install these as unpacked addons, per comment 1; or

No, in most of the cases we are testing the behaviour of installing an XPI so we need these as XPIs.

> - simply checkin the zipped-up files into the tree, and install those via
> TEST_HARNESS_FILES?  (I realize these are not quite as convenient to edit,
> but I doubt these addons really get touched that often...)

Maybe not often but they do get touched and being able to look at their source is important for understanding and working on automated tests.

What's the rationale behind needing to make a change to this that sounds like it will be yet another case of build config changes making it harder to work on the add-ons manager? I need something more than "They're a mess".

Comment 4

[Nathan Froyd [:froydnj]]

(In reply to Dave Townsend [:mossop] from comment #3)
> What's the rationale behind needing to make a change to this that sounds
> like it will be yet another case of build config changes making it harder to
> work on the add-ons manager? I need something more than "They're a mess".

The rationale is that the rules here:

http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/test/Makefile.in#11
http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/test/browser/Makefile.in#10

mean that we're building the XPIs for the testsuite on every build, even when the XPIs already exist in the test directory.  This extra building is just wasted work.  We'd like to do better than that.

Comment 5

[Dave Townsend [:mossop]]

(In reply to Nathan Froyd [:froydnj] [:nfroyd] from comment #4)
> (In reply to Dave Townsend [:mossop] from comment #3)
> > What's the rationale behind needing to make a change to this that sounds
> > like it will be yet another case of build config changes making it harder to
> > work on the add-ons manager? I need something more than "They're a mess".
> 
> The rationale is that the rules here:
> 
> http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/
> test/Makefile.in#11
> http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/
> test/browser/Makefile.in#10
> 
> mean that we're building the XPIs for the testsuite on every build, even
> when the XPIs already exist in the test directory.  This extra building is
> just wasted work.  We'd like to do better than that.

Can't we just use timestamps? If any of the files to go into the xpi are newer than the xpi then rebuild them.

Comment 6

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.