[illumos-Developer] interesting userland project -- non-trivial

[Garrett D'Amore]

I was under the (perhaps wrong) that smake was quite different from
Sun's dmake in that it could not support the same Makefiles.

If smake can support the same Makefiles that dmake does, and it supports
the needed parallel/distributed features and command line switches, then
I will heartily recommend we integrate it.

I'm in no way attached to the implementation.  And I don't want to adopt
GNU make or BSD make, if only because the syntax they support is
different (not even looking at the implementation issues you raise.)

So here's my thought:

If smake can build the existing ON tree, then we'll integrate it as
smake.  If it can do so using parallel build or distributed features,
then it can be "/usr/bin/make" as well.

If it can't do either of these, then it isn't as interesting to me, and
we should pursue a project to enhance existing make.

Hopefully that makes sense.

	- Garrett

On Sun, 2010-08-15 at 18:54 +0200, Joerg Schilling wrote:
> "Garrett D'Amore" <garrett at damore.org> wrote:
> 
> > So one of the tasks that someone who doesn't want to work on kernel
> > code, but is interested in a significant bit of userland work would be
> > to add the parallel/distributed features of dmake into the vanilla make
> > sources we have.
> >
> > We need it to be compatible with Sun dmake, so that we don't have to
> > change a zillion lines of Makefile, nor ask other projects to do so.
> 
> The code from the sun make program is not very clean. As a result it is hard to 
> port. It makes more sense to add the few missing features to smake. 
> 
> There is currently one main missing feature: the Sun Syntax:
> 
> target :=                MACRO= value
> 
> This feature is currently not in smake necause it in principle is a missdesign,
> as it introduced an incompatible and missleading syntax for := 
> 
> There was however a plan to support:
> 
> 
> target ?=                MACRO= value
> 
> to smake and to allow to switch smake into a sun make compatible mode via an 
> environment variable.
> 
> I also planned to add parallel make support to smak ethis year.
> 
> BTW: Do not think about using gmake as gmake is full of bugs, implement a non-POSIX 
> compliant makefile parser (bas backslash ans whitespace handling) and as gmake 
> inly implements toy paralell make support (there is no buffering for the output 
> and thus the messages are mixed from different parallel actions.
> 
> Jörg
>