Advice on distributing a project

[Langer, Stephen A. (Fed)]

On 6/22/18, 10:35 PM, "Ryan Schmidt" <ryandesign at macports.org> wrote:





    On Jun 22, 2018, at 09:12, Langer, Stephen A. (Fed) wrote:



    > 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?



    I don't know how to do what you want to do properly in MacPorts; I'm not well versed in Python software. But your proposal is probably not the right way. With the vast majority of ports, you want to build in the build phase, and install the files into the destroot in the destroot phase; only a very small number of weird custom build systems can't accommodate that and have to combine these two tasks into a single phase.



    I wasn't specific enough earlier. The destroot takes the place of the root of the filesystem (/). So, if, without using a destroot, files would have been installed to ${prefix}, then with a destroot files would be installed into ${destroot}${prefix}. Files do not get installed directly to ${destroot}.



Thanks.  I did figure that out, eventually.



    I agree with Joshua's suggestion to try using the python 1.0 portgroup.



Using the python portgroup has helped immensely.   Now my portfile doesn't do anything fancier than setting some additional arguments for build and destroot.



I still have at least one problem.  We had to extend distutils so that it builds a few .dylib shared libraries that are linked to by the more standardly built python extension modules, which are all .so bundles.  All of them are being installed in the correct location, but the .dylibs retain the install name and id that they were given when they were built.  The destroot phase has somehow fixed those for the .so files.   How can I tell it to do the same for the .dylibs?   "otool -L" shows that the .dylibs have the wrong ids and are linking to the other .dylibs in the wrong locations, and that the .so's have the right ids but are also linking to the wrong .dylibs.  (I don't remember why the shared libraries are .dylibs and not .sos.  Perhaps it's no longer necessary and I should change them all to .so?)



It took quite a while to figure what was going on, because every time I used "port -k install …" so that I could examine the intermediate states, the build appeared to work, but only because the libraries were linking to the old copies in $destroot.



Thanks again.



-- Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20180625/3a5e1ce3/attachment.html>