[En-Nut-Discussion] Question about subversion merging
uprinz2 at netscape.net
Tue Jul 19 22:54:26 CEST 2011
On 19.07.2011 08:56, Harald Kipp wrote:
> Hi Ulrich,
> On 7/18/2011 11:35 PM, Ulrich Prinz wrote:
>> I am afraid, but even I would not try to do an automated merge with
>> these two branches. I prefer winmerge to do that job as there are many
>> things 'just a bit' different.
> I see. Well, I didn't expect a merge running through without manual
> intervention. My first approach was to cherry-pick some changes to get
> the branch in sync with the trunk and do the merge back to the trunk in
> a second step.
Yes, that was my intention too. First there are some new general
architecture independant drivers that I would merge.
Then merge the new architecture layour where arm7/arm9 goes one
directory deeper. Then add stm32.
Then the I2C drivers will make some headache. They need to know about ab
bus. I renamed them from Tw... to NutTwi... and did some #defines for
the Tw... by applying a fixed bus that you can select in nutconf. But I
already tried arm7 in devnut_m3n and it got me by missing arguments
while using I2C devices,
> How do you intend to proceed? Are you going to modify the trunk directly
> by applying the changes from the branch?
No, I would merge devnut_m3n and trunk together in devnut_stm32 or how I
called the other stm/cm3 branch. If that works you can lock trunk and
the merged branch for not accepting any commits and merge them back to
trunk. After that you remove the lock.
With that you urge anyone who modifies the trunk while it is locked and
to update before committing.
>> Give me just a little bit more time. I am actually trying to recompile
>> qnutconf for linux and it works, I think.
> No problem, there's always something else waiting. I'll continue on the
> 4.10 branch. Although prohibited, I'll add a few additions, which can be
> easily applied on the trunk later. I think this is acceptable as long as
> we do not have a final release.
Yes. Lets do everything with a big bang now, for all others we have a
working branch and an installation packet.
> Btw., did you notice, that Ole provided an autoconf'ed version of
> qnutconf in the devnut_autotools_or branch?
No, I got it today. But I was eager to see how linux performs. I had QT
installed from the beginning and it had to show if it works. It works!
>> The versions of arm-linux-gnueabi-gcc do not know about CortexM3...
> Last time I phoned with Ole, he told me that his arm-eCross-gcc build is
> based on YAGARTO scripts. So it should be complete.
I was searching for the yagarto scripts but did not find them directly.
So I used the manual way:) With the new system the complete build needs
below 10min, 4 cores running with -j5 option. It was fun to see that.
I have some little problems with the insigth debugger.
But I'd prefer the yagarto version as it should output binary identical
code compared the windows version. As I do some developments for the
company at home too, this would avoid recompiling and makes QS
More information about the En-Nut-Discussion