New to Macports, trying to make a Portfile, some questions

[Ryan Schmidt]

On Jul 9, 2012, at 01:45, Bryan Ischo wrote:

> Hello, I recently bought a Macbook Pro w/Retina Display as my first Macintosh computer ever, having been a hardcore Linux user for ~17 years now.

Congrats and welcome.


> I have a library that I have developed that I am trying to bring to Macports as a way to install it on my Macbook Pro.  The library is called libmame and it is a library adaptation of the MAME emulator.
> 
> Building libmame takes ~45 minutes on this computer which makes the Portfile development very difficult as I have been having a very hard time preventing the port command from blowing away the pre-existing build when I make changes to the Portfile.  For example after having successfully built the library using 'port build', I found an error in my destroot step and after fixing it, an attempt to re-do just the destroot phase resulted in port blowing away my previously built library.  And so I wait another 45 minutes to test my change to the Portfile …
> 
> Is there any way to tell port NOT to blow away an existing build under any circumstance?  If I've just changed the destroot instructions, it really should not have to rebuild.

"sudo port -o destroot"

"man port" explains:

     -o       honor state files older than Portfile


> I also found some difficulty getting my library to build exactly as I needed it to.  Perhaps I am too used to the Linux way of doing things but I encountered some odd problems.  For example:
> 
> - I couldn't figure out how to tell port that to completely build my library requires TWO gmake commands with different arguments to be invoked.  This is because the way the makefile is set up, building a static library requires setting an environment variable that should not be set when building dynamic libraries.  This you have to run gmake twice, once with the environment variable set, once without.  I ended up just writing my own build phase instructions and figuring out on my own how to make the TCL commands work (and ignore the spurious messages to stderr that the build produces!)

MacPorts runs a single command for each phase. If you need to run multiple commands, you can have MacPorts run the first command, then run additional commands manually in post-build. Or you can override build entirely and run all the commands yourself. Depending on whether there is a normal autoconf configure script, there are several nuances that you need to take care of, including allowing parallel building, building for the right compiler, building for the right architectures (both universal and non-universal), perhaps supporting ccache and distcc, etc.


> - I don't understand Mac OS X's "dynlib" linker very well yet and couldn't understand why the libmame.dynlib file was ending up with an "id" that was the relative path within the build of where the file was built to.  This was screwing up any program that subsequently linked against the port-installed libmame.dylib.  I manually inserted an "install_name_tool -id" command into the build phase to fix this.

The build script should insert -install_name in the correct place. If it does not you may need to modify the build script to do so, or fix it afterward by calling install_name_tool like you do.


> - I wrote a custom destroot phase also because libmame has no 'make install' target.  My destroot commands make directories, copy files, and make symbolic links.  Normal stuff.  I assume this is a perfectly valid way to deal with software that doesn't have a make install target?

That's fine. Make sure you're installing into paths within ${destroot}, usually within ${destroot}${prefix}.


> - I'm still not clear on how I should handle versioning of my library.  I'm loathe to add special linker flags for setting minor version and compatibility version, and am just relying on file naming with a major version included to do the trick.

The build script should insert -current_version and -compatibility_version set to the correct library version numbers. If it does not you may need to modify the build script to do so, or fix it afterward by calling install_name_tool. Note that the library version number is usually not the same as the software version number.


> My biggest question though is definitely about how to keep port from blowing away previous builds on changes to the Portfile.
> 
> Especially because, I am going to play with building self-contained installers using the port tool since I don't expect that the libmame port would be accepted into Macports any time soon given how esoteric this library is.  


I have no objection to including it in MacPorts, assuming the port works the way we want ports to work, and ideally if you or someone agrees to maintain it (keep it updated, respond to bug reports, etc.).

Of course you can keep the port privately if you'd rather do that and not submit it for inclusion.