Sunday, December 25, 2011

Status update

It's been a while since I've posted on my progress. I'm still in the "taking a break from Tart" mode, which is why you haven't heard from me lately. I plan to get back to working on it after the holiday.

In the mean time, I've been busy working on Mint, and things are going pretty well. Mint can not only build itself directly, but can also generate makefiles to build itself indirectly. The Mint source tree now has a "build.osx" directory which contains both the Makefile and header files needed for building Mint on OS X. The contents of this directory are generated entirely by Mint. There's also a "build.linux" directory which will (soon) have the same setup for Linux platforms.

One of my design goals has been to make Mint useful for developers, even if their users don't have Mint installed on their systems. It would be hard to convince developers to use any new tool if it required all of their users to install that tool as well. Of course, Mint would be even more useful if the users had it installed, but first thing is to get some sort of momentum in the developer community.

To that end, I've made it so that the Makefiles generated by Mint are position-independent, so that you can check them into the source tree along with your source files. In other words, a developer can use Mint on their personal workstation, and then generate Makefiles which can be invoked by the users who check out their sources, without those users having to install Mint themselves.

Unfortunately, most projects need more than just Makefiles to build - they also need configuration scripts. For building on a foreign system, one can generally assume that something like 'make' exists, which means that one can use that as a common foundation. With configuration, however, that foundation is far less firm. There's autoconf, of course, which is built up out of shell scripts and m4 macros, but while most Unix-like systems have some version of autoconf installed, they may not have the version of autoconf that you need.

I haven't quite figured out what to do about this, but there are a couple of different paths that could be explored. One idea would be to have Mint generate autoconf-compatible scripts; another would be to generate my own configuration scripts that were not autoconf-based. A third approach would be to not do configuration at all, but instead ship pre-configured Makefiles / build scripts for the most popular platforms.

Ultimately, what I suspect developers want is a tool that will let them generate build scripts that will run on all of the platforms that they care about, while requiring the fewest number of additional tools or dependencies. So for example, it would be nice to press a button and get a Visual Studio project file, an XCode project, a Makefile for various platforms, and so on. The downside is that these pre-generated configurations can't cover every possible host environment, and so have to be configured for a least-common-denominator target environment.

Of course, all of this is based on some assumptions about the users. 99% of users don't want to build from source in the first place - they want to install pre-compiled binaries. And a developer working alone doesn't need a fancy configuration and build system, when they can just add a new source file in their IDE and hit the rebuild button. The use cases where one checks out source and rebuilds it are fairly limited by comparison:
  • The case where a team of developers is working on a single project.
  • The case of a software packager who is creating a binary distribution.
  • The case where a project doesn't yet have an installation script or binary packages, so building from source is the only option for users.
For the first two cases, having to build and install Mint first is not that huge of a burden. For the last case, it makes me think that the really compelling use case for Mint is in the creation of installation packages. That is, if I could figure out how to get Mint to automatically generate a .deb or .rpm or a .dpkg, that would be something that I think developers would really be interested in. Heck, that's something I myself would be interested in, for Tart...hmmm, time to start reading the docs on building packages.

Here are some links:

1 comment:

  1. hi,

    i love tart design, i wonder if you came to a solution to the debugging bug?

    by the way, i opened two entries in google code for windows build not working and and another with a patch to allow to build tart with current llvm trunk.

    ReplyDelete