Re: [PATCH 1/2] genopinit: Distribute generated code across multiple files

> But in my opinion we don't want to keep adding split code to every=20
> gen* file individually
> but concentrate that code in gensupport so ever gen* can use it.

The individual splits are there because I started out with one=20
(genemit), then later realized genrecog is large as well.  It was=20
certainly not the initial intention to split everything individually.
But I agree that by now we have reached a tipping point.

BTW I also touched opinit before, splitting one function into several,=20
because it would trigger pathological compiler behavior.
So we already perform some kind of splitting.  Are we sure we're not=20
actually seeing pathological behavior again that could be helped by=20
something else than file-level splitting?

> Lastly I also don't think splitting on an iterative way is going to=20
> give you the best compile
> time increase.  Because that tends to bias the output.
>
> In genmatch I use ftell to tell how big the files is so far an pick the s=
mallest file. This allows
> me to balance out the compile time over all files. I believe Robin eventu=
ally respun his
> gen<something> match to do this a swell as that allows you to amortize th=
e compile time
> over cores.

Yeah, I added your suggestion to the initial genemit split.  And at=20
least the "which file to write to next"/ftell functionality is not local=20
to genemit but already in gensupport.  The function is choose_output and=20
Kyryll's patch even uses it already so it shouldn't do iterative=20
splitting if I'm not mistaken.

Each gen* still keep track of its own files, though, and that part could=20
be unified still.  I don't think it's terribly difficult but will=20
require some plumbing.


--=20
Regards
 Robin