Re: RFC: Feature macros (aka USE flags)

[clime]

On Mon, 27 Apr 2020 at 13:21, Petr Šabata  wrote:
> Based on the recent discussions around %fedora/%rhel macros and ELN,
> and %bcond generally being confusing to work with, I came up with a
> distribution-wide feature that defines generic feature keywords and
> associated helper macros that packages can check in build-time
> conditionals.
>
> The key advantage here is the defaults are defined by the buildroot,
> not the package. The package is just a building block.
>
> I'd like some input to improve this and unless this turns out to be a
> really bad idea, I intend to submit it as a change proposal. Even
> though the more packages use it the more beneficial it gets, it's, of
> course, perfectly optional.
>
> Details in the gist:
> https://gist.github.com/contyk/0aaaaf0585c57976ca18a293b3566408

Ad. Dan Mach's presented spec file:
> https://github.com/rpm-software-management/libdnf/blob/dnf-5-devel/libdnf.sp...

I really like how all the switches are defined almost on top of the
spec file so I think lots of inspiration can be drawn from that.

Now I also think that introduction of the new %use scheme for build
options instead of the current with/without scheme might be an
overkill.

I think lines like these:

%bcond_with html
%bcond_without man

could be replaced by:

%with_option_env html 0
%with_option_env man 1

i.e. %with_option_env <option_name> <default_value>

%with_option_env could be looking at an environmental buildroot
setting with the possibility to be overridden on command-line by
--with and --without as usual.

There could be also:
%with_option <option_name> <default_value>

which wouldn't look at environment settings so it would be the same
thing as %bcond_with/%bcond_without but less confusing.

So with this, you wouldn't need to change conditions like:

%if %{with foo}
    ...
%endif

and

%if %{without foo}
    ...
%endif

...so fewer changes and less work. I also think these conditions are
quite fine (except relying on with_foo being either defined or
undefined, which is quite funky but I don't think it is a reason to
replace them).

---

The yml files and translation from them into the actual macro files
are nice but I would consider if the hw dependent default values can
be added in future as a feature.

The local_<pkg>.yml file seems somewhat out of place to me. I think it
could be rather kept as an idea for future and for now we could just
start with only buildroot configs?

Best regards!
clime
> Cheers,
> P
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]