On Thu, 15 Dec 2005 20:30:15 +0100 (CET)
Hubert Feyrer <feyrer@cs.stevens.edu> wrote:

> On Thu, 15 Dec 2005, Dieter Baron wrote:
> >  Not all packages' build system support this, many probably fail (or
> > become unreliable) when make is invoked with -j.
> 
> True.
> That's why I suggested a per-package maximum:
>
So what is the significance of per package maximum? I mean if package Makefile
has race conditions, then -j > 1 is likely to cause problems?? May be there
should be a boolean variable - PARMAKEJOBS, (which defaults to false) for
packages to secify support for parallel make jobs.

The user would then specify is mk.conf the max number of parallel make jobs.

The fact that when writing Makefiles it is trivial to introduce parallel races,
makes this job a nightmare for frameworks like pkgsrc. Also some packages use
bmake, some gmake, plust autoconf, automake, etc. This seems like a mess.

Things need to be done in a unified and consistant manner:

1. Precicely define machine architecture, operating system and its version,
compiler and linker used, operating environment and other capabilities needed
for building software 

2. Each package should have a maintainer, who creates customised Makefiles,
that support cross building, parallel make jobs and other features. Currently
pkgsrc Makefiles call Makefiles generated by autoconf and automake from
templates that came with software. I think this is the root of the problem.

Basically what I propose is to take a package, rip out GNU autoconf, automake
and similar crap and replace it with custom made rules and Makefiles. This
would be a unified framework for building software, not just a wrapper around
someone elses Makefiles.