Ned Konz <ned(a)bike-nomad.com> wrote:
> On Monday 28 March 2005 1:50 am, Alan Grimes wrote:
> > Hello, I am contemplating forking the VM due to my frustration over
> > having to live at Ian's mercy with regards to enhancements to the VM. ÊI
> > don't mean to fault Ian, he has clearly done some excellant work with
> > Squeak and is superbly talented. My issue is that I am unable to work
> > with his build environment to the point that I can successfully
> > implement my own extensions such as the SDL driver that I've been
> > working on. -- I can't figure out how to make the build script work.
> I find this a bit odd. I know of many people who have downloaded the sources,
> VMMaker, etc. and have had no problems building a VM.
> Assuming your system has a properly matched set of tools, installed properly,
> the configure script should work properly.
I think he was talking about modifying the build scripts, not running
them as is.
Even so, you must admit that this is a lot of if's. If you have the
wrong awk, you don't get gnuification. If you have the wrong version of
autoconf, then the configure script may not be rebuildable. Wrong
version of gcc? Your compile can fail. etc.
FWIW, the scripts are still not perfect even with all the if's
satisfied. My current system builds without complaint, but the
resulting VM cannot open an X window. (This is why I haven't yet posted
a deb of Ian's latest VM release.) vm-display-X11 is created, and I can
compile other X programs just fine, so I don't know what the problem is.
I intend to eventually dig to the bottom of this; in fact, I've seen it
before, but cannot remember what the problem was! I'm not complaining--
bugs happen! Let's not get so overconfident that we are surprised that
it does not go perfectly for someone.
Regarding the complexity of the script, I have several ideas. In fact,
I have actually coded several of them up in the past, for whatever
credibility that gives me. Since those changes have been rejected--
many times--I won't work further on them myself, but maybe some
people have thicker skin and would like to take a try at it. Here are
a few from the top of my head:
1. Dump make. We already depend on GNU make. It is no more onerous to
depend on Jam, which would make it easy to encode more rules in the
Jamfiles. Jam is easier to understand, and further, it removes a major
temptation to violate #2:
2. Use autoconf only for its purpose: *guessing* about configuration.
Always let the user override the guess. And don't overload it with
other functions, just because make doesn't have if statements or
subroutine calls. A quick test for whether you are overloading it is:
if you change part of the build scripts unrelated to configuration
settings, you should not have to re-run the configure script.
3. Reconsider libtool. It's a nice idea, but it is really confusing,
and I'm not sure it is truly helping out. It sucks having to read an
extra manual just because we are too afraid to hard code "gcc -shared".
It would not be terrible, if the standard build scripts can only build
external plugins if you are using gcc.
4. Heck, while at it, reconsider the default of external plugins.
There are clear advantages to external plugins, but they cause an
installation hassle. Especially it is annoying, if you want to compile
an experimental VM and test it out without installing it on your system.
Make internal the default, if VMMaker allows this.
Don't take me wrong -- the build scripts generally work fine. Let's
just not overestimate them. They are complicated, few people understand
them (maybe just 1?), they sometimes fail, they often require people to
install extra dependencies, and when the the build fails, the error
messages (or lack thereof) are frequently impenetrable. Most of this is
not necessary, and so we should welcome discussion (and code!) about how
to improve them.
PS -- Alan, there are no Squeak Police that will come after you if you just do
something like gcc *.c */*.c. :) Please don't dump great VM work just
because you can't use the official build scripts. Build script crud can
always be fixed up later.