[avrdude-dev] Re: per-user config file - .avrduderc

[eric]

Brian Dean wrote:

> Hi,
>
> Just a heads up that I've implemented the per-user config file that
> we've been tossing around.  The system wide config file is read first,
> and can be changed with the '-C' option.  After that, the per-user
> config file is read which comes from ${HOME}/.avrduderc, if it exists.
> Entries in .avrduderc take precedence over entries in the system wide
> config file.
>
> Also, whenever the programmers or parts are listed out, I display the
> config file name and the line number where that definition came from.
> I thought this would be useful to help determine whether a
> part/programmer is coming from the distributed config file, or is
> being overridden.
>
> Eric, I wasn't sure how to handle this for the Windows port - you
> might need to #ifdef around the code that reads in the per-user file.
> I'm not sure whether this is something that can be autoconf'd.  If the
> code needs reorganized a bit to make this easier, feel free to move
> things around.
>

At this point I'm not completely sure on the final form for Windows. I'll
probably wait until the dust settles on this. :-) The platforms are
different.

What I've been thinking about for Windows:
The system wide config file has the same default name of avrdude.conf
(also hardcoded as is now). On normal Windows install avrdude.exe and
avrdude.conf are located in the same directory. When avrdude.exe is
started without the -C option, it will attempt to open the default config
file and search the PATH for the location of this file until found. If the
-C option is used, avrdude will attempt to open the path/filename
specified with -C; if fail it will search the PATH by appending the -C
option to each directory in the PATH. Note that this would be for Windows
only and there would be code to detect a Windows PATH from a Unix path.

The reason why I'm thinking about going this route and not using the
Windows registry, is #1 it's simpler than having to write code to access
the registry, and mainly #2 how avrdude will be commonly distributed on
Windows. I'm going to be including avrdude in WinAVR. WinAVR has 2
directories that has executables: \bin where the main software development
tools are located, and \utils\bin which includes a Unix/GNU utilties set
built for Windows. These 2 directory paths are included on the Windows
PATH environment variable when WinAVR is installed. avrdude.exe and
avrdude.conf will reside in the \bin directory. It would be easiest if
avrdude.exe searched the PATH for the configuration file.

At the moment this doesn't seem to leave much room for a seperate "user"
config that overrides the system config (I mean on Windows).

Still, I'm not totally convinced that overriding the system file is
completely necessary. I can see specifying with -C a different config file
that is used instead of the system config. I don't see that many users
will be customizing or needing to customize the system file except in the
very beginning until all the AVR processors are specified in the config
file. There's just not that many people making custom programmers that
need to override the system.

BTW, once avrdude is distributed with WinAVR on Windows, it's user base
will increase dramatically. In just over 5 weeks, WinAVR 20030115 has
gotten over 7,000 downloads. :-)

Eric