[Vm-dev] xcode and VM plugins

Levente Uzonyi leves at elte.hu
Sun Dec 19 18:59:49 UTC 2010

On Sun, 19 Dec 2010, Igor Stasenko wrote:

> David,
> i agree that using CMake for building VM is good because it is
> cross-platform tool.
> So, it is obvious choice for automating building tasks.
> But not when you in developing/debugging mode, since you need UI to
> see what happens, (don't tell me gdb is all UI i need ;)
> That's where integrated dev environments like xcode rocks.

There are free, cross-platform IDE's that support CMake and GDB, like 
Eclipse or NetBeans. So that can be unified too if you really want it to 
be. ;)


> So, i wonder if its possible to have a cake and eat it too :)
> On 19 December 2010 19:23, David T. Lewis <lewis at mail.msen.com> wrote:
>> On Sun, Dec 19, 2010 at 06:31:02PM +0100, Igor Stasenko wrote:
>>> On 19 December 2010 18:01, Ken G. Brown <kbrown at mac.com> wrote:
>>>> At 2:59 PM +0100 12/19/10, Igor Stasenko apparently wrote:
>>>>> i just wonder, how one could force xcode to compile & link only those
>>>>> internal plugins, which is listed in
>>>>> plugins.int?
>>>>> This is sorta easy to do using makefiles.. but with xcode.. im lost..
>>>>> Any ideas?
>>>> Xcode project display has a column with header icon looking like a circle with a dot in it. That column has checkboxes beside the files, checked = include in the build, unchecked = do not include. Files would need to be dragged into your project to be visible.
>>> Thanks, captain obvious :)
>>> Now tell me how i call force xcode to automatically do not include
>>> some/all .c files into build, based on the contents of
>>> plugins.int file ?
>>> :)
>> Hi Igor,
>> I know next to nothing about xcode, but I would note that we are
>> accumulating quite a few different build systems. As an individual
>> user building a VM on my own computer, this is no problem. I just
>> read the instructions provided by the platform maintainer, and all
>> is well. I'm also quite happy to use a VMMakerTool that spits out
>> the sources for my specific platform. But if you want to produce
>> repeatable builds across a range of platforms, you are dealing with
>> a different problem.
>> The Cog branch deals with this by:
>> 1) Have VMMaker always generate all the sources for all platforms.
>> 2) Use repeatable build scripts or configure/make proceedures for
>> each platform.
>> However this does seem to rely on a collection of scripts and
>> makefiles that must be maintained for each platform, and for
>> Unix/Linux it is also using the old config process (with libtool
>> etc) rather than Ian's newer CMake-based system that is currently
>> in use for the Unix VM.
>> In my own experience (limited primarily to building on Linux for
>> my own use, as opposed to building and distributing to other users),
>> I found that moving to CMake took some getting used to (damn, not
>> another $#%@#%#@! build system ;-) but once I got accustomed to it,
>> it works as advertised and does a good job of avoiding platform-specific
>> problems, such as libtool failing to work for building 32 bit libraries
>> on a 64 bit system, to cite a recent example.
>> So if I were going to attempt to produce a repeatable, cross-platform
>> build system, I would be inclined to take the following approach
>> long term:
>> 1) Adopt the Cog approach of generating a single set of source code
>> from VMMaker for all platforms (no, that does not mean I want to
>> get rid of the current VMMakerTool, but if I wanted to build for
>> multiple platforms, it is better to use the Cog approach here).
>> 2) Update the current Unix CMake to reflect the changes from the
>> above (I assume Ian will want to do that).
>> 3) Figure out how to replace the current build scripts for the
>> other platforms with CMake.
>> 4) Make it all work the same for Cog and the interpreter VM.
>> To be clear, I do not personally plan to do the above (except
>> for #1), but if I needed a cross-platform build system for a range
>> of VMs, that is how I would attack the problem.
>> Just my $0.02, and I suspect that you will be in an excellent position
>> to offer your own perspective on this pretty soon ;-)
>> Dave
> -- 
> Best regards,
> Igor Stasenko AKA sig.

More information about the Vm-dev mailing list