973757 - Move toolkit/mozapps/extensions/*.idl to ./public/ directory

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Blair McBride [:Unfocused] (UNAVAILABLE)]

The IDL interfaces files in toolkit/mozapps/extensions/ are rarely touched. With bug 952307, the IDL files now dominate that directory - which is silly, and unnecessarily confusing for new contributors.

So let's just sweep them to a corner of the room where we can easily ignore them until that rare instance when we need to mess with them. Convention is to use a subdirectory named "public".

Comment 1

[Ganesh Sahukari]

i would like to work on this bug. Can you assign me the bug

Comment 2

[Ganesh Sahukari]

Attachment: bug-973757-fix.patch

Comment 3

[Dave Townsend [:mossop]]

Comment on attachment 8598142 [details] [diff] [review]
bug-973757-fix.patch

Review of attachment 8598142 [details] [diff] [review]:
-----------------------------------------------------------------

Handing over to a build config guy since I know they have things to say about adding new directories to the build.

Comment 4

[Gregory Szorc [:gps]]

Comment on attachment 8598142 [details] [diff] [review]
bug-973757-fix.patch

Review of attachment 8598142 [details] [diff] [review]:
-----------------------------------------------------------------

Did you `hg mv` these files? The raw patch says you didn't. It is important to preserve rename information.

::: toolkit/mozapps/extensions/moz.build
@@ -8,3 @@
>  TEST_DIRS += ['test']
>  
> -XPIDL_SOURCES += [

Before you add a new moz.build file, try prefixing XPIDL_SOURCES with "public/". I'm optimistic that will "just work."

Comment 5

[Ganesh Sahukari]

Attachment: bug-973757-fix-v2.patch

Used "hg mv" to move the idl files to public directory.
prefixed XPIDL_SOURCES with "public/" and it works fine

Comment 6

[:Paolo Amadini]

Ganesh, since you've already worked on a few patches by now, maybe you want to sign up for Tryserver (Level 1) commit access so you can start your own builds and accelerate the check-in process? Details are at <https://www.mozilla.org/en-US/about/governance/policies/commit/>.

It's still a complicated procedure so if you'd like to focus on fixing actual bugs instead, you're also welcome to do so. Me or other developers can push to try for you if you ask :-)

Comment 7

[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.