On Wed, Sep 04, 2013 at 10:28:21AM +0100, L. David Baron wrote: > On Wednesday 2013-09-04 00:31 -0700, Gregory Szorc wrote: > > Assuming it sticks, bug 896797 just landed in inbound and changes > > how EXPORTS/headers are installed. This may impact your developer > > workflow if you modify EXPORTS in a moz.build file to add/remove > > headers. > > > > Previously, headers were installed incrementally as part of make > > directory traversal. In the new world, we write out a "manifest" of > > headers when the build config is read from moz.build files and then > > we install them in bulk at the top of the build. > > Does this undo the protection that the build tiers were designed > for, which is to prevent "backwards" dependencies between parts of > the build? (In other words, things like preventing XPCOM from > depending on headers in layout, so that XPCOM could be used > standalone.) > > Do we still care about ensuring this? If so, should we have some > other mechanism (like having standalone builds and showing them on > tbpl)?
The way the tier build works is that we effectively make export in all directories of a same tier before make libs. In practice, this means xpcom had access to every header in platform already, and any tier built before platform, for that matter. So only app headers weren't available to xpcom, and that's not a lot of them. So, really, nothing was already there to prevent backwards dependencies. At least not in a very long time (I don't remember if we ever did (make export; make libs) recursively directory by directory instead of tier by tier.) Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
