[PATCH] tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB

[PATCH] tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB

[Roger Pau Monne]

# HG changeset patch
# User Roger Pau Monne <roger.pau@entel.upc.edu>
# Date 1318512213 -7200
# Node ID 8fe2ca552de44aa679be3184b1f98f50a00507e2
# Parent  8d316acde60f93cc8563a3c18950e9cbc3ab7fa8
tools/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.

Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>

diff -r 8d316acde60f -r 8fe2ca552de4 tools/check/Makefile
--- a/tools/check/Makefile	Thu Oct 13 13:59:02 2011 +0200
+++ b/tools/check/Makefile	Thu Oct 13 15:23:33 2011 +0200
@@ -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:
diff -r 8d316acde60f -r 8fe2ca552de4 tools/check/funcs.sh
--- a/tools/check/funcs.sh	Thu Oct 13 13:59:02 2011 +0200
+++ b/tools/check/funcs.sh	Thu Oct 13 15:23:33 2011 +0200
@@ -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
 	)
 }

Re: [PATCH] tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB

[Ian Jackson]

Roger Pau Monne writes ("[Xen-devel] [PATCH] tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB"):
> tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB

Thanks, but:

>  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

Perhaps this would be more easily achieved with "export" ?

>  has_header() {
> +	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.

Re: [PATCH] tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB

[Roger Pau Monné]

2011/10/17 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Roger Pau Monne writes ("[Xen-devel] [PATCH] tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB"):
>> tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB
>
> Thanks, but:
>
>>  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
>
> Perhaps this would be more easily achieved with "export" ?

Exported variables are not passed to the called program (chk in this case).

>>  has_header() {
>> +     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.)

The check_sys_root call was already there, just moved it to the top,
but I don't know if it's really necessary.

> 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.

Re: [PATCH] tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB

[Ian Jackson]

Roger Pau Monné writes ("Re: [Xen-devel] [PATCH] tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB"):
> 2011/10/17 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > 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.

> > 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.)
> 
> The check_sys_root call 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.

Re: [PATCH] tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB

[Roger Pau Monné]

2011/10/18 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Roger Pau Monné writes ("Re: [Xen-devel] [PATCH] tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB"):
>> 2011/10/17 Ian Jackson <Ian.Jackson@eu.citrix.com>:
>> > 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.

>> > 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.)
>>
>> The check_sys_root call 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.

> Ian.
>

Thanks, Roger.

Re: [PATCH] tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB

[Roger Pau Monné]

>> 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.
>

Also, I've forgot to say that has_lib function performs check_sys_root
at the beginning.

Re: [PATCH] tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB

[Ian Jackson]

Roger Pau Monné writes ("Re: [Xen-devel] [PATCH] tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB"):
> 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.

Re: [PATCH] tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB

[Roger Pau Monné]

2011/10/25 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Roger Pau Monné writes ("Re: [Xen-devel] [PATCH] tools/check: check for headers and libraries in EXTRA_INCLUDES and EXTRA_LIB"):
>> 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.

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.