mingw-msys Mailing List for MinGW - Minimalist GNU for Windows

Earnie Boyd wrote, quoting me:
>> Earnie Boyd wrote, quoting Vincent Magnin:
>> [Re: Problem during MSYS postinstall]
>>>> E:\msys\1.0\bin\sh.exe: *** Couldn't reserve space for cygwin's
>>>> heap, Win32 error 6
>>>
>>> Do you have a CYGWIN environment variable?  If so, remove it, then
>>> try again.
>>
>> Hmm.  I have `CYGWIN=ntsec' in my Windows environment.  It has been
>> there since long before I discovered MSYS, and I've never seen this
>> problem, when I've installed MSYS.
>
> But, I have seen this variable cause this sort of thing.

So, yet another problem which isn't consistently reproducible. :-(

But surely, MSYS doesn't need a CYGWIN environment variable.  If
it's known that it *may* cause a problem, perhaps the postinstall
script should unset it, or at least `export -n' it; maybe msys.bat,
or /etc/profile should do likewise.

Regards,
Keith.

Quoting Keith MARSHALL <kei...@to...>:

> Earnie Boyd wrote, quoting Vincent Magnin:
> [Re: Problem during MSYS postinstall]
>>> E:\msys\1.0\bin\sh.exe: *** Couldn't reserve space for cygwin's
>>> heap, Win32 error 6
>>
>> Do you have a CYGWIN environment variable?  If so, remove it, then
>> try again.
>
> Hmm.  I have `CYGWIN=ntsec' in my Windows environment.  It has been
> there since long before I discovered MSYS, and I've never seen this
> problem, when I've installed MSYS.
>

But, I have seen this variable cause this sort of thing.

Earnie Boyd

http://shop.siebunlimited.com

Earnie Boyd wrote, quoting Vincent Magnin:
[Re: Problem during MSYS postinstall]
>> E:\msys\1.0\bin\sh.exe: *** Couldn't reserve space for cygwin's
>> heap, Win32 error 6
>
> Do you have a CYGWIN environment variable?  If so, remove it, then
> try again.

Hmm.  I have `CYGWIN=ntsec' in my Windows environment.  It has been
there since long before I discovered MSYS, and I've never seen this
problem, when I've installed MSYS.

Regards,
Keith.

Quoting Vincent MAGNIN <vin...@ie...>:

> Hello,
> I have a problem to install MSYS on a PC with Windows XP SP2. Perhaps 
> there is an interference with another installed
> software such that g95, gfortran, Photran (Eclipse+g95) that use 
> MingW, or Clamwin that uses cygwin ? I found a message in
> archives about a possible problem between MSYS and the iSafer 
> firewall, but the problem is the same when I stop and exit
> the firewall. This is the message I obtain during the postinstallation :
>
> E:\msys\1.0\postinstall>PATH 
> ..\bin;E:\Utilitaires\TCLTK\bin;E:\Program Files\Mi
> crosoft Visual Studio\Common\Tools;E:\Program Files\Microsoft Visual 
> Studio\Comm
> on\Msdev98\BIN;E:\Program Files\Microsoft Visual 
> Studio\DF98\BIN;E:\Program File
> s\Microsoft Visual 
> Studio\VC98\BIN;E:\WINDOWS\system32;E:\WINDOWS;E:\WINDOWS\Sys
> tem32\Wbem;E:\Utilitaires\j2sdk1.4.2_07\bin;E:\Utilitaires\GTK\2.0\bin;E:\Progra
> m Files\Fichiers 
> communs\GTK\2.0\bin;E:\Utilitaires\Java\Bin\;E:\Utilitaires\Min
> gW32\bin\;E:\Utilitaires\Photran\MinGW\bin\;E:\Utilitaires\gfortran\bin;E:\Utili
> taires\dislin\win;E:\Program Files\Microsoft Visual 
> Studio\DF98\BIN;E:\Utilitair
> es\g95\bin
>
> E:\msys\1.0\postinstall>..\bin\sh.exe pi.sh
> AllocationBase 0x0, BaseAddress 0x715B0000, RegionSize 0x3E0000, 
> State 0x10000
> E:\msys\1.0\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, 
> Win32 error 6
>
> E:\msys\1.0\postinstall>pause
> Appuyez sur une touche pour continuer...
>
> Could you help me ?

