Closed Bug 910781 Opened 7 years ago Closed 5 years ago

Use mozbuild to add files for packaging

Categories

(Firefox Build System :: General, defect)

x86_64
Windows 7
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla36

People

(Reporter: jcranmer, Assigned: jcranmer)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

One semi-common operation is to add files to $(DIST)/bin/{somewhere} that don't have any other semantic meaning. We can use install/purge manifests to handle this install. For example, see the branding makefiles.

As a bonus feature, we could figure out some way to make adding files in this fashion not require touching package-manifest.in files.

Bikeshedded proposal:

# Install a.rdf and b.rdf into $(DIST)/bin/isp
DISTRIBUTED_FILES.isp += ['a.rdf', 'b.rdf']
Depends on: 900526
There's not a lot of stuff floating about in mozilla-central that this could use (although, arguably, DIST_FILES could use--if we solve preprocessing issues). I haven't tested the xpi-stage side of things here, but the dist/bin uses a few browser files to see if it works.
Assignee: nobody → Pidgeot18
Status: NEW → ASSIGNED
Attachment #8340792 - Flags: feedback?(gps)
See Also: → 772828
Comment on attachment 8340792 [details] [diff] [review]
Add some support for GENERIC_FILES

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

This looks good!

Can we call it FINAL_TARGET_FILES instead?
Attachment #8340792 - Flags: feedback?(gps) → feedback+
Here's a rebased version of Joshua's patch.  If this turns out to be OK, I'll
post a second patch that adds as many uses of FINAL_TARGET_FILES as I can find.

Seems to build on x86-64 Linux, at least.
Attachment #8340792 - Attachment is obsolete: true
Attachment #8461026 - Flags: review?(gps)
Comment on attachment 8461026 [details] [diff] [review]
add support for FINAL_TARGET_FILES

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

Looks good.

Wearing my nit hat, tests would be nice. FINAL_TARGET can be fickle.

Please do a Try push before landing. FINAL_TARGET has some weird behavior in that it causes certain lazy-evaluated variables to be evaluated. The side-effects are often unexpected.

::: python/mozbuild/mozbuild/backend/recursivemake.py
@@ +1160,5 @@
> +            install_manifest = self._install_manifests['dist_bin']
> +            reltarget = mozpath.relpath(target, 'dist/bin')
> +        elif target.startswith('dist/xpi-stage'):
> +            install_manifest = self._install_manifests['dist_xpi-stage']
> +            reltarget = mozpath.relpath(target, 'dist/xpi-stage')

We need to watch out for xpi-stage files. Some Makefile do a recursive call into self with an XPI-related variable set. This funkiness can't be detected at moz.build time. Be very careful when converting these Makefile.in. I'd like to think the automation would fail if we get this wrong.

@@ +1162,5 @@
> +        elif target.startswith('dist/xpi-stage'):
> +            install_manifest = self._install_manifests['dist_xpi-stage']
> +            reltarget = mozpath.relpath(target, 'dist/xpi-stage')
> +        else:
> +            raise Exception("Cannot install to " + target)

Ideally this logic would live in emitter.py or data.py so it doesn't need to be duplicated across multiple backends. Fix it now or land and file a follow-up.
Attachment #8461026 - Flags: review?(gps) → review+
https://hg.mozilla.org/mozilla-central/rev/0944ccd05e57
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.