On Tue, Mar 20, 2018 at 10:44 AM, Gregory Szorc wrote:
> moz.build files have a mechanism for associating metadata with files [1].
> We use the "with Files()" primitive [2] for:
>
> * Associating files with Bugzilla components
> * Defining how files impact certain CI components
>
> In the future,
I'll only add that moving this to a separate file set would have the
benefit of significantly simplifying the moz.build reading code, which is
quite complex and somewhat slow. I don't have a profile offhand that points
to Files() as a bottleneck, but it could become a concern if we were to
continue
I agree that the fit with moz.build files is awkward. Other issues
(besides those tom raised) include:
- two different methods of reading files can give different results
- the method of combining different `with Files` clauses, even in
different files, is not clear
- *very* deep Python magic u
On Tue, Mar 20, 2018 at 11:45 AM Gregory Szorc wrote:
> The CI scheduling primitives in there are arguably the domain of the build
> system and should continue to live in moz.build files. But we could have
> that discussion.
>
>From a code standpoint, the only place that appears to use this info
I pushed hard to ensure we had a mostly complete set of data in moz.build
files for BUGZILLA_COMPONENT. This is useful data for many things, the
primary tool is the intermittent bug filer which uses that data to file a
bug in the proper component for the failing test. This also gives us a
path to
moz.build files have a mechanism for associating metadata with files [1].
We use the "with Files()" primitive [2] for:
* Associating files with Bugzilla components
* Defining how files impact certain CI components
In the future, I fully anticipate us wanting to have a primitive that
allows us to
6 matches
Mail list logo
