Skip to content

Home

Jump to bottom
Sektor van Skijlen edited this page Apr 25, 2017 · 2 revisions

Silvercat

Introduction

As there exist lots of high-level build systems - Autotools, CMake, qmake, boost-jam and probably many others, here's yet another one. Like any other project of this kind, it should provide a user with a tool to handle the activities required to automatically compile sources into binaries, with simplest possible definition and preferably portable way. As I was disappointed by actually all such tools that I've found, I decided to create my own - and that's how I created Silvercat.

This project is based on Tcl language - it's used as both the language in which this project is written, and the interpreter of the configuration file. It consists of generally two separate tools:

  • agmake, which aims for having the same functionality as POSIX make (formerly: make.tcl)
  • agcat, which is the high-level build tool, otherwise known as Silvercat (formerly: ag.tcl)

This is the main set of description documents:

The project is in very early stage, please see the current status page. If you're interested, you may also look at Why and why not? page for several explanations.

The name

The name has actually a lot to do with Autotools and comes directly from autogen name. The autogen.sh script is usually created manually and in the simplest form contains the call to "autoreconf", which invokes the first generation phase (configure.ac and Makefile.am to configure and Makefile.in). I reused the autogen name in the short form - ag. This way I had a basis for "autogenerated Makefile" - Makefile.ag.

So, I have then realized that Ag symbol in chemistry is silver. Rest of the name was hinted by my wife's Maine-Coon cat that has quite an unusual color of fur.

Motivation

It all has begun actually with creating my own version of the standard POSIX "make" tool (available now as make.tcl in the repository). This just used the general idea of this tool, without using any specific Makefile syntax (and rely on standard Tcl features instead), with only the ability to define build rules using "rule" command. It turned out later that a high-level build tool can be also created on top of that.

Another important motivation was that among the many of build tools, none of them can be really satisfactory. Here are some:

  • Autotools: known also as Autohell, not without the reason. They theoretically consist only of configure.ac and Makefile.am files defined per directory. They are not distro files, however, because there's yet another layer consisting on configure and Makefile.in files, and only from them the final Makefile files are generated - everything resulting in overly complicated Makefile definitions. This consists of all possible bad techniques plus a "unique language" used in configure.ac file
  • CMake: one of the most stupid projects for high-level build system. Complex and completely unreadable syntax, even when comparing to Makefile, newly invented, not similar to any known scripting language syntax. In use it generates lots of complicated definitions and multi-step Makefiles. Very often various errors that are very hard to determine the cause. And when I hear advices from some of people that I can manually fix cache files, I'm trying to silently stop the topic.
  • qmake: bad thing is that it's predicted for qt only, so specifics of Qt framework are natural in this tool, while support for other kinds of frameworks is complicated to add. Nonetheless, it's one of the best existing high-level build tools. Its language has its own specifics, too, unfortunately, however it's way less complicated comparing to CMake.
  • scons: classes defined in the "makefiles", moreover in Python language? Just to define build rules? Oh, come on!
  • boost-jam: based on Perforce Jam, with a syntax that does not resemble anything and has a tricky rules concerning spaces. I surrendered after trying to read the first 3 pages of documentation that explained actually completely nothing
  • gn, gyp and ninja - the products of Google and my last hope when it came to me to find some reasonable build system (and my ultimate disappointment that led me to creating Silvercat). Gyp is the most disappointing out of these tools, as its "syntax" is - still restrictive - json. Yes, I know, the build systems that use XML are even worse, but I don't even think of dealing with masochists. Gn looks much better and it's a reasonable replacement of Gyp, however the syntax is still tangled, complicated and clumsy. Good thing is that it's still based on some known language, javascript in this case, but it has also various design flaws: the action to build a target is defined separately, which's only result is overly complicated build definition. Ninja is only a kind-of make replacement and Gn files make Ninja files generation, as it usually happens. How does this Ninja look like? For me it's more-less like toilet in Japan or Korea. Especially important for this kind of tool to have the basic datatypes in the language.

What can Silvercat do better?

Everyone whom I surprise by creating some utility script in Tcl language, surprises me by saying that "I don't know anything about Tcl language". Meaning that to understand the syntax rules of Tcl - and therefore parts of Silvercat - they have to spend a lot of time to learn this language, its various tricks and syntax corners.

Well, if you know shell scripting and some other scripting languages, you can quickly come to a conclusion that Tcl doesn't have any "syntax corners"! All things that are considered "syntax" is how to deal with variables, procedures and code execution. 99% of things are just in single commands, which's definition can be found in the Tcl's manpages.

But you don't even have to know all these things! For the most simple things to do in Silvercat, you need to know only the following things:

  • The meaning of $, { ... }, [ ... ] and " ... "
  • Why the { ... } must be absolutely balanced
  • Why the spaces are important, provided that every statement must look like a command with arguments separated by spaces
  • The syntax of commands introduced by Silvercat (part of them are provided by make.tcl tool, which is a "module" inside Silvercat)

This can be learned really quickly, there is also a Tcl Tips page prepared for that.

Sometimes you may be also tempted to do some more advanced things, in which case you should also know:

  • The use of most basic commands: "set", "if" and "expr"
  • Some major system communication things: [exec pkg-config ...] or $env(CXX)
  • How to use POSIX manpages to read Tcl documentation :)

In case of the agmake tool it's even more important to know the standard make tool rather than internals of Tcl language.

Second important thing is that the "base make tool" - unlike autotools, cmake and qmake - is make.tcl (although generators for other types of make tools can be provided as well). This way, Silvercat can also work without generation of any intermediate files (except those explicitly declared in the build configuration). If wanted, it can also generate a fresh Makefile.tcl file with rules for make.tcl - debugging of this tool in work is much easier than debugging the standard make tool. And in the really, really last resort you can also use a debugger for Tcl (such as RamDebugger).

And, last but not least, as it's written in a simple scripting language, the users can very easily add their extensions or specific handling, as well as they can trace some internals to understand how it works. For example, Qt can be added as a "framework", meaning that it applies its additional modification in the internal database - such as adding moc files for particular header files. Any limitations found in high-level tools can be easily overcome.

Clone this wiki locally