Re: [avr-gcc-list] Installing WinAVR 20070122 broke older 3.4.5 install?

[Bruce D. Lightner]

Eric Weddington wrote:
> Yes, there are three keys being installed in the registry:
>
> HKLM\Software\Free Software Foundation\WinAVR\GCC
> HKLM\Software\Free Software Foundation\WinAVR\BINUTILS
> HKLM\Software\Free Software Foundation\WinAVR\G++
>
> Each of these keys should be set to the installation directory.
>
> These keys are placed in the registry to help GCC find the various program
> components (such as CC1).
>
> Without these keys there is the possibility that GCC will search the
> "prefix" directory that it stored internally when it was built. This
> "prefix" directory is the directory that I give it when I build WinAVR. That
> path may, or may not, be there on your system, and if it is not on your
> system then it can wreak all sorts of havoc and slow down tremendously.
>
> WinAVR was not originally built/designed for multiple installations, because
> of these registry keys, but obviously your free to do whatever you like if
> you can get it to work.
>   

Eric,

Ahhh!  This explains some "odd behaviors" we have seen recently with the 
the latest versions of WinAVR!

Is there any way to "override" the WinAVR information in the Windows 
"registry" by using, for example, "environment variables"?

WinAVR clearly did not *always* work this way.  Older copies of 
"avr-gcc" seem to work just fine without first "poking" something into 
the Windows registry.  I'm sure that there were some good reasons for 
switching over to using Microsoft's "registry", but on the surface, this 
looks like this has introduced another serious difficulty, depending 
upon the answer to my question.

The problem with using Microsoft's Windows "registry" for locating gcc's 
component parts is that there can be only *one* copy of "registry" data 
at any given point in time.  So, if you want (or need) to run multiple 
copies of WinAVR (like me), there are no good options, unless of course 
there is some simple way to override the global "registry" information.

"Environment variables" are arguably a better choice (or at least should 
be an *option*) for compiler configuration.  The "environment" is 
exactly what Microsoft's command-line compilers use (e.g., Microsoft 
Visual C++) to locate essential "component parts" (e.g., the "include" 
and "library" directories).  True, this requires that the "environment" 
be pre-configured in the user's command shell, but "it ain't no big 
thing"!  Note that when using one of Microsoft's IDE's, the environment 
variables are set automatically by the IDE's GUI program, typically 
using the Windows "registry".  But in this case, each version of the IDE 
uses it's own set of "registry" variables.

The above observation leads me to ask, why is there just *one* set of 
WinAVR registry variables?  Wouldn't it be better to have each different 
*version* of WinAVR maintain its own *unique* set of WinAVR environment 
variables?  That way multiple copies of WinAVR could be present (and 
"active") on a single Windows PC.  For example:

HKLM\Software\Free Software Foundation\WinAVR\WinAVR_20060421\GCC
HKLM\Software\Free Software Foundation\WinAVR\WinAVR_20060421\BINUTILS
HKLM\Software\Free Software Foundation\WinAVR\WinAVR_20060421\G++

As I've noted, that's how Microsoft does it, no doubt for good reasons.

Best regards,

Bruce

--
Bruce D. Lightner
Lightner Engineering
La Jolla, California
Voice: +1-858-551-4011
FAX: +1-858-551-0777
Email: address@hidden
URL: http://www.lightner.net/lightner/bruce/