<div dir="ltr"><div><div><div><div><div><div>I got an itch to clean up some of our themes' JAR manifests (eg bug 1204182), and noticed a tidbit in the docs that got me thinking about a more radical simplification...<br><br></div>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></div> skin/classic/browser/cats/whiskers.png (cats/whiskers.png)<br><br></div>The docs note that you can actually use wildcards, such that the above can be reduced to a single line:<br><br> skin/classic/browser/cats/ (cats/*.png)<br><br></div>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 cases adding files could be done without any manifest changes at all. The manifests are not adding a lot of innate value (other than a relative handful of cases where we rename files or use chrome overrides), and eliminating tedious boilerplate seems righteous.<br><br></div>The only potential downside I can think of is that vaguely recall a trend of wanting the build system to know exactly what files it's dealing with, a priori, without having to look at the filesystem. But I'm not sure if that's a still a concern, or if it matters in this case (ie, files that just get symlinked/copied, vs being compiled).<br><br></div>Justin<br><div><div><br></div></div></div>