kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-09-18 18:15:59 +00:00
Code Issues Releases Packages Activity
linux/scripts/mkmakefile

48 lines
1 KiB
Raw Normal View History

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
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-02 12:33:20 +02:00
kbuild: fix building with O=.. options 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-12-09 08:55:13 +01:00
kbuild: re-enable Makefile generation in a new O=... directory 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-11 13:22:08 +01:00
kbuild: fix building with O=.. options 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-12-09 08:55:13 +01:00
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-02 12:33:20 +02:00
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
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-11 09:09:00 +00:00
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
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-01-30 10:05:09 +01:00
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-09-21 18:09:02 -05:00
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
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-11 09:09:00 +00:00
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
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-01-30 10:05:09 +01:00
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
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-09-21 18:09:02 -05:00
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-11 09:09:00 +00:00
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