autotools transition report: autotools+dejagnu vs phil in a steel cage match

Gabriel Dos Reis
Fri Jul 25 08:41:00 GMT 2003

Phil Edwards <> writes:

| There's an interesting side idea here, at the end...
| On Fri, Jul 25, 2003 at 09:39:50AM +0200, Gabriel Dos Reis wrote:
| > Phil Edwards <> writes:
| > 
| > | anywhere because We Don't Build For The Target, We Build For The Host.
| > 
| > I should have put a note on that in the doc long time ago -- at the time, I
| > didn't feel that it was needed (I assumed I was the only who didn't know).
| > It would have saved you some nighmarre.  The terminologies are
| > "shifted" when it comes to libraries coming with the built compiler.  
| Oh, we've known that for a long time.  The existing comment in
| describing the shift was put there by me.

ah, I wasn't aware there was a comment to that effect in

| Where we've not been very careful, historically, has been using the word
| "target" to describe the platform in question.  All through our code,
| comments and variables refer to the qualities of the "target" machine... and
| it's true, because in the larger sense, it is the target machine after all.
| It's a confusing situation, but not an insurmountable one, and we just
| need to be on our guard against it.



| (Now, if you had known about the AC_CANONICAL_* names and their silent
| effect on automake, /that/ would have saved me the nightmare. :-) )

I was thinking of the AC_CANONICAL_* thingies -- I think I learnt
about those distinctions and shift when I tried to put support for
<limits> in the compiler.  I'm sorry.


| Possibly we can come up with alternative approaches, to prevent innocent
| mistakes.  The configury-poisoning trick works on identifiers that we'd
| like to prohibit completely.  For names that we'd like to restrict to
| only certain uses (e.g., "this one line and noplace else"), I'd be very
| interested in hearing any ideas that people have.

<this line is left blank>

-- Gaby

More information about the Libstdc++ mailing list