Re: [Xen-devel] [PATCH RFC v2] build: add autoconf to replace custom checks in tools/check

[Roger Pau Monnà <roger.pau@xxxxxxxxxxxxx>]

2012/1/10 Jan Beulich <JBeulich@xxxxxxxx>:
>>>> On 09.01.12 at 21:37, Roger Pau Monne <roger.pau@xxxxxxxxxxxxx> wrote:
>> --- a/README ÂThu Jan 05 17:25:23 2012 +0000
>> +++ b/README ÂMon Jan 09 21:33:52 2012 +0100
>> @@ -41,6 +41,7 @@ provided by your OS distributor:
>> Â Â Â* GCC v3.4 or later
>> Â Â Â* GNU Make
>> Â Â Â* GNU Binutils
>> + Â Â* GNU Autoconf v2.67 or later
>
> I think Ian had asked this already, but I also think that I didn't see
> an answer: Is this relatively new version really a requirement. Not
> even SLE11 SP2, which hasn't shipped yet, has this new an
> autoconf package. And I would hope to continue to be able to
> build on SLE10 SP4, which only has 2.59, without having to
> manually build newer packages...

I've only tested this with 2.68 and 2.67, I *guess* it will work with
2.59, but it will be good if you could run the script and prove that
it actually does. We agreed with Ian that version will be downgraded
based on user-feedback.

>
>> Â Â Â* Development install of zlib (e.g., zlib-dev)
>> Â Â Â* Development install of Python v2.3 or later (e.g., python-dev)
>> Â Â Â* Development install of curses (e.g., libncurses-dev)
>> @@ -87,9 +88,21 @@ 2. cd to xen-unstable (or whatever you s
>> Â3. For the very first build, or if you want to destroy build trees,
>> Â Â perform the following steps:
>>
>> + Â If you are building Xen from a repository (git or mercurial) you
>> + Â must run:
>> +
>> + Â Â# ./autogen.sh
>> +
>> + Â Before executing ./configure (this step can be ommited when
>> + Â building from a distribution package).
>> +
>> + Â Â# ./configure
>
> Can these two steps be automated (i.e. the need to run either
> be determined by the absence of some file(s), and them being
> invoked from the top level Makefile)?

It probably could, just making a target for config.h in
tools/Makefile. Are you sure this is what we want? The configure
script has several build options that should be set by the user (or at
least reviewed, so the user know it has build/install options).

>
>> Â Â Â# make world
>> Â Â Â# make install
>>
>> + Â If you want, you can run ./configure --help to see the list of
>> + Â options available options when building and installing Xen.
>> +
>> Â Â This will create and install onto the local machine. It will build
>> Â Â the xen binary (xen.gz), the tools and the documentation.
>>
>> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
>> +++ b/autogen.sh   ÂMon Jan 09 21:33:52 2012 +0100
>> @@ -0,0 +1,11 @@
>> +#!/bin/sh
>
> Adding -e here ...
>
>> +rm -rf configure
>> +cd tools
>> +autoheader && autoconf
>> +if [ "$?" = "0" ]
>> +then
>
> ... would eliminate the need for this conditional ...
>
>> + Â Âcd ..
>> + Â Âecho "#!/bin/sh" >> configure
>> + Â Âecho "cd tools && ./configure \$@" >> configure
>> + Â Âchmod +x configure
>
> ... and catch failure anywhere here.

Will change that.

>
>> +fi
>> --- a/tools/Rules.mk ÂThu Jan 05 17:25:23 2012 +0000
>> +++ b/tools/Rules.mk ÂMon Jan 09 21:33:52 2012 +0100
>> @@ -3,6 +3,7 @@
>> Â# `all' is the default target
>> Âall:
>>
>> +include $(XEN_ROOT)/config/Tools.mk
>> Âinclude $(XEN_ROOT)/Config.mk
>
> Wouldn't the order better be the other way around (generic before
> subdir specific)?

Since Config.mk uses ?= when setting variables, I don't think it
really matters (the only variable that could be overwritten by
Config.mk is PYTHON, and it is set with ?= in Config.mk), anyway, I
will change it.

>
>>
>> Âexport _INSTALL := $(INSTALL)
>
> Jan
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel