Opened 13 years ago

Closed 8 years ago

#28611 closed submission (wontfix)

mspgcc4 port submission

Reported by: NF6X (Mark J. Blair) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 1.9.2
Keywords: lack-of-interest Cc: ryandesign (Ryan Carsten Schmidt), r.tirrell@…
Port: mspgcc4

Description

I'm submitting my port of the mspgcc4 compiler and debugger toolchain for cross-compiling TI MSP430 code. I'm also volunteering to be the maintainer of this port. I've been in contact with the the main mspgcc4 developer, and I have his go-ahead to push out releases via MacPorts. I tested this port on a fresh install of Snow Leopard, xcode and MacPorts with no other ports installed in order to verify that I didn't miss any dependencies.

Attachments (4)

Portfile (2.7 KB) - added by NF6X (Mark J. Blair) 13 years ago.
Portfile for mspgcc4
buildgcc.pl.disable-dialog.patch (420 bytes) - added by NF6X (Mark J. Blair) 13 years ago.
patch 1/3 for mspgcc4
do-gcc.sh.patch (541 bytes) - added by NF6X (Mark J. Blair) 13 years ago.
patch 2/3 for mspgcc4
gcc-4.4.5.patch.patch (455 bytes) - added by NF6X (Mark J. Blair) 13 years ago.
patch 3/3 for mspgcc4

Download all attachments as: .zip

Change History (16)

Changed 13 years ago by NF6X (Mark J. Blair)

Attachment: Portfile added

Portfile for mspgcc4

Changed 13 years ago by NF6X (Mark J. Blair)

patch 1/3 for mspgcc4

Changed 13 years ago by NF6X (Mark J. Blair)

Attachment: do-gcc.sh.patch added

patch 2/3 for mspgcc4

Changed 13 years ago by NF6X (Mark J. Blair)

Attachment: gcc-4.4.5.patch.patch added

patch 3/3 for mspgcc4

comment:1 Changed 13 years ago by NF6X (Mark J. Blair)

Cc: nf6x@… added

Cc Me!

comment:2 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added; nf6x@… removed

Ok, my feedback:

  • Remove the library dependency on port:wget, unless this software really does use wget at runtime. If you only added it because you call wget during post-fetch, then a) it should have been depends_fetch not depends_lib, b) it should have been curl not wget since curl is standard on Mac OS X but wget is not, and c) see below.
  • Don't fetch distfiles manually in post-fetch; add these files to distfiles so they're cached locally and mirrored by our distfiles network. The problem here is that the port fetches via git and MacPorts only does a single fetch type per port. If possible, switch to fetching the port's main software via a regular distfile instead of git. If no regular distfile is available and git is the only method, then do the git fetch in post-fetch, since we don't cache that anyway (see #16373).
  • Is it necessary to violate the mtree, or could the software be placed somewhere that doesn't violate, like ${prefix}/libexec/${name} or ${prefix}/share/${name} (depending on whether it's architecture-specific or architecture-independent files, respectively)? There's no need for ${version} to appear in the installed location, unless we're going to have multiple ports for multiple versions of this software.
  • There's no need to "file mkdir ${destroot}${prefix}/bin" in destroot; MacPorts creates that directory for you.
  • Are we UsingTheRightCompiler and obeying build_arch and supporting universal builds?
  • Use native tcl commands (glob and ln -s) instead of system to create the symlinks in post-destroot.

comment:3 Changed 13 years ago by NF6X (Mark J. Blair)

  • I'll change the wget stuff as recommended.
  • I'll see if I can fetch the distfiles normally so that they get cached, and run the git pull in post-fetch. It could be tricky, since the software builds from a script which makes different assumptions about how the world works than MacPorts does. I wish that I could avoid the git pull entirely, but that's just how this package is distributed.
  • I'll see if I can make it non-mtree-violating. Simply having the package's regular build process install into ${destroot}{prefix} causes conflicts with other ports; I hadn't considered burying the whole thing under ${prefix}/libexec/${name}. That might work nicely.
  • I'll check into whether it's UsingTheRightCompiler. Thanks!
  • Thanks, I'll fix the post-destroot stuff.

Should I attach my revised Portfile to this ticket, or open a new ticket? It'll probably take me a few days to complete this, since the download + build cycle takes a while. That, and my day job keeps interfering with stuff like this. :)

comment:4 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Just attach new files to this ticket, please. Thanks.

comment:5 Changed 13 years ago by guillaumesalagnac

CC me !

comment:6 Changed 13 years ago by landonf (Landon Fuller)

Regarding violating mtree, we've been making an exception for cross compiler toolchains and libraries. It's standard on other operating systems to place them in ${prefix}/${cpu}-(${vendor}-)${os}, and the existing MacPorts ones do the same; the toolchain for AVR microcontrollers, for instance (avr-binutils, avr-libc, avr-gcc) install in ${prefix}/avr.

comment:7 Changed 13 years ago by NF6X (Mark J. Blair)

Would it be best for me to install this toolchain under ${prefix}/msp430 for consistency, then?

Also, is it OK to create symlinks in ${prefix}/bin so that the user doesn't need to modify their $PATH to use the toolchain? The binaries are named "msp430-gcc", "msp430-ld", etc.

comment:8 Changed 13 years ago by r.tirrell@…

Any update on getting this in the main tree?

comment:9 Changed 13 years ago by r.tirrell@…

Cc: r.tirrell@… added

Cc Me!

comment:10 in reply to:  8 ; Changed 13 years ago by NF6X (Mark J. Blair)

Replying to r.tirrell@…:

Any update on getting this in the main tree?

Based on the comments I received, I decided to investigate splitting this into separate ports for binutils, gcc, gdb, libc, etc. I haven't been able to spend much time on it due to my work schedule, though. I'll try to get back to work on this as soon as I can. It's been a bit challenging to coerce the mspgcc4 distribution into the MacPorts way of doing things.

comment:11 in reply to:  10 Changed 13 years ago by r.tirrell@…

Replying to nf6x@…:

Replying to r.tirrell@…:

Any update on getting this in the main tree?

Based on the comments I received, I decided to investigate splitting this into separate ports for binutils, gcc, gdb, libc, etc. I haven't been able to spend much time on it due to my work schedule, though. I'll try to get back to work on this as soon as I can. It's been a bit challenging to coerce the mspgcc4 distribution into the MacPorts way of doing things.

Awesome - if there's any way I could help (e.g. testing), let me know.

comment:12 Changed 8 years ago by jmroot (Joshua Root)

Keywords: lack-of-interest added; mspgcc4 MSP430 removed
Resolution: wontfix
Status: newclosed

Closing due to lack of activity. Please feel free to reopen if you are interested in working on this.

Note: See TracTickets for help on using tickets.