package-compare: added chatzilla.manifest and venkman.manifest, after bug 521523 landing

NEW
Unassigned

Status

--
trivial
9 years ago
8 years ago

People

(Reporter: sgautherie, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
After bug 521523 landing, on "dep" builds but not 'nightly' ones,
we get new
{
make package-compare

+bin/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}/chrome/chatzilla.manifest

+bin/extensions/{f13b157f-b174-47e7-a34d-4815ddfdfeb8}/chrome/venkman.manifest
}

I wonder what is causing this: "--enable-tests"?

Comment 1

9 years ago
I saw this on all builds, be it locally or on Try, but could not find out what those files are being generated for, and therefore ignored them.
I don't believe tests have anything to do with this, it must be connected with chrome file generation stuff somehow.
Basically, I don't care about those files, and I advise you to ignore them just like the icons for other platforms. We have more important stuff to do than caring about files that are needlessly generated.
(Reporter)

Comment 2

9 years ago
(In reply to comment #1)

> I saw this on all builds

Ah, indeed: I was checking a nightly built before bug 521523 landed :-<

> could not find out what those files are being generated for

I'll want to check that (later).
Summary: package-compare: added chatzilla.manifest and venkman.manifest on dep builds → package-compare: added chatzilla.manifest and venkman.manifest, after bug 521523 landing
(Reporter)

Comment 3

9 years ago
(In reply to comment #2)
> > could not find out what those files are being generated for
> 
> I'll want to check that (later).

I'm not sure how exactly, but bug 521523 somehow added '--both-manifests' to
{
d:/mozilla-build/python25/python.exe /e/builds/slave/comm-central-trunk-win32-nightly/build/mozilla/config/JarMaker.py \
	   -j ../../../dist/xpi-stage/venkman/chrome \
	  -t /e/builds/slave/comm-central-trunk-win32-nightly/build/mozilla -f jar  -e --both-manifests -c /e/builds/slave/comm-central-trunk-win32-nightly/build/mozilla/extensions/venkman/locales/en-US [...]  \
	  /e/builds/slave/comm-central-trunk-win32-nightly/build/mozilla/extensions/venkman/locales/jar.mn
}

Which is documented as
{
http://mxr.mozilla.org/comm-central/source/mozilla/config/JarMaker.py#124

124     p.add_option('--both-manifests', action="store_true",
125                  dest="bothManifests",
126                  help="create chrome.manifest and jarfile.manifest")
}

Which was explained as
{
bug 458014 comment 0
Axel Hecht [:Pike]      2008-10-01 03:50:32 PDT

- libs target

Right now, we're running a libs phase for each target we repackage, in
particular because the langpacks need a different chrome manifest than the
installers/packages.

I'm adding support for writing out both manifests at once to JarMaker.py, and
refactor the Makefile to make all repack targets depend on the libs phase. That
way, we only run through libs once for all two or three targets of repackaging.
}

That said,
*I (clobber) built locally and it looks like the 2 new files were not created :-/
*I'm not sure if we should package these files or not.

Comment 4

9 years ago
http://mxr.mozilla.org/mozilla-central/source/toolkit/locales/l10n.mk is where we hook things together.

It sounds like you have BOTH_MANIFESTS on, no idea why, or if intentional.

Comment 5

9 years ago
(In reply to comment #3)
> *I'm not sure if we should package these files or not.

With that explanation, we should not. It might be just a bug in the build system of those extensions that they are turning this on for the main extension package.
(Reporter)

Comment 6

9 years ago
(In reply to comment #4)
> It sounds like you have BOTH_MANIFESTS on, no idea why, or if intentional.

This var was added (everywhere) by
http://hg.mozilla.org/comm-central/rev/dd85da276da7
bug 464921 - restructure comm-central's locales/Makefile.in files

http://mxr.mozilla.org/comm-central/search?string=BOTH_MANIFESTS&case=on
{
/suite/locales/Makefile.in
    * line 209 -- $(MAKE) -C ../../mozilla/extensions/irc/locales libs-$* BOTH_MANIFESTS=1; \
    * line 212 -- $(MAKE) -C ../../mozilla/extensions/venkman/locales libs-$* BOTH_MANIFESTS=1; \
}

Fwiw, while here,
*http://hg.mozilla.org/comm-central/rev/b9dd4c1ffd4d removed the beginning '@' on these 2 lines (only): not sure why or what that does...
*I also noted that these 2 lines are the only ones (with the /toolkit/locales one) not to have 'AB_CD=$* XPI_NAME=locale-$*': not sure why or what that does...

Comment 7

9 years ago
(In reply to comment #6)
> /suite/locales/Makefile.in
>     * line 209 -- $(MAKE) -C ../../mozilla/extensions/irc/locales libs-$*
> BOTH_MANIFESTS=1; \
>     * line 212 -- $(MAKE) -C ../../mozilla/extensions/venkman/locales libs-$*
> BOTH_MANIFESTS=1; \

How does any of those calls go into building the main .jar of the extension? Those should only do language pack stuff, I think.

> Fwiw, while here,
> *http://hg.mozilla.org/comm-central/rev/b9dd4c1ffd4d removed the beginning '@'
> on these 2 lines (only): not sure why or what that does...

Output control only, should not really matter, AFAIK.

> *I also noted that these 2 lines are the only ones (with the /toolkit/locales
> one) not to have 'AB_CD=$* XPI_NAME=locale-$*': not sure why or what that
> does...

The XPI_NAME would be wrong there, as we don't package those parts into the main SeaMonkey language pack but into separate extension language packs.
You need to log in before you can comment on or make changes to this bug.