blog | oilshell.org
I just got back from a two-week vacation, and the last blog post is over three weeks old. It explained the strategy for building OVM by rewriting Python's build system from scratch.
What's happened since then?
I completed most of that work, and started a few new things, all leading up to an initial OSH release. The work led to ideas for blog posts which I don't have time to write. So in this post, I'll summarize the main ideas (in "Twitter mode").
I've packaged OSH as a single file with both native code and bytecode, as described in the last post.
However, it's too big and too slow. The bash man page acknowledges that bash is too big and too slow, and right now OSH is even worse:
import, and this all happens before
It's not worse than a normal Python program, but I'm (rightly) using the standard of a C program when making these judgements.
This annoys me, but I'm constantly reminding myself that the right strategy is to prioritize completeness and correctness over performance.
In particular, I don't want to block the initial OSH release on performance optimizations. I believe it will have (some) value even if it's bigger and slower than bash, and it's important to release early and often.
After it's released, someone might have better ideas for optimization than I do. That would be nice because a more important goal is to make progress on the Oil language.
I wrote a Makefile to build both the release tarball and the
osh binary. If I were to write a GNU Make experience report, it would
elaborate on these issues:
%.o : %.c) in three different Makefiles now, and they're useful. They can probably be generalized.
make -jwill be the default.)
gcc -Muses the preprocessor to discover dependencies in C source code, then generates GNU Make fragments, which are often massaged with sed. This interface is poorly designed.
$*mean in Make. It's unfortunate that these special variables collide so badly with shell's special variables.
.SECONDARYshould be the default.
.ONESHELLare bolted-on hacks.
This work also led to observations about build systems in general:
setup.pyscript uses distutils to build the standard library.
make -j, but the standard library must be built serially with
setup.py. This is bad because the larger task is done in a slower fashion.
yaccso the end user doesn't need to install it.
configurescript is to discover parameters for the second evaluation.
I completed most the work described in the last post, but the result still needs to be optimized.
Rewriting Python's build system produced specific observations about Makefiles, as well as general observations about build systems. I wrote about them while they're fresh in my mind, so I can use them when designing Boil.
In the next post, I'll give an update on project metrics.