1
Commit Graph

7 Commits

Author SHA1 Message Date
Jan Beulich
1d3b3bfab1 kbuild: scripts/mkmakefile: dynamic determination of output directory
Rather than fixing the output directory in the generated Makefile,
determine it from the placement of Makefile. This allows moving
the build tree around or accessing it through different mount paths.

(The lastword definition is a compatibility one for make prior to 3.81;
newer make will simply ignore it and use the [faster] built-in.)

Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2008-01-28 23:14:38 +01:00
Guillaume Chazarain
971edcfc8b kbuild: re-enable Makefile generation in a new O=... directory
The commit:
18c32dac75 "kbuild: fix
building with O=.. options"
disabled the creation of a Makefile in a new O=... directory. Restore it.

Signed-off-by: Guillaume Chazarain <guichaz@yahoo.fr>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2007-12-13 19:19:20 +01:00
Sam Ravnborg
18c32dac75 kbuild: fix building with O=.. options
The check introduced in commit:
4f1127e204 "kbuild: fix
infinite make recursion"

caused certain external modules not to build and
also caused 'make targz-pkg' to fail.
This is a minimal fix so we revert to previous
behaviour - but we do not overwrite the Makefile
in the top-level directory.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Tested-by: Jay Cliburn <jacliburn@bellsouth.net>
Cc: Jay Cliburn <jacliburn@bellsouth.net>
2007-12-09 08:55:13 +01:00
Milton Miller
0b35786d77 kbuild: call make once for all targets when O=.. is used
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>
2007-10-12 21:20:32 +02:00
Jan Beulich
fd5f0cd6b0 kbuild: Do not overwrite makefile as anohter user
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>
2006-05-08 06:55:32 +02:00
Jan Beulich
96678281bf kbuild: fix mkmakefile
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>
2006-02-19 09:51:21 +01:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00