contemplating a VM fork.

Lex Spoon lex at
Fri Apr 8 17:41:02 UTC 2005

There are a lot of threads here.  This is a discussion that would
probably work better in a bug tracker, with one thread per issue.  Also,
none of these are critical issues at the moment -- these are just all
possibilities for doing even better than the current system.

That said, for anyone who wants to perservere on these issues, here are
a few more cents.

> Ned wrote:
> > Assuming your system has a properly matched set of tools, installed 
> > properly,
> > the configure script should work properly.
> Not really.  If you install completely incompatible versions of 
> autoconf, automake and libtool then you can expect the compilation of 
> lots of things (not just squeak) to break.

Yes.  All I'm saying is that it has proven easy to get incompatible
versions.  To some extent that's just life with autoconf, but also it is
probably possible to be more widely compatible than we are now.  Anyway,
let's not be so excited with what we do have, that we hide from what we
don't have.

> > If you have the wrong awk, you don't get gnuification.
> A while back you told me about Debian not using GNU awk, so I fixed the 
> problem:
> 2002-09-27

Well, I just tried a few days ago and it did not work.  This was also
reported a few months ago on the mailing list, with a similar response
from you that the person must be mistaken.

I appreciate that you have worked on this, and I'm as baffled as you. 
Anyway, given the existing work, it is surely just a one-line tweak
somewhere at this point.

> I don't think gnuify cares which awk you use any more.


> Ned says: It Just Works. 
>  If it's broken, then either you have an 
> incompatible (or obsolete) collection of autothings, or Debian and 
> Apple are both shipping broken development toolsets (which I doubt is 
> the case).

I think you'll retract this argument if you think about it a minute. 
Blaming the user doesn't help!  I'd rather not go there, but if you
really stand by this, I can point out three holes in it.

> You cannot hold up 
> a compiler bug and then point to the source code you're feeding to the 
> compiler as the cause of the bug.

Likewise.  I agree that in some cases it is gcc's fault, but still it is
nice to support as many users as possible.

> Most likely you have an unresolved dependency on the plugin (due to a 
> bug in the source code, or something being rearranged in the x11 libs). 

Yes.  I probably have whatever X library the autoconf script is checking
for, but am missing some other ones.  Thanks for the debugging tip
(snipped), on how to track this down.

> > Regarding the complexity of the script, I have several ideas.
> Cast your mind back to 1996 or so.  The build process was wonderfully 
> simple.  

Yes, I know.  There are tradeoffs.  And I know you did not make it
complicated on purpose.  The current situation is an improvement --
there are more people, now, for whom the build process just works.

It's nice to do even better, though, right?

> When I got fed up of the derogatory remarks, I moved it all to 
> autoconf. 

Just to be clear, I deeply appreciate all the work you've done.  If
Squeak-on-Unix had come out 6 months later, I probably wouldn't have
started using Squeak, and that in turn would likely have led me to being
a static weeny like *all* the other programming language guys I know
outside the Squeak group.  I'd probably be writing greek letters and
chasing the Curry-Howard isomorphism as a way to better computerdom. 

> > 1. Dump make.  We already depend on GNU make.  It is no more onerous to
> > depend on Jam
> Unless this is a demonstrable net reduction in complexity (rather than 
> just moving onerousity from one place to another), and until writing 
> Jamfiles becomes as natural to a randomly-selected developer as writing 
> a Makefile, this is not a good idea.

I agree entirely.  No tool is a silver bullet.  And even a good tool,
needs to be used tastefully, or it will grow into a new monster to
replace the old one.

That said, make is easy to beat.  subroutines....  if statements that
look like if statements....  lexical scope....  Need I say more?  These
describe almost every language on the planet, but not make, and not even
GNU make.

Aside from the general pleasantness of the language, Jam can remove
pressure on the shell scripts in the autoconf part of the build setup,
and give you a nicer separation between configuration scanning
(autoconf's job) and dependencies plus build rules (jam).

>  (I would reject Imake for the same reason.)

Agreed again.  I don't know imake well, but from what I've seen it is a
monster worse than the one it kills.  Good idea, bad implementation.

> > It would not be terrible, if the standard build scripts can only build
> > external plugins if you are using gcc.
> IOW, it would not be so terrible if building external plugins (which 
> include the display and sound drivers, remember) only worked on 
> GNU/Linux?

Good point.  FWIW, it is more than GNU systems, though.  I just tried on
Solaris, and -shared worked fine.  Yes, there are platform differences,
but I'm sure the gcc people are aware of this.

> The move to libtool came after the move to autoconf and (again) was in 
> reaction to many complaints about builds failing on obscure platforms 
> or compilers that were not detected during configuration.  
>   The number of libtool-related complaints I have 
> received since moving to it are significantly less than the number of 
> library-related build failure complaints that I used to receive before 
> moving to libtool.

A good argument for keeping it.

I guess I am finding libtool itself to be messed up, even though it
solves an important problem--another good idea with a bad
implementation.  At one point, to give an example, the author was
religiously opposed to having libraries which link to other libraries. 
Yet, many of Squeak's plugins--such as X11 and NAS--need to have .so's
linked to other dynamic libraries.

The general complexity of the interface is what really bothers me,
though.  I have skimmed the manual twice now -- and one day, I'm sure,
I'll read it again and really try to learn it -- but it seems like an
aweful lot of effort is required to learn this dratted tool.

> (I have explained elsewhere the details of why the display drivers 
> absolutely cannot be compiled internally because of logical [not 
> procedural] conflicts.  I will not repeat myself here.)

I missed that discussion, but how can this be?  X11 used to be compiled
internally, and that other Squeak ports can compile their display driver
internally.  I don't see how it can be a logical problem, when other
systems do it, and when Unix used to do it.

Also, what about systems that don't have dynamic linking?  Does
Squeak/Unix now *require* dynamic linking?

> > 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.
> You can make anything you like internal when you run VMMaker.

Fine, if VMMaker shackles what the build scripts can accomplish, then
there is nothing the Unix code can do.

None of this has to be the case, of course.  I actually worked on this a
bit at one time, but have not pursued it.  It really ought to be
possible to compile things internally or externally or even both, even
after the sources are generated.


More information about the Vm-dev mailing list