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

Autif Khan autif.mlist at gmail.com
Tue Jan 15 10:53:22 PST 2013


On Thu, Jan 3, 2013 at 10:45 AM, Alex J Lennon
<ajlennon at dynamicdevices.co.uk> wrote:
> 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
>>>>>>
>>>>>>
>>>
>

Merged into master.



More information about the yocto mailing list