Re: Parallel make with distributed systems

[Paul Smith]

On Sun, 2015-05-03 at 09:31 +0200, SF Markus Elfring wrote:
> > I have nothing against doing more than that in theory, but before I'd
> > agree to add something complex I'd need to understand where the existing
> > method fails, and the new method would provide significant benefits.
> 
> I guess that there are some software development challenges around
> the specification which tasks should be performed on a local computer
> and which should be executed in a more powerful remote build environment.
> The corresponding work forwarding will also need some preparation steps.
> There are more constraints to consider for tasks besides elements like
> distributed compilation.

Yes, I have no doubt.  The question is, why is it the case that these
challenges, tasks, work, and constraints need to be handled within make
itself, rather than farmed out to a separate process via the SHELL
capability?

Offhand I can't see any reason why make has to internalize this effort:
it seems cleaner, and simpler, to me to have different job management
environments provide their own command line tool that can submit jobs to
be run, which could be used by any build system, and integrate that with
make via the SHELL variable rather than through a compiled-in API.

It's quite possible I'm just not seeing the benefits; if you have a
specific use-case in mind and could describe them, that would be very
helpful to the discussion.

> Would you like to make the build tool capable for the automatic selection
> of the preferred data processing system?

I don't really know how to answer that question... it's too vague.

Cheers!