Closed Bug 1051642 Opened 10 years ago Closed 2 years ago

Allow for flat chrome format when packaging extensions

Categories

(Firefox Build System :: General, defect)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: iannbugzilla, Assigned: iannbugzilla)

References

Details

Attachments

(1 file)

What used to happen was that extensions were built into dist/bin/extensions and then in omnijar builds suite/app/Makefile.in would zip them up into XPIs into dist/bin/extensions or dist/bin/distribution/extensions as appropriate, but if you used --enable-chrome-format=flat then the extensions would remain flat in dist/bin/extensions so that you could easily develop them. Is there any way we can maintain this developer option?
Attachment #8470570 - Flags: review?(mh+mozilla)
You're not specifying what the actual problem is. Is it that with --enable-chrome-format=flat, extensions are still XPIs in dist/bin/distribution/extensions, or is it that they are flat in dist/bin/distribution/extensions, but don't work?
Flags: needinfo?(iann_bugzilla)
My understanding of the issue is that currently, with --enable-chrome-format=flat, add-ons get put into dist/bin/distribution/extensions which means it is more difficult for developers to test changes to their add-ons. For users, it is the correct location though. The fact that SeaMonkey, without --enable-chrome-format=flat, packages add-ons into XPIs is probably not relevant. The issue was originally mentioned over in Bug 1047924 comment 4 by Neil.
Flags: needinfo?(iann_bugzilla)
Why is testing changes to addons more difficult when they are in dist/bin/distribution/extensions instead of dist/bin/extensions?
Flags: needinfo?(iann_bugzilla)
(In reply to Mike Hommey from comment #3) > Why is testing changes to addons more difficult when they are in > dist/bin/distribution/extensions instead of dist/bin/extensions? Addons are only distributed from distribution, so you have to delete it from the profile, then reinstall it, then restart again, then test it. With flat chrome on Linux, you just have to edit the source file and away you go.
Flags: needinfo?(iann_bugzilla)
So, why exactly does seamonkey want venkman, etc. in distribution/ at all?
(In reply to Mike Hommey [:glandium] from comment #5) > So, why exactly does seamonkey want venkman, etc. in distribution/ at all? So when a new user, rather than developer, starts SeaMonkey the add-on gets copied to their profile.
(In reply to Ian Neal from comment #6) > (In reply to Mike Hommey [:glandium] from comment #5) > > So, why exactly does seamonkey want venkman, etc. in distribution/ at all? > > So when a new user, rather than developer, starts SeaMonkey the add-on gets > copied to their profile. And why exactly would you want that?
To quote from Callek. SeaMonkey wants to copy add-ons (from dist/bin/distribution/extensions) specifically because our add-ons have out-of-band install from AMO In order to allow AMO update we need it there, otherwise AMO won't be queried or used to install an update Additionally if we bump the version in dist/bin/distribution/extensions the app will recognize that @profile@ has an older version and install the newer one for the user, *when the major app ver bumps as well*
Comment on attachment 8470570 [details] [diff] [review] Check if flat chrome format before setting location Review of attachment 8470570 [details] [diff] [review]: ----------------------------------------------------------------- ::: config/rules.mk @@ +1356,5 @@ > ifndef XPI_NAME > $(error XPI_NAME must be set for INSTALL_EXTENSION_ID) > endif > > +ifdef MOZ_OMNIJAR Make that depend on DEVELOPER_OPTIONS instead.
Attachment #8470570 - Flags: review?(mh+mozilla) → review-
Product: Core → Firefox Build System
Severity: normal → S3

As this is now done differently in SeaMonkey, no longer required.

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: