mspgcc4 port submission

[nf6x@…]

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.

[nf6x@…]

Portfile for mspgcc4

[nf6x@…]

patch 1/3 for mspgcc4

[nf6x@…]

patch 2/3 for mspgcc4

[nf6x@…]

patch 3/3 for mspgcc4

[nf6x@…]

Cc Me!

[ryandesign@…]

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.

[nf6x@…]

• 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. :)

[ryandesign@…]

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

[guillaume.salagnac@…]

CC me !

[landonf@…]

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.

[nf6x@…]

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.

[r.tirrell@…]

Any update on getting this in the main tree?

[r.tirrell@…]

Cc Me!

[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.

[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.