avrdude-dev
[Top][All Lists]
Advanced

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

Re: [avrdude-dev] Re: Avrdude GUI and Avr Studio Plugin


From: Joerg Wunsch
Subject: Re: [avrdude-dev] Re: Avrdude GUI and Avr Studio Plugin
Date: Tue, 11 May 2010 11:51:19 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

As Doug Brown wrote:

> Obviously that's the easiest way to go. It would be nice to reuse
> the some of the file parsers included in avrdude anyway.

They are part of the library code.

> >> library<->CLI split

> I wasn't aware of this split, but I don't have the code on
> me. Unless the split is "main.c" (the CLI) vs all other files (the
> libraries)?

All other object files are combined into one libavrdude.a library,
and main.o is linked against it.  I tried my best to separate the
CLI frontend and the generic backend code that way.

> >> I'm aware there are too many potential calls to exit() in the library ...

> Additionally, all status messages are through fprintf(stderr,...), which I
> assume should be changed.

Well, that's mostly debugging stuff.  True status information has been
converted to callbacks, and main.c simply installs fprintf-based
callback functions.  A GUI frontend is expected to install its own
callbacks to gather status information.

We could perhaps replace all the fprintf(stderr) by something else, like

void msghandler(const char *fmt, ...);

which main.c then translates into:

void msghandler(const char *fmt, ...)
{
        va_list ap;
        va_start(ap, fmt);
        (void)vfprintf(stderr, fmt, ap);
        va_end(ap);
}

I think a global search&replace like that could be done without much
problems.

> Also, '-x' parameters are decoded in the 'library' part of the code.

As they are backend-specific, that can only happen there.  A GUI
frontend would be responsible for passing the respective strings to
the backend's extended option parser.

> Is the configuration file to be converted to XML at some stage?

Maybe, if someone really does it.  A hierarchically structured file
would be better than the current mess, but recrafting everything is
going to be a lot of work.

> And can we
> turf out the lexer/parser?!?! :)

When using some XML format, probably, albeit that's the least of the
problems.  lex/yacc is pretty simple to handle (once you grasped it,
basically it's a BNF with actions added to it), and it's going to be
much more of a challenge to find an XML parser library that is going
to be equally well supported on all the platforms AVRDUDE is running
on (Windows, MacOS X, Linux, *BSD, Solaris).

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)



reply via email to

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