Advice on distributing a project

[Langer, Stephen A. (Fed)]

Hi--

I'm making some progress in writing a Portfile for my project, but I'm stuck on one point.  The project's build script uses python distutils (which I'd be happy to get rid of but that's not likely to happen soon).   The build commands, outside of MacPorts, are

python setup.py build --3D
python setup.py install  --3D --prefix=/some/installation/directory

The Portfile contains this:

build.cmd           ${prefix}/bin/python2.7
build.args          setup.py build  --portdir=${prefix}
build.target        ""
use_parallel_build  no

destroot.cmd        ${prefix}/bin/python2.7
destroot.args       setup.py install --skip-install-name-tool
destroot.target     ""
destroot.destdir    --prefix=${destroot}${prefix}

The portdir argument to "setup.py build" is used to get the right -I and -L paths for the compiler.
This seems to work, in the sense that everything is compiled and moved to the correct locations, but the libraries don't have the correct install names and try to link to other libraries in the wrong locations.

The project consists of python files, C++ files that are compiled into simple python extension modules, and C++ files that are compiled into shared libraries that are used by those extensions.  Because distutils builds everything in a temp directory and then installs into a target directory, the setup script runs install_name_tool to fix the install names and rpaths in the libraries.   But now it's installing into ${destroot}, which isn't the final destination, so the script is giving the wrong arguments to install_name_tool.  MacPorts must have the same issue, since it copies libraries out of destroot, so I hoped that I could ignore the problem and let MacPorts handle it.  I added the --skip-install-name-tool option to "setup.py install" to try that, but it doesn't work.  "otool -L" shows that the installed libraries have the wrong install names and are trying to link to libraries in non-existing locations, so rev-upgrade fails.  For example:

% cd /opt/oofports/lib
% otool -L liboof3dcommonGUI.dylib
liboof3dcommonGUI.dylib:
                build/temp.macosx-10.12-x86_64-2.7-3d/shlib/liboof3dcommonGUI.dylib (compatibility version 0.0.0, current version 0.0.0)      <== Wrong
                /opt/oofports/lib/libgtk-quartz-2.0.0.dylib (compatibility version 2401.0.0, current version 2401.32.0)
                /opt/oofports/lib/libgdk-quartz-2.0.0.dylib (compatibility version 2401.0.0, current version 2401.32.0)
              [other correct lines omitted]
                build/temp.macosx-10.12-x86_64-2.7-3d/shlib/liboof3dcommon.dylib (compatibility version 0.0.0, current version 0.0.0)             <== Wrong

So, how does MacPorts handle this?  Have I prevented MacPorts from solving the install name problem by redefining destroot.cmd?   Would xinstall fix it?  Should I run both the build and install phases of setup.py in the MacPorts build phase, and use the default destroot phase?  How do I do that and still redefine build.cmd, since destroot.cmd defaults to build.cmd?

Thanks!
    -- Steve


On 6/15/18, 11:54 PM, "dstrubbe at gmail.com<mailto:dstrubbe at gmail.com> on behalf of David Strubbe" <dstrubbe at gmail.com<mailto:dstrubbe at gmail.com> on behalf of dstrubbe at macports.org<mailto:dstrubbe at macports.org>> wrote:

Regarding +x11 vs +quartz, you can use a line like this (from PortGroup active_variants) to check that dependents (e.g. gtk2) have the right variant (namely, yes +quartz and not +x11):

require_active_variants gtk2 quartz x11

David

On Fri, Jun 15, 2018 at 6:53 PM, Ryan Schmidt <ryandesign at macports.org<mailto:ryandesign at macports.org>> wrote:

On Jun 14, 2018, at 12:58, Langer, Stephen A. (Fed) wrote:

> Thanks for the advice.  If I make a new non-standardly located macports directory on my system, build my program and all of its dependencies in that directory (including dependencies that aren't packaged with macports), and then package it with "port mpkg", is that guaranteed to avoid conflicts on users' systems?  I'd be using both a non-default installation prefix in my portfile, and also a non-default version of macports to build it.

Note that "port mpkg" will only include files that were (or can be) installed by MacPorts (with "sudo port install ..."). If your software depends on things that aren't in MacPorts, you'll have to write Portfiles for those things first, and either contribute them to MacPorts for inclusion in our repository, or at least have them available in the PortIndex of the MacPorts installation in which you run "port mpkg".

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20180621/0a5da503/attachment.html>