Change the invocations of make in the output directory Makefile and the
main Makefile for separate object trees to pass all goals to one $(MAKE)
via a new phony target "sub-make" and the existing target _all.
When compiling with separate object directories, a separate make is called
in the context of another directory (from the output directory the main
Makefile is called, the Makefile is then restarted with current directory
set to the object tree). Before this patch, when multiple make command
goals are specified, each target results in a separate make invocation.
With make -j, these invocations may run in parallel, resulting in multiple
commands running in the same directory clobbering each others results.
I did not try to address make -j for mixed dot-config and no-dot-config
targets. Because the order does matter, a solution was not obvious.
Perhaps a simple check for MAKEFLAGS having -j and refusing to run would
be appropriate.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Change the conditional of the outputmakefile rule to be evaluated entirely
in make, and add a conditional to not touch the generated makefile when e.g.
running 'make install' as root while the build was done as non-root. Also
adjust the comment describing this, and move the message printing and
redirection to mkmakefile.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
With the current way of generating the Makefile in the output directory
for builds outside of the source tree, specifying real targets (rather
than phony ones) doesn't work in an already (partially) built tree, as
the stub Makefile doesn't have any dependency information available.
Thus, all targets where files may actually exist must be listed
explicitly and, due to what I'd call a make misbehavior, directory
targets must then also be special cased.
Signed-Off-By: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Milton Miller