On 10/18/2015 10:17 PM, Bobby Holley wrote:
On Sun, Oct 18, 2015 at 8:37 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
On 10/18/15 7:14 PM, Nicholas Nethercote wrote:
Eventually |mach build| should just do the right
thing, no matter what files you've touched...
The problem is that definitions of "right thing" differ depending on the
goal, right?
Exactly. It's not clear to me that even the perfect build system would
solve this problem (unless it were perfectly fast, in which case I don't
care about any of this). The C++ compilation model requires that we rebuild
everything that #includes a header file that changed, which can take a long
time, so I use my wetware capabilities to short-circuit that heavy rebuild
when I know it isn't needed.
I know this may void my warranty in general, but (as Jonas points out) the
only thing I really care about is making sure that the stuff I rebuilt gets
linked, which IMO is something the build system should be able to
guarantee. This may be simpler than it used to be now that (most?)
everything is linked into libxul, but I think there are still various
corner cases in the tree (correct me if I'm wrong).
If I were to sketch out a "principled" version of this functionality, I
think it would look something like having different views of shared
files when rebuilding. So when you change someCommonHeader.h and request
a minimal inconsistent rebuild of dom/base, all of the dependency logic
for files within dom/base would see (the timestamp of) the new file,
while all source files within dom/base would see the old version. More
generally, you'd want to define an arbitrary subset of directories that
see the new file.
You could even do exactly that with filesystem namespaces, completely in
userspace in linux 3.8+, but if I understand the current build system
architecture properly, that would mean modifying all the backends to
understand these contortions.
Would it be possible to make a |./mach frankenbuild dom/base| that
copied all of the dom/base headers into frankendist/include/, leaving
the existing headers in dist/include/, and make the dependency files
within dom/base (and the rest of the please-rebuild subset) refer to
files from frankendist? And of course, the include path for the actual
compile commands would have to put frankendist/include before
dist/include in the include search order (for the subset to rebuild).
When you did a regular build, it would then have to rebuild everything
that was using frankendist, of course, but that would happen automatically.
I may just not understand the full scope of the problem, but it seems
like handing the backend a fully correct description of the dependencies
you want and letting it Do The Right Thing (as in, rebuild everything
whose dependencies have changed full stop) has got to be better than
hardcoding in metarules about specific directories.
Or maybe the problem is that you're touching stuff in dom/base and you
only want things in dom/bindings to see your changes? So it should be
more like |./mach frankebuild --modified 'dom/base/**.h' dom/bindings|?
Same basic solution.
Or maybe I should keep my mouth shut until I know what the actual
problem is.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
