$ mkdir ting $ cd ting $ wget http://pippin.gimp.org/hytte/Makefile $ vim Makefile
Hytte is a Makefile aimed to reduce the amount of thought a developer needs to devote to the build system, providing a skeleton that makes starting a new project low.
Hytte is small and should be much easier to understand and modify, most tasks are automated when using hytte, only when adding new library dependencies should you need to touch the build system for a simple project.
Hytte is released to the public domain, put together by Øyvind Kolås <pippin@gimp.org>in 2007 and 2008. He uses it to create test cases for bug reports as well as a starting point when testing bugs and ideas in C. Hytte itself and it's website are an example usage of hytte.
Hytte can be downloaded from http://pippin.gimp.org/hytte/snapshots/, though all that you really need is http://pippin.gimp.org/hytte/Makefile.
The actual source repository of hytte which the snapshots represent are also found in the git repository at http://pippin.gimp.org/hytte/hytte.git.
To build a project using hytte simply type make. For information about additional build targets available type make help.
In this project we create the project called ting.
$ mkdir ting $ cd ting $ wget http://pippin.gimp.org/hytte/Makefile $ vim Makefile
At the top of the Makefile you gind.
PROJECT_NAME=$(shell basename `pwd`) # Dependencies of the project. PKGMODULES = glib-2.0
And add the other libraries you depend on. To see a list of all the pkg-config aware libraries you've got installed:
$ pkg-config --list-all | less
If you need to tweak low-level, there is also CFLAGS and LIBS that you can manually add to.
Now drop .c and .h files into the directory and run make.
$ make -- some compile failure vim Makefile ... tweak makefile, or perhaps install missing development packages start from top.
Now you've got a working setup, drop more .c and .h files in, and they will be built. Make sure to remove the hello-world.c file though if you started from a fully copy a hytte tarball to get rid of it's main().
When I've got something building I often want to run it, to do that type
$ make test
Other targets exist for debugging as well, gdb, gdb2 which make gdb trip using —g-fatal-warnings and valgrind which does a full leak check and callgrind which generates data suitable for kcachegrind.
You've now got something to share with the world, the simplest is probably to give someone a tarball:
$ make dist ... 8.0K -rw-r--r-- 1 pippin pippin 5.2K 2008-08-27 21:03 ../hytte-20080827-2103.tar.bz2 $
When you've got code that you want to distribute, you need to test yourself that you haven't included any accidental extra files. The distcheck is one of the good features of autotools (the goal you strive for when you battle Makefile.am). Note that hytte will not work on as a wide range of platforms if you need wide portability you should think about migrating to autotools.
You can also configure a scp target and a target location to syncronise a http based git repository, the makefile itself is simple enough that you can read it and modify it and tailor it to your needs.
I use make snapshot to upload a snapshot of the current sourcetree to a configured location. And make git-sync to syncronise a git repository.
If you also copy the docs directory from stuff, asciidoc will be used to turn it into the index of a website in docs. All .txt files in docs are also turned into html. When the docs directory is included, asciidoc becomes a dependency of your project (this should probably be fixed.)
The website is scp'd to the server directory specified in the docs directory Makefile.