On 6/22/18, 10:35 PM, "Ryan Schmidt" <ryandes...@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
