Commit Graph

8 Commits

Author SHA1 Message Date
Michal Marek ef8ff89b58 kbuild: Really don't clean bounds.h and asm-offsets.h
Commit 7d3cc8b tried to keep bounds.h and asm-offsets.h during make
clean by filtering these out of $(clean-files), but they are listed in
$(targets) and $(always) and thus removed automatically. Introduce a new
$(no-clean-files) variable to really skip such files in Makefile.clean.

Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-03-11 11:15:22 +01:00
Robert P. J. Day 3156fd0529 kbuild: fix some minor typoes
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2008-04-25 20:18:48 +02:00
Sam Ravnborg 836caba77c kbuild: kill backward compatibility checks
These checks has been present for several kernel releases (> 5).
So lets just get rid of them.
With this we no longer check for use of:
EXTRA_TARGETS, O_TARGET, L_TARGET, list-multi, export-objs

There were three remaining in-tree users of O_TARGET in some
unmaintained sh64 code - mail sent to the maintainer + list.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2007-10-12 21:20:32 +02:00
Paul Smith 4f1933620f kbuild: change kbuild to not rely on incorrect GNU make behavior
The kbuild system takes advantage of an incorrect behavior in GNU make.
Once this behavior is fixed, all files in the kernel rebuild every time,
even if nothing has changed.  This patch ensures kbuild works with both
the incorrect and correct behaviors of GNU make.

For more details on the incorrect behavior, see:

http://lists.gnu.org/archive/html/bug-make/2006-03/msg00003.html

Changes in this patch:
  - Keep all targets that are to be marked .PHONY in a variable, PHONY.
  - Add .PHONY: $(PHONY) to mark them properly.
  - Remove any $(PHONY) files from the $? list when determining whether
    targets are up-to-date or not.

Signed-off-by: Paul Smith <psmith@gnu.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2006-03-06 00:09:51 +01:00
Sam Ravnborg db8c1a7b2c kbuild: fix building external modules
kbuild failed to locate Makefile for external modules.
This brought to my attention how the variables for directories
have different values in different usage scenarios.

Different kbuild usage scenarios:
make       - plain make in same directory where kernel source lives
make O=    - kbuild is told to store output files in another directory
make M=    - building an external module
make O= M= - building an external module with kernel output seperate from src

Value assigned to the different variables:

           |$(src)          |$(obj) |$(srctree)        |$(objtree)
make       |reldir to k src |as src |abs path to k src |abs path to k src
make O=    |reldir to k src |as src |abs path to k src |abs path to output dir
make M=    |abs path to src |as src |abs path to k src |abs path to k src
make O= M= |abs path to src |as src |abs path to k src |abs path to k output

path to kbuild file:

make       | $(srctree)/$(src), $(src)
make O=    | $(srctree)/$(src)
make M=    | $(src)
make O= M= | $(src)

From the table above it can be seen that the only good way to find the
home directory of the kbuild file is to locate the one of the two variants
that is an absolute path. If $(src) is an absolute path (starts with /)
then use it, otherwise prefix $(src) with $(srctree).

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2005-07-27 22:11:01 +02:00
Sam Ravnborg 2315c6e422 kbuild: define clean before including kbuild file
Defining clean before including the kbuild file give us knowledge when
the kbuild file is included for cleaning. This is rarey usefull - but in
a corner case in klibc this proved necessary.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---
2005-07-25 22:41:12 +00:00
Sam Ravnborg 2a69147034 kbuild: fix make O=...
kbuild failed to locate Kbuild.include.
Teach kbuild how to find Kbuild files when using make O=...

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---
2005-07-25 20:26:04 +00: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