AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-11-24 04:20:53 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
96678281bf
linux_dsm_epyc7002/scripts/mkmakefile

34 lines
648 B
Plaintext
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-17 05:20:36 +07:00
#!/bin/sh
# Generates a small Makefile used in the root of the output
# directory, to allow make to be started from there.
# The Makefile also allow for more convinient build of external modules
# Usage
# $1 - Kernel src directory
# $2 - Output directory
# $3 - version
# $4 - patchlevel
cat << EOF
# Automatically generated by $0: don't edit
VERSION = $3
PATCHLEVEL = $4
KERNELSRC := $1
KERNELOUTPUT := $2
MAKEFLAGS += --no-print-directory
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 16:05:09 +07:00
.PHONY: all \$(MAKECMDGOALS)
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-17 05:20:36 +07:00
all:
\$(MAKE) -C \$(KERNELSRC) O=\$(KERNELOUTPUT)
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 16:05:09 +07:00
Makefile:;
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-17 05: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 16:05:09 +07:00
\$(filter-out all Makefile,\$(MAKECMDGOALS)) %/:
\$(MAKE) -C \$(KERNELSRC) O=\$(KERNELOUTPUT) \$@
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-17 05:20:36 +07:00
EOF
Reference in New Issue Copy Permalink