RFC: Convert bconds to autoconf-like options.

[Przemyslaw Iskra]

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