From owner-freebsd-python@freebsd.org Wed Dec 9 00:10:01 2015 Return-Path: Delivered-To: freebsd-python@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB1CF9D4A4E; Wed, 9 Dec 2015 00:10:01 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8352A1B1A; Wed, 9 Dec 2015 00:10:01 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: by pfu207 with SMTP id 207so19967529pfu.2; Tue, 08 Dec 2015 16:10:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:reply-to:subject:references:to:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Lrq1qdGl8v1i2mKLR0Ts1WnS2ygflKUE84Js5OjlRy0=; b=Gi8iMbtIuolrRmlaW3Etp7qS/2yX9UTOlfu/ZlYKupKPSH3wA7lOXFWGvi3ZeoJwPF +bll8VbQ92mAzCAxRTa1H8HVZDF9UfPI/9lPO7vlHD/RB4OSKXFQZ2cdQN2AdYrC7c3y wDnKqF9cM+NcdiELV8f1Uxhxt0XSMythw/09raUFPZVLiji7F4ph6RWeOIHDyMUvd715 XDsWlR0nMajRCleEsjuOx5RVktwQoik/B3PZ7S/GtkzRxMUyFxyHQkSL0A8mB1ZOw6rs PYzlE/gpe6w8Gkton5o1sL6+yyriwM/yC1sl4+Dk3yAgXYyspcrCBKdbet8PWodt9XA9 ME6w== X-Received: by 10.98.14.67 with SMTP id w64mr8488398pfi.163.1449619800885; Tue, 08 Dec 2015 16:10:00 -0800 (PST) Received: from ?IPv6:2001:44b8:31ae:7b01::2? (2001-44b8-31ae-7b01-0000-0000-0000-0002.static.ipv6.internode.on.net. [2001:44b8:31ae:7b01::2]) by smtp.gmail.com with ESMTPSA id hw7sm7264543pac.12.2015.12.08.16.09.58 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Dec 2015 16:10:00 -0800 (PST) Sender: Kubilay Kocak Reply-To: koobs@FreeBSD.org Subject: Re: Python and SWIG support in ports? References: <56624F9B.30508@FreeBSD.org> To: Craig Rodrigues Cc: ports , freebsd-python@freebsd.org From: Kubilay Kocak Message-ID: <56677151.9050403@FreeBSD.org> Date: Wed, 9 Dec 2015 11:09:53 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Thunderbird/42.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-python@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: FreeBSD-specific Python issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 00:10:01 -0000 On 9/12/2015 4:53 AM, Craig Rodrigues wrote: > On Fri, Dec 4, 2015 at 6:44 PM, Kubilay Kocak > wrote: > > On 5/12/2015 9:40 AM, Craig Rodrigues wrote: > > Hi, > > > > I am working with the upstream maintainer of M2Crypto ( > > https://gitlab.com/m2crypto/m2crypto ). > > > > In the distutils that comes with Python, the swig binary is harcoded > > to "swig" if on a POSIX system: > > > > https://hg.python.org/cpython/file/v2.6.2/Lib/distutils/command/build_ext.py#l635 > > Short-term, swig20 could provide a symlink to the versioned binary until > a 'more correct' and permanent fix can be made. > > I'm not sure what to do about those ports that depend on swig30 in the > presence of swig20 also being installed, given they don't appear to > CONFLICT_INSTALL on each other. They both can't provide the swig > symlink. Supporting swig in DEFAULT_VERSIONS doesn't sound right and is > probably overkill. > > > Actually, fixing the swig port in this way with a symlink is not a bad > idea at all. > I've looked at multiple platforms (Linux, OS X, Windows) > and they all install a binary "swig". > Pushing an upstream fix to Python distutils just to appease FreeBSD may > not work out. > > The down side of this change would be that you would not be able > to install swig1, swig2, and swig3 at the same time, but that might be OK. > > -- > Craig The correct thing to do is be PEP-394'ish compatible (even though swig itself isnt a python package). Again swig20 is a short term solution. The root cause is technically an inadequate 'find the binary file name' method. We do want to keep/allow concurrent swig install support if they don't already CONFLICT_INSTALL