Building StackVM with faster bitblt; problems, problems

Now that the faster bitblt is working for the plain interpreter it is time to try to incorporate it into the StackVM on the Pi. Unfortunately, the StackVM still uses the old autoconf stuff to put together the makefiles. I'm not making a whole lot of sense out of what goes on and I really need some help.

 + I don't have the openGL developer stuff on my Pi and thus the B3DAcceleratorPlugin can't build. Perhaps I should load it but I'm rather inclined to think that the configure ought to test for the presence of the libraries and not make the plugin as appropriate. So far as I can tell the configure script *is* in fact checking for openGL and if I'm reading the config.log & confige.status files correctly has detected the absence (ac_cv_header_GL_gl_h=no is the relevant line). How are plugins excluded by the configure script tests?

+ similarly for the SqueakSSLPlugin, except I can't spot
+ sometime back in April I had to stop it making the mpeg3, klatt & croquet plugins and now I can't work out WTF I did to cause that. Sigh. What did I do?

+ how can I add the new files needed by the bitbltplugin? Configure does actually automatically add the .c files to the constructed bitbltplugin/Makefile but *not* the .s files

+ in a similar problem there is a .s file needed in the vm-display-x11 module; if I add it to the OBJS variable in the relevant makefile.in fragment, it appears in the generated makefile ok but I get a 'no rule to make foo' error. I thought unixy makefile stuff handled assembler files by default? If not, how do I get them built and where do I specify (or discover in the config?) that it should be using asasm?

+ I suspect it would be good practise to not even try to refer to the fast bitblt files unless the relevant switch was set in the configure. How do we do that?

While pointers to good doc explaining how to do this kind of thing would be nice, direct advice on the 'do this, do that, make' level would be ver y welcome. I'm not overly excited about trying to become expert at autoconf. With luck I'll never have to do anything other than ../configure' etc after this particular task.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: LJD: Lock Job on Disk

 
On Fri, Jun 21, 2013 at 04:06:13PM -0700, tim Rowledge wrote:
>
> Now that the faster bitblt is working for the plain interpreter it is time to try to incorporate it into the StackVM on the Pi. Unfortunately, the StackVM still uses the old autoconf stuff to put together the makefiles. I'm not making a whole lot of sense out of what goes on and I really need some help.
>
>  + I don't have the openGL developer stuff on my Pi and thus the B3DAcceleratorPlugin can't build. Perhaps I should load it but I'm rather inclined to think that the configure ought to test for the presence of the libraries and not make the plugin as appropriate. So far as I can tell the configure script *is* in fact checking for openGL and if I'm reading the config.log & confige.status files correctly has detected the absence (ac_cv_header_GL_gl_h=no is the relevant line). How are plugins excluded by the configure script tests?
>
> + similarly for the SqueakSSLPlugin, except I can't spot
> + sometime back in April I had to stop it making the mpeg3, klatt & croquet plugins and now I can't work out WTF I did to cause that. Sigh. What did I do?

For the oscog build procedure, you edit the plugins.int and plugins.ext files
in your build directory to control which plugins are built. Delete the plugins
that you do not want, and they will be excluded from the build. Save a copy of
your plugins.int and plugins.ext files somewhere safe so you can put the pieces
back together if you clean out your build directory and forget to save your
plugins.int and plugins.ext configuration.

The idea behind the oscog build is that VMMaker should generate the full set
of sources needed by the platforms, and that you should control the actual build
at configure/make/compile time, thus the approach of editing plugins.int and
plugins.ext.

>
> + how can I add the new files needed by the bitbltplugin? Configure does actually automatically add the .c files to the constructed bitbltplugin/Makefile but *not* the .s files
>

I don't know the answer, but for what it's worth the SqueakFFIPrims plugin contains
assembler modules, so you might be able to figure something out based on how
it is done there.

> + in a similar problem there is a .s file needed in the vm-display-x11 module; if I add it to the OBJS variable in the relevant makefile.in fragment, it appears in the generated makefile ok but I get a 'no rule to make foo' error. I thought unixy makefile stuff handled assembler files by default? If not, how do I get them built and where do I specify (or discover in the config?) that it should be using asasm?
>
> + I suspect it would be good practise to not even try to refer to the fast bitblt files unless the relevant switch was set in the configure. How do we do that?
>
> While pointers to good doc explaining how to do this kind of thing would be nice, direct advice on the 'do this, do that, make' level would be ver y welcome. I'm not overly excited about trying to become expert at autoconf. With luck I'll never have to do anything other than ../configure' etc after this particular task.
>

I'm with you on that one. The less I know about autoconf the happier I am.

Dave

> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: LJD: Lock Job on Disk
>

On 22 June 2013 00:06, tim Rowledge <[hidden email]> wrote:
> While pointers to good doc explaining how to do this kind of thing would be nice, direct advice on the 'do this, do that, make' level would be ver y welcome. I'm not overly excited about trying to become expert at autoconf. With luck I'll never have to do anything other than ../configure' etc after this particular task.

I've found http://www.flameeyes.eu/autotools-mythbuster/ to be helpful
in the past, though its target audience is more developers writing
their own autotools stuff rather than working with legacy files.

Alex

On 21-06-2013, at 6:55 PM, "David T. Lewis" <[hidden email]> wrote:
>
>
> The idea behind the oscog build is that VMMaker should generate the full set
> of sources needed by the platforms, and that you should control the actual build
> at configure/make/compile time, thus the approach of editing plugins.int and
> plugins.ext.

Hmph. OK, I guess I must have done something like that and forgotten about it. I can see a logic in the basic idea but boy would it be nice for it to be documented...
>
>>
>> + how can I add the new files needed by the bitbltplugin? Configure does actually automatically add the .c files to the constructed bitbltplugin/Makefile but *not* the .s files
>>
>
> I don't know the answer, but for what it's worth the SqueakFFIPrims plugin contains
> assembler modules, so you might be able to figure something out based on how
> it is done there.

I spotted that plugin and thought the same; sadly there is nothing there that offers any suggestions to my eyes. The makefile fragments don't look any different to those for other plugins.



tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Debugger: A tool that substitutes afterthought for forethought.

On 21-06-2013, at 6:57 PM, Alex Bradbury <[hidden email]> wrote:

>
> On 22 June 2013 00:06, tim Rowledge <[hidden email]> wrote:
>> While pointers to good doc explaining how to do this kind of thing would be nice, direct advice on the 'do this, do that, make' level would be ver y welcome. I'm not overly excited about trying to become expert at autoconf. With luck I'll never have to do anything other than ../configure' etc after this particular task.
>
> I've found http://www.flameeyes.eu/autotools-mythbuster/ to be helpful
> in the past, though its target audience is more developers writing
> their own autotools stuff rather than working with legacy files.

Thanks Alex, I'll see if any of it makes any sense. Don't suppose you have any experience fitting assembler files into the dang stuff?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Receptickle: a very playful welcome from a receptionist