[Vm-dev] xcode and VM plugins
Ken G. Brown
kbrown at mac.com
Sun Dec 19 20:13:22 UTC 2010
Have you looked at Xcode Build System Guide: Introduction, Build Phases, where it talks about adding custom steps to the Target build phase, including 'Copy Files', and 'Run Script' build phases. You can also create custom build rules scripts, see Creating a Build Rule Script.
Maybe something in there will allow you to do what you want.
At 7:48 PM +0100 12/19/10, Igor Stasenko apparently wrote:
>i agree that using CMake for building VM is good because it is
>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.
>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
>>> >>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 ;-)
>Igor Stasenko AKA sig.
More information about the Vm-dev