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

[Joerg Schilling]

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

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

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.

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

I started smake in 1984 in order to learn how a make program works.
I started to make smake fully featured after I discovered that GNU make compiles
on many platforms but does correctly only work on a very limited number of 
platforms. In order to allow my software to become portable I needed a 
really portable make program.

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.

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.

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


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

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)

we do not have a recent libm source

ON does not compile on a ON environment.

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