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.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
