Menu

WhyBuildGen Log in to Edit

Kevin Cox

Why I Made It

I created BuildGen because I wasn't satisfied with the alternatives. I believe a build system should be extremely simple to use for simple tasks while remaining basic enough so that it does not restrict you. As Pau Garcia i Quiles \<pgquiles@elpauer.org> said about CMake:

What are you selling?
- A flight simulator? or,
- A “flight simulator built with an awesome in­house developed build system”?

Speaking about CMake, CMake is a fantastic build system (generator) and is a large inspiration to BuildGen. I liked it a lot and is shows in BuildGen. CMake is used to build and install BuildGen for these exact reasons. Unfortunately, there were some things that I didn't like about CMake, inspiring me to create BuildGen.

I also wanted it to be completely language independent but being easy to use for any language.

Principles of BuildGen

As stated above I wanted to create a build system that made common tasks simple while still allowing people to do the unusual. To achieve this I took a step back and said "What is the most basic step of a build that applies to every step?" What came out of this the the core of BuildGen. The concept of generators. I realized that every step of the build took some number of input files and created one or more output files using a program to make the connection. A compiler takes source files and creates an executable. Installing files is taking the original and using the copy command to move the files to the output. This created the core function of BuildGen C.addGenerator() this function takes a list of inputs and a list of files that will be created as well as a command that does the creating. With that one function we essentially have an extremely simple build system. The one other function that is in the core of BuildGen is C.addDependancy() this function is not strictly necessary, but it is often useful to be able to add dependancies whenever you want rather than only when using C.addGenerator().

So now we have two functions with which we can build anything. But we have to implement them. At first I thought about writing my own parser and creating a language. But the more I thought about it the more daunting it became. I would need to make the language interact with C++ and allow it to call the functions. Also, I needed it to because to support the libraries that I had planned (more on that later) So I needed a full featured language. Then I started to look around to avoid re-inventing the wheel. And I found Lua. Lua was intended to be embedded in applications, was light and fast, written in ANSI C allowing it to be cross-platform. Lua was perfect for BuildGen. With Lua I had the simple interface I needed for users to use while maintaining a powerful language with full featured control structures for library writers. Also, the libraries could use a C backend for even greater control and speed.

Now, with the core commands and a good scripting language the program will run cross platform, but it will need a different set of scripts for each system and will be a pain to write and maintain. This is where the standard libraries come in. No programming language can do everything while maintaining high level and simple. (except Python :P, Python can do anything with less than 3 function calls) Ok, so what do we do? Let's go back to that side note. While the python standard built-ins can do a lot (all right a ton, but still not as much as people exaggerate it to) The true power comes with the modules. With the modules you can truly do everything. BuildGen took that concept and put it to use. For example, if you want to compile some C code, you don't have to use C.addGenerator() and call the compiler. Instead you use S.import("c") and import the C standard library. (not stdlib.h but the BuildGen one) Now you can use S.c.compile() and give it your executable's name and sources and it will do all of the work for you. It will find your compiler, check that it works, check that you have all of the required libraries and pass the flags you tell it to. Now, you can compile on any system with one line. The core is language independent but the standard libraries are what make it easy to build any language.

But, what is the power of the libraries if they are all standard? That is a great question. This is why BuildGen allows you to create your own custom libraries and use them in the same way. All you have to do is call L.import("libname") and it will be imported either from your custom lib path or from the current project. And, if you library is popular enough it can be added to the core so that it is available on every system.

Lastly, is the decision to use other build systems to actually build the project. This is because they work very (extremely) well and do a lot of the hard work such as dependency tracking and only build the files that need it. This allows for a lot of flexibility and moves the work around. Also, while the intention was for a build script to be generated from BuildGen's XML output there is no reason why a program could not directly build the project from it. If you really want BuildGen to build it you still can, it is just a more modular interface.

This is why I have created BuildGen and I hope that you enjoy it, be it for these reasons or your own.

-- Kevin Cox
-- Creator of BuildGen


Related

Wiki: Home

Discussion

Anonymous
Anonymous

Add attachments
Cancel





Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.