Re: [Cegcc-devel] Imported cegcc into git
On Sat, 18 Dec 2010, Paul Sokolovsky wrote: > Hello, > > On Sat, 18 Dec 2010 13:04:43 +0100 > Vincent Richomme wrote: > >> Hi, >> >> You should discuss with mingw-w64 folks and especially with Kai Tietz >> because >> he was interested in including mingw32ce inside their repository. >> It would be great to do so because some features that have been >> included into >> mingw-w64 could be backported to cegcc (SEH exceptions, unicode >> startup). >> I already added some files their and you should have a look. > > I tried to look at what mingw-w64 uses for w32api (did they fork it? > do they maintain upstream connection?), but among first google hits I > found discussion of licensing quality concerns with mingw-w64 headers, > and I didn't look further. Then, just ask the mingw-w64 guys. On irc : OFTC, mingw-w64 Vincent Torri -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Re: [Cegcc-devel] Imported cegcc into git
Hello, On Sat, 18 Dec 2010 13:04:43 +0100 Vincent Richomme wrote: > Hi, > > You should discuss with mingw-w64 folks and especially with Kai Tietz > because > he was interested in including mingw32ce inside their repository. > It would be great to do so because some features that have been > included into > mingw-w64 could be backported to cegcc (SEH exceptions, unicode > startup). > I already added some files their and you should have a look. I tried to look at what mingw-w64 uses for w32api (did they fork it? do they maintain upstream connection?), but among first google hits I found discussion of licensing quality concerns with mingw-w64 headers, and I didn't look further. Can you give some hints regarding what you added where - I'm pretty overloaded with information, so that's helpful. I'm so far concentrating on w32api, because that's IMHO the most lacking part of cegcc now - out of 2 (native) apps I tried, none built OOB, and one required heavy header patching. But exception handling was my next concern, because if SEH isn't supported, cegcc can't replace proprietary compiler, and I still don't have clear picture regarding that in cegcc, though presense of *sjlj*.dll somehow hints... OTOH, that thread which I refer to (around http://lists-archives.org/mingw-users/18900-yet-another-mingwrt-w32api-provenance-discussion.html ) mentioned that w64 does use sjlj, while original mingw dwarf2 EH... > -- Best regards, Paul mailto:pmis...@gmail.com -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Re: [Cegcc-devel] Imported cegcc into git
Hi, You should discuss with mingw-w64 folks and especially with Kai Tietz because he was interested in including mingw32ce inside their repository. It would be great to do so because some features that have been included into mingw-w64 could be backported to cegcc (SEH exceptions, unicode startup). I already added some files their and you should have a look. -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Re: [Cegcc-devel] Imported cegcc into git
Hello Max,
On Sat, 18 Dec 2010 01:39:01 +0100
Max Kellermann wrote:
> On 2010/12/18 01:26, Paul Sokolovsky wrote:
> > Or, it would be possible to produce list of all commits on branch,
> > manually filter out merge commits from it, and then pass to some
> > "mass cherry-pick" tool. Of course, there will be conflicts, so that
> > tool must behave like rebase - stop on cnflict, allow to inspect,
> > fix, or skip it, and then continue with the sequence. Well, does
> > such mass c-p tool exist? It must be ;-)
>
> As always with git, there are several ways of doing that. Here's how
> I would do it:
>
> First, "git filter-branch" may be used to get only a sub tree (such as
> src/gcc-4.4.0). That will leave only commits touching gcc.
Yeah, or just git svn import gcc subdir.
> Then use "stg uncommit"
So, is stgit still alive? They r.i.p.ed cogito, so I worry for any
other wrapper, taking into account pace with which git develops.
Anyway, my idea was that git rebase -i should be good enough for
in-repo patch maintenance (even though I have to admit I didn't try it
for that use in prolonged time).
> to convert all commits after the pristine
> import to stgit patches.
>
> Import the newest upstream gcc into a new branch.
>
> Use "stg rebase" to replace cegcc's initial gcc import with the new
Somehow it seems that you either presume, or simplify, that cegcc was
developed in linear manner, with single initial import, followed with
just cegcc-related commits. But it's not like that. There're multiple
upstream syncs/merges, cherry-picks from upstream or elsewhere
("updated to 3.15 with patches"), post-merge updates (can be part of
merge or no), etc. That's what complicates commit re-extraction. Some
parts like gcc might be not too affected; I may imagine, gcc 4.4.0
indeed was dropped once and then mostly cegcc-patched, but gcc at all
has cleaned up patchset from Pedro Alves:
http://article.gmane.org/gmane.comp.gnu.cegcc.devel/2841
But for other tools, I don't see how stgit would help without even
more work than mass c-p approach I imagined.
> upstream version, and stgit will push all the patches on top of the
> new upstream version (with lots and lots of conflicts, of course).
>
> In the end (after a few days of hard work), you'll have a branch full
> of patches, and these need to be sorted, folded, submitted.
Just to make it clear - I'm not interested in upstreaming anything. I'm
interested in making it maintainable outside of upstream. I also have
-10 free hours a day (that's why noise on ML - I can be swayed away
tomorrow for unknown period of time, so would rather leave some traces
for next session, be it mine or somebody else's) and intend cegcc for
higher-level goals than itself, so hacking on it is nuisance. But if
doing that, I try to do it in such way that result will be a cleaner
thing than before. Well, there may be some Guardian knot cuts (and I
may fail to produce something).
--
Best regards,
Paul mailto:pmis...@gmail.com
--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
___
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Re: [Cegcc-devel] Imported cegcc into git
On 2010/12/18 01:26, Paul Sokolovsky wrote: > Or, it would be possible to produce list of all commits on branch, > manually filter out merge commits from it, and then pass to some > "mass cherry-pick" tool. Of course, there will be conflicts, so that > tool must behave like rebase - stop on cnflict, allow to inspect, fix, > or skip it, and then continue with the sequence. Well, does such mass > c-p tool exist? It must be ;-) As always with git, there are several ways of doing that. Here's how I would do it: First, "git filter-branch" may be used to get only a sub tree (such as src/gcc-4.4.0). That will leave only commits touching gcc. Then use "stg uncommit" to convert all commits after the pristine import to stgit patches. Import the newest upstream gcc into a new branch. Use "stg rebase" to replace cegcc's initial gcc import with the new upstream version, and stgit will push all the patches on top of the new upstream version (with lots and lots of conflicts, of course). In the end (after a few days of hard work), you'll have a branch full of patches, and these need to be sorted, folded, submitted. -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Re: [Cegcc-devel] Imported cegcc into git
Hello, On Fri, 17 Dec 2010 08:58:49 +0100 Max Kellermann wrote: > Hi, > > good to see some activity over here again. I'm a developer on the > XCSoar project, which ultimately needs mingw32ce to compile for > Windows CE targets, so this project is vital for us. Unfortunately, I > didn't have any chance to free some time to work on mingw32ce/cegcc so > far. > > I have imported the cegcc subversion trunk into a git repository (with > git-svn), just in case anybody here finds that useful: > > git://git.xcsoar.org/xcsoar/max/cegcc.git > http://git.xcsoar.org/cgit/max/cegcc.git/ Thanks! Quite useful already for revision browsing. > > It might be a good start to get more people involved quickly. Clone > it, and hack it. If nobody else steps up, maybe I would volunteer to > manage the "main" repository, and handle pull requests from you. I'd > really love to hack the code myself, if only the day had 96 hours... > > It might be a good idea to make separate git repositories for gcc, > binutils etc., to sync with the upstream projects in the long run, so > this could just be a temporary solution until some brave person > decides to start this upstream merge. Yes, to get some real boon out of it, all of gcc, binutils, mingw and w32api need to split into own repos. But what's next? Well, it's clear that cegcc commits should be "rebased" to git-managed mirror of pristine repos, but in what form - as a big flattened patch, or as sequence of original individual commits? One big flat patch is what should be output of such project IMHO, and yet if to think about upstreaming it, it should at least somehow split. In this regard, sequence of original individual commits is not much useful, and yet they represent detailed history and useful as a reference... And I have no idea how to "copy" them from an "alien" branch which mixes upstream merges and actual useful commits. Apart from manual cherry-picking each commit, of course. Or, it would be possible to produce list of all commits on branch, manually filter out merge commits from it, and then pass to some "mass cherry-pick" tool. Of course, there will be conflicts, so that tool must behave like rebase - stop on cnflict, allow to inspect, fix, or skip it, and then continue with the sequence. Well, does such mass c-p tool exist? It must be ;-) But it seems that the ideal solution is mid-way: big flat patch is too big and flat, while bothering to faithfully port commits like "Oops, I added file to wrong dir" makes little use too. So, I'm going to (subject to time constraints) make a proof of concept migration of w32api with following procedure: 1. git svn import cegcc's w32api 2. git cvs import upstream w32api (yeah, they use CVS by the end of 2010, whoa!) 3. Then, put these two imports as separate branches into one repo. They are not expected to be merged. 4. cegcc's w32api will be there for reference at fingertips, and to pull from SVN, if there will be changes (and cherry-pick them). 5. Upstream w32api will track upstream closely. 6. From it, work branch will be created. 7. One big flat patch will be produced from cegcc w32api repo and its upstream. 8. Then, it will be cleaned up based on ideas in my other today's mails. 9. Then, it will be split per some usefull, yet simple, criteria, like separate patch for each header vs build changes vs bulk .def additions. 10. Those patches will be applied one by one to work branch. 11. Regarding attribution, ChangeLog.ce will be there. Not sure how to deal with it, ideally each patch should include relevant bits from it, but that doesn't qualify as "simple". So, likely will be dropped in intact, elaboration of that can be left for later, if there ever be upstream submission. -- Best regards, Paul mailto:pmis...@gmail.com -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
[Cegcc-devel] Imported cegcc into git
Hi, good to see some activity over here again. I'm a developer on the XCSoar project, which ultimately needs mingw32ce to compile for Windows CE targets, so this project is vital for us. Unfortunately, I didn't have any chance to free some time to work on mingw32ce/cegcc so far. I have imported the cegcc subversion trunk into a git repository (with git-svn), just in case anybody here finds that useful: git://git.xcsoar.org/xcsoar/max/cegcc.git http://git.xcsoar.org/cgit/max/cegcc.git/ It might be a good start to get more people involved quickly. Clone it, and hack it. If nobody else steps up, maybe I would volunteer to manage the "main" repository, and handle pull requests from you. I'd really love to hack the code myself, if only the day had 96 hours... It might be a good idea to make separate git repositories for gcc, binutils etc., to sync with the upstream projects in the long run, so this could just be a temporary solution until some brave person decides to start this upstream merge. (Thanks Danny for offering SVN write access for us, but I have been spoiled by git already, and can't ever feel comfortable with SVN anymore - that's just my personal opinion) Max -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
