Re: Checking for GCC 4

[Harlan Stenn]

> > > 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.

Why could there never be a reason?

The world I live in shifts and changes.

> > > > 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.

Because they CANNOT, which means we (as package developer) CANNOT use
what would ordinarily be a "run this command and tell me the answer"
test, which means we must use some other method to make the decision,
which means (for example) the version number string or some other test
(which may be instruction from the person running "configure").

> > 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.

'k...

> > 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 a subtle 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).

The user supplied value or the first-pass result from config.guess goes
thru config.sub (as I recall) to be put in *a* canonic form.

I maintain that the 4-part gnu-linux versions are pretty much useless.

> 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.

Not really, mytarget is still run thru config.sub to make sure it's in a
canonic form.

And I'm not sure which is more fragile, user input or coded checks.

I'm getting tired tonight...

H