#35154 closed submission (fixed)
libmame port
Reported by: | bryan@… | Owned by: | ryandesign (Ryan Carsten Schmidt) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.1.1 |
Keywords: | Cc: | ||
Port: | libmame |
Description
This is my first Portfile, please examine carefully to ensure that I have not made any mistakes! It has been tested and installs libmame just fine on my Mac OS X Lion system. I have also tested that I can link programs against the resulting dynamic and static libraries.
Attachments (1)
Change History (5)
Changed 12 years ago by bryan@…
comment:1 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Owner: | changed from macports-tickets@… to ryandesign@… |
---|---|
Port: | libmame added |
Status: | new → assigned |
Thanks.
comment:2 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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 usingsystem
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 inuname
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 systemsuname
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.
comment:3 Changed 12 years ago by bryan@…
Wow, thank you for all of the great improvements to the Portfile!
Thanks especially for figuring out how to make the build rules work better with the libmame makefile. This makefile is inherited from the MAME project itself and I patched it as minimally as possible to make libmame work, so it is still kind of crufty as you have figured out. I think it's great that you figured out how to incorporate variable definitions in the Portfile to make the build more robust in the face of these limitations in the makefile.
I can't believe how quickly you made the changes too. I really am very impressed!
comment:4 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Glad I could help. I have a few years of MacPorts experience already so that probably makes it easier for me. Even so I went through several iterations, so having an 8-core Mac to build on didn't hurt either (only took 15 minutes to build everything). Let us know on macports-dev or in a new ticket if you need anything else.
Portfile