On Jul 15, 2009, at 2:38 PM, Scott Haneda wrote:
Can someone summarize why some sources are so simple to make a portfile for, and others require reinplacing the Makefile to alter it just enough to conform how MacPorts will need it to be?99% of the time, --prefix works fine, why would someone omit it, and assume that software wants to be in say /usr/local/bin? There could be any number of other layouts the user wants to put things in, /opt/ local being just one.
Where the user wants to install the software is something that can be overlooked by developers who right software for their needs and then release it to the public. They're under no obligation to make it conform to expected behavior.
When people aim to be as compliant as they can, you find the easiest portfiles.
memtestx is a branch of memtester, that is pay for software. A very small fee. I would like to release memtester as free software. I feel a lot of people would benefit from it. However, a lot of people are not going to want to install MacPorts just to get memtester.If I use MacPorts to make a package installer, do I need to do so on each of 10.4, and 10.5 for PPC and Intel, and make 4 total binary files? Is there any way to make a universal binary so I can only distribute one file?
Unless specifically deactivated, all ports have a +universal variant. This will combine the pcc and and intel, and targets whatever OS you have configured (both of these settings are found at the bottom of macports.conf).
Suggestions on how to deal with the man page would also be appreciated, as well as a standard to OS X location to store memtester in this scenario. Is /Applications a bad spot of a command line binary in a case like this?
Manpages are ${prefix}/share/man/manX/
If you're going to install these outside of MacPorts, I'd suggest /usr/
local/bin
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