At this point MSYS is installed.  The pi.sh script is more for cleanup 
purposes but also creates an entry in /etc/fstab if you choose to do 
that.  Your PATH variable is large and riddled with spaces but I don't 
think that is unusual.  Do you have a CYGWIN environment variable?  If 
so, remove it, then try again.

Earnie Boyd

http://shop.siebunlimited.com

Hello,
I have a problem to install MSYS on a PC with Windows XP SP2. Perhaps=20
there is an interference with another installed
software such that g95, gfortran, Photran (Eclipse+g95) that use MingW,=20
or Clamwin that uses cygwin ? I found a message in
archives about a possible problem between MSYS and the iSafer firewall,=20
but the problem is the same when I stop and exit
the firewall. This is the message I obtain during the postinstallation :

E:\msys\1.0\postinstall>PATH ..\bin;E:\Utilitaires\TCLTK\bin;E:\Program=20
Files\Mi
crosoft Visual Studio\Common\Tools;E:\Program Files\Microsoft Visual=20
Studio\Comm
on\Msdev98\BIN;E:\Program Files\Microsoft Visual=20
Studio\DF98\BIN;E:\Program File
s\Microsoft Visual=20
Studio\VC98\BIN;E:\WINDOWS\system32;E:\WINDOWS;E:\WINDOWS\Sys
tem32\Wbem;E:\Utilitaires\j2sdk1.4.2_07\bin;E:\Utilitaires\GTK\2.0\bin;E:=
\Progra
m Files\Fichiers=20
communs\GTK\2.0\bin;E:\Utilitaires\Java\Bin\;E:\Utilitaires\Min
gW32\bin\;E:\Utilitaires\Photran\MinGW\bin\;E:\Utilitaires\gfortran\bin;E=
:\Utili
taires\dislin\win;E:\Program Files\Microsoft Visual=20
Studio\DF98\BIN;E:\Utilitair
es\g95\bin

E:\msys\1.0\postinstall>..\bin\sh.exe pi.sh
AllocationBase 0x0, BaseAddress 0x715B0000, RegionSize 0x3E0000, State=20
0x10000
E:\msys\1.0\bin\sh.exe: *** Couldn't reserve space for cygwin's heap,=20
Win32 error 6

E:\msys\1.0\postinstall>pause
Appuyez sur une touche pour continuer...

Could you help me ?
Thanks

--=20
Vincent MAGNIN

-------------------------------------------------
IEMN Laboratoire Central
Cit=E9 Scientifique - Avenue Poincar=E9,=20
BP 69
59652 Villeneuve d'Ascq Cedex - FRANCE

http://www.iemn.univ-lille1.fr/
http://www.polytech-lille.fr/~vmagnin/
-------------------------------------------------

Escorter wrote:
> I'm using the latest stable MSYS and MinGW. Everything is
> fine, but I have a little porblem: the fonts in MSYS are too
> small! How can I set the font size?

This depends on whether you are running the MSYS shell within
an RXVT terminal emulator, (the default), or in a native Win32
console.  (Please refer to the list archives, for an extended
discussion of why you may *not* wish to use RXVT, and make
your own choice on this option).

If you use a Win32 console, then you simply set the font property
for the console window;  (right click the title bar, select the
Properties->Font tab, and adjust to suit your preference; apply,
and save for all windows of the same name).

If you want to continue using RXVT, in spite of its limitations,
then the only way to achieve a font change, with all MSYS versions
released to date, is to modify the msys.bat script.  (Note that we
normally discourage such modifications, since any future upgrade
of your MSYS installation will overwrite them).  However, if needs
must:

1) Locate the line in the script, where RXVT is started.

