sdcc - Cross Compiler, Needs Packaging Standards?

[Hans de Goede]

Ralf Corsepius wrote:
>>> This is why I plea for a cross-compiler SIG, so far I know of the
>>> following people being interested:
>>>
>>> Hans de Goede   (avr-gcc, arm-linux-gp2x-gcc)
>>> Kevin Kofler    (tigcc)
>>> Ralf Corsepius  (rtems)
> .. freebsd, cygwin, mingw ...
> 

So does this mean we can count you in? (I think we can, but you never
explicitly said yes).

>>  that some of the names of the binaries from sdcc where to
>> generic, and I therefore moved the binaries to /usr/libexec/sdcc, and
>> created symlinks to /usr/bin. But I wonder if this is a good
>> solution...?
> Do you see any problem with it? I don't. 
> 
> To the contrary, you automatically get $bindir/<target>-<tools> as
> surplus, which is what the GNU toolchain applies and which is what
> modern autotools automatically support for cross-toolchains.
> 

+1


>>> Welcome aboard, notice that I've got a couple of last-year CS students
>>> working on packaging avr-gcc, so please contact me before things get
>>> done twice.
> 
> Do me a favor, don't name cross tools "cpu", use a more specific name,
> such as avr-elf. "avr" is too unspecific to specify a particular
> toolchain, which, gnerally speaking, will always consists of more than
> just a "target" compiler.
> 

The avr is a 8 bit OS less mcu, the avr-gcc chain generates code to run
directly on the bare hardware. There is no "executuble" format, no OS,
no nothing. Also notice that every makefile for AVR software under the
sun (that I know of) refers to avr-gcc as avr-gcc and nothing else.

Thus for exact the same reasons why we want
/usr/<target>/{bin,lib,include} and not seperate <target> dirs under bin
lib include, we want avr-gcc to be just plain avr-gcc. The only
alternative I can come up with would be avr-nothing-gcc or avr-NA-gcc,
which both are bogus.


Regards,

Hans