Re: RFC: Feature macros (aka USE flags)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 27, 2020 at 2:15 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
>
> On Mon, Apr 27, 2020 at 01:19:29PM +0200, 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.
>
> IMHO it is valuable having the package self-contained as it is
> today, as both maintainers & users are able to see and control
> exactly what features are intended, from a single place.
>
> With this proposal they'd have to read the global.yml and the
> local.$PKG.yml and the $PKG.spec file to figure out what is going
> to be built. Some features will need to vary per-architecture too,
> so this will need a global-$ARCH.yml  and a local-$ARCH.$PKG.yml file
> too for each Fedora arch, or the global.yml file will need to ship
> different content on each arch somehow. So that's potentially 3-5
> files that need to be consulted to figure out what the enabled
> features are for a given package build.

Yes, there is this additional complexity of changing it / looking at
two different places but that's the price paid for having the package
itself independent and the features set by the environment. These
approaches are not exclusive, people can use whichever method,
although I obviously prefer the latter. Hence this proposal.

You're correct about the architecture-specific needs. I wanted to keep
this simple and have people check for that in their packages. However,
that might be contradicting the point above. Architecture-specific
macros would solve this but be more complex to navigate and maintain.

> > 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
>
> IIUC, the global.yml file is intended to live in the use-macros
> package. It wasn't clear though where the local-$PKG.yml file is
> intended to live ? Is it for the use-macros too, or in the
> per-package dist-git ?

Both global and local macros live in the use-macros package. The YAMLs
are sources and generate a single file with all the macros defined in
it. Again, there's nothing binding the distribution local YAMLs to the
packages themselves; they could be built in completely different
buildroots with different macros set from exactly the same commit.

> I'd be concerned about the per-package yml file living in "use-macros"
> because that would means when package maintainers need to rebase to a
> newer release, they potentially have to wait for any "use-macros" update
> to be approved & built before they can update their specfile in Fedora
> and do a build based on those features. This could also be an impact for
> users trying to build new upstream releases in Copr, if the features for
> the new upstream release ned to be different from those in the existing
> release for that Fedora release stream.

It's true this requires some coordination or uglier package checks
(assume the originally submitted default value if undefined and
simplify it later).

> On the point about trying to maintain compat for existing distros which
> lack %use macros. I think the example shown is not the route I would take.
>
> Instead I'd just define a %{with_XXX} macro for the feature upfront, based
> on the %{use XXX} macro value, and then not use the %use macros at all.
> In fact I might be inclined to do this even ignoring the old distro compat
> question, because it makes it easy to override the %{use} global defaults
> in the package.
>
> %define with_foo %{?use:%{use foo}}%{!?use:1}
>
> %if %{with_foo}
> BuildRequires:  foo-devel
>
> % define foo_configure_arg --with-foo
> % define foo_test_arg -Dfoo
> %endif
>
> %prep
> %configure %{?foo_configure_arg}
>
> %check
> make test %{?foo_test_arg}

You should also explicitly define --without-foo here. Sure, you could
do it this way if you think it's nicer.

> NB The "%{use_enable ...}"  macro is targetting autoconf syntax, but
> autotools is not the only build system. Should this aim for a
> consistent approach - either provide macros for all build systems,
> or for none.

I started with these two helpers because autotools are extremely
common and because the source of inspiration, Gentoo, also defines
these. I have nothing against defining more for other build systems.

P
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux