In message <
[hidden email]>
Andreas Raab <
[hidden email]> wrote:
> Hi -
>
> Just tried to build a VM from the latest sources (the first time I tried
> 64bit) and promptly run into problems. The first ones: It seems that by
> now we not only have sq.h, sqConfig.h, and sqPlatformSpecific.h (sqGnu.h
> nonwithstanding) but also interp.h and config.h. Can someone please shed
> a light on what definitions need to go where? For example, if we have
> config.h shouldn't interp.h (which contains a single definition) be
> folded into that? Shouldn't sqConfig.h go away? Since config.h seems to
> be optional (at least so far Windows managed without it) why can't it be
> optional? This hole mix of strange header files has lost any sensibility
> to me.
>
Walk down your corridor and beat on Ian. He will tell you that running
autoconf is what you have to do in order to work out all those strange
incantations in config.h.in or something similar. What, you don't have
autoconf? Tut-tut young man, your computer is not fit to be called an abacus.
Ian Piumarta <
[hidden email]> wrote:
> On Mar 17, 2005, at 5:00 PM, Tim Rowledge wrote:
>
> > So far as I can tell, there is a (possibly) new file 'config.h' being
> > #included by Cross/vm/sqMemoryAccess.h. I am unable to find a copy of
> > this file but there are hints that it is created by the unix autoconf
> > process. Would that be correct?
>
> Yes.
>
> > If so, perhaps you could list the
> > things the file is expected to define for the benefit of platforms that
> > don't use autoconf or otherwise point me to the file.
>
> Look in platforms/unix/config/config.h.in which is a template for
> config.h. When dealing with a single platform you can copy config.h.in
> to config.h then manually set each option as appropriate (and never
> touch the file again).
>
> As a concession to 64-bit progress I release you from the second clause
> in the boilerplate that requires you to rename the file before
> distributing a modified copy of it, provided your version of config.h
> remains within your platform's subtree. (Ditto for the win32 and
> carbon VMs too.)
>
> > I see that in the newer sq.h, sqConfig.h is included, which in unix'
> > case includes config.h. sq.h then includes sqMemoryAccess.h which again
> > includes config.h. A possible source of confusion I imagine, at least
> > for humans reading the code.
>
> Some source files include sq.h, while others must avoid including it
> and include sqMemoryAccess.h instead. In both cases, the definitions
> in sqMemAccess and config.h are vital (at least for Unix). Including
> config.h twice does no harm whatsoever.
>
> > Is there actually any need for the current sqConfig.h file at all? It
> > doesn't seem to be used to do anything much these days, with Mac &
> > win32
> > doing a very small bit of fiddling in there. Perhaps this new config.h
> > and sqConfig.h might be best merged?
>
> When VMM generates 64-bit compatible sources and everyone has figured
> out how to build a working VM from them, then we should think about
> tidying up header files.
>
> Ian
For what it's worth, I manage to build ok with:-
/**************************************************************************/
/* A Squeak VM for Acorn RiscOS machines by Tim Rowledge */
/*
[hidden email] &
http://sumeru.stanford.edu/tim */
/* Known to work on RiscOS >3.7 for StrongARM RPCs and Iyonix, */
/* other machines not yet tested. */
/* config.h -- */
/* configuration stuff analogous to that produced on *nix machines whenv */
/* you run the spawn-of-satan-autoconf stuff. */
/**************************************************************************/
#define SIZEOF_VOID_P 4
#define HAVE_INTERP_H 1
#define SIZEOF_LONG_LONG 8
as my config.h
Yes, I completely agree that the number of headers etc has got out of hand. It
seem to me that for many platforms the stuff aabove ought to go into
sqPlatformSpecific.h and maybe unix should just include the generated config.h
there. It seems sqConfig.h is pretty much pointless too. interp.h is something
that needs to be generated by VMMaker right now.
tim
--
Tim Rowledge,
[hidden email],
http://sumeru.stanford.edu/timStrange OpCodes: GSI: Garble Subsequent Instruction
Locked
