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>
While running "make menuconfig" and "make mrproper"
some people experienced that /dev/null suddenly changed
permissions or suddenly became a regular file.
The main reason was that /dev/null was used as output
to gcc in the check-lxdialog.sh script and gcc did
some strange things with the output file; in this
case /dev/null when it errorred out.
Following patch implements a suggestion
from Bryan O'Sullivan <bos@serpentine.com> to
use gcc -print-file-name=libxxx.so.
Also the Makefile is adjusted to not resolve value of
HOST_EXTRACFLAGS and HOST_LOADLIBES until they are actually used.
This prevents us from calling gcc when running make *clean/mrproper
Thanks to Eyal Lebedinsky <eyal@eyal.emu.id.au> and
Jean Delvare <khali@linux-fr.org> for the first error reports.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---
scripts/kconfig/lxdialog/check-lxdialog.sh uses gcc to check for
what libraries are present. Redirect output to /dev/null
so we do not generate an a.out.
Also included support for ncursesw - so if present prefer that
instead of ncurses.
The order is now (first is preferred):
1) ncursesw
2) ncurses
3) curses
The latter is to support SunOS.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cleaning up the lxdialog Makefile by factoring out the
ncurses compatibility checks.
This made the checks much more obvious and easier to extend.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
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!
Paul Smith