On 2014-08-27, 5:28 PM, Mike Hommey wrote:
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.
Well, you could just generate the proper Makefile in the subdirectory
dir, that only builds the sources beginning with "dir/", right? I was
just using ninja as an example because we started to talk about it in
the thread, but I don't think this is ninja specific.
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.
Sure.
> 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.
I don't know what the exact plans are as they have not been discussed in
any of the venues that I follow, but I was talking about a hypothetical
future with rainbows and unicorns. I don't actually know if we'll get
there within any short amount of time... :(
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)
Invoke the build rules for those files?
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
