On 2014-08-27, 10:55 AM, Gregory Szorc wrote:
On 8/27/2014 7:39 AM, Benjamin Smedberg wrote:
On 8/27/14, 10:22 AM, Gregory Szorc wrote:
There is additional cognitive load required to map a logical feature
into a set of directories. I would prefer this burden go away, as it
only breeds confusion and a higher barrier to contributing (new
contributors don't know these shortcuts so they sit through painfully
long full builds).
I don't understand. I didn't pick these directories because there was
any concept of a logical feature: I picked those because those were the
files that I edited. That seems like the least-posssible cognitive load
in general.
The least-possible cognitive load is |mach build|. If that were near
instantaneous, we wouldn't be having this discussion.
Sure. But more to Benjamin's point, there is no conceptual modules in
any useful way in our code base. All we have are files and directories,
and that is the most useful mental model that people have when they're
working on something (because they have just edited a file. Who can say
what "module" content/html/document/src/VideoDocument.cpp belongs to?!
Is it content? dom? html?
Also, for the JS-centric use case you mentioned, if we invested in those
parts of the build system, we could probably get full tree builds with
no binary changes to under 10s. e.g. |mach build nonbinaries|.
Sure. But since we don't have that yet, let's make sure that thing we
did have keeps working? Is returning to the prior behavior by making
`mach build dir` recursive a complex fix?
The context that may be missing here is that the build system no longer
does directory traversal like it once did.
It still does that when finding the moz.build files, right? How about
doing something extremely simple such as: when you encounter a moz.build
file, record its path, build a ninja target for the path, and when you
found any SOURCES/UNIFIED_SOURCES/otherThingsWhichTriggerBuildActions
just add them under that ninja target. And if you have a ninja target
called foo/bar, put that under the ninja target foo.
I believe that is all we need to do here. No need for a moz.build
variable, no need to recurse directories more than we already do, and it
will support the exact same functionality of ./mach build subdir.
> At moz.build evaluation time,
we essentially build a DAG of all the binaries and construct directory
traversal rules from that: actual directory structure conceptually has
very little to do with things. In reality, the order on the filesystem
matches the derived dependencies because that's how things always
worked. But this won't always hold! Viewing the build as an iteration of
directories in their filesystem layout is antiquated and this practice
needs to further go away to make the build faster.
It will be ninja who will determine in what other build actions are
executed, so I think this doesn't matter here. Ninja will happily
choose the order either for top level builds or a target build.
Again, I want to provide something. But making it purely derived on
directory layout is artificially constricting to making the build
faster. It ties us to the old world and prevents us from moving forward.
I don't think my proposal above has any of those side effects. And I
think it's simple which is why I like it.
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
