<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi--<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">python setup.py build --3D <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">python setup.py install --3D --prefix=/some/installation/directory<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal">The Portfile contains this:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">build.cmd ${prefix}/bin/python2.7<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">build.args setup.py build --portdir=${prefix}<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">build.target ""<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">use_parallel_build no<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">destroot.cmd ${prefix}/bin/python2.7<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">destroot.args setup.py install --skip-install-name-tool<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">destroot.target ""<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">destroot.destdir --prefix=${destroot}${prefix}<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The portdir argument to "setup.py build" is used to get the right -I and -L paths for the compiler.
<o:p></o:p></p>
<p class="MsoNormal">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.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">% cd /opt/oofports/lib<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in">% otool -L liboof3dcommonGUI.dylib <o:p>
</o:p></p>
<p class="MsoNormal" style="margin-left:.5in">liboof3dcommonGUI.dylib:<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"> build/temp.macosx-10.12-x86_64-2.7-3d/shlib/liboof3dcommonGUI.dylib (compatibility version 0.0.0, current version 0.0.0) <span style="font-family:Wingdings">ç</span> Wrong<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"> /opt/oofports/lib/libgtk-quartz-2.0.0.dylib (compatibility version 2401.0.0, current version 2401.32.0)<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"> /opt/oofports/lib/libgdk-quartz-2.0.0.dylib (compatibility version 2401.0.0, current version 2401.32.0)<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"> [other correct lines omitted]<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"> build/temp.macosx-10.12-x86_64-2.7-3d/shlib/liboof3dcommon.dylib (compatibility version 0.0.0, current version 0.0.0) <span style="font-family:Wingdings">ç</span> Wrong<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks!<o:p></o:p></p>
<p class="MsoNormal"> -- Steve<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">On 6/15/18, 11:54 PM, "<a href="mailto:dstrubbe@gmail.com">dstrubbe@gmail.com</a> on behalf of David Strubbe" <<a href="mailto:dstrubbe@gmail.com">dstrubbe@gmail.com</a> on behalf of
<a href="mailto:dstrubbe@macports.org">dstrubbe@macports.org</a>> wrote:<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">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):
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">require_active_variants gtk2 quartz x11<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">David<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in">On Fri, Jun 15, 2018 at 6:53 PM, Ryan Schmidt <<a href="mailto:ryandesign@macports.org" target="_blank">ryandesign@macports.org</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
<br>
On Jun 14, 2018, at 12:58, Langer, Stephen A. (Fed) wrote:<br>
<br>
> 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.<br>
<br>
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".<o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
</div>
</body>
</html>