Re: [avrdude-dev] avrdude.conf

[Joerg Wunsch]

As E. Weddington wrote:

> > Under Windows, the latter is probably the purpose of
> > HKEY_LOCAL_MACHINE vs. HKEY_LOCAL_USER registry keys, but Eric's more
> > competent here.
> 
> I'd rather keep stuff out of the Windows registry.

I'm afraid you can't.  For the usual Unix systems, at least the
location of the files is clear from the beginning, since there's an
agreed filesystem standard.  So the only difference is whether people
would set their ${PREFIX} to /usr/local (usually indicating additional
software by this), or to just /usr (indicating system software).
Config files then always go into ${PREFIX}/etc, and there's also
common agreement that user customizations belong into dot-files in the
user's home directory.

For Windows, you IMHO have to defer the ${PREFIX} decision to
installation time due to the CP/M "drive letter" concept, since you
can't demand from anybody that he's going to install it under
C:\avrdude and nowhere elese -- it might be that hist C: drive is just
full and he needs to have it elsewhere.

Also (correct me if i'm wrong), the agreed method to store user
customization data is just there, in the registry.

> Any code to write 
> to it is of course going to be Windows specific.

As evaluating "getenv("HOME")" is Unix-specific.

> Whereas keeping it 
> to config files is still cross-platform.

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.

> I would suggest keeping the 
> number of files to a minimum if possible.

My 2..3 file approach has the following in mind:

. 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.

> Because Windows users either prefer things as simple 
> as possilbe or they are novice users, the easier it is to use the 
> better. 

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.

> 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).

> One possible way of doing this would be to have a config directory 
> which would include many XML files. One XML file per programmer, one 
> per part, and a "setup" file that could contain default 
> settings(port, programmer, part, etc.).

That's quite more files than the 2...3 files i'm suggesting. :-) Other
than that, we basically agree that the local system's customizations
need to be segregated from the software's base configuration.

> A user could write a custom programmer 
> definition without disturbing other definitions.

A user cannot write into a system directory. :-)

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), 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.
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/