[MacPorts] #35154: libmame port
MacPorts
noreply at macports.org
Wed Jul 11 06:19:38 PDT 2012
#35154: libmame port
------------------------------+---------------------------------------------
Reporter: bryan@… | Owner: ryandesign@…
Type: submission | Status: closed
Priority: Normal | Milestone:
Component: ports | Version: 2.1.1
Resolution: fixed | Keywords:
Port: libmame |
------------------------------+---------------------------------------------
Changes (by ryandesign@…):
* status: assigned => closed
* resolution: => fixed
Comment:
Committed in r95376 with these changes:
* You pasted your name and email address into the maintainers field. This
field needs to contain email addresses only, and as a spam prevention
measure, ideally in our obfuscated "host:user" format.
* The github portgroup exists to abstract away the peculiarities of
dealing with projects whose distfiles are hosted on github. Switching the
port to this portgroup simplified it.
* We try to use rmd160 and sha256 checksums for distfiles now. I replaced
the sha1 checksum with a sha256 checksum.
* I removed most of your Portfile comments because they merely described
how MacPorts works. While I appreciate that they were probably useful to
you while learning how MacPorts works, they would mainly just slow others
down when reading the Portfile.
* I removed the gmake build dependency and the use of gmake. The version
of GNU make included with Xcode (which is what ports use by default) seems
to be sufficient.
* I moved the library version number into a variable so it's not repeated
in multiple places and is easier to change later.
* I changed from using `exec` to using `system` to run the build
commands; this allowed the stdout to be displayed (in debug/verbose mode
and in the log) which is very helpful when debugging.
* I added a configure block, with the sole purpose of outputting the
configured values to stdout and thus to the log.
* I removed the need to run `install_name_tool` manually by instead
supplying the -install_name argument directly to the linker when creating
the library in the first place.
* I moved the build arguments that were common to the dynamic and static
libraries into the usual build.args variable, and made use of it (and
build.cmd and build.target) when running the build commands.
* The -current_version flag (and the -install_name flag) are only
supplied when building the dynamic library; they would have no effect for
a static library.
* I set the CC and LD variables to ensure we're UsingTheRightCompiler.
* The libmame build system incorrectly assumes that inspecting the output
of the `uname` command is a reliable way to determine the architecture to
build for. In fact, on Intel Macs, the architecture displayed in `uname`
is the architecture of the kernel, but there are many 64-bit Macs (like my
MacBookPro3,1) that run the 32-bit kernel. Thus on some systems `uname`
says "i386" but nevertheless we should build for x86_64. MacPorts wants to
be in control of what architecture a port builds for; it supplies this
information to the port in the form of the build_arch variable. I made the
port respect this variable by adding the canonical -arch flags to the CC
and LD variables, and also setting the libmame-specific PTR64 and
BIGENDIAN variables based on the architecture. Libmame's calculation of
BIGENDIAN was probably ok but I felt better specifying it explicitly.
* libmame puts 64-bit builds in a directory whose name has "64" in it.
The Portfile assumed this would always be the case. I fixed the port to
compute the output directory name based on PTR64 above.
--
Ticket URL: <https://trac.macports.org/ticket/35154#comment:2>
MacPorts <http://www.macports.org/>
Ports system for Mac OS
More information about the macports-tickets
mailing list