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. > 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 ? 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. 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} 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. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ 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
