Closed Bug 910781 Opened 7 years ago Closed 5 years ago

Use mozbuild to add files for packaging


(Firefox Build System :: General, defect)

Windows 7
Not set


(Not tracked)



(Reporter: jcranmer, Assigned: jcranmer)


(Blocks 1 open bug)



(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 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
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/
@@ +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 time. Be very careful when converting these 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 or 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+
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.