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, "[email protected]<mailto:[email protected]> on behalf
of David Strubbe" <[email protected]<mailto:[email protected]> on behalf of
[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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".
