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

[Bruce D. Lightner]

Eric Weddington wrote:
>  
> I agree that the situation can be improved w.r.t allowing multiple
> installations.
>
> Thanks, Bruce, for providing some concrete solutions.
>
> The main problem that I've been dealing with since 2002 has been that the
> GCC model is to build your compiler from source. GCC was not designed to be
> relocated after it is built, as is the model with most Windows programs.
>
> In the last few weeks, there was finally some help in the GCC project. A GCC
> bug (that I opened) was finally fixed that makes GCC not look at the
> configured prefix for relocated compilers.
> <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621> This was fixed for the
> 4.3 branch.
>
> I haven't had time to test the official fixes, but I have other, older
> patches, that are supposed to do the same thing. My intent is to see how
> well the solution works and see if those patches can be backported for the
> WinAVR distro.
>
> So now it's time to revisit this whole issue and make it so WinAVR won't
> have any problems in being relocated, as well as allowing multiple
> installations, vis-a-vis registry settings, environment variables or
> whatever. Registry settings seemed like the thing to do at the time, because
> one can associate a distro with a distro-specific registry key such as:
> ..FSF\WinAVR_<version>\GCC etc.
>
> My concern with doing enviornment variables is that AFAIK, it does not allow
> different distros,.e.g. what if one has both an AVR GCC distro (WinAVR) and
> an ARM GCC distro (WinARM)?
>
> I'm open to suggestions that will work for all scenarios.
>
> Thanks for a good discussion.
> Eric Weddington
>   

Eric,

I'm glad you're open to making changes.  I'm pretty sure you should be 
able to keep everyone happy, including the "naive" Windows users, with a 
registry-key scheme like the one you're using today.

Your last comment about using "environment variables" confuses me.  I 
must be missing something, because I don't understand why "WinAVR" would 
conflict with "WinARM", unless you are thinking about a *globally* 
defined environment variable that needs to be shared by *both* 
cross-compilers, such as "GCC_ROOT" (see below).

I (and many others) may use environment variables under Windows in 
different way than you are used to.  I almost never setup Windows 
environment variables and the PATH as "globals".  (In the "good old 
days" this was done using "AUTOEXEC.BAT" when Windows was "booted".)  
That's what the Windows "registry" is for now days, and what you are 
doing today with the "registry" I think probably is fine, except for the 
fact that each WinAVR release does not use it's own set of unique 
registry entries.

That being said, if you can make use of the Windows "registry" 
*optional*, that's always better.  I think "Windows install" programs 
with "secret" registry side-effects are "evil", but that's just me.  
Today, I can copy any of Microsoft's many versions of their command-line 
C compiler and linker anywhere I want, and as long as I setup the few 
needed environment variables and PATH (e.g., with a "command file") the 
software just works.  No "install/uninstall" is required.  Personally, I 
like that a lot!

Here's how I like to use "environment variables" under Windows:  Instead 
of trying to make "environment variables (and the PATH) *global*, I use 
a ".PIF" or desktop "short-cut" which runs a .BAT (or .CMD) file to 
setup the "environment" for each particular "build" environment (i.e., 
when the new "command-prompt window" is opened).  That BATCH/command 
file also is where I setup the PATH to include the WinAVR directory.  
That way one can have multiple versions of WinAVR running side-by-side.  
The key to making that work "naturally" is getting WinAVR to use 
environment variables to find stuff...if and only if they have been defined!

What Joerg says gives me hope that this can be made to work:

 Yes, they can be overridden with environment variables.  I had to
 review gcc/prefix.c again (I guess it's also in their docs, but the
 source code was easier to spot for me), the sequence is:

 .. when running in a Win32 environment, the registry key GCC is
   looked up,
 .. if not found, the environment variable GCC_ROOT is queried,
 .. if not found, the configure-time default prefix is used.

 So you have to remove the registry keys before the environment
 variables will get into effect.

That's useful information!

By "zapping" the Windows registry entries for WinAVR I can see how one 
could re-define $GCC_ROOT and get WinAVR to "behave" properly there 
needs to be multiple copies of WinAVR present.  Unfortunately, deleting 
the registry entries can "break" other copies of WinAVR on a PC unless 
they also get the needed environment variable "tweak" for $GCC_ROOT.  
And, I see "danger" with this if "tweaking" the definition of $GCC_ROOT 
fouls up the *native* copy of "gcc"!  I, for one, routinely compile 
"native" apps in the same command window where I'm developing and 
"cross-compiling" AVR code using "avr-gcc"!  (But, maybe by using 
"Makefile magic" to reset $GCC_ROOT, this would not be a problem.  It's 
just confusing to someone that does not know exactly what is going on!

If I had my way, I'd vote for one more "search" step, specific to 
WinAVR.  Add one more step to the above "search list", namely a check 
for an environment variable such as "WINAVR_ROOT"...*first* in the 
list.  This way, if and only if that "special" WinAVR environment 
variable is present then it overrides the (globally defined) 
registry-key information.

Another excellent option would be to use the "path" to the "avr-gcc" 
executable to find the other important "gcc" subdirectories, using 
"relative" paths off the "avr-gcc" executable's base path.  In fact I 
*know* that this is the way "avr-gcc" *used to* work...at least for my 
old favorite "avr-gcc-2.95.2"!  I wonder when that logic was removed?  
This allows you to move the "avr-gcc" release anywhere you want, as long 
as you keep everything "together".  It is the *execution* of "avr-gcc" 
that sets the "search path".

How much trouble these various changes would be you will have to 
answer.  I'm guessing that there is already WinAVR-specific code there 
anyway if the Windows registry is being used.

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/