At 11:24 PM 2/20/02 -0500, you wrote:
>At 04:01 PM 2/20/2002, you wrote:
>>I've attached a file with some modifications to VMMaker-3-2-5 and changes 
>>to the code on SF (in unified diff format).
>>I used these to build a 3.2gamma VM using MSVC.  Note that the changes 
>>will break the gcc build.  I see this as a way station to getting a 
>>proper win32 build with multiple directories for internal and external 
>>plugins.  Rather than get gcc working with the current lame state, it 
>>seems more useful to define the unlame state and then move MSVC and gcc to it.
>
>Well done, Ross!   Unfortunately, I can't do MSVC.  It's lame!   Although 
>the idea of debugging is an interesting one.   hehe :)    Anyway, I would 
>really prefer if the gcc Makefile is also generated, before we go rolling 
>these changes into 'official' VMMaker.  Unfortunately, I am in crunch mode 
>on the job and I just don't have much time.  If you do and are interested, 
>supporting internal plugins generated to the intplugins directory would be 
>the last operation to get it not-lame, the antithesis of lame, the goal of 
>every healthy person in this modern archaic metaworld.
>
>cheers,
>Rob

The source code changes are distinct from the VMMaker changes, so perhaps 
they could go in sourceforge?  Preferably after somebody reviews them.

I have trouble following your last sentence.  Does it mean doing internal 
plugins would come after external plugins, or just that it is a nice goal?

I agree that in its current state the changes to VMMaker (Win32VMMaker 
actually) should not go into the baseline, since they break gcc 
builds.  However, if you're suggesting tweaking it so the appropriate 
makefile for gcc gets spit out, I think that's not worth it, since that 
would all be scrapped when we move to separate directories.  I think it 
would be better to get both MSVC and gcc working with the separated 
directories to spare wasted effort.