/usr/ports/devel/py-gobject3: typo?

Antoine Brodin antoine at FreeBSD.org
Tue Nov 25 19:43:44 UTC 2014


On Tue, Nov 25, 2014 at 9:02 AM, Marcus von Appen <mva at freebsd.org> wrote:
> On, Tue Nov 25, 2014, Antoine Brodin wrote:
>
>> On Tue, Nov 25, 2014 at 5:38 AM, Jia-Shiun Li <jiashiun at gmail.com> wrote:
>> > See if this is helpful to you..
>> >
>> > I encountered this in the middle of building gnome3-lite. On my case
>> > py-gobject3 builds fine alone but fails if built as dependency.
>> >
>> > When failing, there is no
>> >   pygobject-3.14.0-py2.7-freebsd-11.0-CURRENT-amd64.egg-info
>> > as requested in install phase, but there does have
>> >   pygobject-3.14.0-pypython2.7-freebsd-11.0-CURRENT-amd64.egg-info
>> > in the directory. looks something messed up PYTHON_VER for plist.
>> >
>> >
>> > The easier way to reproduce is
>> >   cd /usr/ports/accessibility/caribou && make
>> > vs.
>> >   cd /usr/ports/devel/py-gobject3 && make install
>> >
>> > config.log files from both do not differ. It is more likely 'make
>> > install' causing the problem.
>> >
>> >
>> > My temporary workaround is to rename the file as plist required and continue.
>>
>> Hi mva@,
>>
>> Could you have a look at this?
>> I believe that the DEPENDS_ARGS+=PYTHON_VERSION=${PYTHON_VERSION} in
>> python.mk can cause this kind of issue for some autoconf based
>> projects.
>> In python.mk,  PYTHON_VERSION=python2.7, but in some autoconf based
>> projects PYTHON_VERSION=2.7 (${PYTHON} -c "import sys;
>> sys.stdout.write(sys.version[:3])" 2>/dev/null)
>> So the DEPEND_ARGS may pollute the build of dependencies...
>
> Yes, it looks like DEPENDS_ARGS is the culprit here. The conditionals
> within the configure script of pygobject3-common can run into
> situations, where they do not override PYTHON_VERSION properly.
>
> We have two ways around that:
>
> - override PYTHON_VERSION in the individual ports, which break that way
>   - quickly done
>   - has to be done on a port-per-port basis
>   - adds another "hack" to maintain per port
> - rename PYTHON_VERSION in the ports infrastructure to something else
>   - more clean approach(?)
>   - not done quickly
>   - may affect users using PYTHON_VERSION actively
>   - may need other ports to receive additional changes
>   - needs a full exp-run (without isolations, so poudriere is a no-op)
>
> As workaround, I'd go with the first option for now. Depending on how
> the gnome stuff evolves, we may need to look into option two as well.


The attached patch is ugly, but it seems to work.
I agree that long term solution would be to use variable names that
don't pollute ports build in DEPENDS_ARGS.

Cheers,

Antoine
-------------- next part --------------
Index: devel/py-gobject3/Makefile
===================================================================
--- devel/py-gobject3/Makefile	(revision 373424)
+++ devel/py-gobject3/Makefile	(working copy)
@@ -11,5 +11,7 @@
 
 MASTERDIR=	${.CURDIR}/../../devel/pygobject3-common
 PLIST=		${.CURDIR}/pkg-plist
+# Override PYTHON_VERSION from DEPENDS_ARGS
+MAKE_ARGS=	PYTHON_VERSION=${PYTHON_VER}
 
 .include "${MASTERDIR}/Makefile"


More information about the freebsd-gnome mailing list