From: SourceForge.net <no...@so...> - 2005-05-17 15:22:03
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3155889 By: earnie If it is GNU Standard source then the makefile line should read @for subdir in "$(SUBDIRS)"; do The quoted empty string works well. The quoted empty string is what should be used. Changes to the Makefile.am or Makefile.in, which ever is appropriate, will need to be made. This should be considered a bug by the source maintainer. 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 |
From: SourceForge.net <no...@so...> - 2005-05-17 15:58:23
|
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 |
From: SourceForge.net <no...@so...> - 2005-05-17 16:08:25
|
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 |
From: SourceForge.net <no...@so...> - 2005-05-17 16:09:06
|
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 |
From: SourceForge.net <no...@so...> - 2005-05-18 02:13:56
|
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 |
From: Michael S. Z. <ms...@mo...> - 2005-05-18 11:48:35
|
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 |
From: Michael S. Z. <ms...@mo...> - 2005-05-18 11:59:30
|
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 |
From: SourceForge.net <no...@so...> - 2005-05-20 01:40:44
|
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 |
From: SourceForge.net <no...@so...> - 2005-05-20 09:59:30
|
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 |
From: SourceForge.net <no...@so...> - 2005-05-20 10:09:49
|
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 |
From: SourceForge.net <no...@so...> - 2005-07-20 02:32:39
|
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 |
From: SourceForge.net <no...@so...> - 2005-07-20 08:48:16
|
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 |