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

[Garrett D'Amore]

On Sun, 2010-08-15 at 20:42 +0200, Joerg Schilling wrote:
> "Garrett D'Amore" <garrett at damore.org> wrote:
> 
> > I was under the (perhaps wrong) that smake was quite different from
> > Sun's dmake in that it could not support the same Makefiles.
> 
> Smake is of course different, but it supports a lot of the sunpro make features
> since I was interested to retain Sunpro make compatibility in the schily 
> makefilesystem without introducing many different implementations for similar 
> basic features.
> 
> Smake has the advantage that it supports to boostrap itself without the need 
> for a working make program. Once star is integrated into ON, all the 
> infrastructure for compilong other programs from me is present and it is really 
> simple to add more, e.g. smake
> 
> > 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.
> 
> There are currently very few things that are not supported. 
> 
> I could add support for these target dependent macros to find the real amount 
> of effort. There then would be still no support for sunpro dependencies and no
> parallel make support but we can see whether it is able to compile ON or 
> whether there are hidden undocumented features tthe ON compilation depends on.

I think trying to get to the point that smake can build ON would be very
useful.

> 
> Did someone already try to compile ON using the simple sunpro make?

When I build I use /usr/ccs/bin/make.  This does include parallelization
features.

> 
> Let me make a note: I am not willing to support some non-POSIX behavior from
> sunpro make. This is the usage of the dynamic macros "$*" and "$<" for explicit
> target rules. This usage is a bug (these macros only have defined values in case
> an inplicit target rule is executed) and would need to be fixed in the makefiles.
> As smake writes a warning in such a case, it is easy to find.

If the fixes to the Makefiles are easy to make, and there are not a
large number of Makefiles that rely on this, then I'm willing to accept
this limitation.

However, if we find that a large percentage of Sun Makefiles (such as in
ON) use these constructs in ways that would be hard to correct, then I
think we will need to reconsider.  The goal here is to provide a
solution that is minimally disruptive.

[snip!]

> Since 4 years, smake is the only make program I am aware of that does not dump
> core in case you use strings longer that aprox. 1 kB in a makefile. This is 
> because smake does not use static strings definitiuons.

Great.  Although why you would have such long strings in a Makefile is
surprising...  I guess with long dependency lists perhaps.

> 
> GNU make supports different makefile syntax and GNU make is written in a way 
> that makes it hard to maintain. It's maintainer is not very active, a serious 
> bug I reported in 1997 is still unfixed.
> 
> BSD make is much cleaner, but it has deviations from POSIX that have been 
> introduced to compile the BSD kernel sources. A few years I thought that it's 
> main problem was incorrect support for pattern matching macro expansions. Then 
> we fixed this but unlike Sun make and gmake it was not possible to let it 
> use the Schily Makefilesystem as BSD make chdirs to the target base dir which 
> causes problems with e.g. include paths.

I'm not too interested in either BSD or GNUmake.  Especially not GNU
make.  I do not want to become another GNU operating system; and I think
many here share that feeling.

> 
> > 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.
> 
> There is currently no plan to support distributed features but there is a plan 
> to add parallel make support.

Ok, well parallelization would be the most important anyway.  I've never
used the distributed functionality.

> 
> 
> BTW: it is interesting that we now start exactly at the same point we have been 
> in summer 2005 after I published SchilliX. 

I'd like to think we're at a somewhat different point.  For example,
many of the closed bits are no longer closed, and we have a fully open
libc.  We also have many more resources behind this than existed back in
2005 -- back then everyone expected Sun to play along.  Now the Sun has
set, and nobody expects any help from Oracle.

> 
> We have no source for a make program to compile ON (well maybe this could be 
> done with sunpro make but this source is not really portable)

Right now we build using sun make.  We do need a working "make" program
that we have source for, so that's what we're working on.

> 
> we do not have a recent libm source

This is being worked on.  It may be that the source we do have is recent
enough ... I'm not sure.

> 
> ON does not compile on a ON environment.

We're fixing this now. -)  See Richard's recent commit to eliminate the
dependency on the extra consolidation for example.

	- Garrett
> 
> Jörg
> 
> -- 
>  EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
>        js at cs.tu-berlin.de                (uni)  
>        joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
>  URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily