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 

Re: [gentoo-portage-dev] [PATCH] Use env to find python

2020-06-15 Thread Sid Spry
On Mon, Jun 15, 2020, at 2:36 AM, Ulrich Mueller wrote:
> But we know that it is in /usr/bin, so why add yet another indirection?
> 
> Attachments:
> * signature.asc

Ah, sorry -- I forgot to note this here. If you wish to support prefix it is 
possible it may not be in /usr/bin. Granted I am not sure if the prefix stage3 
I was using is old enough to be broken in some way, but adding this would 
prevent future breakage.

I understand your concern but are these really in a hot path? Whatever the 
scripts are doing will beat the time it takes to invoke env by orders of 
magnitude. I can run benchmarks if you'd like, would the tests serve as such?



Re: [gentoo-portage-dev] [PATCH] Use env to find python

2020-06-15 Thread Ulrich Mueller
But we know that it is in /usr/bin, so why add yet another indirection?


signature.asc
Description: PGP signature