Re: parallel building documentation

[Rik]

On 07/09/2015 07:05 AM, John W. Eaton wrote:
> On 07/09/2015 01:09 AM, Mike Miller wrote:
>> On Wed, Jul 08, 2015 at 22:01:32 -0700, Rik wrote:
>>> The parallel building in the documentation directory makes for some
>>> confusing logs which is why we had the .NOTPARALLEL directive.  It's not
>>> the end of the world, just confusing, but is there any way to get that
>>> behavior back?  Here is an example from my finally successful compile job.
>> […]
>>> Note that it mixes build jobs from the etc/icons, doc/interpreter, *and*
>>> top-level directory (.gdbinit).
>
> The output from any parallel build could be confusing.  It's just more so when running tools like TeX that are chatty.  But now that we hide most of that by default, I don't think it should be too bad.  If you really want to see an easy to read log, then use -j1.
>
>> IMHO that's what I would want it to do. If you could do a make -j1000,
>> why not let it do everything it can in whatever order? If it can build
>> some icons at the same time as it's compiling liboctave, why not? Yes,
>> the output will be completely interleaved, but the end result should be
>> much more efficient.
>
> I agree.  Once I'm done, I hope that we will have fewer points where only one long job is running (for example, linking liboctave.la or generating octave.info).  That should speed things up a little if you are doing a parallel build.

What I see is that there is generally enough directory level parallelism to soak up processes so that there isn't waste either way you do the build, but I had a preference for the clearer structure.  No big deal though.

Because of the dependencies, the order of build is liboctave/ followed by a chokepoint on the link, libinterp followed by a chokepoint on the link, libgui and a chokepoint on the link, and then the src/ directory.  That is the bulk of the build and wouldn't change even if a machine supported -j1000.  I don't have the execution times to know if the remaining parts of the build --  doc/ etc/, examples/, test/, and top-level -- are 20% or 5% of the total build.  Certainly the doc/ directory is large enough to soak up parallel processes on its own, so then it's really a question of whether etc/, examples/, test/, and top-level  benefit tremendously from being run in parallel.  That seems unlikely, but I can always use -j1 if necessary.

--Rik