> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On > Behalf Of Joerg Wunsch > Sent: Wednesday, March 23, 2011 4:51 PM > To: [email protected] > Subject: Re: [avrdude-dev] configuration file generation > > 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.)
See, I told you: it would bring up all the same arguments again. :-) I wasn't referring to a standard *interface*; yes yacc/lex is a standard infterface. The file format used for the config file is not a standard. No one else uses that. However, an XML file is at least some type of standard. Yes, we would be trading yacc/lex for some XML lib, so that's a wash. > 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. Point. Which is an argument for actually not changing a thing. > 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.) Please, no. That just adds yet another library and prerequisite that we have to add to avrdude. Again, disk space is cheap. If we have a configuration *directory*, which had in it multiple XML files, one for each device, then I think it would be simple to add a new device entry; just plop in a new XML file in the directory. > 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. Hey, look! We can agree! :-D Yes, doing this would only give us marginal progress. I think that doing this feature would only buy us these advantages: - Easier to add a new device entry. (Which may be nothing to sneeze at. At the rate that Atmel is coming out with new devices, this may be a very good reason.) - Maybe (big if) easier for a novice to read / add to the configuration info. - Slightly easier to customize / clone an avrdude setup. If there is one xml file per device, then you can prune out the devices that you don't work worth / don't care. Any other advantages that I'm missing? Eric _______________________________________________ avrdude-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avrdude-dev
