MinGW - Minimalist GNU for Windows

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

As Earnie has said, the required syntax is

@for subdir in "$(SUBDIRS)"; do ...

the idiom omitting the quotes results in invalid syntax in *any* POSIX conforming
shell, and indeed, in any traditional Bourne shell, if $(SUBDIRS) is null.

I may be wrong, but I believe that this for loop is actually evaluated by make
itself, rather than by a spawned shell, so even if you did install a shell which
accepted this invalid syntax, the Makefile would probably remain broken.

As a side note, not all shells handle variable expansion and word splitting
in the same order.  The portable way to write the above for loop, when it *is*
to be evaluated by a shell, is

for subdir in ""${SUBDIRS}; do ...

or

eval for subdir in "${SUBDIRS}"; do ...

If you quote "${SUBDIRS}", and don't use eval, most shells will evaluate "${SUBDIRS}"
as a single valued loop iterator,  and will not iterate through the list of
SUBDIRS, which is presumably what is intended.

Regards,
Keith.

______________________________________________________________________
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

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

In fact,having checked it more thoroughly, the

eval for ...

form doesn't work!  You have to use

for subdir in ""${SUBDIRS}; do ...

Sorry any confusion caused.

Regards,
Keith.

______________________________________________________________________
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

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

Thanks for correcting me.  I learned something new.

______________________________________________________________________
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

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

I have build a copy of Bash 3.0 which really fixs some bugs. But I have found
it still unstable when using it. For example, when I compile some open source
code in Bash shell 3.0, I am always confroned with some strange errors that
I don't know how to solve it. The same conduct can be done in Bash shell
2.04.0(1)-release . So I still use Bash shell  2.04.0(1)-release now.

______________________________________________________________________
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

On Tue May 17 2005 21:13, SourceForge.net wrote:
> 
> Read and respond to this message at: 
> https://sourceforge.net/forum/message.php?msg_id=3156948
> By: heromyth
> 
> I have build a copy of Bash 3.0 which really fixs some bugs. But I have found
> it still unstable when using it. For example, when I compile some open source
> code in Bash shell 3.0, I am always confroned with some strange errors that
> I don't know how to solve it. The same conduct can be done in Bash shell
> 2.04.0(1)-release . So I still use Bash shell  2.04.0(1)-release now.
> 
Would you post it somewhere?
Perhaps also some examples of the 'strange errors' ?
Mike

On Wed May 18 2005 06:48, Michael S. Zick wrote:
> On Tue May 17 2005 21:13, SourceForge.net wrote:
> > 
> > Read and respond to this message at: 
> > https://sourceforge.net/forum/message.php?msg_id=3156948
> > By: heromyth
> > 
> > I have build a copy of Bash 3.0 which really fixs some bugs. But I have found
> > it still unstable when using it. For example, when I compile some open source
> > code in Bash shell 3.0, I am always confroned with some strange errors that
> > I don't know how to solve it. The same conduct can be done in Bash shell
> > 2.04.0(1)-release . So I still use Bash shell  2.04.0(1)-release now.
> > 
> Would you post it somewhere?
> Perhaps also some examples of the 'strange errors' ?
> Mike
Third question...
Which patches did you apply?  There are at least 16 patches against
bash-3.0 to fix found problems.
Mike

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

I tried 

for subdir in ""${SUBDIRS}; do ...

but bash (or make) treated the empty string as a single item list, and ran the
loop once. Within the loop is a

(cd $$subdir && $(MAKE) $$target)

and it treated the $$subdir of "" as my home directory!

$ make
making all in include
make[1]: Entering directory `/c/Dev/scheme/gambc40b13/include'
making all in
make[2]: Entering directory `/home/e'
make[2]: *** No rule to make target `all'.  Stop.
make[2]: Leaving directory `/home/e'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/c/Dev/scheme/gambc40b13/include'
make: *** [all-recursive] Error 1

So, I see no way to accomodate this idiom yet.

e


______________________________________________________________________
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

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

Why do you want to use such an idiom, if $(SUBDIRS) is empty?  Just write the
body of the for loop once, without the enclosing `for ...; do ...; done

Of course, if the definition of SUBDIRS is generated by running configure, and
an empty expansion *is* both possible and acceptable, then you should extend
the idiom, (using Makefile semantics):

if test -n "$(SUBDIRS)"; then   for subdir in ""$(SUBDIRS);     do (cd $$subdir && $(MAKE) whatever);     done; fi

That way, if SUBDIRS *does* have an empty expansion, then the for loop will
not be executed.  However, notice that you still need the ""$(SUBDIRS) idiom,
to satisfy the shell's syntax rules, when parsing the command.  Also notice
the parentheses around the `cd $$subdir && ...' command; these simply ensure
that each invocation of the loop starts out with the same notion of the current
directory.

BTW, invoking the above Makefile fragment, but omitting the "" before the $(SUBDIRS)
in the for statement, and with SUBDIRS undefined, results in error messages
which suggest that make *does*, in fact, spawn /bin/sh to execute the for loop.

HTH.

Regards,
Keith.

______________________________________________________________________
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

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

Please ignore the first paragraph of my preceeding post; of course, what I meant
was: just leave the whole construct out, altogether :-)

Regards,
Keith.

______________________________________________________________________
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

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

add "" seems don't work under GNU make, I solve it  
by this way:

# for win32 shell, translate '/' to '\'
dep_cdir        = $(shell echo $(OBJDIR) | sed 's/\//\\//g')
dep_cwd         = $(shell pwd)

DUMMY_DIR       := /dev/null
DEPSUBDIRS      = $(SUBDIRS)
DEPSUBDIRS      += $(DUMMY_DIR) #some shell doesn't support `for' with empty
argument list such as msys shell(sh-2.04)

dep:
        if [ -f .objs ];         then                 for src in `find $(dep_cwd) -name '*.[cCs]' -maxdepth 1 -mindepth
1`;                 do                              $(DEPTOOL) $$src $(INCLUDE) 2>>$(DEPERRLOG) | sed -e
's/^\(.*\.o:\)\(.*\)/$(dep_cdir)\/\1\2/g' -e 's/ /\ /g' >.depend &
& echo -n "." ;                 done;                 echo "";         fi;
        if [ ! "$(DEPSUBDIRS)" = "$(DUMMY_DIR)" ];         then                 for dir in $(DEPSUBDIRS);                 do                              if [ ! $$dir = "$(DUMMY_DIR)" ];                         then                                 $(MAKE) $@ -C $$dir || exit 1;                         fi;                 done;         fi

______________________________________________________________________
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

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

<quote author="wangbaojun">
# for win32 shell, translate '/' to '\' 
dep_cdir = $(shell echo $(OBJDIR) | sed 's/\//\\//g')  
</quote>

If you have to do this with the MSYS version of make then something isn't correct.
Either you are not using the MSYS make or there is a bug.

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