I think resolving this with symlinks feels a bit like a ‘last resort’. It would be better to fix the relative resource path code and include a couple of standard places where to go look for resource files (and gracefully fail if not found rather than crash). Those standard places should follow the way Apple organizes resource paths (for example for iPhone, or find out how it was done for the AVR gcc compiler).

Bas, many of your patches relate to the resource paths and hard-coding them into the compiler. Microchip’s convoluted path parsing code is clearly designed to handle the situation where the whole packing is copied to a folder specified by the user, long after the package was built with “make install”. Is Microchip’s technique for doing this worth keeping? Someone should try moving the base folder of their pic30 installation and see if it still works. If it does, then Microchip’s relative paths might make creating an installer much simpler.

Also, I realized that my patch for the file “c30_resource_paths.h” was only necessary because in Microchip’s distribution there are two copies of the .gld and .inc files: with the assembler and with the compiler. There are two ways to handle this: 1) modify the toolchain’s hardcoded relative search paths or 2) symlink/copy resouces the the appropriate locations so that the directory layout is identical to Microchip’s. Which would be preferable?

Until now lack of time has held me back of trying to plug it into Xcode (I’m using textmate right now).

Now if we could implement remote debugging via Xcode, that would be code nirvana

However, the compiler spec appears to be outdated. For one, the “.pbcompspec” files that they talk about are replaced by “.xcpsec” files in Xcode 3. Some reverse engineering would be required to make an Xcode plugin for PIC30.

The standard library, headers, and linker scripts would have to come separately, of course. That wouldn’t be a big problem because any user that has any kind of license, whether the full professional version or the free educational version, for Microchip C30 has a copy of the standard library already.

I have been using Xcode with SCons for cross-platform embedded development for about a year. However, I see no reason why one couldn’t use Xcode directly for building PIC30 projects. Xcode should be able to parse debugging symbols from C30 object files, for auto-complete.

I am tempted to take a stab at a set of Xcode project templates for C30.

I’ve added a command that touches all .y and .l files in the binutils before building, so that the lex and yacc scripts will be rebuild, and I’ve added a

--disable-nls

option to the configure script of binutils (appearantly not only gcc suffers from this problem, but also binutils). This avoids a failing linker binary for users with different locale settings/libraries than me.