On Fri, 2006-02-03 at 06:56 +0000, Harlan Stenn wrote: > > On Fri, 2006-02-03 at 06:07 +0000, Harlan Stenn wrote: > > > Ralf, > > > > > > How about something that would use AC_RUN_IFELSE()? > > > > We are talking about distinguishing different compiler > > versions !!!!!!!!! > > No, we are talking about making decisions using, say, the version number > of a tool or the output of config.guess (or something like that). > > > Why on earth would you want to run something conditionally, depending on > > which compilers it had been compiled with? > > I don't know, but that doesn't mean there isn't a good reason do to it. My point is: There can't be the slightest reason. > > > There's a reason it come with ACTION-IF-CROSS-COMPILING - it means one > > > CANNOT feature test so one has to make the decision beforehand and > > > decide based on some other factors. > > > > You are talking about a package using a toolchain to require _target_ > > run-time features. Right, these are occasionally required. > > > > But we are talking about compiler/toolchain features. The cross > > compilers/toolchains *never* retrieve anything from a target at > > run-time. > > Perhaps we had a little confusion about exactly what we were talking > about. > > I was going off about folks who say "the only way to go is feature test > - never rely on version numbers", Basically, I am amongst those, but I say: Avoid them whenever possible and think a 100 times before relying on them. They should be the absolute least resort if all else fail. > as I have had that discussion before > and it included testing based on OS type or version. I don't recall this particular discussion, but I recall many such discussions. > In general I prefer to test. If that's "too difficult" I'll go for > version numbers or the CPU-Vendor-OS string (I have something that > converts the output of config.guess and some optional local poking > around into something I find useful). Ouh, there is are subtile difference between using the canonicalization triple (cpu-vendor-os) and checking a tool's version. The canonicalization triples are user input, which fall back to automatically detected defaults, using a fairly evolved and complex machinery underneath (config.guess). In case of cross-compilation, they are always user-specified input (--host=mytarget), and not automatically detected - This makes a huge difference: User input vs. fragile and error-prone checks. > > If the toolchains require knowledge about a target's runtime feature, > > the toolchains must know about it in advance, but the > > application/package using the toolchain doesn't have to. It can > > compile/link check the toolchain. > > This is simply a degenerate case. We could certainly go back to the old > days where folks said #ifdef BSD or #ifdef SYSIII. > > The point I was trying to make is that "feature testing is good and we > cannot always do it TODAY. Sometimes we must use another way, like > version numbers." Well, I disagree on this. I say, try to use a feature test if possible. Esp. for compilers it is really hard to find a case where this isn't possible (I don't know any), in particular, if you consider that you normally have a test case exposing a toolchain issue - Otherwise you wouldn't want to implement a "version check" ;) Ralf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf