Friendly ping (or have I missed any discussion channel?).
As a user, I'm really looking forward to see blender >=2.80 in the tree.
According to https://bugs.gentoo.org/689740 this eclass is the main blocker.
Gerion
Am Mittwoch, 27. Mai 2020, 03:40:04 CEST schrieb Adrian Grigo:
> Hello, I am a proxied maintainer of blender and openvdb and wish to propose a
> new eclass and USE_EXPAND variable to ensure the same version of the openvdb
> abi is used when building the blender, openvdb and openimageio packages.
>
> The tree currently contains openvdb 4 and 5, and I plan to add 6 and 7 soon
> to support my new blender PR. Each major release of openvdb has a new ABI,
> and can also support legacy versions. However only one version can be built
> at a time, which is passed to cmake through OPENVDB_ABI_VERSION_NUMBER, and
> produces a library with functions named xxx_7abi5 when building openvdb 7
> with support for abi 5. Client packages like blender and openimageio which
> depend on openvdb and also need to be compiled with the same version number
> in order to link correctly.
>
> To enforce this I propose to add a new USE_EXPAND variable called
> OPENVDB_ABI, which is set to the version number the user wants to use in the
> system eg 5, which expands to openvdb_abi_5. The packages can then append
> -DOPENVDB_ABI_VERSION_NUMBER=${OPENVDB_ABI} to ensure they pass the same
> value to cmake.
>
> To reduce the boilerplate code required to ensure that only one supported
> value is set in OPENVDB_ABI and used by all packages, so I propose to add an
> eclass to maintain this in one place. Similar to PYTHON_COMPAT, each ebuilds
> set OPENVDB_COMPAT to specify which legacy ABI they can support. The
> openvdb.eclass uses it to set global variables OPENVDB_REQUIRED_USE and
> OPENVDB_SINGLE_USEDEP and verify in pkg_prepare that only one of the
> openvdb_abi_X flags is set.
>
> Each ebuild sets REQUIRED_USE="${OPENVDB_REQUIRED_USE}" which evaluates to ^^
> ( openvdb_abi_3 openvdb_abi_4 ... ) to ensure only one abi is enabled from
> those it supports.
> They set RDEPEND="openvdb? ( media-gfx/openvdb[${OPENVDB_SINGLE_USEDEP}] )"
> which evaluates to openvdb_abi_3(-)?,openvdb_abi_4(-)?,... to allow portage
> to enforce the same abi version is built between all packages.
>
> With a new release of openvdb, I will only need to add it to the
> openvdb_abi.desc file, to an eclass internal list _OPENVDB_ALL_ABI, and to
> OPENVDB_COMPAT for each ebuild which supports the new version.
>
> Please review my proposed eclass below. I have tested it works when
> OPENVDB_ABI is missing, set to invalid values, or set to values that cannot
> satisfy all package requirements simultaneously, and that the system
> recompiles all packages when the ABI is changed. It also works when set to
> appropriate values.
>
> I considered other alternatives during development. It is possible to
> manually add the expanded REQUIRED_USE and RDEPEND strings to each package,
> but with each new version of openvdb and multiple client packages to maintain
> this becomes messy and error prone. The user also needs to set the same
> openvdb_abi_X flag for each package. While currently there are only three
> packages which need to be synchronised, any other package which depends on
> openvdb in future will benefit from this infrastructure.
>
> Also without the USE_EXPAND variable the ebuilds do not have access to the
> version number to pass to the build system, and need to generate it by
> testing each USE flag. So I think this is the cleanest solution.
>
> I also looked into slotting openvdb as then packages could specify the
> slot/subslot required eg openvdb:7/5 but don't think this is possible. This
> would be a major undertaking as it has a static as well as dynamic core
> library, another library for python, and the cmake modules that find openvdb
> use the output of a binary at /usr/bin/vdb_print to determine which version
> to link against. It would also not centralise the boilerplate code.
>
> For further information and my discussion during development see
> https://github.com/redchillipadi/ebuild-overlay/issues/4
>
> Please let me know if there is a better solution or improvements are required.
>
> Kind Regards,
> Adrian Grigo
>
>
> # Copyright 1999-2020 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> # @ECLASS: openvdb.eclass
> # @MAINTAINER:
> # Adrian Grigo
> # @ AUTHOR:
> # Author: Adrian Grigo
> # Based on work of: Michał Górny and Krzysztof Pawlik
>
> # @SUPPORTED_EAPIS: 5 6 7
> # @BLURB: An eclass for OpenVDB to control which ABI version is compiled
> # @DESCRIPTION:
> # The OpenVDB package is a library for sorting and manipulating sparse
> # data structures with dynamic topology as required for use in volume
> # rendering for computer graphics.
> #
> # Each major version of OpenVDB provides an updated ABI, as well as
> # the ability to compile
