tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB
PATCH 1/1 tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB
# HG changeset patch
# User Roger Pau Monne <[email protected]>
# Date 1318512213 -7200
# Node ID 8fe2ca552de44aa679be3184b1f98f50a00507e2
# Parent 8d316acde60f93cc8563a3c18950e9cbc3ab7fa8tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB
Parse EXTRA_INCLUDES and EXTRA_LIB during checks, to search for required files.
tools/check/Makefile +2 -2
@@ -7,12 +7,12 @@ all install: check-build # Check this machine is OK for building on. .PHONY: check-build check-build: - PYTHON=$(PYTHON) LIBXENAPI_BINDINGS=$(LIBXENAPI_BINDINGS) ./chk build + PYTHON=$(PYTHON) LIBXENAPI_BINDINGS=$(LIBXENAPI_BINDINGS) EXTRA_INCLUDES=$(EXTRA_INCLUDES) EXTRA_LIB=$(EXTRA_LIB) ./chk build # Check this machine is OK for installing on. .PHONY: check-install check-install: - PYTHON=$(PYTHON) LIBXENAPI_BINDINGS=$(LIBXENAPI_BINDINGS) ./chk install + PYTHON=$(PYTHON) LIBXENAPI_BINDINGS=$(LIBXENAPI_BINDINGS) EXTRA_INCLUDES=$(EXTRA_INCLUDES) EXTRA_LIB=$(EXTRA_LIB) ./chk install .PHONY: clean clean:
tools/check/funcs.sh +23 -7
@@ -25,15 +25,23 @@ has_or_fail() { } has_header() { + check_sys_root || return 1 + case $1 in /*) ;; - *) set -- "/usr/include/$1" ;; + *) + if [ -r "$CROSS_SYS_ROOT/usr/include/$1" ]; then + return 0 + fi + for path in ${EXTRA_INCLUDES}; do + if [ -r "$CROSS_SYS_ROOT${path}/$1" ]; then + return 0 + fi + done + ;; esac - check_sys_root || return 1 - - test -r "$CROSS_SYS_ROOT$1" - return $? + return 1 } has_lib() {
@@ -42,6 +50,7 @@ has_lib() { # subshell to prevent pollution of caller's environment ( PATH=/sbin:$PATH # for ldconfig + LIBRARIES="$EXTRA_LIB /usr/lib" # This relatively common in a sys-root; libs are installed but # ldconfig hasn't run there, so ldconfig -p won't work.
@@ -49,8 +58,15 @@ has_lib() { echo "Please run ldconfig -r \"$CROSS_SYS_ROOT\" to generate ld.so.cache" # fall through; ldconfig test below should fail fi - ldconfig -p ${CROSS_SYS_ROOT+-r "$CROSS_SYS_ROOT"} | grep -Fq "$1" - return $? + if [ "${OS}" = "Linux" ]; then + ldconfig -p ${CROSS_SYS_ROOT+-r "$CROSS_SYS_ROOT"} | grep -Fq "$1" + return $? + fi + if [ "${OS}" = "NetBSD" ]; then + ls -1 ${LIBRARIES} | grep -Fq "$1" + return $? + fi + return 1 ) }
Roger Pau Monne writes ("[Xen-devel] [PATCH] tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB"):
Quoted 1 line
tools/check: check for headers and libraries inEXTRA_INCLUDESandEXTRA_LIB
Thanks, but:
tools/check/Makefile all install: check-build · line 10
Quoted 3 lines
check-build:
tools/check/Makefile +1
-1- PYTHON=$(PYTHON) LIBXENAPI_BINDINGS=$(LIBXENAPI_BINDINGS) ./chk build + PYTHON=$(PYTHON) LIBXENAPI_BINDINGS=$(LIBXENAPI_BINDINGS) EXTRA_INCLUDES=$(EXTRA_INCLUDES) EXTRA_LIB=$(EXTRA_LIB) ./chk build
Perhaps this would be more easily achieved with "export" ?
tools/check/funcs.sh has_or_fail() { · line 29
Quoted 3 lines
has_header(){tools/check/funcs.sh +2
-0+ check_sys_root || return 1 +
The check_sys_root stuff seems unrelated ? Or at least, it's not mentioned in your commit message. I'm not sure if it should be disentangled but it should definitely be mentioned. (I'm not much of an expert on tools/check.)
Also, I should probably wait with applying this until after your revised USER_* flags variables patch, since you probably want to do a similar job for USER_ ?
Ian.
2011/10/17 Ian Jackson <[email protected]>:
Quoted 10 lines
Roger Pau Monne writes ("[Xen-devel] [PATCH]
tools/check: check for headers and libraries inEXTRA_INCLUDESandEXTRA_LIB"):Quoted 1 line
tools/check: check for headers and libraries inEXTRA_INCLUDESandEXTRA_LIBThanks, but:
Quoted 3 lines
check-build:
- PYTHON=$(PYTHON) LIBXENAPI_BINDINGS=$(LIBXENAPI_BINDINGS) ./chk build
+ PYTHON=$(PYTHON) LIBXENAPI_BINDINGS=$(LIBXENAPI_BINDINGS) EXTRA_INCLUDES=$(EXTRA_INCLUDES) EXTRA_LIB=$(EXTRA_LIB) ./chk buildPerhaps this would be more easily achieved with "export" ?
Exported variables are not passed to the called program (chk in this case).
Quoted 8 lines
Quoted 3 lines
has_header() {
+check_sys_root|| return 1
+The
check_sys_rootstuff seems unrelated ? Or at least, it's not mentioned in your commit message. I'm not sure if it should be disentangled but it should definitely be mentioned. (I'm not much of an expert ontools/check.)
The check_sys_root call was already there, just moved it to the top, but I don't know if it's really necessary.
Quoted 3 lines
Also, I should probably wait with applying this until after your revised USER_* flags variables patch, since you probably want to do a similar job for
USER_?
I'm going to send a series now with the two patches.
Roger.
Roger Pau Monné writes ("Re: [Xen-devel] [PATCH] tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB"):
Quoted 4 lines
2011/10/17 Ian Jackson <[email protected]>:
Quoted 1 line
Perhaps this would be more easily achieved with "export" ?
Exported variables are not passed to the called program (chk in this case).
Are you sure ? One purpose of "export" is to put the variable in the environment of commands make runs.
Quoted 7 lines
Quoted 4 lines
The
check_sys_rootstuff seems unrelated ? Or at least, it's not mentioned in your commit message. I'm not sure if it should be disentangled but it should definitely be mentioned. (I'm not much of an expert ontools/check.)The
check_sys_rootcall was already there, just moved it to the top, but I don't know if it's really necessary.
Why do you move it ?
Ian.
2011/10/18 Ian Jackson <[email protected]>:
Quoted 8 lines
Roger Pau Monné writes ("Re: [Xen-devel] [PATCH]
tools/check: check for headers and libraries inEXTRA_INCLUDESandEXTRA_LIB"):Quoted 4 lines
2011/10/17 Ian Jackson <[email protected]>:
Quoted 1 line
Perhaps this would be more easily achieved with "export" ?
Exported variables are not passed to the called program (chk in this case).
Are you sure ? One purpose of "export" is to put the variable in the environment of commands make runs.
I'm not an expert on Makefiles, but from what I've found on the internet, export is used to pass variables to sub-makefiles:
http://www.gnu.org/s/hello/manual/make/Variables_002fRecursion.html
but I couldn't find any reference about using export to pass variables to executed commands. I've tried:
export PYTHON
export LIBXENAPI_BINDINGS
....
./chk build
And variables where not passed to executed script. At the end I think the most suitable solution is to use:
PYTHON=$(PYTHON) \
LIBXENAPI_BINDINGS=$(LIBXENAPI_BINDINGS) \
....
./chk build
To avoid having long lines. This way works fine, variables are passed to the called script.
Quoted 9 lines
Quoted 7 lines
Quoted 4 lines
The
check_sys_rootstuff seems unrelated ? Or at least, it's not mentioned in your commit message. I'm not sure if it should be disentangled but it should definitely be mentioned. (I'm not much of an expert ontools/check.)The
check_sys_rootcall was already there, just moved it to the top, but I don't know if it's really necessary.Why do you move it ?
Because if I found the requested headers in one of the folders while doing the for loop I perform a return 0, I could also perform a break and left the check_sys_root at the end, but does it really matter that much to check_sys_root at the start or at the end of has_header? Looking at the code of the function it doesn't seem to matter when it is performed.
Quoted 2 lines
Ian.
Thanks, Roger.
Quoted 9 lines
Quoted 1 line
Why do you move it ?
Because if I found the requested headers in one of the folders while doing the for loop I perform a return 0, I could also perform a break and left the
check_sys_rootat the end, but does it really matter that much tocheck_sys_rootat the start or at the end ofhas_header? Looking at the code of the function it doesn't seem to matter when it is performed.
Also, I've forgot to say that has_lib function performs check_sys_root at the beginning.
Roger Pau Monné writes ("Re: [Xen-devel] [PATCH] tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB"):
Quoted 1 line
And variables where not passed to executed script.
mariner:~/junk> cat t.make
export TEST=value
target:
printenv | grep TEST
mariner:~/junk> make -f t.make target
printenv | grep TEST
TEST=value
mariner:~/junk>
Or if you prefer documentation, here is what Debian's make-doc-non-dfsg 3.81-5 has to say:
5.7.2 Communicating Variables to a Sub-`make'
---------------------------------------------
...
To pass down, or "export", a variable, `make' adds the variable and
its value to the environment for running each command. The sub-`make', in turn, uses the environment to initialize its table of variable values. *Note Variables from the Environment: Environment.
Ian.
2011/10/25 Ian Jackson <[email protected]>:
Quoted 20 lines
Roger Pau Monné writes ("Re: [Xen-devel] [PATCH]
tools/check: check for headers and libraries inEXTRA_INCLUDESandEXTRA_LIB"):Quoted 1 line
And variables where not passed to executed script.
mariner:~/junk> cat t.make
export TEST=valuetarget:
printenv | grep TEST
mariner:~/junk> make -f t.make target
printenv | grep TEST
TEST=value
mariner:~/junk>Or if you prefer documentation, here is what Debian's make-doc-non-dfsg 3.81-5 has to say:
5.7.2 Communicating Variables to a Sub-`make'
---------------------------------------------
Quoted 6 lines
...
To pass down, or "export", a variable,
make' adds the variable and its value to the environment for running each command. The sub-make', in turn, uses the environment to initialize its table of variable values. *Note Variables from the Environment: Environment.
Sorry for that, I was doing it all wrong, I was reading the make man page, not the gmake man page, and also I was trying to export the variables inside the target definition. Anyway, I hope the patch I've just sent is fine, sorry for the mess and the time you lost on this.
Roger.