From: dw d. <bob...@ho...> - 2006-03-15 12:58:15
|
Hi, MSYS seems to be having a problem resolving Windows environment variables. See below: I have set the following Windows user environment variables: ENV_VAR = /c/Programs/Work ENV_VAR_GAME = $ENV_VAR/Game/Source The main makefile i use to build my application contains this: --snip GAMESOURCE=$ENV_VAR_GAME --snip So, i load up a MSYS window and i'd expect to be able to do this: cd $ENV_VAR_GAME However, this results in an error: sh: cd: $ENV_VAR_GAME: No such file or directory When i echo to the screen the value of ENV_VAR_GAME i get this: $ENV_VAR_GAME/Game/Source when i'd hope to see this: /c/Programs/Work/Game/Source So it looks as if MSYS is not resolving Windows environment variables that contain other Windows environment variables. Does anyone have any suggestions as to how i can fix this as it is breaking my compilation? Thanks Bob. _________________________________________________________________ Are you using the latest version of MSN Messenger? Download MSN Messenger 7.5 today! http://messenger.msn.co.uk |
From: Keith M. <kei...@to...> - 2006-03-15 13:29:37
|
dw dw wrote: > I have set the following Windows user environment variables: > > ENV_VAR = /c/Programs/Work > ENV_VAR_GAME = $ENV_VAR/Game/Source Reading between the lines of your message, I assume that you have done this via Windows Control Panel. The $ENV_VAR syntax is not valid there; you need: ENV_VAR_GAME=%ENV_VAR%/Game/Source > When i echo to the screen the value of ENV_VAR_GAME i get this: > > $ENV_VAR_GAME/Game/Source With the definitions you've specified, I'd actually expect to see: $ echo $ENV_VAR_GAME $ENV_VAR/Game/Source > when i'd hope to see this: > > /c/Programs/Work/Game/Source > > So it looks as if MSYS is not resolving Windows environment > variables that contain other Windows environment variables. This is correct behaviour. You've assigned an explicit value of '$ENV_VAR/Game/Source' to ENV_VAR_GAME. You could equally well have done this from within MSYS' bash, with the assignment: ENV_VAR_GAME='$ENV_VAR/Game/Source' (note the *single* quotes, which suppress the expansion of $ENV_VAR in the assignment to ENV_VAR_GAME). When bash expands variables, it does *not* do so iteratively. You can force an additional expansion pass using `eval'. Try this, and you should see what I mean: $ ENV_VAR=/c/Programs/Work $ ENV_VAR_GAME='$ENV_VAR/Game/Source' $ echo $ENV_VAR_GAME $ENV_VAR/Game/Source $ eval echo $ENV_VAR_GAME /c/Programs/Work/Game/Source Of course, if you define ENV_VAR_GAME this way: $ ENV_VAR_GAME="$ENV_VAR/Game/Source" or without quotes at all: $ ENV_VAR_GAME=$ENV_VAR/Game/Source then bash expands $ENV_VAR when you *assign* ENV_VAR_GAME, and you will see the effect you wanted. The way you assigned it in Windows Control Panel is equivalent to the singly quoted form in bash; using the %ENV_VAR% form in Windows is the equivalent of the unquoted bash form. HTH, Keith. |
From: dw d. <bob...@ho...> - 2006-03-15 15:05:38
|
Hey Keith, Thanks for your response i understand where i was going wrong now. So in my makefile can i do something like this?: --snip GAMESOURCE=eval $ENV_VAR_GAME --snip Thanks Bob. >From: Keith MARSHALL <kei...@to...> >Reply-To: min...@li... >To: min...@li... >Subject: Re: [Mingw-msys] Windows Environment Variables >Date: Wed, 15 Mar 2006 13:27:52 +0000 > >dw dw wrote: > > I have set the following Windows user environment variables: > > > > ENV_VAR = /c/Programs/Work > > ENV_VAR_GAME = $ENV_VAR/Game/Source > >Reading between the lines of your message, I assume that you have >done this via Windows Control Panel. The $ENV_VAR syntax is not >valid there; you need: > > ENV_VAR_GAME=%ENV_VAR%/Game/Source > > > When i echo to the screen the value of ENV_VAR_GAME i get this: > > > > $ENV_VAR_GAME/Game/Source > >With the definitions you've specified, I'd actually expect to see: > > $ echo $ENV_VAR_GAME > $ENV_VAR/Game/Source > > > when i'd hope to see this: > > > > /c/Programs/Work/Game/Source > > > > So it looks as if MSYS is not resolving Windows environment > > variables that contain other Windows environment variables. > >This is correct behaviour. You've assigned an explicit value of >'$ENV_VAR/Game/Source' to ENV_VAR_GAME. You could equally well have >done this from within MSYS' bash, with the assignment: > > ENV_VAR_GAME='$ENV_VAR/Game/Source' > >(note the *single* quotes, which suppress the expansion of $ENV_VAR > in the assignment to ENV_VAR_GAME). > >When bash expands variables, it does *not* do so iteratively. You >can force an additional expansion pass using `eval'. Try this, and >you should see what I mean: > > $ ENV_VAR=/c/Programs/Work > $ ENV_VAR_GAME='$ENV_VAR/Game/Source' > $ echo $ENV_VAR_GAME > $ENV_VAR/Game/Source > $ eval echo $ENV_VAR_GAME > /c/Programs/Work/Game/Source > >Of course, if you define ENV_VAR_GAME this way: > > $ ENV_VAR_GAME="$ENV_VAR/Game/Source" > >or without quotes at all: > > $ ENV_VAR_GAME=$ENV_VAR/Game/Source > >then bash expands $ENV_VAR when you *assign* ENV_VAR_GAME, and you >will see the effect you wanted. > >The way you assigned it in Windows Control Panel is equivalent to >the singly quoted form in bash; using the %ENV_VAR% form in Windows >is the equivalent of the unquoted bash form. > >HTH, >Keith. > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live >webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >_______________________________________________ >Mingw-msys mailing list >Min...@li... >https://lists.sourceforge.net/lists/listinfo/mingw-msys _________________________________________________________________ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters |
From: Greg C. <chi...@co...> - 2006-03-15 15:36:39
|
On 2006-3-15 15:05 UTC, dw dw wrote: > > So in my makefile can i do something like this?: > > --snip > GAMESOURCE=eval $ENV_VAR_GAME > --snip Doesn't Keith's suggestion: >> ENV_VAR_GAME=%ENV_VAR%/Game/Source seem preferable? |
From: dw d. <bob...@ho...> - 2006-03-15 15:44:43
|
Yeah i guess, but i wanted to know how i could fix it in the makefile? >From: Greg Chicares <chi...@co...> >Reply-To: min...@li... >To: min...@li... >Subject: Re: [Mingw-msys] Windows Environment Variables >Date: Wed, 15 Mar 2006 15:36:30 +0000 > >On 2006-3-15 15:05 UTC, dw dw wrote: > > > > So in my makefile can i do something like this?: > > > > --snip > > GAMESOURCE=eval $ENV_VAR_GAME > > --snip > >Doesn't Keith's suggestion: > > >> ENV_VAR_GAME=%ENV_VAR%/Game/Source > >seem preferable? > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live >webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >_______________________________________________ >Mingw-msys mailing list >Min...@li... >https://lists.sourceforge.net/lists/listinfo/mingw-msys _________________________________________________________________ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters |
From: Keith M. <kei...@to...> - 2006-03-15 15:57:09
|
dw dw wrote: > So in my makefile can i do something like this?: > > --snip > GAMESOURCE=eval $ENV_VAR_GAME > --snip Well no, not really. 1) That isn't correct Makefile syntax for variables; you need $(ENV_VAR_NAME) or ${ENV_VAR_NAME} in the Makefile. 2) You are mixing shell variable expansions and Makefile macro expansions, in the Makefile context; since you have part of the expansion which is itself a shell variable name, you are creating a scenario which *might* confuse make; (it certainly *would* confuse *me*, even if make did handle it correctly, and I like to be able to keep track of what goes on in my Makefiles). 3) If you really *must* do it, (and I wouldn't; see below), you need GAMESOURCE = eval $$ENV_VAR_GAME in the Makefile. Here's how I would do it: 1) Expunge *both* ENV_VAR and ENV_VAR_GAME *utterly* from the Windows master environment, (i.e. where you set them with Windows Control Panel). 2) In your Makefile, include: GAMESOURCE=/c/Programs/Work/Games/Source (don't bother trying to resolve the shell variables here). 3) Invoke make as normal, to use the default GAMESOURCE you set at (2). 4) Invoke, say make GAMESOURCE=/c/Programs/Fun/Games/Source to override the default, and use /c/Programs/Fun/Games/Source instead. HTH, Keith. |
From: Janssen, F. Dr. <Dr....@dr...> - 2006-03-15 16:44:19
|
On Wed, 15 Mar 2006 15:05:28 +0000 "dw dw" <bob...@ho...> wrote: > GAMESOURCE=eval $ENV_VAR_GAME Apart from Keith's discussion of how to do it I'd suggest using GAMESOURCE=$(ENV_VAR_GAME) in the makefile. The expansion of %ENV_VAR%/Game/Source is taken care of in windows. You can check the env variables from sh using echo $ENV_VAR_GAME On Win2000 i observed that nested %BLA% syntax cannot be used to arbritrary depth. A variable definition refering to a second variable TWO that was define with reference to a third variable THREE still contained %THREE% when expanding it under cmd. This is why I would suggest to check the result of your variable definitions on shell level before actually using it in make. --folkert -------------------------------------------------------------------------------- The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. 3166 -------------------------------------------------------------------------------- |
From: dw d. <bob...@ho...> - 2006-03-15 17:26:04
|
Is it possible to make "eval" recursively evaluate the environment variables? Say i have: ENV_VAR = /c/dir ENV_VAR_ONE = $ENV_VAR/sub ENV_VAR_TWO = $ENV_VAR_ONE/file ENV_VAR_THREE = $ENV_VAR_TWO/proj At the moment if i did an eval on ENV_VAR_TWO it would result in $ENV_VAR_ONE/sub when really i want: /c/dir/sub/file Thanks in advance Bob. >From: "Janssen, Folkert Dr." <Dr....@dr...> >Reply-To: min...@li... >To: min...@li... >Subject: Re: [Mingw-msys] Windows Environment Variables >Date: Wed, 15 Mar 2006 17:44:04 +0100 > >On Wed, 15 Mar 2006 15:05:28 +0000 >"dw dw" <bob...@ho...> wrote: > > > GAMESOURCE=eval $ENV_VAR_GAME > >Apart from Keith's discussion of how to do it I'd suggest using >GAMESOURCE=$(ENV_VAR_GAME) >in the makefile. The expansion of %ENV_VAR%/Game/Source is taken care of in >windows. You can check the env variables from sh using >echo $ENV_VAR_GAME > >On Win2000 i observed that nested %BLA% syntax cannot be used to arbritrary >depth. A variable definition refering to a second variable TWO that was >define with reference to a third variable THREE still contained %THREE% >when expanding it under cmd. > >This is why I would suggest to check the result of your variable >definitions on shell level before actually using it in make. > >--folkert > > >-------------------------------------------------------------------------------- >The information contained herein is confidential and is intended solely for >the >addressee. Access by any other party is unauthorised without the express >written permission of the sender. If you are not the intended recipient, >please >contact the sender either via the company switchboard on +44 (0)20 7623 >8000, or >via e-mail return. If you have received this e-mail in error or wish to >read our >e-mail disclaimer statement and monitoring policy, please refer to >http://www.drkw.com/disc/email/ or contact the sender. 3166 >-------------------------------------------------------------------------------- > > > >------------------------------------------------------- >This SF.Net email is sponsored by xPML, a groundbreaking scripting language >that extends applications into web and mobile media. Attend the live >webcast >and join the prime developer group breaking into this new coding territory! >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >_______________________________________________ >Mingw-msys mailing list >Min...@li... >https://lists.sourceforge.net/lists/listinfo/mingw-msys _________________________________________________________________ Are you using the latest version of MSN Messenger? Download MSN Messenger 7.5 today! http://messenger.msn.co.uk |
From: Janssen, F. Dr. <Dr....@dr...> - 2006-03-15 17:52:34
|
Ciao Bob, I am under the impression that you are mixing up two pieces of syntax On shell level one would write: ENV_VAR=/c/dir ENV_VAR_ONE=$ENV_VAR/sub ENV_VAR_TWO=$ENV_VAR_ONE/file ENV_VAR_THREE=$ENV_VAR_TWO/proj (note the missing blanks and the absence of parenthesis) and have echo $ENV_VAR_TREE printing '/c/dir/sub/fil/proj' - as desired. In make one wourd use ENV_VAR = /c/dir ENV_VAR_ONE = $(ENV_VAR)/sub ENV_VAR_TWO = $(ENV_VAR_ONE)/file ENV_VAR_THREE = $(ENV_VAR_TWO)/proj (blanks allowed but using parenthesis is mandatory) and would have $(ENV_VAR_THREE) (again we need parenthesis) expanding to /c/dir/sub/file/proj) - as desired. > At the moment if i did an eval on ENV_VAR_TWO it would result in > $ENV_VAR_ONE/sub when really i want: /c/dir/sub/file Yes, try $(ENV_VAR_TWO) instead. Let me give you an example. Let me give you an example of what I mean. A rule for compiling a cpp file could look like this (just ignore $@ and $< as they are special variables. %.o: %.cpp: g++ -I$(ENV_VAR_TWO) -c -o $@ $< make bla.cpp would result in g++ -I/c/dir/sub/file -c -o bla.o bla.cpp Hope this helps. --folkert -------------------------------------------------------------------------------- The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. 3166 -------------------------------------------------------------------------------- |
From: Keith M. <kei...@to...> - 2006-03-16 11:14:48
|
dw dw wrote: > Is it possible to make "eval" recursively evaluate the environment > variables? Nope. It is possible to do it *iteratively*, but you'd have to write the `while' or `until' loop, as a shell command sequence, for yourself. > Say i have: > > ENV_VAR = /c/dir > ENV_VAR_ONE = $ENV_VAR/sub > ENV_VAR_TWO = $ENV_VAR_ONE/file > ENV_VAR_THREE = $ENV_VAR_TWO/proj > > At the moment if i did an eval on ENV_VAR_TWO it would result in > $ENV_VAR_ONE/sub when really i want: /c/dir/sub/file If you've used Windows Control Panel to (incorrectly) define these, then yes, that's what you will see. If you define them directly in the MSYS shell: $ ENV_VAR=/c/dir $ ENV_VAR_ONE=$ENV_VAR/sub $ ENV_VAR_TWO=$ENV_VAR_ONE/file $ ENV_VAR_THREE=$ENV_VAR_TWO/proj (Note: as Folkert pointed out, you *must* not interpose spaces in these *shell* variable definitions). then the intermediate variables would be resolved at the time when you *define* the dependents, and you would see exactly what you want; you only need `eval' when you want to *delay* the interpretation of a variable, and then you need to use the singly quoted form of the dependent definition, as I explained yesterday, to prevent the premature interpretation within the definition. Regards, Keith. |
From: Keith M. <kei...@to...> - 2006-03-16 09:25:08
|
Dr. Folkert Janssen wrote: [Initialising Makefile valiables from the shell environment] >> GAMESOURCE=eval $ENV_VAR_GAME > > Apart from Keith's discussion of how to do it I'd suggest using > GAMESOURCE=$(ENV_VAR_GAME) I'd caution very strongly against using environment variables to initialise Makefile variables in this manner. By doing this, you are introducing a dependency on a user defined entity, over which you have little or no control. This dependency is fragile; if the user fails to define the environment variable, or provides an inappropriate definition, your build process *will* break. Quite apart from the incorrect syntax of the OP's `GAMESOURCE' definition, the fact that he even considers using `eval' here is compelling evidence of the fragility of this design. Regards, Keith. |
From: Greg C. <chi...@co...> - 2006-03-16 10:34:19
|
On 2006-3-16 9:20 UTC, Keith MARSHALL wrote: > > I'd caution very strongly against using environment variables to > initialise Makefile variables in this manner. By doing this, you > are introducing a dependency on a user defined entity, over which > you have little or no control. This dependency is fragile; if the > user fails to define the environment variable, or provides an > inappropriate definition, your build process *will* break. The GNU make manual says the same thing: | It is not wise for makefiles to depend for their functioning on | environment variables set up outside their control, since this | would cause different users to get different results from the same | makefile. Until recently, the main makefile I use for my production system contained extra logic to allow users to change the way it works by setting certain variables in the environment. I always felt queasy about that, but another developer strongly advocated this and I reluctantly acceded. A few days ago I tried running the daily build in a shell where I had set $CVSROOT to point to a local directory, which contained the sources as of early 2004. Imagine the terror I felt when it appeared that someone had removed the current production branch from our online repository. |