Nathan Froyd [:froydnj] Reporter
	Description • 9 years ago

I think this might have come up as a complaint when we moved EXTRA_JS_MODULES to moz.build in bug 880245, but it's come up again today, and seems like a reasonable request: folks don't want to list out a bunch of .js files, especially when lots of small JavaScript modules are common.

Once we move EXTRA_JS_MODULES to manifests, this should be very straightforward to support.  (And we could probably ditch the mach command we added for the addon-sdk, etc.)

	James Long (:jlongster)
	Comment 1 • 9 years ago

For what it's worth, this would allow the devtools code to be a lot more modular. Right now it's discouraging to make things too modular because of having to track individual files in the build system.

	Gregory Szorc [:gps]
	Comment 2 • 9 years ago

I am somewhat fundamentally opposed to globbing because it means we have to perform additional I/O when processing moz.build files. This can slow down execution, especially on Windows. I would strongly prefer to avoid globbing, if possible.

	Mike Hommey [:glandium]
	Comment 3 • 9 years ago

Oh come on, that's I/O we do anyways because we verify all the files listed exist.

	Mike Hommey [:glandium]
	Comment 4 • 9 years ago

That said, I'd rather have a FileFinder-like interface exposed to moz.build.

	Gregory Szorc [:gps]
	Comment 5 • 9 years ago

I forgot we check file existence. We do that so inconsistently. It should probably be enforced at the moz.build context layer instead of emitter, where it is commonly done today.

I also like the idea of a FileFinder-like interface. I'll go a step further and say that it would be cool if it emitted rich file instances that already contained their stat result and could do things like read and cache file content. That would likely cut down on a lot of redundant I/O. Perhaps this is implied by a "FileFinder-like interface?"