avrdude-dev
[Top][All Lists]
Advanced

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

Re: [avrdude-dev] configuration file generation


From: Joerg Wunsch
Subject: Re: [avrdude-dev] configuration file generation
Date: Wed, 23 Mar 2011 23:51:04 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

As jo wrote:

> Is it possible to try to  directly use Atmel's file then ?

No, we are not allowed to store verbatim copies anywhere in an
opensource repository.

However, we are allowed to store arbitrary information out of them in
an arbitrary format.


As Weddington, Eric wrote:

> If it were in XML, we could drop the yacc code, use standard xml
> libraries, plus it would be easier to use xmlstar (open source
> command-line xml processing tool) to convert the info from AVR
> Studio XML files to avrdude XML files.

Well, the yacc code has proven to be nothing like rocket science in
the past: we've got a number of patches being submitted that extended
it in some way.  By using XML, we'd just replace one prerequisite
(yacc + lex) by another one (some XML library), so that's not much of
an argument.  (Agreeing on a certain XML library API might cause more
headache than agreeing on the yacc/lex interface which is pretty
standardized.)

XML converters could be equally used to produce the current file
format out of some well-structured XML file, and even out of
not-so-well structured XML file ;-), see tools/*.xsl.

Anyway, what bothers me most about the current format is not so much
whether it's "standard" in some form or not, but the already mentioned
sheer size (which makes it a little cumbersome to handle e.g. when
cloning one device entry into another one), and the fact it does not
employ some kind of hierarchical structure so a new tag name is needed
for each parameter, even if the parameter applies to a completely
different scope.

So, by no means, that doesn't mean I'm opposed to using XML.  At the
very least, it would automatically give us a hierarchical structure.
It's just I'm not really ecstatic about XML itself: it's pretty
bloated after all.  (We could perhaps store the on-disk copy in the
end-user's installation in a zip format, using zlib to extract it at
run-time.)

Alas, rewriting all this is going to be a tedious work: it will
replace one existing, *working* config file implementation by another
one, with a lot of work to spend, which will *at best* yield just
that: another working implementation.
-- 
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]