summaryrefslogtreecommitdiffstats
path: root/scripts/mkmakefile
AgeCommit message (Collapse)AuthorFilesLines
2008-12-03kbuild: teach mkmakfile to be silentSam Ravnborg1-1/+3
With this fix a "make -s" is now really silent Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2008-01-28kbuild: scripts/mkmakefile: dynamic determination of output directoryJan Beulich1-3/+7
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>
2007-12-13kbuild: re-enable Makefile generation in a new O=... directoryGuillaume Chazarain1-1/+1
The commit: 18c32dac75b187d1a4e858f3cfdf03e844129f5e "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-09kbuild: fix building with O=.. optionsSam Ravnborg1-0/+6
The check introduced in commit: 4f1127e204377cbd2a56d112d323466f668e8334 "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-10-12kbuild: call make once for all targets when O=.. is usedMilton Miller1-3/+5
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>
2006-05-08kbuild: Do not overwrite makefile as anohter userJan Beulich1-1/+4
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-02-19kbuild: fix mkmakefileJan Beulich1-3/+5
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>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+31
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!