Re: Checking for GCC 4

[Ralf Corsepius]

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