<div dir="ltr"><div><div><div><div>My concerns with wildcards are as follows:<br><br></div>1) Performance. Iterating directories and doing pattern matching on results is more expensive than calling stat() on single files. You likely won't notice on Linux and OS X. Windows is where this will bite us.<br></div>2) Inadvertent usage of files not under version control. Wildcards will pick up files on the file system that aren't under version control. If said files are ignored by your VCS, we could find ourselves using files left over from a previous build. This will inevitably result in a handful of busted Try pushes and landings due to people forgetting to add files.<br></div><div>3) Complexity. From the perspective of tools, you have to teach things to speak in terms of wildcards and not merely simple paths. We've already done this in several places, so I think this is a minor concern.<br></div><div><br></div>The upside is wildcards are much easier to maintain. Trade-offs.<br><br></div>I say experiment with wildcards. If the downsides are too great, we can always switch back to individual files later.<br><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 12, 2015 at 1:40 AM, Mike Hommey <span dir="ltr"><<a href="mailto:mh@glandium.org" target="_blank">mh@glandium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There are diverging opinions about explicit file naming in the build<br>
system. I, personally, am very much in favor of more wildcards when they<br>
make sense. The proposal from this thread makes sense to me.<br>
<br>
Maybe Greg has something to say, since he's the main proponent for<br>
explicit file naming.<br>
<br>
Mike<br>
<br>
PS: Please be aware, though, that wildcards currently don't work well<br>
with localized content yet (where the part between the parens contains a<br>
% character). I have a patch for that that I'll attach to a bug next<br>
week.<br>
<div class="HOEnZb"><div class="h5"><br>
On Sat, Sep 12, 2015 at 09:22:27AM +0100, Gijs Kruitbosch wrote:<br>
> Sounds good to me. We might want to move some things so folders map more<br>
> exactly, too. Maybe Mike can comment on build system implications?<br>
><br>
> Gijs<br>
> On Sep 12, 2015 4:52 AM, "Justin Dolske" <<a href="mailto:dolske@mozilla.com">dolske@mozilla.com</a>> wrote:<br>
><br>
> > I got an itch to clean up some of our themes' JAR manifests (eg bug<br>
> > 1204182), and noticed a tidbit in the docs that got me thinking about a<br>
> > more radical simplification...<br>
> ><br>
> > Right now we have LOTS of boilerplate like:<br>
> ><br>
> >  skin/classic/browser/cats/earskritch.png (cats/earskritch.png)<br>
> >  skin/classic/browser/cats/fluffy.png (cats/fluffy.png)<br>
> >  skin/classic/browser/cats/noseboop.png (cats/noseboop.png)<br>
> >  skin/classic/browser/cats/puddypaw.png (cats/puddypaw.png)<br>
> >  skin/classic/browser/cats/whiskers.png (cats/whiskers.png)<br>
> ><br>
> > The docs note that you can actually use wildcards, such that the above can<br>
> > be reduced to a single line:<br>
> ><br>
> >  skin/classic/browser/cats/ (cats/*.png)<br>
> ><br>
> > Is there any major reason not to start using this?<br>
> ><br>
> > It would eliminate huge swaths of our manifests, and mean that in most<br>
> > cases adding files could be done without any manifest changes at all. The<br>
> > manifests are not adding a lot of innate value (other than a relative<br>
> > handful of cases where we rename files or use chrome overrides), and<br>
> > eliminating tedious boilerplate seems righteous.<br>
> ><br>
> > The only potential downside I can think of is that vaguely recall a trend<br>
> > of wanting the build system to know exactly what files it's dealing with, a<br>
> > priori, without having to look at the filesystem. But I'm not sure if<br>
> > that's a still a concern, or if it matters in this case (ie, files that<br>
> > just get symlinked/copied, vs being compiled).<br>
> ><br>
> > Justin<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > firefox-dev mailing list<br>
> > <a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
> > <a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
> ><br>
> ><br>
<br>
> _______________________________________________ firefox-dev mailing<br>
> list <a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a><br>
> <a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/firefox-dev</a><br>
<br>
</div></div></blockquote></div><br></div>