[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