It's common to have packages that generate header files out of
configure options. If prefix changes from configure to build time,
the header files end up incorrect.
That would be a bug, according to the present spec.
Ok, so the right thing to do is to generate the header files at build
time, based on `make' options, right?
Yes.
But then, what if someone
starts a build with `prefix=/foo', modifies some files, then re-starts
with `prefix=/bar'?
Indeed, that would lead to bad results.
I see the point you're making. If prefix were only a configure-time option,
that problem could not happen. That would be an advantage.
That raises two questions:
* Is the advantage big enough to justify the incompatible change
of saying "You can't specify the prefix when you run Make"?
* What about other related Make variables, such as *dir?
Should they all be configure time options too?
If yes, that is a much bigger incompatible change.
If not, then prefix would be treated differently from the rest;
that lack of consistency is also not a good thing.
All in all, I don't see that the change is clearly an improvement.
However, it *might* be a good idea to say that all configure scripts
should accept --... args to specify all these directories and
encourage people to use them that way. (It looks like
Autoconf-generated scripts already support them.)
