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.
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.
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.
See how a seemingly simple problem is, in fact, not.
I still think the solution is simple. :-)
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
