[yocto] [meta-mono] Support for Visual Studio debugging on Yocto/OE targets (e.g. RPi)

[Alex J Lennon]

On 03/01/2013 15:24, Autif Khan wrote:
> On Wed, Jan 2, 2013 at 3:46 PM, Alex J Lennon
> <ajlennon at dynamicdevices.co.uk> wrote:
>> On 02/01/2013 20:27, Autif Khan wrote:
>>> On Thu, Dec 27, 2012 at 12:10 PM, Autif Khan <autif.mlist at gmail.com> wrote:
>>>> On Wed, Dec 26, 2012 at 12:05 PM, Alex J Lennon
>>>> <ajlennon at dynamicdevices.co.uk> wrote:
>>>>> Hi all, Autif,
>>>>>
>>>>> I've been working to support .NET development on Linux
>>>>> over the past few days.
>>>>>
>>>>> There is a Visual Studio plugin, MonoTools for Visual Studio
>>>>> which provides support for local and remote debugging of
>>>>> .NET applications with Mono.
>>>>>
>>>>> This requires a remote stub to be running on the target
>>>>> platform, monotools-server.
>>>>>
>>>>> I've created a recipe to build monotools-server, which in
>>>>> turn required me to pull in Openembedded Legacy recipes
>>>>> for mono-xsp and gtk-sharp.
>>>>>
>>>>> As it stands I'm now able to build an X enabled image for
>>>>> the Raspberry Pi and remote-debug some simple Windows
>>>>> Forms .NET applications within the Visual Studio IDE.
>>>>>
>>>>> Recipes are hosted here in 'recipes-mono'
>>>>>
>>>>> git at git.assembla.com:ciseco-eve.meta-eve.git
>>>
>>> I could not "git clone" the repo.
>>
>> Apologies. I should have given you the public r/o link.
>>
>> Originally I was trying to avoid modifying meta-mono, adding .bbappends
>> into my own meta-eve layer instead, but since my last post to you I
>> found I couldn't build against the current HEAD of Yocto due to some odd
>> file location issues which I couldn't overlay. (i.e. it didn't seem to
>> be able to pick up the patches where you had them - although was fine
>> with an older commit of the Yocto core).
>>
>> As a result I've moved the original meta-mono patches that weren't being
>> picked up by bitbake and merged my additions into a fork of meta-mono
>> which is here:
>>
>> git://git.assembla.com/ciseco-eve.meta-mono.git
> 
> Got it.
> 
> I scanned thru the code and saw what you did to re-organize the
> directory structure.
> 
> When I get back, I will see if I can build libGDI+ and mono with
> denzil (I am stuck with denzil for reasons beyond my control, or until
> I find a show stopping bug in denzil for our project - unlikely)
> 
> Meanwhile, I have no questions about changes for gk-sharp, mono,
> mono-xsp and monotools-server.
> 

Good oh.

> Presumably, you will take care of the "TODO: This needs fixing
> properly and needs to be revisited" in mono_<version>.bb - I
> definitely do not want unstripped binaries on my distribution -
> presumably, this was needed for some debugging and is not meant to be
> checked into production.

Ah yes. I'd forgotten about that. I shall habe to revisit why that was
erroring.

> I could not understand the purpose of
> libgdiplus/files/libgdiplus-2.10/libgdiplus-2.10.1-libpng15.patch -
> could you please help me understand what prompted these seemingly non
> trivial changes.
>

Yes there seems to be a problem building libGDI against libpng15. It
seems a known issue:

https://github.com/mono/libgdiplus/pull/4

> Everything else looks good.
> 

Good oh

>> I'm coming up the curve on Git, as I migrate from mainly Subversion use.
>> Can I issue a "pull request" to you or some such?
> 
> Yes, a pull request should work.
> 
>>> Presumably, you want to release the recipes with the MIT and/or GPLv2 licenses.
>>>
>>> If the license is different for monotools-server or mono-xsp or
>>> gtk-sharp, you will likely have to submit a patch for README file too.
>>> Even otherwise, section 4 in README needs to be updated. If you have
>>> any tasks left - please add them to section 10.
>>>
>>
>> Will double check this. I am waiting for feedback from the
>> monotools-server people on their license as there's nothing explicit in
>> their source.
> 
> Will wait for that. Might affect the README
> 

I'll give them another nudge once I've worked our what's going on with
the stripping, commit to my fork and then try to work out how to send
you a pull req.

>>> The guidelines for the Yocto project are very similar to other FOSS
>>> projects including the Linux kernel. They are outlined here:
>>>
>>> https://wiki.yoctoproject.org/wiki/Contribution_Guidelines
>>>
>>> I used the following as a guide when I have submitted my patches in
>>> the past. This is for the Linux kernel, adapt as appropriate for
>>> meta-mono.
>>>
>>> http://linux.koolsolutions.com/2011/02/26/howto-create-and-submit-your-first-linux-kernel-patch/
>>>
>>> Please submit separate patches for each of the recipes (presumably
>>> there are no changes to the mono/libGDI+ recipes)
>>>
>>> Please add me to the "To:" recipient (I filter a lot of PATCH related
>>> traffic) - this should allow the emails to be caught by the filter
>>> instead of archiving.
>>>
>>> In case I do not respond within 72 hours, please email me with a
>>> gentle reminder :-)
>>>
>>> I have not had the opportunity to integrate patches just yet, please
>>> bear with me in case I screw up.
>>>
>>> Thanks again for contributing!
>>>
>>> PS #1: If you do not want to go thru the hassle - please email me the
>>> tar.gz as an attachment and I will check it in directly - a bad side
>>> effect of this would be that you will not get any "git" credit for
>>> this
>>>
>>> PS #2: I am still on vacation, but had a few hours - the 72 hour clock
>>> will start only after Monday :-)
>>>
>>> And finally, PS #3:
>>>
>>> http://marc.info/?l=linux-usb&m=135229956521385&w=2
>>> http://marc.info/?l=linux-usb&m=135119051922403&w=2
>>> http://marc.info/?l=linux-usb&m=134858043613838&w=2
>>> http://marc.info/?l=linux-usb&m=134791970203982&w=2
>>> ... many others ...
>>>
>>> Please refrain from top posting :-)
>>
>> Happy to try if that's the etiquette here - like this?
>>
>>> Autif
>>>
>>>>> If there is interest in migrating these recipes into meta-mono
>>>>> and  somebody will review them then I'll be pleased to make
>>>>> whatever changes are needed to comply with relevant
>>>>> Yocto policies.
>>>>
>>>> Absolutely!
>>>>
>>>> I am about to embark on a vacation returning to work on Jan 7.
>>>>
>>>> More then - Unfortunately, I will not have time to look at this today
>>>> or until Jan 7.
>>>>
>>>> Working hard - then playing hard :-)
>>>>
>>>> I will dig into then when I return.
>>>>
>>>> (Side note - we gave up on GTK# recipe and decided that Windows forms
>>>> are 'good enough' for us. This makes me glad :-)
>>>>
>>>>>
>>>>> Best Regards, (& Happy Holidays)
>>>>>
>>>>> Alex
>>>>>
>>>>>
>>