On Wed, Aug 27, 2014 at 05:03:21PM -0400, Ehsan Akhgari wrote: > On 2014-08-27, 4:54 PM, Mike Hommey wrote: > >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). > > That's fair. We can fix that by looking at the contents of SOURCES and take > the directories included in the SOURCES entries into account when building > the target names.
Well, that works because you're only considering an hypothetical ninja -t dir case. And I'm considering today's make -C objdir/dir case, which is quite different (or cd objdir/dir; make, which apparently people do, too). As much as you'd like ninja to be used, it's not going to be used for everything any time soon (see below). At best, it could be used for compilation soonish, but then that makes mach build dir even more complex with some things done with ninja and others with make. > >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. > > We wouldn't need this special handling if we did the above. > > >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. > > That won't happen if we nest the ninja targets properly (by properly, I > mean, nest them in the same manner as the files and directories are nested.) > > >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. > > Well, sure, each build backend will need to do all of these separately by > definition. But how many build backends are we looking to have? I always > imagined the answer to be 1. Well, I'm afraid the answer can't be 1 if it's going to be ninja. At least not until the last Makefile.in dies. And even then, we still have third party code built with make, so you'd still be requiring two tools for people to build, until we get rid of the third-party build systems. And even then, we'll want to have several anyways, at the very least to experiment things. > >But then, some people do want recursion. > > Again ninja will take care of that if we nest the targets properly. > > >And then, what should be the semantics for non-compilation? > > I don't understand this question. What is mach build dir supposed to mean when dir points somewhere containing xul/js/whatever-non-C++ code? (hint: people like what dumbmake does for this usecase, so that adds one more to sfink's list) Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
