Older blog entries for tromey (starting at number 26)

Not much work this week. However, I have done some thinking about the front end. My current plan is to build things so that all work -- not simply the work of running the build instructions, but also the work of elaborating the tree -- will be done in parallel. This requirement is a consequence of allowing one step of the build fill in new dependencies for a subsequent step. I've also thought a bit about requirements for the lexical structure of the input files.

What's Up Doc?. Watched this again, probably the 5th or 6th time. I love this movie. It is a nice homage to the early screwball comedies, and is hilarious besides. Some people I know won't watch it since it starts Barbra Streisand; fortunately I'm not victim to that particular ideological narrowness.

Il Mostro. Another Benigni comedy. This one wasn't as funny as Johnny Stecchino.

As often happens, someone sent in a patch for one of the gcj bugs I was planning to fix. That's some odious debugging I don't have to do :-).

SWT, as it turns out, is not 64-bit clean. And changing it to be so looks to be a fair amount of work (which, eventually, I'll probably have to do). I find this irritating; it isn't hard to write 64-bit clean code from the start.

Blood Work. This movie was entertaining enough, but not one of Eastwood's better efforts. I did enjoy the fact that he owned up to his age and played an aging cop in poor health -- a nice touch of reality rarely seen in Hollywood films (yesterday I saw in The Onion: "Woody Allen's Third Wife Born").

In one scene, Eastwood is interviewing a computer programmer in his cubicle. On the shelf behind the programmer is a copy of RHL 6.1. That's nice, but even nicer is that there is also a copy of the autobook. It is blurry, but I like to think that's what it is.

American Astronaut . I went to see this again last night. This time Cory McAbee was in town to promote it. He also gave a concert (I didn't attend). He's an interesting and charismatic guy. Anyway, I learned some things about the movie, and I always like hearing from the directors and learning about their processes.

There's Something About Mary. Saw this (again) at the outdoor theater this week. It was funny, though not as funny as the first time I saw it.

More work on making Eclipse build. I fixed a few random bugs and made stack traces print interpreted frames nicely. There's nothing like compiling a large application to shake out the bugs. Next we have to fix class loading. At last.

Last night I looked at AWT again, a little. I didn't have time to make any progress; I was just reorienting myself.

I've started on the logging interface and I've done some more internal cleanups. I've also started thinking about the front end design (not syntax, but available functionality).

Eventually I'm going to want someone to read through the design and the ideas and help me see if something obvious is missing. I frequently prefer working in a collaborative mode, where I have someone to help with decisions and tradeoffs.

Tadpole. I loved this movie and laughed out loud quite a bit. (I'm a sucker for movies shot on DV.)

Last night I looked into making the build tool impervious to comment and indentation changes in C source. This turns out to be quite easy conceptually: you simply base the file's signature on a tokenized form of the source file. This is feasible if your tokenizer is relatively fast. I'm putting off writing this code, since it isn't entirely trivial and there are more important things that must be done first. I imagine it would be most useful to enable this by default for .h files in the project, and use a (presumably) more efficient text-based scanner for other sources.

I've also figured out how to make "config.h" files work well. The idea here is to change cpp to output more dependency information. Then config.h can compute its signature based on the defines actually inspected by a given compilation. This means that, say, adding a test to config.h will only cause a rebuild of those files which actually use the new define. Something like this would be nice for large projects.

Both these ideas are easy to implement in the current framework.

I've been re-reading the Odin paper again. I always forget how different this approach really is. Odin doesn't put intermediate files like a .o into the build tree. They exist only in the cache. I doubt I'll be going that route. For one thing, I've found that I occasionally look at the .o files to debug some problem or another. Also it feels "too different".

Tonight I'm just working on general cleanup.

A couple nights ago I added derived object caching (about 20 lines of Python code) and command file dependency tracking (if /usr/bin/gcc changes, your program is recompiled). Last night I changed the gcc tool to know how to do automatic dependency tracking.

Derived object caches are a bit funny to work with. For instance, rm *.o doesn't cause a rebuild. It just pulls things in from the cache. This "feels weird", perhaps due to my long history with make. Signatures also are a bit odd. For instance, the build tool is impervious to touch. Another example is if I add whitespace to a C source file, the resulting executable isn't relinked (since the object file doesn't change). (This stuff all works right now with my prototype.)

Recently I've been trying to build Eclipse with gcj. This is an adventure, since Eclipse has 75 jar files (for now I'm compiling from bytecode) and uses all kinds of packages, including things it shouldn't like com.sun.tools (hiss). I've also tried getting Eclipse to run with gij; this has shown me that working out the library issues is only the start of my problems.

Austin Powers 3. Better than I thought it would be. I found the opening sequence particularly interesting, and inventive. Parts lagged, though, and by the end I was ready to leave.

raph brings up some interesting points regarding language choices in a new build tool. There are a few points here that I'd like to address.

First, in automake we always separated the implementation language of the tool from the language the user used to make things happen. There have been many requests over the years to blur this barrier, but I never regretted being firm here. Blurring this line basically means you must be very confident in your particular implementation, since giving access to it means it will be much, much harder to change.

My earlier questions were really ones about the implementation language of the tool. Is it ok to have a dependency on some other, larger project (Python or Perl or ...)? Of course that isn't a question with a fixed answer. It depends on what you want to accomplish. One of my goals is wholesale replacement of the auto* tools. This makes the question particularly hard.

The user's language is of course extremely important. We've all seen how autoconf's quoting and mix of m4 and sh is confusing and limited. We've all seen make's many syntax problems.

The tension comes because in some situations the user language has to have some power, and it is tempting to just use the same language for both. For instance, expressing autoconf-style configuration requires expressive power.

This is all "front end" stuff. I still haven't really started the front end design beyond kicking a few ideas around.

raph, I'd be interested in seeing rebar. How about sending me a tar file?

Today I finally put Advo on my personal toolbar in Mozilla. I find I really enjoy reading the Advo diary entries, and I look forward to them. I think it is because some people put real thought into their entries, so they can be good reading. Also it is interesting to see what other people are working on or thinking about.

Today I did something I ordinarily dislike, which was rewiring so that I could boot the alpha box I have here. Honestly I think Red Hat forgot they ever sent it to me. It's nice for testing gcc; today I'm using it to test a gcj patch for a bug that occurs only on 64-bit architectures. What I really need to do is move that box plus the other old one to the basement and run wiring down there. Then the noise won't bug me so much. Given my general level of hardware procrastination, I think it is safe to say that will never happen.

Last night I did some hacking on a build tool prototype. Basically I'm trying to test some of my plans against reality; earlier hacking in this vein led me to revise how the database is laid out. Sometimes I find it easier to follow logic in the code, while I'm writing it, than I do if I try to plan everything about ahead of time. In situations like this I just consider the prototype code as part of the design process.

Anyway, the prototype tool is smart enough to avoid re-running a rule when the output won't be different. And since it is using signatures and not timestamps it is impervious to touch.

It is awfully daunting to have 500 LOC in a project and know you need 10,000 LOC.

There's a fire in Steamboat today and here in Boulder the sky has been yellow and the air smells of smoke. Ugh. It's almost enough to make me look forward to winter.

Today was pretty slow. I need to make some kind of change here.

Saw XXX today. This movie somehow managed to fall below my already low expectations. Amazing.

I'm finally back from my vacation. It was wonderfully relaxing and made me want to hack again. Nice.

I've done a lot more thinking about a replacement build tool. True to form, I thought about it a lot on vacation. I've written some design docs for the back end, and started thinking about the front and "middle" ends, but so far nothing suitable for public viewing.

One implementation issue I struggle with is what language to use. I wonder whether people will be willing to give up the portability of the current auto* tools in order to have a somewhat cleaner build environment. My current preference would be to write a new tool in one of the common scripting languages, probably Python (I don't know it, therefore I can't dislike it :-). Luckily implementation is a long way off, potentially infinitely long.

My Big Fat Greek Wedding. I finally saw this because several friends reported back enthusiastically. I thought it was quite boring. Also it espoused a very stereotypical view of Greek-Americans, on the borderline of offensively so. I guess I didn't see the humor in it that other people did.

A few weeks ago, before vacation, I saw The Sting at the outdoor theatre. Even though I had seen it just a couple months before, I enjoyed it again. Some movies I can see over and over.

Today I read through mjw's diary entries. I also have a difficult relationship with free Java efforts.

On the one hand, I'm proud of gcj. I think we've done some great work. On the other hand, we're still missing pieces that people seem to consider fundamental (AWT...). We still haven't found our killer app, that gets gcj widely used.

Also there's the issue that people still consider kaffe the premiere free Java. Being first really does have its benefits. Lately this hasn't bothered me much. I just work on gcj (less frequently right now), trying to make it as good as I can.

Mark has a very good point when he says that people in the community seem willing to build their projects on non-free infrastructure. From one point of view, the one I most commonly take, this is a mistake -- that work helps to enhance the hegemony of Sun, against the free community. On the other hand, I suppose one might consider it as a pragmatic approach similar to that taken by the GNU tools in 1990: we're doing this now, but when a free solution comes along, we'll migrate. Though so far the migration hasn't happened. And with the rate of change in the Java specification, it may never happen.

So, this is a concern. My own preference has been to use only free tools, to the extent possible, as soon as possible. I usually prefer to suffer a bit with less-than-perfect free tools than to support the non-free ones that may work better. I don't mind finding and reporting some number of bugs. The counter argument is "I have to get work done". Ok, fine, but let's keep an eye on the long term, the important thing: the free software.

gcj still has some legs. If you look at the web page you'll see a steady stream of news items as people add things to it. And more things are coming: Andrew has written a new inliner; we'll probably (eventually) get some nice optimizations out of the tree-ssa work; Bryce is working on the AWT merge with Classpath (when this is done I'll probably dig up some cycles to work on the peers again).

There are plenty of cool projects for interested hackers, too...

Lately I've been thinking quite a bit about the next generation build tool. I've been writing a design for the back end. Don't know if or when it will be available.