Closed Bug 511648 Opened 15 years ago Closed 11 years ago

kill Packager.pm

Categories

(Firefox Build System :: General, defect, P4)

defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: ted, Assigned: khuey)

Details

Attachments

(1 file, 1 obsolete file)

I don't like Perl, and I hate the way Packager.pm interacts with the rest of our packaging bits. Feels like it'd be easier to rewrite it than try to make it suck less.

We should write some unit tests for its current behavior, then write a new implementation in Python, then replace the old one. Then we can clean up and change behavior of the new implementation.
Also: it turns out to be full of hacks, which make dealing with it a huge pain.
khuey has probably 90% of a Python implementation in bug 231062.
Assignee: nobody → me
Status: NEW → ASSIGNED
Priority: -- → P4
Can we pull the trigger and remove @BINPATH@ from package manifests?  Is there a reason it's there?
It translates to a different path on OS X vs. other platforms:
http://mxr.mozilla.org/mozilla-central/source/browser/installer/Makefile.in#115

(It used to just be hardcoded as bin/, but I changed that in bug 511642)

Note that on OS X we do package a few things that aren't in @BINPATH@:
http://mxr.mozilla.org/mozilla-central/source/browser/installer/package-manifest.in#13

If you can come up with a cleaner solution I'm all ears, though.
Ah ok.  I have something that works on Linux and Windows, but tryserver doesn't seem to be running Mac builds at the moment so I can't test there :-(
Attached patch WIP (obsolete) — Splinter Review
This works on Linux and Windows, though the Python module doesn't get registered which hampers my efforts to use it in Bug 231062.  Not likely to get any farther on this till next weekend.
It looks to me like the xpinstall directory is not built at all in Firefox.  Is that true?
You're correct:
http://mxr.mozilla.org/mozilla-central/source/toolkit/toolkit-tiers.mk

Generally in the build system we haven't bothered with installing our Python modules as actual modules with distutils etc. We've got a few random things in build/ (like upload.py), a few things in config/ (like JarMaker.py), and if we need to get things into sys.path, we have a helper script called pythonpath.py. (For example: http://mxr.mozilla.org/mozilla-central/source/js/src/xpconnect/src/Makefile.in#200 )
I'd like to split the weird mac stuff into a separate manifest (maybe one that could live in toolkit, it looks the same on all apps).  Is that something you would be OK doing?  I know a while ago you did a lot of work to use just one manifest ...
toolkit manifest is in a bug assigned to :rs, but I don't remember the summary, something about "other apps are a PITA" :)
I'd be OK with the Mac bundle stuff not existing in the manifest. We can hardcode that somewhere else if need be, since it's not likely to change much (if at all), and will probably be there for all apps.
Attached patch WIPSplinter Review
This still explodes on Mac, but it produces correct intermediate directory trees on the other platforms and is closer to not exploding on Mac.
FYI to other c-c folks; Kyle has promised to do a c-c patch for this too though.
Note to self, I should finish this.
Hey look, I waited long enough, and somebody else did this.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: