Re: config.cache considered harmful
> test "x$foo" != "x" I'm in the habit of writing it like this: test x"$foo" != x""
Re: config.cache considered harmful
Harlan Stenn <[EMAIL PROTECTED]>: > 2> I'm in the habit of writing it like this: test x"$foo" != x"" > And exactly why are you using both the quotes and the x? quotes because this fails: foo='hi there' test x$foo = xbar x because this fails: foo='!' test "$foo" = "bar" It's always safe to write string compares as: test x"$foo" = x"bar" and it's simpler to do so uniformly than to prove whether a particular $foo can only have safe values or not. --
Re: problem with multiple -e flags for egrep
Akim Demaille <[EMAIL PROTECTED]>: > In fact I've thought all the RE engines were the same, so a failing > sed would be a failing egrep. But actually the problem we faced was > an anchor inside a paren group, which I had generalized a bit too fast > to all the `complex' structures. Maybe alternation doesn't suffer > from this. yes, afaik it's only sed /\(^foo$\)/ that isn't portable. egrep '(^foo$)' and '^foo|bar$' should be fine. (sed /\(^foo$\)/ fails to do what you expect on an obscure OS known as 'solaris', which appears to have two or three different regexp engines, and about five man pages describing them.) --
Re: [cygnus.egcs.patches] Patch for IFS
Alexandre Oliva <[EMAIL PROTECTED]>: > BTW, this won't work as expected if `configure' is generated on > platforms that use CR+LF as line separators. We should probably try > to find some way that does the right thing even in such contexts. how about IFS=`echo 'abc' | tr 'abc' '\040\011\012'` --
Re: [cygnus.egcs.patches] Patch for IFS
Alexandre Oliva <[EMAIL PROTECTED]>:
> This assumes ASCII. We've just removed the latest assumptions of
> ASCII, so it wouldn't be wise to re-introduce them :-)
oh. hmm. then how about using awk?
IFS=`awk 'BEGIN { printf " \t\n" }' /dev/null`
--
Re: [cygnus.egcs.patches] Patch for IFS
Alexandre Oliva <[EMAIL PROTECTED]>:
> > IFS=`awk 'BEGIN { printf " \t\n" }' /dev/null`
> Did you know that shells do eat up trailing new-lines, and that's why
> we can't do it this way? :-)
so reverse it.
IFS=`awk 'BEGIN { printf "\n \t" }' /dev/null`
--
Re: [cygnus.egcs.patches] Patch for IFS
Alexandre Oliva <[EMAIL PROTECTED]>: > I think awk is overkill for that, since it can be done with plain > echo. Moreover, I'm not really sure `\t' and `\n' are portable AWK. well, I'm not fond of embedding tabs in scripts. \t and \n should be portable awk. they were in the original awk. --
Re: Definition of cross-compiling
Akim Demaille <[EMAIL PROTECTED]>: > - Ideal cross compiling situation: > The user said --host. This gives a better control than build != host. what if I'm specifying --host because for some reason I don't like the string that config.guess comes up with? for instance, I'm building on a sparc-sun-solaris2.5.1 but I happen to know that it will work on sparc-sun-solaris2.5 as well, so I'd rather use that string as --host. --
Re: rfc: new libgcc build mechanism
Akim Demaille <[EMAIL PROTECTED]>: > PS/ I have a bizarre demand to make: does anybody know a means for me > to have an access to a wide set of old systems? how about, work for a company that supports them? cygnus has a couple of old systems lying around. no 4.3bsd though. perhaps it would be nice to set up a farm of assorted systems, available for general nonprofit freesoftware use, but I can't think of a reasonable way of doing it offhand. --
Re: rfc: new libgcc build mechanism
Donn Terry <[EMAIL PROTECTED]>: > The current partial solution involves having two the-same-but-different > versions of the same string, with different levels of \ quoting > of ` (to allow nesting of `). what do you gain from nesting `` that you can't do by using temp variables? I can't think of a case where they aren't equivalent. --
Re: rfc: new libgcc build mechanism
Donn Terry <[EMAIL PROTECTED]>: > Sort of as a poll: on what systems is the getconf > command not present, and which ones have it but not of the systems I have easy access to, these are the oldest that have it and the newest that don't. aix 4.2 /bin/getconf hpux 10.01/usr/bin/getconf irix 5.3 no irix 6.2 /usr/sbin/getconf solaris 2.5.1 /usr/bin/getconf sunos 4.1.4 no redhat 5.0/usr/bin/getconf ultrix 4.4no unixware 2.1.1/bin/getconf --
Re: rfc: new libgcc build mechanism
Donn Terry <[EMAIL PROTECTED]>: > I don't follow. The inner echo outputs the value of the > CC macro, and munges it for the "stage" change. The outer > echo makes it a string (as opposed to a command to be > executed) to pass it to the second sed to do .. insertion. sorry, that makes no sense to me. I think you're confused. this is perfectly legal make & sh: FOO=` \ case '$(CC)' in \ (stage*) \ echo '$(CC)' | \ sed -e 's|stage|../stage|g' \ ;; \ (*) \ echo '$(CC)'\ ;; \ esac | \ $(PREPEND_DOTDOT_TO_RELATIVE_PATHS) \ ` you don't need to wrap the case statement in an `echo`. I put while loops and case statements and if statements in middle of pipelines all the time. btw, using balanced () for case statements isn't portable. --
Re: rfc: new libgcc build mechanism
Donn Terry <[EMAIL PROTECTED]>: > SUBDIR_FLAGS_TO_PASS = $(ORDINARY_FLAGS_TO_PASS) \ > "CC=$$(echo @cc_set_by_configure@ | > $(PREPEND_DOTDOT_TO_RELATIVE_PATHS) )" oh, I see. you didn't mention @cc_set_by_configure@ in your original example. ok. hmm... this is ugly, but seems to work, and I don't recommend it. but at the moment I can't think of another solution without major restructuring. cc_0=`echo "$(CC)" | sed -e 's/^/cc0:/'` # or this: #cc_0=testing PREPEND=sed -e 's/^/pre:/' FLAGS= "cc_1=$(cc_0)" \ "CC=\`echo \$$(cc_1) | $(PREPEND)\`" first: make $(FLAGS) next next: echo "$(CC)" --
Re: rfc: new libgcc build mechanism
Donn Terry <[EMAIL PROTECTED]>: > That would be nice... in fact configure HAS done a meta > build to presumably fix as much as it can. However, CC can > be passed in on the make command line, and thus needs to be > munged at make time, so the munging needs to be in the makefile. or you can use a two-stage make. (ie, Makefile just writes vars.mk then invokes 'make -f vars.mk -f build.mk') --
Re: rfc: new libgcc build mechanism
[EMAIL PROTECTED] (Paul D. Smith): > I'm a little concerned that the & token isn't supported by all versions > of sed, either, but I couldn't find any examples... anyone have thoughts > on the portability of that? s//&/ has been in ed forever, so it should be in all versions of sed too. --
Re: rfc: new libgcc build mechanism
Donn Terry <[EMAIL PROTECTED]>: > PREPEND_DOTDOT_TO_RELATIVE_PATHS = sed \ > -e 's|^ *[^ /][^ /]*/|%&|' \ > -e 's| -B| -B%|g' \ > -e 's|% *[^- /]|%&|g' \ > -e 's|%% *|../|g' \ > -e 's|%||g' > SUBDIR_FLAGS_TO_PASS = $(ORDINARY_FLAGS_TO_PASS) \ > "CC=$$(echo $$(case '$(CC)' in (stage*) echo '$(CC)' | sed -e > 's|stage|../stage|g';; (*) echo '$(CC)';; esac) | > $(PREPEND_DOTDOT_TO_RELATIVE_PATHS) )" ugh. I'm generally against complicated constructs in Makefiles. ideally, I want my build scripts to have no conditionals or substitutions in them. my preferred strategy is to have a meta-build script that emits a very simple build script that is linear and easy to understand. But anyway. in this case, I don't see why you need the outer $(echo). you can just delete it. but in the general case... ok, you want to do something like: vars= "x=1" "y=`foo 1`" "z=$$(bar $$(foo 1))" recurse: (cd subdir; make $(vars)) my first instinct is to extract the '$(bar $(foo))' into a single function, by using a shell script, call it barfoo.sh. #!/bin/sh x=`foo "$@"` bar "$x" and then you can write the makefile as: vars= "x=1" "y=`foo 1`" "z=`$(aux)/barfoo.sh 1`" recurse: (cd subdir; make $(vars)) my second instinct is to evaluate all those vars and write their values into a file, and use recurse: $(tmp)/vars.mk (cd subdir; make -f $(tmp)/vars.mk -f Makefile) --
Re: rfc: new libgcc build mechanism
Felix Lee <[EMAIL PROTECTED]>: > cc_0=`echo "$(CC)" | sed -e 's/^/cc0:/'` > # or this: > #cc_0=testing > > PREPEND=sed -e 's/^/pre:/' > FLAGS= > first: > make $(FLAGS) next > next: > echo "$(CC)" ok, on second thought, a better way of doing this is to move the computation of the value for CC into the shell commands, something like so: cc_0=`echo "$(CC)" | sed -e 's/^/cc0:/'` # or this: #cc_0=" tes ting " PREPEND=sed -e 's/^/pre:/' FLAGS= first: cc=$(cc_0); \ cc=`echo "$$cc" | $(PREPEND)`; \ make $(FLAGS) "CC=$$cc" next next: echo "$(CC)" --
Re: acgeneral.m4 & unsupported case patterns
Akim Demaille <[EMAIL PROTECTED]> wrote: > BTW, what is the right spelling? > Built-in, builtin, built in. What is the plural? www.m-w.com says 'built-in'. elision of hyphens is typical in language evolution, so 'builtin' may eventually become 'normal' english. no special plural noted for the noun form, so 'built-ins'. --
Re: Detecting DJGPP, Cygwin, Mingwin and EMX OS/2
Alexandre Oliva <[EMAIL PROTECTED]>: > if (cd c:\\ && cd .. && test `pwd` = "C:\\") 2> /dev/null there doesn't have to be a c:. I've seen a system where the only disk is a hard drive named a:. --
Re: --host => cross breaks GCC builds
Akim Demaille <[EMAIL PROTECTED]>: > I'm sorry, but I disagree. The only sane and simple definition of > cross-compilation is when --host is specified. so what do you do if config.guess is wrong and you want to specify the --host string exactly, but you don't want a cross-compile? --
Re: --host => cross breaks GCC builds
Alexandre Oliva <[EMAIL PROTECTED]>: > If your problem is with the result of config.guess, what you want to > specify is --build, not --host, because config.guess can only guess > that the build platform is. ok, that's fine. --
Re: bug in cvs-autoconf
Lars J. Aas writes: > : -for warning in `IFS=,; echo syntax,$WARNINGS,$warnings | tr [A-Z] [a-z]` > : +for warning in `IFS=,; echo syntax,$WARNINGS,$warnings | tr '[A-Z]' '[a-z]'` > Why use the braces at all? Are they really necessary? tr A-Z a-z has > always worked for me, and that format won't be expanded by the shell. The square brackets were a system-V-ism, SVID era. I don't have any manuals from that era any more, but I seem to think that 'A-Z' without the brackets would be considered just three chars, not a range. this was completely different from BSD Unix behavior, but '[A-Z]' worked on BSD cuz its tr would treat the '[' as a non-magic character and translate '[' to '['. so script writers just used '[A-Z]' all the time in self-defense. these days, we have POSIX thingies in tr like '[:alpha:]' so '[' is magic again, sometimes, depending. --
Re: expr "..." : "\(.*\)" is limited on size!
appears to work on sunos 4.1.4
btw, the length limit is 120 bytes, not 128.
Paul Eggert <[EMAIL PROTECTED]>:
> We could use AWK as a fallback if the standard tools fail. However, I
> think we can do it with the standard tools. The following works for
> me, using Solaris 8 /usr/ucb/expr (sorry, I no longer have a SunOS 4
> host to test with).
>
> # Prefer expr to sed, since it's usually faster and it handles
> # newlines correctly. However, SunOS 4 expr and Solaris
> # /usr/ucb/expr have a silly length limit that causes expr to
> # fail if the matched substring is longer than 128 bytes.
> # So use sed if expr fails.
> dirname=`expr "X$filename" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
> "X$filename" : 'X\(//\)[^/]' \| \
> "X$filename" : 'X\(//\)$' \| \
> "X$filename" : 'X\(/\)' \| \
> . : '\(.\)' \
> 2>/dev/null` ||
> dirname=`
> sed '
> /^\(.*[^/]\)\/\/*[^/][^/]*\/*$/{ s//\1/p; q; }
> /^\(\/\/\)[^/].*/{ s//\1/p; q; }
> /^\(\/\/\)$/{ s//\1/p; q; }
> /^\(\/\).*/{ s//\1/p; q; }
> s/.*/./p; q
> ' < $filename
> EOF
> `
>
Re: Meta list issue: subject prefixes
Akim Demaille <[EMAIL PROTECTED]>: > Earnie> Not all. Only some. Akim's posts are being repeated. > > ??? If someone has some clues, please tell me what I should do/check. doesn't look like your fault. message-ID is the same, all the headers are the same up to fencepost.gnu.org, and at fencepost it gets duplicated and processed twice. --
