[Vm-dev] xcode and VM plugins

[Igor Stasenko]

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.

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.