Re: [gentoo-dev] New eclass: openvdb.eclass

2020-06-15 Thread Gerion Entrup
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 

[gentoo-dev] New eclass: openvdb.eclass

2020-05-26 Thread 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 using a legacy version of the ABI.
# Openvdb 7 can be compiled to support version 5, 6 or 7 of the ABI.
#
# However the user needs to choose at compile time which version to
# build by passing OPENVDB_ABI_VERSION_NUMBER="5" to cmake.
# It is not possible to support multiple versions concurrently
# so OpenVDB and all packages depending upon it must be built for the
# same ABI version. This currently means blender and openvdb, and
# will also include