On 6/21/18, 11:01 PM, "Ryan Schmidt" <ryandes...@macports.org> wrote:
On Jun 21, 2018, at 16:46, Langer, Stephen A. (Fed) wrote:
> 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}
It won't affect the issue you're having, but from an organizational
standpoint, build.cmd and destroot.cmd should be "${prefix}/bin/python2.7
setup.py", build.target should be "build", build.args should be
"--portdir=${prefix}", destroot.target should be "install", and destroot.args
should be "--skip-install-name-tool".
Thanks.
> 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?
MacPorts handles it by setting destroot.destdir to DESTDIR=${destroot} and
assuming that the project's Makefile will use that variable correctly, as a
staging directory into which the files will be installed but which will not be
used by the build in any other way. It is also assumed that there will be
another variable (e.g. PREFIX=/opt/local) or configure arg (e.g.
--prefix=/opt/local) by which we can inform the build system of the ultimate
install directory, the one to which MacPorts will move the files from the
destroot, and that the build system will correctly use that variable as the
basis for library install names.
If your project's build system does not support DESTDIR, maybe adding that
support would be the best way forward. I'm not sure what the standard is in the
land of distutils/setuptools for such support.
If I change the MacPorts build phase so that it runs "python setup.py build
install --prefix=${destroot}, then everything that MacPorts needs to install
will be in ${destroot}/lib, ${destroot}/bin, etc. Will the default MacPorts
destroot phase work properly in that case? How do I restore the default
destroot after redefining build.cmd, since destroot.cmd uses build.cmd when
build.cmd is defined?
-- Steve
