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