2) Change the `Courier-12' parameter to anything that suits you
   better, (but if you change the font family, make sure you choose
   an ASCII font;  multibyte fonts will yield very unsatisfactory
   results).

HTH,
Keith.

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3642434
By: earnie

See the CVS module msys/dvlpr/script/msysrls.sh.

Earnie

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Hi!

I'm using the latest stable MSYS and MinGW. Everything is
fine, but I have a little porblem: the fonts in MSYS are too
small! How can I set the font size?

=0A=0A_____________________________________________________________________=
____=0AT=E1rsash=E1zi gyakorlati k=E9zik=F6nyv - Hasznos =E9s n=E9lk=FCl=F6=
zhetetlen seg=EDt=F5je=0Aminden t=E1rsash=E1zban lak=F3nak: http://manager.=
menedzsmentforum.hu/tarsashaz/=0A=0A

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3640744
By: mueckl

I'd like to see the installer sources, but for another reason: I need to deploy
MSYS without running an installer and it is not obvious what the installer actually
does (creating registry keys, creating files on the fly...). And without the
installer sources or any decent description of what the installer does this
is impossible.

Thanks.


______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

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.

dw dw wrote:
> Sorry for emailing you all directly but for some reason my
> emails to the MSYS mailing list are failing.  I'll try to post
> again tomorrow but for now here is what i want to say.

Please *don't* mail list members privately.  If you want private
tuition, then perhaps we can negotiate an appropriate fee; otherwise
please keep your queries on the mailing list.

> Thanks for your replies everybody.  I'm still having a few issues
> so hopefully you'll be able to help me resolve them.
>
> I have 2 Windows environment variables set via the Windows control
> panel.  These are:
>
> API = /c/work/game/api
> API_SOURCE = $API/source

I explained this yesterday (sigh)!

In Windows Control Panel, referring to variables using UNIX syntax
is *wrong*;  you should set API_SOURCE to %API%/source, and *not*
$API/source.

In any case, unless you need these variables outside of your MSYS
environment, you should *not* use Windows Control Panel to set them;
define them directly from the command line as you need them, or in
$HOME/.profile, if you want them permanently.  (Don't forget to
export them, if you need `make' to see them).

And furthermore, if you design your Makefile correctly, you probably
don't *need* these particular environment variables at all.

------------------------------------------------------

> I have a .mk file which containts:
>
> ifndef API_SOURCE
> SOURCE_DIR=$(API)/source
> else
> SOURCE_DIR = $(API_SOURCE)
> endif

What is $(API) here?  If you rely on a definition being present
in the environment, then your Makefile is fragile.  Better to also
provide an explicit default definition for API here as well, and
allow the user to override it, either by an environment variable
setting, or better still, by an explicit API=/some/path assignment
argument to `make' itself.

------------------------------------------------------

> I have a Makefile which contains:
>
> include $(GAME_DIR)/game_defs.mk
>
> all:
> $(MAKE) -f Makefile -C $(SOURCE_DIR)

Why force the build in the source directory?  Usually, the exact
opposite is preferable.

I hinted at this yesterday, but let's formulate a more concrete
example;  let's say we are going to build project `demo', and we
have set up the following directory hierarchy:

  $HOME/projects
          +  sources
          |    +  demo
          |    :    +  demo.c
          |    :    :
          +  build
          :    +  demo
          :    :    +  Makefile

Now, we have all our sources in `$HOME/projects/sources/demo', and
we will build the project in `$HOME/projects/build/demo', so we

  $ cd $HOME/projects/build/demo

Let's now consider what we should have in our Makefile, (that is
the file `$HOME/projects/build/demo/Makefile'):

  --------8<------------------------------
  srcdir = ../../sources/demo
  VPATH  = $(srcdir)

  CC = gcc

  OBJEXT = o
  EXEEXT = .exe

  all: demo$(EXEEXT)

  demo$(EXEEXT): demo.$(OBJEXT)
        $(CC) -o $@ $(CFLAGS) $(LDFLAGS) demo.$(OBJEXT) $(LIBS)

  demo.$(OBJEXT): demo.c
        $(CC) -c -o $@ $(CFLAGS) $(srcdir)/demo.c
  --------8<------------------------------

(Actually, the two rules for `demo$(EXEEXT)' and `demo.$(OBJEXT)'
 are more explicit that they need to be; for this simple project,
 make's implicit rules would probably suffice, but I thought it
 best to show these for illustration).

