Re: [Xen-devel] [PATCH for-xen-4.5] Add configure --with-extra-cflags-*

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2014-10-10 at 08:55 +0200, Olaf Hering wrote:
> On Thu, Oct 09, Olaf Hering wrote:
> 
> > +AC_ARG_WITH([extra-cflags-tools],
> > +    AS_HELP_STRING([--with-extra-cflags-tools="EXTRA_CFLAGS"],
> > +       [Additional CFLAGS to be used to build tools.]),
> > +       [EXTRA_CFLAGS_XEN_TOOLS=$withval],
> > +       [EXTRA_CFLAGS_XEN_TOOLS=])
> > +AC_SUBST(EXTRA_CFLAGS_XEN_TOOLS)
> 
> I wonder why all the other --with-foo are not done that way as well. It
> looks like they would take the variable from the environment and do
> AC_SUBST(). IMO private variables like seabios_path, ovmf_path,
> EXTRA_QEMUU_CONFIGURE_ARGS should not be passed via environment.

It looks to me like seabios_path isn't, so I'm confused about what you
are trying to suggest:

AC_ARG_WITH([system-seabios],
    AS_HELP_STRING([--with-system-seabios@<:@=PATH@:>@],
       [Use system supplied seabios PATH instead of building and installing
        our own version]),[
    case $withval in
        no) seabios_path= ;;
        *)  seabios_path=$withval ;;
    esac
],[])
AC_SUBST(seabios_path)

Doesn't take anything fro the env, does it?

>  I also
> question if --with-foo=no is useful at all.

Isn't $withval=no the result of passing --without-foo?

>  My suggestion is to convert
> these three to the style quoted above: a --with-foo=val assigns $val to
> the given private variable, otherwise the private variable is
> initialized empty.
> 
> What do you think?

I have no real opinion one way or the other, since I'm not really sure
what the practical implication of what you are suggesting is.

But it certainly doesn't sound like 4.5 material at this point.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel