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

[Joerg Schilling]

"Garrett D'Amore" <garrett at damore.org> wrote:

> 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.

Onless you changed "nightly" or fiddle with environment variables, "dmake" will 
be called instead.


> > 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.

There are 71 potentially incorrect calls to "$*", I cannot easily count the number 
of incorrect calls to "$<". There are ~ 3000 calls but the vast majority is 
obviously legal calls.

> 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.

Let us try to bring smake close to be able to compile, then smake will list the 
incorrect calls as warnings.


> > 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.

Well, smake did use static arrays like the other make implementations. We did 
come into problems with compiling the software that is to access the new German 
electronic ID card on Microsoft. I forgot the ecact problems.


> 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.

It seems that I was the first to mention this in 2004 already ;-)


> > 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.

This is interesting, as it seems that Sun did add the distributed feature in a 
time when machines did have very few CPUs. In theory, this is doable but I 
currently don't see a real usage for this feature.


> > 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.

Well, things did change gradually. 


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