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.
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. 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!) - 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. - 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? - 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. 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. And I would like to have an installer that I can point people to. And I really, really don't want to wait 45 minutes every time I screw something up as I figure out the correct incantations for this kind of packaging operation using the port command. Thank you, and best wishes! Bryan _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
