Sadly I didn't double-check all the ramifications of Bruce's patch in
quite enough detail and missed a side-effect. I think it would be
better to auto-detect everything at build-time as well as at run-time,
and this should make all of this stuff much less of a source of
tripping-over.
Ian.
# HG changeset patch
# User Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
# Date 1285067824 -3600
# Node ID c41252a55a0a0da08bfca98e65a7075f1af27ed0
# Parent 7167d6dd5c7c6597ca8e2ce416295b44fb1bcf65
tools, build system: Detect distro-variant directories at build-time
In b59f87f56b1e, the defaults for some of the directory config
variables implicitly changed. In this commit we arrange for the
defaults to be auto-detected (with the same logic as the run-time
scripts use).
This will make the build more likely to produce answers which the
builder intends. (And, in particular, it should un-break the
automated tests, which didn't set these variables explicitly and
therefore got broken by b59f87f56b1e.)
Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
diff -r 7167d6dd5c7c -r c41252a55a0a Config.mk
--- a/Config.mk Mon Sep 20 20:11:43 2010 +0100
+++ b/Config.mk Tue Sep 21 12:17:04 2010 +0100
@@ -31,11 +31,21 @@ MANDIR ?= $(SHAREDIR)/man
MANDIR ?= $(SHAREDIR)/man
BASH_COMPLETION_DIR ?= $(CONFIG_DIR)/bash_completion.d
-# These are the Red Hat settings.
+# arguments: variable, common path part, path to test, if yes, if no
+define setvar_dir
+ ifndef $(1)
+ ifneq (,$(wildcard $(2)$(3)))
+ $(1) ?= $(2)$(4)
+ else
+ $(1) ?= $(2)$(5)
+ endif
+ endif
+endef
+
# See distro_mapping.txt for other options
-CONFIG_LEAF_DIR ?= sysconfig
-SUBSYS_DIR ?= /var/run/subsys
-INITD_DIR ?= /etc/rc.d/init.d
+$(eval $(call setvar_dir,CONFIG_LEAF_DIR,,/etc/sysconfig,sysconfig,default))
+$(eval $(call setvar_dir,SUBSYS_DIR,/var/run,/subsys,/subsys,))
+$(eval $(call setvar_dir,INITD_DIR,/etc,/rc.d/init.d,/rc.d/init.d,/init.d))
ifneq ($(EXTRA_PREFIX),)
EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
diff -r 7167d6dd5c7c -r c41252a55a0a docs/misc/distro_mapping.txt
--- a/docs/misc/distro_mapping.txt Mon Sep 20 20:11:43 2010 +0100
+++ b/docs/misc/distro_mapping.txt Tue Sep 21 12:17:04 2010 +0100
@@ -2,26 +2,26 @@ other distros one needs to set the varia
other distros one needs to set the variables for the elements below
-----------------+------------------+---------------+----------------+
- | RedHat (default) | Debian | Suse |
+ | Red Hat | Debian | Suse |
-----------------+------------------+---------------+----------------+
CONFIG_LEAF_DIR | sysconfig | default | sysconfig |
SUBSYS_DIR | /var/run/subsys | /var/run | /var/run |
INITD_DIR | /etc/rc.d/init.d | /etc/init.d | /etc/init.d |
-----------------+------------------+---------------+----------------+
-The build currently defaults to the elements used by Red Hat.
-For others, these env variables must be set in the shell env
-or modified in Config.mk before running make.
+The existence of these directories are tested at build-time (on the
+build host, via the "setvar_dir" macro in Config.mk) and for some
+scripts at run-time. If the Red Hat directory exists, it is used;
+otherwise the Debian one is used.
-This mechanism sets the location that files are installed to, but does
-not change the code itself. Scripts that refer to files affected by these
-directories must check each possible location at run time.
+You can override this by setting the variables in the environment or
+your ".config" (which is included by .config).
To add support for new distributions that don't use the above locations,
one must grep for the above elements and add appropriate checks.
-For example if a new distro uses /etc/bork as it's config dir, It's not
-sufficient to set CONFIG_LEAF_DIR=bork, one must also add tests for the
+For example if a new distro uses /etc/bork as its config dir, it's not
+sufficient to set CONFIG_LEAF_DIR=bork; one must also add tests for the
existance of the bork dir in every context where config files are read.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|