Gregory Szorc wrote:
> 4. Native support for list and maps. Make files only support strings.
> The hacks this results in are barely tolerable.
>
> 5. Ability to handle conditionals. We need to be able to
> conditionally define things based on the presence or value of certain
> "variables."
> e.g. "if the current OS is Linux, append this value to this list." I
> quote "variables" because there may not be a full-blown variable
> system here, just magic values that come from elsewhere and are
> addressed by some convention.
>
> 6. Ability to perform ancillary functionality, such as basic string
> transforms. I'm not sure exactly what would be needed here. Looking
> at make's built-in functions might be a good place to start. We may
> be able to work around this by shifting functionality to side-effects
> from specially named variables, function calls, etc. I really don't
> know.
>
> 7. Evaluation must be free from unknown side-effects. If there are
> unknown side-effects from evaluation, this could introduce race
> conditions, order dependency, etc. We don't want that. Evaluation
> must either be sandboxed to ensure nothing can happen or must be able
> to be statically analyzed by computers to ensure it doesn't do anything
> it isn't supposed to.
...
> On the other end of the spectrum, we could have the build manifest
> files be Python "scripts." This solves a lot of problems around
> needing functionality in the manifest files. But, it would be a
> potential foot gun. See requirement #7.
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.
Cheers,
Brian
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
