[Vm-dev] xcode and VM plugins

David T. Lewis lewis at mail.msen.com
Sun Dec 19 18:23:39 UTC 2010

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 ;-)


More information about the Vm-dev mailing list