> how many question are you still going to ask?
Is there a set limit? I think you are giving out useful info.
> > Why this cannot be substituted by "sub-builds" (with many or most modules that are
> > untouched in the release, disabled) and only do the final build once?
> > (and I believe that is what you guys do anyway...?)
> because if you don't build the whole tree, you could break some dependence (e.g. of a
> different driver from the one you're working on, which shares some components) and
> doing so you could stop some other devs' work. and checking over and over which
> components are interconnected takes sometimes as much time as compiling the complete
> tree from scratch.
Clear. Also means that there is need to be some more restructuring to make it more oo and modular? (which AFAIK MAME takes pride that IS like that already)
> also, most of the complains were about building time of the maintainer before a
> release: you do realize that before every release the maintainer compiles baseline,
> debug, SDL and (when applicable) MSVC builds to be sure that everything compiles fine
> and only after that packaging a release? add the times you have to fix a compile and
> start from scratch, and maybe you will start to understand the magnitude of time we
> are talking about
Also clear, still I am curious to read real numbers on a typical machine.
> > If someone is responsible for the builds (or even more than one person), how hard
> > it to raise a fund to pay for the extra hardware needed?
> because this is not a job. taking care of releases should not be an obligation due to
> people having paid for that, or it would get very close to obligations towards paying
> clients at work
Of course this is not a job. I see what you are saying. Funding some better hardware I don't think crosses the line though in obligating someone (that already IS doing THIS part).
As a general comment personally I think this thread is becoming a great read on the whole subject of merging. Maybe something to revisit sooner or later. (hopefully sooner)