RFC: target macro->hook migration idea

[DJ Delorie <dj at redhat dot com>]

The rules for migration, as I understand it, are:

1. Force people to move forward, not back.

2. Make sure we don't end up with a half-migration.

The current migration is "Migrate one macro at a time" but that leads
to a messy target.h and forces every developer who wants to migrate
one macro to test many systems, which they may not have enough working
knowledge of to be able to do properly.

I suspect it would be better if we had a third rule:

3. Let the people who know, migrate their files.


So, I got an idea from Alex Oliva about building a migration layer for
some work I'm doing (so I can postpone migrating the other targets
until the appropriate time), but it violated rules 1 and 2 above.
Now I have an idea that might work...

The migration layer is a simple set of target hooks that just call the
target macros they're replacing.  So, for unmigrated targets, life is
as it was (er, is), but new work can use the target hooks instead.
More importantly, the common files can be converted to target hooks
with a much smaller effort.

This allows rule #3, as each target can be migrated by its maintainer,
who would be in the best position to debug any problems.  It also
allows the common files to be migrated by people who know how the
common files work.

It also allows us to design the target.h layout, rather than just
paste in hooks one at a time in an ad-hoc way.

We can thus migrate the common files way faster than we currently can.
Heck, we can migrate ALL the macros at once without creating a huge
task.  And we should do it that way, because that allows us to handle
rules 1 and 2.

As for rules 1 and 2, we would still poison the migrated macros.
The trick is that this is conditional - a backend tm.h can
ask for them to be unpoisoned like this:

	#define PLEASE_DONT_POISON_TARGET_MACROS

We might have to put it elsewhere, like the t-foo file, but you get
the idea.  This line would be added to all targets at the start, and
removed when the maintainer migrates their target.  This cannot be
added to any new targets.

It also makes it easy for us to detect (and harass ;) unmigrated
targets.

When most of the targets are migrated (or at some pre-determined
deadline), we make the poisoning unconditional and any unmigrated
targets just break.

A side effect of all this is we don't waste time migrating and testing
targets that end up deprecated anyway.