[Vm-dev] CMake for Windows?

Igor Stasenko siguctua at gmail.com
Tue Apr 13 17:55:46 UTC 2010


On 13 April 2010 19:21, Javier Pimás <elpochodelagente at gmail.com> wrote:
>
>>I have been trying to adapt the Unix CMake files for the Windows port,
>
> nice!!
>
> If I am correct, when you generate sources with VMMaker you get something like this:
>
> \-src
>       \-plugins <- external plugins
>             \-pluginA
>             \-pluginB
>       \-vm <- interpreter, gc, etc.
>             \intplugins  <- internal plugings. Inside vm dir makes sense because
>                                  they'll be statically linked to the VM.
>                   \-pluginC
>                   \-pluginD
>
Nope. My VMMaker producing following layout:

\src
  \vm
  \pluginA
  ...
  \pluginX
  plugins.int
  plugins.ext

> This is all generated from Slang. You may have some other part of some plugins in Cross/plugins if they have code directly written in C.
>
>
> Regards,
>             Javier.
>
>
> On Tue, Apr 13, 2010 at 12:58 PM, Geoffroy Couprie <geo.couprie at gmail.com> wrote:
>>
>> Hello,
>>
>> I have been trying to adapt the Unix CMake files for the Windows port,
>> but I have difficulties understanding the sources layout. I understand
>> at least the difference between internal and external plugins, but
>> what is in vm/intplugins? It seems that CMake looks for sources in a
>> lot of directories, and that some of them are not used anymore. I have
>> these directory layouts:
>> platforms
>>  \-Cross
>>  \-plugins
>>   \-pluginA
>>    \-pluginB
>>  \-vm
>>  \-specificplatform
>>  \-plugins
>>   \-pluginA
>>   \-pluginB
>>  \-vm
>>
>> And for the generated sources directory:
>> src
>>  \-pluginA
>>  \-pluginB
>>  \-vm
>>
>> Is that the definitive sources layout?
>>
>> Also, if you're interested in using CMake for Windows, should I
>> assemble Unix and Windows instructions in the same files?
>>
>> Best regards,
>>
>> Geoffroy Couprie
>
>
>
> --
> Javier Pimás
> Ciudad de Buenos Aires
>
>



-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list