[Vm-dev] xcode and VM plugins

[Igor Stasenko]

On 19 December 2010 19:59, Levente Uzonyi <leves at elte.hu> wrote:
>
> 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.
> ;)

ouch..
Tried using NetBeans once... on a small C++ project..
Just two words: crawls, crashes.
I can't imagine what will happen with it if you pass interp.c to it.
xcode btw, also feels a bit shocked
when it opens interp.c :) (takes around a minute for it, when you
happily watching the rolling rainbow disc)

>
>
> Levente
>
>>
>> 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.
>>
>



-- 
Best regards,
Igor Stasenko AKA sig.