Review Request 123963: First bits of refactorings. Skeleton of interface for KDevelop. Build system. CompilationDatabase for CMake projects and ClangTool.
Maciej Poleski
d82ks8djf82msd83hf8sc02lqb5gh5 at gmail.com
Fri Jul 10 12:19:57 UTC 2015
> On Lip 6, 2015, 4:33 po południu, Milian Wolff wrote:
> > refactoring/renamevardeclrefactoring.cpp, line 44
> > <https://git.reviewboard.kde.org/r/123963/diff/9/?file=382502#file382502line44>
> >
> > this change is already part of https://git.reviewboard.kde.org/r/124200/ no? you are really messing up the diffs here, and always just paste one huge diff of everything. that does not help at all. Do you know how to rebase changes locally? I'd assume you'd have a local branch where you have one commit per review you post. Then you create one diff per commit and then show these for review. My nitpicks should then be squashed into the commits and the diff reuploaded...
>
> Maciej Poleski wrote:
> How rebasing can help this? The problem is I have two commits:
>
> B
> A
>
> I make review for A, then for B (rbtool creates diff with all local changes, if i create patch myself then review board rejects diff).
>
> Then we have some fixes for A (from review). I commit new revision.
>
> C (fixes for A)
> B
> A
>
> When I update review with new fixes, then changes from B are also pulled in. What is more if I push, also B will land on repo.
>
> How to handle this problem?
>
> Milian Wolff wrote:
> you rebase interactively, then reorder the commits such that C follows A directly, then squash it into A, giving just A, B.
>
> Maciej Poleski wrote:
> `git rebase tooling -i` says `noop`. Not surprising - man says about branches and origins. I have one branch (tooling) with all commits. If I detach head to commit "on different branch" - I guess git will forget about detached head and lose history (or simply refuse to perform one of required steps)
>
> Maciej Poleski wrote:
> stackoverflow helped, still don't know how to squash them, but history is modified in a way i expeced
>
> Milian Wolff wrote:
> the following is untested, better do this in a separate branch:
>
> git checkout -b test-rebase
> git rebase -i origin/master
> # now in your editor, reorder the commits (you seem to have done that)
> # then change the first column of a patch you want to squash from 'p' to 'f'
> # the editor should at the bottom also give you a list of commands
>
> Maciej Poleski wrote:
> I'm working on separate branch (tooling). This branch detached from master at 30.05.2015. master was merged to this branch at 20.06.2015 (just before I made changes to ClangSupport). I squashed commits after this merge and before introduction of RefactoringManager. I have problems with squashing changes before merge. The merge itself is a problem. Do You have some advice for this?
>
> Milian Wolff wrote:
> I don't want you to waste too much time on it, but you could create a new branch (tracking master) and then cherry-pick your commits in there and drop the old branch then rename the new branch. In the future, you'd then rebase it on master. But that won't work nicely if you want to publish your branch, as you'd potentially rewrite history and that is not allowed on KDE git. So probably just ignore this stuff, and concentrate on your actual problem at hand: getting refactoring features in.
>
> In the future though, you could use git commit --amend and similar to keep the history clean.
>
> Maciej Poleski wrote:
> I'm getting these two errors:
>
> ```
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
> ```
> or
> ```fatal: remote error: access denied or repository not exported: /kdev-clang```
>
> Each with probability 0.5 (i added my ssh key to KDE identity)
>
> Milian Wolff wrote:
> do you still get that error? sounds like a temporary network issue. if you still have the issue - what does `git remote -v` say for you?
>
> Maciej Poleski wrote:
> Yes. Still the same.
> My command is:
> `git push origin be8f7d168bf61397ff12a694be7e66f26567a497:refs/heads/tooling`
>
> and result of `git remote -v`:
> ```
> github git at github.com:Maciej-Poleski/kdev-clang.git (fetch)
> github git at github.com:Maciej-Poleski/kdev-clang.git (push)
> origin git://anongit.kde.org/kdev-clang (fetch)
> origin git://anongit.kde.org/kdev-clang (push)
> ```
>
> Milian Wolff wrote:
> Ah, you cannot push to anongit - that is readonly. Do you have a KDE developer account? If not, please apply for one: https://techbase.kde.org/Contribute/Get_a_Contributor_Account Put me in as your mentor.
>
> Furthermore, please rename your branch to something like this:
>
> git checkout -b wip/maciej/tooling
> git push --set-upstream origin wip/maciej/tooling
>
> Maciej Poleski wrote:
> I probably have KDE developer account. I tried this:
> `$ git push --set-upstream origin be8f7d168bf61397ff12a694be7e66f26567a497:wip/maciej/tooling`
>
> with result:
> ```
> error: unable to push to unqualified destination: wip/maciej/tooling
> The destination refspec neither matches an existing ref on the remote nor
> begins with refs/, and we are unable to guess a prefix based on the source ref.
> error: failed to push some refs to 'git at git.kde.org:kdev-clang'
> ```
>
> Maybe I should go back to `refs/heads/tooling` option? (this suffix is used to tell that i want new branch to be created on remote server)
>
> Milian Wolff wrote:
> if you have a dev account, fixup your remote:
>
> git remote set-url origin ssh://git@git.kde.org/kdev-clang
>
> Maciej Poleski wrote:
> The same result.
> ```
> github git at github.com:Maciej-Poleski/kdev-clang.git (fetch)
> github git at github.com:Maciej-Poleski/kdev-clang.git (push)
> origin ssh://git@git.kde.org/kdev-clang (fetch)
> origin ssh://git@git.kde.org/kdev-clang (push)
> ```
> git says that something is wrong with "unqualified destination: wip/maciej/tooling"
>
> Milian Wolff wrote:
> so you are locally on a branch called wip/maciej/tooling? (look at `git branch -a` - where is the asterisk?). If so, what happens when you call `git push`, or `git push origin`? Please paste the output to `paste.kde.org`. thanks
>
> Maciej Poleski wrote:
> https://paste.kde.org/po7nl1dp6/mwxo4u
>
> Milian Wolff wrote:
> have you tried what it says?
>
> git push --set-upstream origin wip/maciej/tooling
https://paste.kde.org/p9sy8u6cy/tm3zt4
But if I proceed with this command, then all local commits will be pushed (instead of only "accepted"). If I try `git push --set-upstream origin be8f7d168bf61397ff12a694be7e66f26567a497:wip/maciej/tooling -n` then I get https://paste.kde.org/pnoipnhyf/day4gf
- Maciej
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123963/#review82133
-----------------------------------------------------------
On Lip 2, 2015, 11:43 po południu, Maciej Poleski wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123963/
> -----------------------------------------------------------
>
> (Updated Lip 2, 2015, 11:43 po południu)
>
>
> Review request for KDevelop.
>
>
> Repository: kdev-clang
>
>
> Description
> -------
>
> First bits of refactorings.
> Skeleton of interface for KDevelop.
> Build system (really nasty, linked DSO has 18MiB).
> CompilationDatabase for CMake projects and ClangTool (with cache, but without cache updates).
> Interface is not frozen for now.
>
> Currently building of refactorings is enabled only if Clang 3.6.x is found. In other case build system behaves exactly as current master.
>
> Refactorings require some contextual informations about projects. I made draft of interface with should feature:
> - Stable ABI - dlopen (or equivalent) a DSO and if succeed (binary is still compatible with Clang libraries ABI), dlsym (or equivalent) some functions which are to provide all refactorings features
> - Prototypes (with some implementation) of functions constituting API between KDevelop and refactorings backend
> - It may be considered to use Qt plugin system to provide implementation of this (or equivalent) interface. This would be more expensive, but also more portable
> - In worst case this library (static version) can be used with additional driver to make stand-alone executable providing all refactorings features (but it would require additional marshaling and hamper cooperation with user (how to provide UI in such a case?))
>
> Handling dependencies between Clang/LLVM libraries is a nightmare. I extended FindClang.cmake to find much more libraries and used them to link with first pieces of my code. This is huge, requires additional libraries like zlib and even ordering of dependencies can cause linker errors.
>
> Interface is not finished
>
>
> Diffs
> -----
>
> CMakeLists.txt 875172a8407f4bd9faf330f032a280fa66c2b16f
> clangsupport.h 8ed1ec90bbbc41d7c7a94d926e0951c729a6194c
> clangsupport.cpp e22c55426a2e839ec11cbe0b2fe1e13721b0583a
> cmake/FindClang.cmake 6c9bd6ef0242319122dcc7e6fd6cea8d9f0cbfbb
> refactoring/CMakeLists.txt PRE-CREATION
> refactoring/documentcache.h PRE-CREATION
> refactoring/documentcache.cpp PRE-CREATION
> refactoring/interface.h PRE-CREATION
> refactoring/interface.cpp PRE-CREATION
> refactoring/kdevrefactorings.h PRE-CREATION
> refactoring/kdevrefactorings.cpp PRE-CREATION
> refactoring/kdevrefactorings_disabled.h PRE-CREATION
> refactoring/nooprefactoring.h PRE-CREATION
> refactoring/nooprefactoring.cpp PRE-CREATION
> refactoring/refactoring.h PRE-CREATION
> refactoring/refactoring.cpp PRE-CREATION
> refactoring/refactoringcontext.h PRE-CREATION
> refactoring/refactoringcontext.cpp PRE-CREATION
> refactoring/refactoringinfo.h PRE-CREATION
> refactoring/refactoringinfo.cpp PRE-CREATION
> refactoring/renamevardeclrefactoring.h PRE-CREATION
> refactoring/renamevardeclrefactoring.cpp PRE-CREATION
> refactoring/utils.h PRE-CREATION
> refactoring/utils.cpp PRE-CREATION
>
> Diff: https://git.reviewboard.kde.org/r/123963/diff/
>
>
> Testing
> -------
>
> Compiles on my Gentoo system. It makes sense to build this only on system with Clang 3.6.
>
>
> Thanks,
>
> Maciej Poleski
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20150710/b200a67e/attachment-0001.html>
More information about the KDevelop-devel
mailing list