role of executable_checksum & LTO?

[Joern Rennecke]

Quoting Basile Starynkevitch <basile@starynkevitch.net>:

> On Tue, 2010-06-29 at 12:50 -0400, Diego Novillo wrote:
>> On Tue, Jun 29, 2010 at 12:35, Basile Starynkevitch
>> <basile@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 svnpath@version till you get to a state where you are
more slower and deliberate when you change the format / semantics.