This is the mail archive of the
mailing list for the libstdc++ project.
Re: autotools transition report: autotools+dejagnu vs phil in a steel cage match
Phil Edwards <email@example.com> 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 <firstname.lastname@example.org> 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 configure.in
| describing the shift was put there by me.
ah, I wasn't aware there was a comment to that effect in configure.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>