[lldb-dev] Is lldb-server compatible with GDB ?
Hello, Can we use GDB with lldb-server ? I see the vice-versa wroks i.e LLDB with gdbserver. I did try using lldb-server with GDB but I got errors (incompatible packet length). I was wondering if there is some special tweaking needed for lldb-server to work with GDB ? BR, A Ravi Theja ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [llvm-dev] Switching to git (Windows experience) (was re:[cfe-dev] Github anyone?)
Hi, My 2 cents on the topic: 1) I recommend not to use TortoiseGit. It tries to apply SVN workfliw to git, which doesn' t really work. 2) We use GitExtensions at our company for more than 2 years now. I prefer to use it with P4Merge instead if KDiff. It works much better(in my opinion). And to answer a specific concern: GitExtensions does have an "Apply Patch" function integrated in to the UI. I haven't used it yet. But by looking at it, it supports calling the preferred merge/diff tool when errors occur. Just like rebasing and merge. I don't think it can be simpler as that. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] GitHub anyone?
On 2 June 2016 at 08:48, Renato Golin via lldb-dev wrote: > Of all those issues, Windows tooling is a minor problem that shouldn't > impact decision that much and sub-modules need a lot of ironing out to > be considered good enough. My *personal* take away is that sub-modules > (or an alternative server side solution) is the only strong technical > issue we need to solve before we decide. I think Takumi's repository and script covers the real uses (bisection, principally) as well as we need and probably better than SVN. I suppose we might extend it to put an auto-incrementing revision number in the commit message too, but that's trivial. I think the responses in the thread have been heavily in favour (including after AAron's mention in LLVM weekly), so we should either get a more rigorous survey going as Tanya suggested (if we think it's useful) or get started on the actual move. I'm not really convinced that a survey would reach enough of a wider audience to affect our actions here, though I think the results would be very interesting anyway in the longer term (particularly on preferred workflows). > How does a move look like? > > If we decide to move, the proposed schedule is something like this: > > STEP #1 : Pre Move > > [...] > 1. Register an official GitHub project with the LLVM foundation. Chandler already did that: https://github.com/llvm. So we're one step in already! Tim. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [3.9 Release] Release plan and call for testers
Hello everyone, It's time to start planning for the 3.9 release. Please let me know if you'd like to help providing binaries and testing for your favourite platform. I propose the following schedule: - 18 July: Create the release branch; build and test RC1 soon thereafter. - 1 August: Tag, build and test RC2. Any unfinished features need to be turned off by now. As we get closer to the release, the bar for merging patches rises. - 22 August: Tag 3.9.0-final. The release ships when binaries are ready. Also, I have three more questions for the community: 1) Right after the branch, the version number of the trunk will be incremented. I assume this means bumping the major version number, taking us to 4.0? IIUC, that's what happened after 1.9 and 2.9. 2) Following up on the May thread about the release process [1], I'd like to make the schedule we've followed for the last few years more official by posting somewhere on the web page that we're committed to shipping two major releases per year: one in early March (branching mid-January), and one early September (branching mid-July), usually with one (or sometimes two) "dot" releases in between. 3) Another follow-up from that thread: it's usually the same people who test the releases for their platform. Rather than asking everyone each time, I'd like to make a list of who's responsible for each platform and put that on the web page. Testers can still sign-up or resign as they like, of course. Would you testers be OK with this? Let me know what you think. Cheers, Hans [1]. http://lists.llvm.org/pipermail/llvm-dev/2016-May/099541.html ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?
For the JuliaLang project, we started with git-submodules for building some of our loosly-coupled external dependencies, but eventually moved to a custom-built solution (we call it "git-externals") to overcome some of the workflow limitations. I haven't yet run across a similar suggestion elsewhere as a replacement for git-submodules (although it's perhaps an expansion on "Simply require multiple clones + tooling for bisect"), so I thought I would suggest it for consideration too. As the author of this code, I may be a bit biased, but I think it takes a slightly different approach to understanding the problem: it approaches the question as being part of the domain of the build system (of ensuring a reproducible and automated build, as controlled by the committer) rather than being the domain of the source-management system (of describing a reproducible checkout, but controlled by the user). Our implementation is an inscrutable `make` script, but really only consists of a couple lines, as I'll describe later. For other similar prior art, I consider package management like the Rust Cargo lock file (http://doc.crates.io/guide.html#cargotoml-vs-cargolock) to be a roughly equivalent concept for approaching the problem from the other direction (as build-dependency version-management, as opposed to considering alternative implementations of git-submodules). As others have mentioned, one of the issues JuliaLang was encountering with git-submodules was that the basic git commands (such as pull and bisect) don't natively consider submodules and require extra flags to ensure everything in sync. Our initial solution for this was to call `git submodule update --init` as part of calling `make`. This seemed to work much better for the casual user at keeping the build "just working" with minimal git experience. The second limitation we encountered was that the submodule state is not available as a normal file in the repo. This meant that packaging the repo required more work than simply `tar cjf` and the download link auto-generated by Github ( https://github.com/JuliaLang/julia/archive/master.zip) was unable to build. Our solution was to have the build system (`make` in our case) be fully responsible for managing the state of the external dependencies, instead of involving `git submodule` at all. Now we can store the dependency information as a regular makefile (for an example, see https://github.com/JuliaLang/julia/blob/master/deps/utf8proc.version). The build system would include this `$(EXT).version` file, then inspect the resulting variables `$(EXT)_SHA1` and `$(EXT)_BRANCH` to pick the right commit (`git fetch $(EXT)_BRANCH && git checkout $(EXT)_SHA1`). The trigger for this checkout is the relative timestamp of `$(EXT).version` vs. `$(EXT)/.git/HEAD`; this (heuristically) allows the user to make edits to the sub-repo without triggering the checkout code, but ensures that a checkout of the updated version will be triggered whenever the `$(EXT).version` file is modified, such as by pull or bisect in the parent repo. -Jameson On Thu, Jun 2, 2016 at 2:29 PM via llvm-dev wrote: > Renato Golin via cfe-dev writes: > > I'd like to generate and add to your notes a list of submodule > alternatives so we can explore options. Here's a start. Not all of > these are equally good IMHO. > > - Creating one big repository > - Simply require multiple clones + tooling for bisect > - git-subtree (with to-be-contributed enhancements) > - Google repo > > -David > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Incorrect libclang dependency in standalone build
Hi! I got next message for each internal library when building standalone LLDB on RHEL 6: CMake Warning (dev) at cmake/modules/AddLLDB.cmake:90 (add_dependencies): Policy CMP0046 is not set: Error on non-existent dependency in add_dependencies. Run "cmake --help-policy CMP0046" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The dependency target "libclang" of target "lldbTarget" does not exist. It was introduced recently. r272406 is last version I tried to build. Eugene. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Incorrect libclang dependency in standalone build
This is a side-effect of the cmake version bump to 3.4. Cmake now errors out on non-existing targets. You'll need to figure out a way to avoid adding this target to the dependency list. Patches welcome. :) pl On 10 June 2016 at 16:20, Eugene Zelenko via lldb-dev wrote: > Hi! > > I got next message for each internal library when building standalone > LLDB on RHEL 6: > > CMake Warning (dev) at cmake/modules/AddLLDB.cmake:90 (add_dependencies): > Policy CMP0046 is not set: Error on non-existent dependency in > add_dependencies. Run "cmake --help-policy CMP0046" for policy details. > Use the cmake_policy command to set the policy and suppress this warning. > > The dependency target "libclang" of target "lldbTarget" does not exist. > > It was introduced recently. r272406 is last version I tried to build. > > Eugene. > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Incorrect libclang dependency in standalone build
On Fri, Jun 10, 2016 at 4:25 PM, Pavel Labath wrote:
> This is a side-effect of the cmake version bump to 3.4. Cmake now
> errors out on non-existing targets. You'll need to figure out a way to
> avoid adding this target to the dependency list. Patches welcome. :)
Comment in cmake/modules/AddLLDB.cmake tells:
# Hack: only some LLDB libraries depend on the clang autogenerated headers,
# but it is simple enough to make all of LLDB depend on some of those
# headers without negatively impacting much of anything.
add_dependencies(${name} libclang)
May be dependencies should be expressed explicitly? Of course, if
libraries will be valid.
> pl
Eugene.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
