Advice on distributing a project

[Langer, Stephen A. (Fed)]

On 6/21/18, 11:01 PM, "Ryan Schmidt" <ryandesign at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20180622/7234bb83/attachment.html>