1227892 - Change how binary xpcom components manifests are created

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Mike Hommey [:glandium]]

The FasterMake backend doesn't handle them at all for the moment, and the RecursiveMake backend relies on rules that only exist without --disable-compile-environment.

Comment 1

[Mike Hommey [:glandium]]

Attachment: Add a NO_COMPONENTS_MANIFEST moz.build variable

The variable is used by Lightning in comm-central and influences
binary-component manifest creation.

Comment 2

[Mike Hommey [:glandium]]

Attachment: Move NO_COMPONENTS_MANIFEST to moz.build in c-c

Comment 3

[Mike Hommey [:glandium]]

Attachment: Emit a specialized object for chrome.manifest entries

This new ChromeManifestEntry object type is generic and can hold any kind of
chrome manifest entry, but we currently only emit them for binary components.

References to sub-directory manifests is left to the backend, for now, until
all manifest entries are emitted by the frontend.

Comment 4

[Mike Hommey [:glandium]]

Attachment: Add basic tests for IS_COMPONENT/NO_COMPONENTS_MANIFEST

Comment 5

[Mike Hommey [:glandium]]

Attachment: Emit a specialized object for chrome.manifest entries

Initially, I had a separate patch for FasterMake, but at the moment I was going to attach it, I figured it made no sense to separate it considering its size, so I folded it with this one.

Comment 6

[Mike Hommey [:glandium]]

Comment on attachment 8692409 [details] [diff] [review]
Add basic tests for IS_COMPONENT/NO_COMPONENTS_MANIFEST

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

::: python/mozbuild/mozbuild/test/frontend/test_emitter.py
@@ +938,5 @@
> +        self.assertEqual(objs[0].entry.relpath, objs[1].lib_name)
> +        self.assertIsInstance(objs[1], SharedLibrary)
> +        self.assertEqual(objs[1].basename, 'foo')
> +        self.assertIsInstance(objs[2], SharedLibrary)
> +        self.assertEqual(objs[1].basename, 'bar')

typo: objs[2]

Comment 7

[Mike Hommey [:glandium]]

Attachment: Emit a specialized object for chrome.manifest entries

With a fixup.

Comment 8

[Gregory Szorc [:gps]]

Comment on attachment 8692409 [details] [diff] [review]
Add basic tests for IS_COMPONENT/NO_COMPONENTS_MANIFEST

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

Thank you for adding tests.

Comment 9

[Gregory Szorc [:gps]]

Comment on attachment 8692948 [details] [diff] [review]
Emit a specialized object for chrome.manifest entries

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

::: python/mozbuild/mozbuild/backend/recursivemake.py
@@ +1406,5 @@
> +                make_quote(shell_quote('manifest %s' %
> +                                       mozpath.relpath(obj.path,
> +                                                       obj.install_target))),
> +            ]
> +            rule.add_commands(['$(call py_action,buildlist,%s)' %

It seems like we're a few steps away from writing out fragments of the final file directly instead of having to rely on buildlist. Too much scope bloat for this series?

Comment 10

[Mike Hommey [:glandium]]

(In reply to Gregory Szorc [:gps] from comment #9)
> Comment on attachment 8692948 [details] [diff] [review]
> Emit a specialized object for chrome.manifest entries
> 
> Review of attachment 8692948 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: python/mozbuild/mozbuild/backend/recursivemake.py
> @@ +1406,5 @@
> > +                make_quote(shell_quote('manifest %s' %
> > +                                       mozpath.relpath(obj.path,
> > +                                                       obj.install_target))),
> > +            ]
> > +            rule.add_commands(['$(call py_action,buildlist,%s)' %
> 
> It seems like we're a few steps away from writing out fragments of the final
> file directly instead of having to rely on buildlist. Too much scope bloat
> for this series?

We can only partially write those out, as there's part of their data in jar manifests, and as much as I'd like jar manifests to be handled in the frontend (as written in a comment in fastermake.py), it's opening a large can of worms considering the impact on l10n and XPI_NAME-related stuff.

Those files *can* now be written completely from fastermake.py, now, but we don't have anything generic yet besides buildlist to create files with given generated contents. I'm considering adding an install manifest type for that. But yeah, that's out of scope.

Comment 11

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2a2355e3d100
https://hg.mozilla.org/integration/mozilla-inbound/rev/8421887c8042
https://hg.mozilla.org/integration/mozilla-inbound/rev/573992ac6b3d

Comment 12

[Mike Hommey [:glandium]]

https://hg.mozilla.org/comm-central/rev/ba38177b5aa3

Comment 13

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/2a2355e3d100
https://hg.mozilla.org/mozilla-central/rev/8421887c8042
https://hg.mozilla.org/mozilla-central/rev/573992ac6b3d