> On Jun 14, 2018, at 1:58 PM, Langer, Stephen A. (Fed) > <stephen.lan...@nist.gov> wrote: > > On 6/13/18, 8:37 PM, "Craig Treleaven" <ctrelea...@macports.org> wrote: > >> On Jun 13, 2018, at 6:35 PM, Rainer Müller <rai...@macports.org> wrote: >> >> On 2018-06-13 21:37, Langer, Stephen A. (Fed) wrote: >>> (2) Package all of the compiled libraries and dependencies into a Mac-like >>> app and distribute binaries, but not a portfile. Will "port pkg" do this >>> if I write a portfile for the project? Can I tell it to include the vtk >>> libraries that have been built outside of MacPorts? >> >> You could use 'sudo port mpkg', which creates a single .pkg installer >> that includes the files for the port and all of its dependencies. This >> assumes that you have a port that provides the required vtk libraries. >> It is not possible to include extra files that are not provided by a port. >> >> If you are going to distribute this installer, please use a prefix other >> than /opt/local for it, to avoid a collision for users that also use >> MacPorts. >> >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fguide.macports.org%2F%23using.binaries.binary-packages&data=02%7C01%7Cstephen.langer%40nist.gov%7C13c0320a0b5d4cbf5f6008d5d18ef78f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636645334320959905&sdata=VhTttsZ3dydXb7vatIRiExciRimMpMa38%2Bj6zLNeTZE%3D&reserved=0 > > If you anticipate that some or all the users will have MacPorts installed, > creating an installer with MacPorts _may_ lead to problems even though you > use a non-default prefix when creating your installer. That non-default > prefix is where your packaged software ends up on the user’s system. If your > packaged software looks for utilities (or libraries) at run-time, the user’s > PATH could lead to version conflicts. Hopefully this would not affect you > but it could lead to ‘wild-goose-chasing’ bugs. Something to give thought to > before going down this path. > > Re vtk, or any other dependency, you can create/modify any of the ports > for the deps so as to get the version you want. See the guide section: > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fguide.macports.org%2F%23development.local-repositories&data=02%7C01%7Cstephen.langer%40nist.gov%7C13c0320a0b5d4cbf5f6008d5d18ef78f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636645334320959905&sdata=uo57kLPv9JZjJnZDb9%2FTIVhAcqmojVI03kbfUhWjTJQ%3D&reserved=0 > > In addition to the guide section that Rainer linked, you might want to > review the following wiki page. I’ve written up some tips and tricks…mostly > to aid my own memory. Contributions encouraged! > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.macports.org%2Fwiki%2Fhowto%2FCreateInstallers&data=02%7C01%7Cstephen.langer%40nist.gov%7C13c0320a0b5d4cbf5f6008d5d18ef78f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C636645334320959905&sdata=5G7LcSLCO%2FSWO2W4b4TMIzWp2JOHMONoGWuHIjfnLq0%3D&reserved=0 > > If you get into the process and have questions or issues, don’t hesitate > to post to this mailing list. I and others would be happy to try to help. > > Craig > > > 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. >
I can’t “guarantee” that there won’t be conflicts—I don’t know what you are trying to package! If your software consists of a few C++ programs that link to libraries in the normal way, it is very likely that everything will be fine. However, if you are packaging mostly scripts that call utilities (without a fully qualified path), there is the potential for breakage. Then there are systems that look up plugins at run time, etc. Suppose, for an extreme example, that a user had installed a few things with MacPorts several years ago. They might have ancient versions of something (installed under /opt/local) where your package relies on an up-to-date version installed in your custom prefix (say /opt/fed). The user’s PATH may still include /opt/local/bin and friends. As long as all of the software you are packaging avoids using PATH to find things, it should be fine. HTH, Craig
