autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Support for SDCC (small device C compiler)


From: Ralf Wildenhues
Subject: Re: Support for SDCC (small device C compiler)
Date: Sun, 21 May 2006 06:01:38 +0200
User-agent: Mutt/1.5.11+cvs20060403

Hi Paul,

* Paul Eggert wrote on Sun, May 21, 2006 at 02:00:23AM CEST:
> Ralf Wildenhues <address@hidden> writes:
> 
> > [1] "binary" because what it generates is an interesting string of
> > colons followed by runs of characters that all belong to the hexadecimal
> > system.
> 
> My understanding is that an .ihx file is neither binary or executable.
> You need to feed it to another program to make an executable binary
> file.

Right, thanks for correcting me.  But it's the output file that can be
turned into an executable binary file, so it's as close as we get
without a wrapper program.

This opens up an interesting question: Since sdcc will only function
as cross compiler anyway, and all Autoconf does with cross compiled
binaries is test for existence and nonemptiness, the file may very
well serve as witness for the successful compiler run.  A solution
to the issue of how to deal better with cross-compiled binaries could
take this into account.  (But of course, it would be sensible as well
to wrap sdcc and the linker.)

> >     * lib/autoconf/lang.m4 (_AC_COMPILER_OBJEXT_REJECT): Add
> >     .adb, .asm, .cdb, .dump, .lnk, .lst, .mem, .rst, and .sym,
> >     for the Small Device C Compiler (sdcc).
> >     (_AC_COMPILER_EXEEXT_REJECT): Likewise, add .rel.
> >     Report by Kallol Borah <address@hidden>.
> 
> http://sdcc.sourceforge.net/doc/sdccman.html/node41.html says
> that there are many different extensions beginning with .dump,
> so that the pattern should be *.dump* and not *.dump.

Thanks for catching that.

> It also says that sdcc optionally generates a file with no extension,
> e.g., "cc foo.c" creates a file named "foo." that is an AOMF or AOMF51
> file.  And this file apparently is an "executable"?  What will/should
> the code do with that?  Count it as an executable?

I don't know.

Maybe it's better to not apply the posted patch, but just to fix the
exeext overridability by the cache variable (which is one of the issues
that Stepan's patch achieved, and I intend to fix after backing out his
patch anyway), and then suggest to use that for now.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]