Hi
I am just wondering if anyone has experiences maintaining a clang fork and how you do it ?
It wasn't very easy for me to move from 3.7 to 3.8, since there were about 2000 commits I had to merge. git wasn't too clever with the merge either, finding stuff to merge in files I had never touched. In the end I reversed my mode of operation, and merged into master from my branch, using -strategy ours to keep mainline intact and preferred to reedit many of my changes.
It would appear advantageous to have some sort of continous integration, where each commit from mainline is automatically merged into my branch and then a compile is attempted. If things break, the integration stops. Otherwise it just keeps on churning. If this makes things really easier though, I don't know. Does this exist ?
Ciao
Nat!
Sony folks gave a talk called "Living Downstream Without Drowning"
that sounds relevant to this:
- Hans
From: "Nat! via cfe-dev" <cfe-dev@lists.llvm.org>
To: cfe-dev@lists.llvm.org
Sent: Thursday, March 10, 2016 10:41:59 AM
Subject: [cfe-dev] Maintaining a clang fork
Hi
I am just wondering if anyone has experiences maintaining a clang
fork
and how you do it ?
It wasn't very easy for me to move from 3.7 to 3.8, since there were
about 2000 commits I had to merge. git wasn't too clever with the
merge
either, finding stuff to merge in files I had never touched. In the
end
I reversed my mode of operation, and merged into master from my
branch,
using -strategy ours to keep mainline intact and preferred to reedit
many of my changes.
It would appear advantageous to have some sort of continous
integration,
where each commit from mainline is automatically merged into my
branch
and then a compile is attempted. If things break, the integration
stops.
Otherwise it just keeps on churning. If this makes things really
easier
though, I don't know. Does this exist ?
When I've done this I've had scripts that do a nightly pull/merge followed by a build and test. If any of that fails, I'd get an e-mail. In my experience, doing this between 3-4am central time works best.
-Hal
Also I will be running a follow-up BoF at EuroLLVM next week.
(And this time I remembered to CC the list...)
--paulr
Merge at least weekly with trunk, but only when bots are green.
From: "Nat! via cfe-dev" <cfe-dev@lists.llvm.org>
To: cfe-dev@lists.llvm.org
Sent: Thursday, March 10, 2016 10:41:59 AM
Subject: [cfe-dev] Maintaining a clang fork
Hi
I am just wondering if anyone has experiences maintaining a clang
fork
and how you do it ?
It wasn't very easy for me to move from 3.7 to 3.8, since there were
about 2000 commits I had to merge. git wasn't too clever with the
merge
either, finding stuff to merge in files I had never touched. In the
end
I reversed my mode of operation, and merged into master from my
branch,
using -strategy ours to keep mainline intact and preferred to reedit
many of my changes.
It would appear advantageous to have some sort of continous
integration,
where each commit from mainline is automatically merged into my
branch
and then a compile is attempted. If things break, the integration
stops.
Otherwise it just keeps on churning. If this makes things really
easier
though, I don't know. Does this exist ?
When I've done this I've had scripts that do a nightly pull/merge followed by a build and test. If any of that fails, I'd get an e-mail. In my experience, doing this between 3-4am central time works best.
We have an automated script which runs twice a day and does an automated pull/merge/test. If everything succeeds, it directly pushes into our local tree. We've found this succeeds roughly 50% of the time and that the rest need (mostly minor) hand resolution. I'd generally say that a faster merge interval leads to less pain overall.
How often you'll run into a problem depends on (a) what you've changed,
and (b) what other people upstream are working on. We're experimenting
with a continual-merge bot and observing conflicts 2-3 times a week.
(No hard data on frequency of test failures, that's next on the list.)
Philip is doing things that are much more invasive (from what he's said)
than we do, so I'm not surprised he sees something essentially every day.
--paulr
All of your experiences have been very helpful to me for deciding to do nothing 
No matter how I slice it, I have to expect to put significant (for me) time into merging clang. Since my fork is just one project amongst many, I can not put weekly attention to it. So I think I am resigned to spent a few days every half year, merging in my patches.
Ciao
Nat!
You’ve had lots of other replies, but no one has yet mentioned git-imerge. It burns a *lot* of cycles, but I’ve found that it’s the best way of handling the merges. It identifies the pair of revisions (yours and upstream) that cause a conflict and lets you fix them one at a time.
Unfortunately, the clang and llvm git repos are separate in the git export, so you can’t easily run the clang test suite during the merge (you can run LLVM tests though, and if you merge LLVM first then you can find the revision that corresponds to your head merged with a specific clang svn revision and try running that).
Our fork has some fairly invasive changes from upstream (support for pointers that are not integers all the way from clang to the back end), so merges are quite painful and I wait longer between them than I should.
David
You’ve had lots of other replies, but no one has yet mentioned
git-imerge. It burns a *lot* of cycles, but I’ve found that it’s the best
way of handling the merges. It identifies the pair of revisions (yours and
upstream) that cause a conflict and lets you fix them one at a time.
Unfortunately, the clang and llvm git repos are separate in the git
export, so you can’t easily run the clang test suite during the merge (you
can run LLVM tests though, and if you merge LLVM first then you can find
the revision that corresponds to your head merged with a specific clang svn
revision and try running that).
What I have found works really well is to use a combined repo like this
one: https://github.com/llvm-project/llvm-project
-- Sean Silva
