Quoting Basile Starynkevitch <bas...@starynkevitch.net>:
On Tue, 2010-06-29 at 12:50 -0400, Diego Novillo wrote:
On Tue, Jun 29, 2010 at 12:35, Basile Starynkevitch
<bas...@starynkevitch.net> wrote:
> I agree, but a plugin could also do likewise, e.g. write memory contents
> in some kind of persistent storage.
Why don't we cross that bridge when we get to it?
[I am not sure to understand the above sentence. What is the bridge?
What is crossing it? Remember that I am not a native English speaker]
It means don't borrow trouble.
I.e. it is not a problem we face now, and when/if we should ever face it,
there is still time address it. In programmer's terms, lazy evaluation.
There is also another aspect to this: when you face an actual problem,
you know more detail about what the problem actually is.
The main "data" which is reusable from one version of GCC to the next is
the object *.o files produced by GCC (& processed by the linker), but
this is possible because there are tons of conventions & specifications
& formalizations of what exactly such object files contain (and dozens
of years of past experiments). We don't have such precise & experimented
definitions for other data produced by GCC or plugins (e.g. LTO or PCH
or an hypothetical ccache-like plugin data).
If we don't know what our data means, we are in trouble.
If you mean we'll change the format / semantics often initially, that
can be addressed by an equally fast changing version number. You can
start out using svnp...@version till you get to a state where you are
more slower and deliberate when you change the format / semantics.
