Required to fix a few errors where some enum->int->wchar_t* casting happens.
This repository contains the Illumos make source code (in branch
illumos) and based on that a port to Linux (branch
The Illumos make is based on Sun's dmake, which is compatible to Sun make.
Motivation: compile old Solaris projects (that use Sun make) under Linux without much effort. Think: the C code needs serious fixing because it includes metric tons of non-portable constructs such that you want to postpone the porting of the existing build system (which heavily uses Sun make specific extensions).
Another motivation to use a Sun compatible make might be the inclination to test one of its extensions, e.g. target groups, command and hidden dependencies.
2016, Georg Sauthofff email@example.com
git clone https://github.com/gsauthof/somake.git mkdir somake-build cd somake-build cmake ../somake -DCMAKE_BUILD_TYPE=Release make
Or to use Ninja instead of GNU Make:
git clone https://github.com/gsauthof/somake.git mkdir somake-build cd somake-build cmake ../somake -DCMAKE_BUILD_TYPE=Release -G Ninja ninja-build
The following assumes that the repository was cloned to the
somake and that
somake-build is the build
Copy the example files and the basic rule file for testing:
$ cd ../somake-build $ cp -r ../somake/example/ . $ cp ../somake/bin/make.rules.file example/make.rules $ cd example $ ln -s ../somake
Compile the hello world program:
$ ./somake -m serial helloworld cc -o helloworld helloworld.c
Verify that make detects that no rebuild is necessary:
$ ./somake -m serial helloworld `helloworld' is up to date.
Test command dependencies:
$ ./somake -m serial helloworld CC=gcc gcc -o helloworld helloworld.c
Also works for other variables:
$ ./somake -m serial helloworld CC=gcc CFLAGS=-Wall gcc -Wall -o helloworld helloworld.c
Test hidden dependency checks:
$ ./somake -m serial hello cc -c hello.c cc -c world.c cc hello.o world.o -o hello $ ./somake -m serial hello `hello' is up to date. $ touch world.h $ ./somake -m serial hello cc -c hello.c cc -c world.c cc hello.o world.o -o hello $ ./somake -m serial hello `hello' is up to date. $ touch world.h $ ./somake -m serial world.o cc -c world.c $ ./somake -m serial hello cc -c hello.c cc hello.o world.o -o hello
Note that command and hidden dependencies are enabled by declaring the
.KEEP_STATE: pseudo target.
Test target groups:
$ ./somake -m serial main_foo ./gen_foo.sh cc -c main_foo.c cc -c foo.c cc foo.h main_foo.o foo.o -o main_foo
Now remove the
+ in the generating rule
foo.c + foo.h: gen_foo.sh ./gen_foo.sh
and run again:
$ ./somake -m serial clean $ rm .make.state $ ./somake -m serial main_foo ./gen_foo.sh cc -c main_foo.c ./gen_foo.sh cc -c foo.c cc foo.h main_foo.o foo.o -o main_foo
Note that the
./gen_foo.sh action is now executed twice because the rule
foo.c foo.h: gen_foo.sh ./gen_foo.sh
is equivalent to two separate rules:
foo.c: gen_foo.sh ./gen_foo.sh foo.h: gen_foo.sh ./gen_foo.sh
This is how classic make behaves - also GNU make - although in this toy example it is harder to trigger - because in sequential execution GNU make uses a advantageous timestamp comparison strategy:
$ make main_foo ./gen_foo.sh cc -c -o main_foo.o main_foo.c cc -c -o foo.o foo.c cc main_foo.o foo.o -o main_foo
But a parallel execution will do:
$ make -j3 main_foo ./gen_foo.sh ./gen_foo.sh cc -c -o main_foo.o main_foo.c cc -c -o foo.o foo.c cc main_foo.o foo.o -o main_foo
Note that GNU make supports target groups with pattern rules, though:
$ make -j3 both echo x > foo.bar sed 's/x/y/' foo.bar > foo.one sed 's/x/z/' foo.bar > foo.two
With Sun make the same result is yielded iff a
+ is inserted between both
$ ./somake -m serial both echo x > foo.bar sed 's/x/y/' foo.bar > foo.one sed 's/x/z/' foo.bar > foo.two
The example makefile also contains an example for Sun make style conditional
macro assignments (with
$ ./somake -m serial warn-helloworld cc -Wall -o helloworld helloworld.c
The combination with command dependencies makes this feature even more useful:
$ ./somake -m serial warn-helloworld cc -Wall -o helloworld helloworld.c $ ./somake -m serial helloworld cc -o helloworld helloworld.c $ ./somake -m serial warn-helloworld cc -Wall -o helloworld helloworld.c
In contrast, GNU make doesn't rebuild
helloworld because it doesn't
consider changed variables.
Illumos is based on OpenSolaris, the now discontinued open-source version of Solaris. OpenSolaris was started by Sun after the Solaris 10 release and was closed down in 2010 after Oracle bought Sun. Sun used the CDDL license on its open sourced code.
Traditionally, Solaris includes it own version of
/usr/ccs/bin/make, also known as 'Sun make'. It has some
extensions over other make versions, such as BSD make and
POSIX make. It only supports sequential execution
(unlike e.g. GNU make), however, Sun also developed
(think: distributed make), usually bundled with the Solaris
compiler suite 'Solaris Studio'. Dmake is compatible
with the Sun make syntax and besides serial execution it supports
parallel execution on an SMP system and on a cluster (apparently
similar to distcc). It was also open-sourced by Sun
under the CDDL.
Illumos started with the code base that included the original Sun make but later switched to dmake.
Comparison with other make Implementations
GNU make is the most popular, portable and thus relevant make. Similar to most GNU tools it contains many very useful extension over the traditional make and it basically runs everywhere.
Examples of GNU make features that are missing from Sun make:
- parallel execution (the Sun make compatible dmake supports it)
- conditional constructs
- many built-in function
- user-defined functions
- guile integration
Sun make features that aren't supported by GNU make:
- target groups - i.e. to specify that more than one target depends on a source file and that the one action generates those targets at once. GNU make only supports a group of targets with pattern rules.
- command dependencies - i.e. a target is also considered
out-of-date if the command changes - i.e. due to changed values
of variables like
- hidden dependencies - automatic discovery of header dependencies
There are also features where GNU and Sun make just use different syntax. For example, conditional macros:
- Sun make:
target := VAR = value
- GNU make:
taget: VAR = value
(Note that GNU make interprets
:= as assignment with immediate
As always, neither GNU make nor Sun make/dmake are bug-free. For
example, in versions released before 2016, the
generation in GNU make prints misleading messages (cf. e.g. bug
102). Sun make's
.make.state file (that is used for hidden
dependency and command dependency tracking) sometimes causes more
harm than good - e.g. when outdated dependencies aren't removed
(e.g. when one converts a target group into a target list). Or when
include files are regenerated unconditionally (cf.
The distributed make that comes with OpenOffice is also named DMake. It seems that it was independently developed of Sun's dmake - and that it uses a different syntax.
The changes in the
master branch fix portability issues in the
original code such that the resulting
make compiles and runs
under Linux. Also, a CMake build file is included for portable
Although those changes target Linux, they aren't really Linux specific. That means that the ported make should also compile on other modern POSIXy operating systems.
So far, the port was successfully tested under:
- Fedora 23/x86-64
- Solaris 10/SPARC
I avoided the names
smake because there
are already multiple published make versions that use those
names. There is a dmake that comes with Solaris Studio, a dmake
bundled with OpenOffice, a dmake that OpenOffice's
dmake is based on, an imake to build old X versions and
the Schily smake.
Thus, to not add to the confusion I chose
The build file also contains an install target, e.g.:
$ DESTDIR=dest ninja-build install [1/1] Install the project... -- Install configuration: "Release" -- Installing: dest/usr/local/bin/somake [..]
If you use the standard makefile generator with cmake, just
make. Also, omitting the
installs everything for real. The destdir mechanism is useful for
preparing a binary package and just to have a preview.
To change the default install prefix, you have to call
$ cmake ../somake -DCMAKE_INSTALL_PREFIX=/usr \ -DCMAKE_BUILD_TYPE=Release -G Ninja $ DESTDIR=dest ninja-build install [..] -- Install configuration: "Release" -- Installing: dest/usr/bin/somake [..]
If you are compiling on a legacy platform with ancient libraries you may need to tweak the cmake call a little bit. For example, to compile with GCC on a Solaris 10 system:
$ CC=gcc CXX=g++ CFLAGS='-m64' CXXFLAGS='-m64' \ cmake -DCMAKE_BUILD_TYPE=Release ../somake
In case you prefer a manual installation, basically it is just:
- copy the created
somakebinary to a
bin/directory under some prefix
- copy the man page into the related manpath
- copy the rule files that contain the built-in rules and are located
bin/subdirectory of this repository to one of the directories searched by
somake(and also remove the
Rule Search Path
make.rules as an example,
somake tries to open it in
the following order:
$ORIGIN/../share/somake/make.rules# added by this port
The CMake build file
CMakeLists.txt also defines some variables
for CPack, the CMake companion tool for creating binary packages.
For example, to create
$ cmake ../somake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr \ -DCPACK_GENERATOR='RPM;DEB' -GNinja $ ninja-build package $ ls somake-* somake-0.6.0-Linux.deb somake-0.6.0-Linux.rpm
As always, the
-GNinja generator option can be dropped -
ninja-build has to be replaced with
The content of the archives can be verified like this:
$ dpkg --contents somake-0.6.0-Linux.deb $ dpkg --info somake-0.6.0-Linux.deb
$ rpm2cpio somake-0.6.0-Linux.rpm | cpio --list -v $ rpm -qip somake-0.6.0-Linux.rpm
Open Build Service
There is also an Open Build Service Repository that provides somake binary packages for several distributions.
Perhaps not required by the CDDL, but I license my changes also under the CDDL.