Am Sonntag, 21. Dezember 2003 16:33 schrieben Sie:

Martin Kuball wrote:

...

Hi!

I'm trying to build an up to date VM. I searched the internet and found a reference to the anonymous cvs repository on sourceforge. I checked out the ned-branch, installed VMMaker in my 3.7 image and generated everything. Than I noticed that there is no platform/unix/config/configure script and even no configure.in. So what now?

Martin

Hello Martin,

The current Squeak sources use autoconf.

cd to the ../platform/unix/config directory.

In that directory do: make

That will make your configure script.

Unfortunately it won't. autoconf needs configure.in and thats missing.

Martin

Ned Konz ned@squeakland.org wrote:

There is no configure.in; automake uses configure.ac instead.

Are you using a recent version of autoconf and automake?

autoconf 2.57 automake 1.5

I can confirm from recent frustration that without autoconf 2.57 you are utterly screwed. Take care when installing it to confirm that it has _actually _ installed.

tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim State-of-the-practice: What we can do with the money you have.

"David T. Lewis" lewis@mail.msen.com wrote:

Perhaps the actual configure script could also be maintained on SF. Granted, configure.ac is the real source code, but it seems like a heavy restriction to require an up-to-date autoconf installation in order to compile a Squeak VM.

That's not quite the case, however. If you just want to compile the VM then you can use a source release. If the releases are not frequent enough and CVS is way ahead of the releases, then go bug the maintainer....

<rant> It's not up to me, but I've always thought it more logical to leave the configure script outside of CVS. Leave CVS for the true developers, and require true developers to have a complete tool chain. Trying to support people with various fragments of the development tools sounds like a recipe for pointless confusion and wasted effort. It reminds me of the "cult of the dead" world where you ship around binary files and then "oops" write all these tools to try and make binary files act like source files. Use the source, Luke, and things get a lot simpler. </rant>

In the particular case of configure scripts, remember that somehow the configure script in the repository has to be kept up to date. I can't think of a method of doing this that is easier than making a new source release. For example, what do you do when something is posted to CVS and it becomes impossible to produce a correct configure script at all?

Lex

Torsten,

Based on Yoshikis sources I have successfully compiled a VM for the Siemens Simpad running Linux+Opie. As soon as I figure out the scancodes of all the keys I will build the final version with hopefully working modifiers.

Cool. What is the result you get from tinyBenchmarks?^^;

While it makes sense to fit it to the default keymap, I think Opie has an 'etc' file with which you can map the character codes. It may be interesting option if you want to customize it more.

-- Yoshiki

Torsten Sadowski moehl@akaflieg.extern.tu-berlin.de wrote:

I tackled the keyboard and mouse modifiers. tinyBench gives me about 9.200.000 Bytecodes/s and 310.000 Sends/s.

That's not too bad; IIRC the simpad is a 200-ish MHZ SA1100 and thus might be squeezed to another 10% or so. A trick that got a big boost on the RISC OS SA110 machines was to use the globals-in-a-big-array plus sticking the base address of said array in a global register. I have _no_ idea if the relevant compiler for the simpad can handle that.

tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- An experiment in Artificial Stupidity.