Re: Cocotron used for a real-world app

[Nicolas Roard]

On Thu, Oct 30, 2008 at 2:17 PM, David Chisnall <theraven@sucs.org> wrote:
>
> On 30 Oct 2008, at 14:10, Nicolas Roard wrote:
>
>> On Thu, Oct 30, 2008 at 1:56 PM, Truls Becken <truls.becken@gmail.com>
>> wrote:
>>>
>>> Nicola Pero wrote:
>>>>
>>>> Anyway, I agree that for an Xcode programmer the idea of just having a
>>>> button in Xcode that cross-compiles to Windows might be attractive.
>>>> I also agree with you that it would be nice for GNUstep to support that.
>>>> :-)
>>>
>>> Even more awesome, was your idea of a button in Xcode that sends the
>>> code changes to the virtual machine, and triggers a recompile there.
>>> This would be easiest to implement as a network protocol, so sending
>>> it to a physical computer shouldn't make any difference. Perhaps using
>>> distributed objects?
>>
>> It's definitely something you could do -- have a special script in
>> xcode triggered when you use a "windows" target, with the script
>> basically calling (lots of different possible ways to do this) the
>> gnustep installation in the VM to recompile the program.
>> Frankly I think it's a better approach than doing the
>> cross-compilation, specially considering installing GNUstep on windows
>> is just a matter of running the installer.
>
> This is pretty much what I did when I was developing on OS X and deploying
> on IRIX, but I just had a trivial shell script that ran rsync and then ssh'd
> to the target machine and ran make. Using a network share is another option.
>  Most desktop VMs have the ability to export a host folder via SMB or
> similar to the guest.  Even better would to have some kind of file changed
> notification system on the guest used to automatically recompile when files
> in the share were changed, so it would always be up to date.

yup, rsync is probably the simplest solution in fact, and wouldn't
require any development.
Just write a tutorial on how to do that on windows, showcase it with a
large application (gnumail?) and you'll see people interested...

>
>>> The biggest challenge probably is syncing the code changes. If
>>> commiting to a repository for every cycle is acceptable, it would be
>>> easily solved that way.
>>
>> A network drive might be doable (i.e. create a network drive on osx
>> and put your sources here, so they can be accessed both by xcode and
>> by the vm).
>>
>> The only last hurdle is the GNUmakefile generation -- there is no
>> xcode->gnumakefile translator anywhere ? surely it can't be that hard
>> to do -- iirc the xcode stuff is in xml.
>
> I take it you've never looked at the XCode project files in a text editor.
>  They're graphs wrapped in XML, with opaque references everywhere, and so
> difficult to parse that I've had XCode fail on them a few times, and had to
> recreate them from scratch.  XCode does expose most of its model via the
> scripting interface, however, so it would probably be possible to write an
> AppleScript that would create a GNUmakefile from the active project.

Good point -- I forgot they were just serialized graph. An applescript
could do the work yes, at worse you can always write the gnumakefile,
it's not really difficult and doesn't change that often.

Basically, all this is doable, probably very easily done in fact.
Anybody willing to write a nice tutorial then ? :)
I may work on this next month if nobody wants to do it before.

-- 
Nicolas Roard