@pmatilai commented on this pull request.
> @@ -76,47 +76,25 @@
%defined() %{expand:%%{?%{1}:1}%%{!?%{1}:0}}
%undefined() %{expand:%%{?%{1}:0}%%{!?%{1}:1}}
-# Shorthand for %{defined with_...}
+# Handle conditional builds.
+# (see 'conditionalbuilds' in the manual)
+#
+# Internally, the `--with foo` option defines the macro `_with_foo` and the
+# `--without foo` option defines the macro `_without_foo`.
+# Based on those and a default (used when neither is given), bcond macros
+# define the macro `with_foo`, which should later be checked:
+
+%bcond() %{expand:%[ (%2)
+ ? "%{expand:%%{!?_without_%{1}:%%global with_%{1} 1}}"
+ : "%{expand:%%{?_with_%{1}:%%global with_%{1} 1}}"
+]}
+%bcond_with() %{expand:%%{?_with_%{1}:%%global with_%{1} 1}}
+%bcond_without() %{expand:%%{!?_without_%{1}:%%global with_%{1} 1}}
I think the new %bcond macro should be built on top of the pre-existing
%bcond_with/without macros, or the other way around. This is effectively
implementing the inner logic twice. The other thing is, seeing nested
%{expand:..} is a bit of a red flag: they quickly escalate into %%%%%%%-escape
madness in specs. Didn't try it, but to me it seems the outer %{expand:..}
should not be needed. The one that creates the %global definition is.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1520#pullrequestreview-614390730_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
