On Wed, Aug 27, 2014 at 01:27:16PM -0400, Ehsan Akhgari wrote: > 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.
$developer changes a file in intl/uconv/ucvlatin/, He does mach build intl/uconv/ucvlatin... except that doesn't work, because the last moz.build is in intl/uconv (and we have many of those type of things, because some people apparently don't like having moz.build in every directory). Currently, mach build intl/uconv/ucvlatin would do make -C objdir intl/uconv ucvlatin, which would fail. Sure, we can get around this by saying that, if $dir is a directory in the source directory, and is has no moz.build, then do the equivalent of mach build $parentdir, where the same rule applies to $parentdir. But then, someone else will complain that they changed a file in intl/iconv/ucvlatin, ran mach build intl/iconv/ucvlatin, and had things build from intl/iconv/ucvibm. Or had things build in intl/iconv/tests. So, we could also filter the SOURCES to consider depending on the given subdirectory. And not recurse. And each build backend would need to handle this in its own way. But then, some people do want recursion. And then, what should be the semantics for non-compilation? See how a seemingly simple problem is, in fact, not. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