Note that I've specified an *explict* definition of `srcdir', as
a *relative* path from the build directory, (which will be current
when you invoke `make'), and that `VPATH' tells make where it must
look for prerequisites in it's dependencies, when these aren't
satisfied in the build directory.

------------------------------------------------------

> So when i load up MSYS and type Make i'd expect the make command
> to resolve to something like this:
>
> make -f Makefile -C /c/work/game/api/source
>
> but as you know it actually displays this:
>
> make -f Makefile -C $API/source
> *** No such file or directory

Simply because you've specified invalid syntax, in the definition
of API_SOURCE.  (See above).

> Could someone please show me how i would use the "eval" command
> to get this working.

If you are even considering using `eval' in this context, then your
entire build system design is probably flawed.

Regards,
Keith.

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.

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.

Douglas Vechinski wrote:

>   1) gcc -o spdtst spdtst.c -lm
>   2) gcc -O -o spdtst spdtst.c -lm
>   3) gcc -O2 -o spdtst spdtst.c -lm
>   4) gcc -O2 -ffast-math -o spdtst spdtst.c -lm

You didn't specify -march or -mtune anywhere.  Without those gcc is
going to be rather conservative about the kind of code it generates, so
it's probably not really a fair judge of its optimization capability
verses other compilers.  Try giving -march to reflect the CPU of the
system.  I'm not sure why the mingw and cygwin gcc doesn't line up
against the linux compiled version of gcc very well, but it could be
that those packages have different defaults "baked in" for -march and/or
-mtune.

gcc 4.2 will have -mtune=generic which does a somewhat better job of
optimizing in a generic way for modern CPUs, but that is many versions
removed from 3.3.

Also, -lm is not necessary and does nothing under both mingw and Cygwin.

Brian

A few years ago I submitted a question concerning the execution time
difference for codes compiled under different environments.  At the time
no one was able to provide sufficient insight into why differences were
so great.  So I thought I'd try again.

My primary question is to find out why codes compiled with the
Msys/MingW environment are so slow compared to Linux/Cygwin/MS .Net.  I
typically write/develop scientific research codes under Linux that may
also be frequently used (by others) under Windows.  I typically use
Cygwin or Msys/Mingw to generate the Window executables.  I've noticed
that the executables generated on Windows with these environments are
much slower than the Linux compiled executable under Linux or one
compiled with the MS compiler for C or Digital Fortran compiler for
Fortran for Windows.

I created an example and attached it.  Several large matricies are
calculated and filled with trig functions. Using the same machine, I
compiled the code under a) Linux (Red Hat FC3) (gcc 3.4.4), b) Cygwin
(gcc 3.3.3), c) Cygwin using -mno-cygwin (gcc 3.3.3), d) Msys/Mingw (gcc
3.4.2), and e) .Net.  For a-d I also tried a couple of different
optimization options.  For each environment (a-d) four different
compilations were performed as follows:

  1) gcc -o spdtst spdtst.c -lm
  2) gcc -O -o spdtst spdtst.c -lm
  3) gcc -O2 -o spdtst spdtst.c -lm
  4) gcc -O2 -ffast-math -o spdtst spdtst.c -lm

Note:  for case c) an extra -mno-cygwin flag was included on the compile
line.  For case e) two executables were created, a Debug version and a
Release version using standard project settings.  The run times (in
secs) below represent the average of 5 runs.

A) Linux
    1) 22.9
    2) 20.6
    3) 20.5
    4) 14.2
B) Cygwin
    1) 37.4
    2) 36.3
    3) 36.1
    4) 20.9
C) Cygwin using -mno-cygwin
    1) 66.3
    2) 66.0
    3) 65.8
    4) 25.0
D) Msys/MingW
    1) 66.4
    2) 65.8
    3) 65.7
    4) 24.9
E) .Net
     Debug) 20.5
     Release) 8.9

>From what I understand, cases C) and D) produce native Window
executables that use the MS runtime environment.  These two cases
basically take 3 times longer to run than the Linux version and a lot
worse when compared the the .Net Release (optimized) version.  Since I
perfer methods C or D to generate the window executables, the increase
runtime is so bad I have to consider using case E) although its going to
create more maintanability headaches.  (The codes I normal run take much
longer than the example used here).  The executable generated by B) is
not much of an option as I can't send the cygwin1.dll to other people
that what to run the codes and don't want to install cygwin on their
machines.

This is a straight forward example.  No disk usage or other fancy OS
stuff is being done.  My primary question is does anyone know why the
executables generated by Msys/Mingw or Cygwin with the -mno-cygwin flag
perform so much worse?  I don't know enough about the ramifications of
using the -ffast-math option to say that I would consider using this.
Does anyone know why the Release version produced by .Net is so fast?
(Is it doing some things similar to the -ffast-math option?)

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
--------------------------------------------------------------------------------

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

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
--------------------------------------------------------------------------------

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.

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

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?

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

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.

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

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3628854
By: earnie

Have you looked at the help provided at http://www.mingw.org
and http://www.mingw.org/MinGWiki/index.php

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575