> Date: Thu, 3 Mar 2005 07:10:54 -0500 (EST) > From: "Earnie Boyd" <[EMAIL PROTECTED]> > Cc: [email protected] > > MSYS and Cygwin as well as the child cmd.exe (at least on NT 5.1) will retain > > export a=A > export A=a > > in their respective environments. However cmd.exe, even though both A and > a are variables, will pick A for either ``echo %a%'' or ``echo %A%'' and > return the value ``a''. MSYS and Cygwin have no problem with picking the > correct variable. Now in the cmd.exe shell when I ``set B=b'' and ``set > b=B'' what remains is B=B. If I reverse the order of the set commands, > assuming neither B or b is a valid variable at the time, what remains is > b=b. This environment variable quackery becomes even more burdonsome if > one makes use of the C runtime _environ pointer. And even worse is the > envp argument to the main function, according to MSDN the variable may not > contain the correct data in all cases.
So this means that whoever writes Makefiles for Windows (or Makefiles that should be portable to Windows) should be careful about variables that differ only in letter case. FWIW, I don't think I've seen any Makefiles that have such variables, but perhaps I misremember. In any case, Make itself does not have to solve all such problems, only those that can adversely affect Make's own operation. And I think Path is the only variable that belongs to that category. Maybe we should also add to this variables that are internal to Make: MAKE, MAKEFLAGS, MAKEFILES, MAKEFILE_LIST. > Uppercasing the variable name helps avoid confusion and possibly reduce > list noise. I don't recall too many messages on this list about problems related to environment variables, with the exception on Path. > We could replace getenv() and setenv() with our own versions that > read and write the _environ variable directly. This is possible, but can we do this reliably? That is, are getenv and setenv purely application code in the libraries used by MinGW, or do they involve some OS interaction? If the latter, there's a possibility that the OS does something that will preclude what you want. (Cygwin replaces the MS runtime libraries, unlike MinGW, so Cygwin might be able to do more magic than MinGW.) _______________________________________________ Make-w32 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/make-w32
