[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avrdude-dev] avrdude.conf
From: |
E. Weddington |
Subject: |
Re: [avrdude-dev] avrdude.conf |
Date: |
Fri, 14 Feb 2003 16:08:42 -0700 |
On 14 Feb 2003 at 23:44, Joerg Wunsch wrote:
<snip>
> I don't necessarily say you need to put the information itself into
> the registry, but you'll probably need it to record the location of
> the files.
Ah, that was the mix up. I thought you were implying putting the data
in the registry. Agreed on file location.
> . A central system-wide file that is not going to be customized but
> keeps the central definitions (programming hardware, AVR devices).
> This file can be updated in a new version without asking questions.
>
> . A system-wide file that records system-wide defaults, like the
> programming hardware that is (usually) connected to the system, the
> port it is sitting on, and so on. This file is initially missing
> (so only compile-time builtins will apply), and will not be modified
> by an update.
>
> . Possibly a third file that overrides all this per user. This is
> meant to store a user's preference that is different from the
> system administrator's view. I guess this will be mostly absent,
> but if we need to implement an override mechanism for file #2 above,
> it wouldn't be hard to implement #3 as well.
>
> Basically, the current avrdude.conf.sample is the contents of #1, but
> the purpose of combinde #1 & #2. In order to preserve any local
> changes that are required for #2, Brian appended the .sample to the
> name, so he doesn't need to care about clobbering it during an
> upgrade.
>
> File #1 above can again be installed without asking. File #2 above
> needs to be established from information gathered from the
> administrator during installation. File #3 is, again, normally
> missing, and will only be available if a user has certain requirements
> for overriding the system defaults. Maybe it will never be used on
> Windows.
Agreed. As you said, I doubt #3 will ever be used on Windows.
> > This is one reason why I suggested perhaps using XML for the future.
>
> I don't see how this would improve the situation. You still need to
> differentiate between system-wide defaults, and the shipped
> configuration details that need an easy upgrade path when installing a
> new version.
>
> That doesn't mean i'm totally against XML, it's a nice generic
> language, but i don't see what it would buy us right now, except from
> the need to write another parser construct. The existing parser just
> works as it is, without much effort to maintain it (at least right
> now).
That's why I mentioned in another thread the expat parser lib:
http://sourceforge.net/projects/expat
But I agree that it's not necessary for now. That's why I had
mentioned it for the future. But it might be a more user-friendly
format for writing up custom programmer definitions.
>
>
> > A user could write a custom programmer
> > definition without disturbing other definitions.
>
> A user cannot write into a system directory. :-)
Ah well that blows it then.
> I see your point though, but you forgot that you then have to add
> something like an index file (so the software knows about an added
> definition),
Not necessarily, I was assuming looking into the config subdir and
reading all .xml files present; if it ain't there, it can't be used.
>which is subject to the same considerations again as #1
> above... You cannot easily upgrade the index file without risking to
> clobber system modifications.
>
> XML or not, the option to split the configuration from one file out
> into many would be there using the yacc parser as well, if we really
> want that.
Well in theory we agree. I guess the main point I want to make is the
KISS rule in any design. Keeping it simple will help Windows users
and require less support. :-)
Eric