false positive, but a workaround...

[Gedare Bloom]

On Wed, Jun 24, 2015 at 10:57 AM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
>
>
> On 6/24/2015 9:40 AM, Ed Sutter wrote:
>>
>> On 6/24/2015 10:41 AM, Jarielle Catbagan wrote:
>>>
>>> On Wed, Jun 24, 2015 at 6:10 AM, Ed Sutter <ed.sutter at alcatel-lucent.com>
>>> wrote:
>>>>
>>>> Jarielle,
>>>> Well, it took almost 5 hours to build the tools last night. Obviously I
>>>> need
>>>> to upgrade the machine I have
>>>> this stuff running on at home!
>>>>
>>>> Anyway, this AM I was able to walk through what I thought I had done in
>>>> work
>>>> yesterday, and unfortunately due
>>>> to the fact that I am working in two different locations on two
>>>> different
>>>> machines (very very inefficient, but I'm
>>>> stuck in this mode at the moment); I fooled myself yesterday thinking I
>>>> had
>>>> stubbed out the __ctype_ptr__
>>>> declarations from docmd.c...  Unfortunately, I didn't :-(, so what I
>>>> thought
>>>> built clean didn't.
>>>>
>>>> Anyway, I want to get you over this hump quickly 'cause this isn't what
>>>> I'd
>>>> like you to be working on.  I really
>>>> want you to concentrate on beaglebone-specific stuff.   That's the
>>>> important
>>>> stuff.  Today I brought my beaglebone
>>>> board to the office, and I've got it working clean now using a local set
>>>> of
>>>> ctype.h and ctypetbl.c files as I had in
>>>> umon1.19.  For now this is temporary, but it may turn out to be the most
>>>> efficient way to get around this.
>>>
>>> These files would conflict with the licenses, am I right?  Would a
>>> permanent solution be to implement a new local ctype.h?
>>
>> Yep, that's exactly what I'm looking in to.  :-)
>> Just wanted to get you rolling meanwhile...
>
>
> All code in newlib has appropriate licenses. It would be easier to
> selectively pull in files from there. We just need to be careful
> to ensure we know versions so updates can occur. But that's true
> for every place you could grab from.
>
> New software has new bugs.
>
> Do you happen to have a master list of what methods you used
> in the original source base?
>
Tracking the upstream (source, version, license) for every file is the
most important part of grabbing source to incorporate directly. After
that, minimizing changes and pushing patches back to the upstream are
necessary to minimize maintenance costs.

>>>
>>>> So, attached to this are three files:
>>>> ctypetbl.c:  put this under main/glib
>>>> ctype.h:      put this under main/common
>>>> mydiffs:     small list of diffs based on the tree after installing your
>>>> initial set of 24 patches.
>>>>                      most of these changes you probably have, the
>>>> important
>>>> one is in main/make/common.make so that ctypetbl.c is built.
>>>>
>>>> If you can incorporate these changes into a tree that starts with the
>>>> master
>>>> and has your initial 24 patches applied,
>>>> you should be good to go.  I know I should be using git to email you
>>>> patches, but I'm still trying to figure out how to
>>>> do that and I don't want you to be delayed by that.
>>>>
>>>> Does this make sense to you?
>>>
>>> Yes.  Ok, I'll incorporate those files and I believe you are right
>>> that everything should be all set.
>>>
>>>> Ed
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> umon-devel mailing list
>>>> umon-devel at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/umon-devel
>>
>>
>>
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel