RFC: Convert bconds to autoconf-like options.

[Jeff Johnson]

Before you get into a litter of additional macros for
bconds, please note that when originally implemented
(by PLD, always first ;-) bcond's were intended as booleans.

When bconds were picked up by RPM using --with/--without popt aliases
(that are essentially just --define wrappings to conventionally
set macro strings), there was already an attempt to try to
conventionalize the string values to be passed straight to
./configure.

So there is a previous attempt to do what you seem to be attempting now.

Whether the existing mapping is flexible enough (or not) is an entirely
different issue than attempting a common conventional approach to
setting build options through RPM.

Personally, I don't believe the existing macro infrastructure in RPM
is robust enough to support full blown "build option" configuiration.

What should be done instead is to add additional macro primitives,
with a reliably defined "registry", not yet more gunky and obscure lazy
string expansions using the existing RPM macro implementation.

I can help with implementing macro primitives (and adding a "registry")
if you wish. YAML would likely be a representation markup that
isn't too painful, other approaches, using embedded lua symbol
tables instead of the existing macro store (which is quite feeble imho).

But you can do whatever you please too ...

73 de Jeff

On Nov 18, 2009, at 11:07 AM, Przemyslaw Iskra wrote:

> 
> Because I don't expect any constructive feedback just yet I'm going to
> introduce the changes right away and we will discuss and later fix them
> eventually.
> 
> 
> I'm proposing few macros to easily convert bconds to configure options.
> Implementation looks like this:
> 
> 
> # expand bconds to --enable-something and --disable-something
> %__enable() %{expand:%%{?with_%{1}:--enable-%{?2}%{!?2:%{1}}}}
> %__disable() %{expand:%%{!?with_%{1}:--disable-%{?2}%{!?2:%{1}}}}
> %__enable_disable() --%{expand:%%{?with_%{1}:en}%%{!?with_%{1}:dis}}able-%{?2}%{!?2:%{1}}
> 
> # same as above, but condition inverted
> %__enable_unless() %{expand:%%{!?with_%{1}:--enable-%{?2}%{!?2:%{1}}}}
> %__disable_if() %{expand:%%{?with_%{1}:--disable-%{?2}%{!?2:%{1}}}}
> %__enable_disable_not() --%{expand:%%{!?with_%{1}:en}%%{?with_%{1}:dis}}able-%{?2}%{!?2:%{1}}
> 
> # expand bconds to --with-something and --without-something
> %__with() %{expand:%%{?with_%{1}:--with-%{?2}%{!?2:%{1}}%{?3:=%{3}}}}
> %__without() %{expand:%%{!?with_%{1}:--without-%{?2}%{!?2:%{1}}}}
> %__with_without() %{expand:%%{?with_%{1}:--with-%{?2}%{!?2:%{1}}%{?3:=%{3}}}%%{!?with_%{1}:--without-%{?2}%{!?2:%{1}}}}
> 
> # same as above, but condition inverted
> %__with_unless() %{expand:%%{!?with_%{1}:--with-%{?2}%{!?2:%{1}}%{?3:=%{3}}}}
> %__without_if() %{expand:%%{?with_%{1}:--without-%{?2}%{!?2:%{1}}}}
> %__with_without_not() %{expand:%%{!?with_%{1}:--with-%{?2}%{!?2:%{1}}%{?3:=%{3}}}%%{?with_%{1}:--without-%{?2}%{!?2:%{1}}}}
> 
> 
> 
> Each macro requires bcond name and accepts optional option name, if option
> isn't specified bcond name is used as option name. Options returning
> --with-something also allow third argument which will be added as value
> in case or positive condition, but won't be added otherwise.
> 
> I was thinking using another prefix, but __ best mimics the two dashes in
> front of options.
> 
> Examples:
> * Basic enable and disable options: 
> - %{__enable bcond}
>   returns --enable-bcond if build condition "bcond" is set,
>   returns nothing otherwise
> - %{__enable bcond option}
>   returns --enable-option if build condition "bcond" is set,
>   returns nothing otherwise
> - %{__disable bcond}
>   returns --disable-bcond if build condition "bcond" is not set,
>   returns nothing otherwise
> - %{__enable_disable bcond}
>   returns --enable-bcond if build condition "bcond" is set,
>   returns --disable-bcond if build condition "bcond" is not set
> 
> * Negated enable and disable options, probably useful only with second argument:
> - %{__enable_unless bcond option}
>   returns --enable-option if build condition "bcond" is not set,
>   returns nothing otherwise
> - %{__disable_if bcond option}
>   returns --disable-option if build condition "bcond" is set,
>   returns nothing otherwise
> - %{__enable_disable_not bcond option}
>   returns --enable-option if build condition "bcond" is not set,
>   returns --disable-option if build condition "bcond" is set
> 
> * Basic with and without options: 
> - %{__with bcond}
>   returns --with-bcond if build condition "bcond" is set,
>   returns nothing otherwise
> - %{__with bcond option}
>   returns --with-option if build condition "bcond" is set,
>   returns nothing otherwise
> - %{__with bcond option value}
>   returns --with-option=value if build condition "bcond" is set,
>   returns nothing otherwise
> - %{__without bcond}
>   returns --without-bcond if build condition "bcond" is not set,
>   returns nothing otherwise
> - %{__with_without bcond}
>   returns --with-bcond if build condition "bcond" is set,
>   returns --without-bcond if build condition "bcond" is not set
> - %{__with_without bcond option value}
>   returns --with-option=value if build condition "bcond" is set,
>   returns --without-option if build condition "bcond" is not set
> 
> * Negated with and without options, probably useful only with second argument:
> - %{__with_unless bcond option}
>   returns --with-option if build condition "bcond" is not set,
>   returns nothing otherwise
> - %{__with_unless bcond option value}
>   returns --with-option=value if build condition "bcond" is not set,
>   returns nothing otherwise
> - %{__without_if bcond option}
>   returns --without-option if build condition "bcond" is set,
>   returns nothing otherwise
> - %{__with_without_not bcond option}
>   returns --with-option if build condition "bcond" is not set,
>   returns --without-option if build condition "bcond" is set
> - %{__with_without_not bcond option value}
>   returns --with-option=value if build condition "bcond" is not set,
>   returns --without-option if build condition "bcond" is set
> 
> 
> That's how most options would be replaced, taken from mplayer:
> 
> -	%{?with_joystick:--enable-joystick} \
> +	%{__enable joystick} \
> 
> -	%{!?with_ssse3:--disable-ssse3} \
> +	%{__disable ssse3} \
> 
> -	--%{!?with_dvdnav:dis}%{?with_dvdnav:en}able-dvdnav \
> +	%{__enable_disable dvdnav} \
> 
> -	%{!?with_amr:--disable-libopencore_amrnb --disable-libopencore_amrwb} \
> -	%{?with_amr:--enable-libopencore_amrnb --enable-libopencore_amrwb} \
> +	%{__enable_disable amr libopencore_amrnb} \
> +	%{__enable_disable amr libopencore_amrwb} \
> 
> -	--%{?with_runtime:en}%{!?with_runtime:dis}able-runtime-cpudetection \
> +	%{__enable_disable runtime runtime-cpudetection} \
> 
> Negated options are rather hard to understand so I'm not sure wether to add
> them at all. In case below I think the old way is better:
> 
> - 	%{?with_alsa:--enable-alsa --disable-select} \
> +	%{__enable alsa} %{__disable_if alsa select} \
> 
> If there are multiple options it probably is best to leave it as is:
> 	%{?with_xmms:--enable-xmms --with-xmmsplugindir=%{_libdir}/xmms/Input --with-xmmslibdir=%{_libdir}}
> 
> because it would look like this:
> 	%{__enable xmms} \
> 	%{__with xmms xmmsplugindir %{_libdir}/xmms/Input} \
> 	%{__with xmms xmmslibindir %{_libdir}} \
> 
> 
> Questions, comments anyone ?
> 
> -- 
> ____  Sparky{PI] -- Przemyslaw _  ___  _  _  ........... LANG...Pl..Ca..Es..En
> /____) ___  ___  _ _ || Iskra  |  | _ \| |  | : WWW........ppcrcd.pld-linux.org
> \____\| -_)'___| ||^'||//\\// <   |  _/| |  | : JID......sparky<at>jabberes.org
> (____/||   (_-_|_||  ||\\ ||   |_ |_|  |_| _| : Mail....sparky<at>pld-linux.org
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3370 bytes
Desc: not available
Url : /mailman/pipermail/pld-devel-en/attachments/20091118/69758c09/attachment.p7s