Closed Bug 781311 Opened 9 years ago Closed 8 years ago

Install xpcshell test files via manifests


(Firefox Build System :: General, defect)

Not set


(Not tracked)



(Reporter: gps, Assigned: gps)



(Whiteboard: [buildfaster:?])


(1 file)

The current rule for installing xpcshell tests always executes and prevents no-op builds. Ideally, xpcshell test files will only be installed if the source files change.

Additionally, we are relying on $(wildcard) to find xpcshell test files.

A proper solution probably involves integrating xpcshell.ini parsing to produce a dependency file or something. I would certainly consider replacing XPCSHELL_TESTS with XPCSHELL_MANIFESTS (a variable that defines paths to xpcshell.ini files).
This is probably tricky to do right. Currently the xpcshell manifest bits are just layered on top of the crappy "install the directory of tests" stuff.
Since this bug was filed, we now have support for install manifests and should use them for managing installing xpcshell test files into the _tests directory.

We still have a problem with file wildcards. We can either teach install manifests how to find source files (presumably via a FileFinder matching syntax). Or, we could attempt to account for all test files via xpcshell.ini manifests. I'm a fan of the former as it is more verbose and should cut down on directory scanning, which can be slow.
Summary: Proper xpcshell test install rule → Install xpcshell test files via manifests
This patch moves xpcshell test file installation into an install
manifest. The patch can't be committed as-is because dependencies are
broken. If a file is added or deleted the manifest won't get updated
until config.status runs. config.status is executed based on
dependencies. This is why I would prefer having all files referenced

Alternatively, we could perform the directory scanning at the top of the
build, every build. I'm not a huge fan of this either. But it's similar
to what we do now. The big difference is we perform a single scan
instead of doing it incrementally as part of recursive traversal. If we
do things right, we could probably have this scanning performed
concurrently with other build steps.

This patch shouldn't get checked in as-is because it lacks tests.

Just figured I'd post what I have in case others have comments.
Assignee: nobody → gps
Depends on: 900569
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 901990
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.