On 8/24/12 12:42 PM, Brian Smith wrote:
I do not think it is reasonable to require support for alternate build systems
for all of Gecko/Firefox.
But, let's say were were to divide the build into three phases:
1. Generate any generated C/C++ source files.
2. Build all the C/C++ code into libraries and executables
3. Do everything else (build omnijar, etc.)
(I imagine phase 3 could probably run 100% concurrently with the first two
phases).
It would be very nice if phase #2 ONLY could support msbuild (building with
Visual Studio project files, basically), because this would allow smart
editors'/IDEs' code completion and code navigation features to work very well,
at least for the C/C++ source code. I think this would also greatly simplify
the deployment of any static analysis tools that we would develop.
In addition, potentially it would allow Visual Studio's "Edit and Continue" feature to
work. ("Edit and Continue" is a feature that allows you to make changes to the C++ source
code and relink those changes into a running executable while execution is paused at a breakpoint,
without restarting the executable.)
I think that if you look at the limitations of gyp, some (all?) of them are at
least partially driven by the desire to provide such support. I am sure the
advanced features that you list in (4), (5), (6), (7) are helpful, but they may
make it difficult to support these secondary use cases.
That said, getting the build system to build as fast as it can is much more
important.
Agreed.
Changing how we define the build config would enable us to do everything
you mentioned and more. With the current "architecture" of our
Makefile's, we effectively have different build phases called tiers. See
[1] for more. As much as I would love to split things up into more
distinct phases/tiers, the overhead for recursive make traversal would
be prohibitive. As far as prioritizing work to enable basic Visual
Studio project generation, I'm all for that: my build-splendid branch
[2] had its roots in VS generation after all (if you go back far enough
in the history you can still see this)!
Once we treat the build system as a giant data structure, we are free to
transform that any way we want. We feed that data structure into a
generator and spit something out the other side. This is very similar to
GYP's model. Essentially what we are proposing is reinventing GYP, but
with a different frontend. It's entirely possible we will implement
things using GYP's APIs so we can reuse GYP's existing generators! Time
will tell.
[1] http://gregoryszorc.com/blog/2012/07/29/mozilla-build-system-overview/
[2] https://github.com/indygreg/mozilla-central/tree/build-splendid
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
