hold off on check-ins, please [ALL CLEAR]

A sync on all 3 of llvm, clang and lldb up to r214233 has removed all the new errors on Linux and MacOSX.

Thanks for the help and patience, all. Please feel free to check in once again.

So, maybe I'm just new no LLDB, but is there *ever* any expectation that
all three repos don't need to be version locked?

Clang, LLVM, LLD, compiler-rt, etc. are all absolutely version locked.
While things *may* work if you are skewed by a bit, there is no guarantee
and this is an expected failure mode if you take the risk....

Is this different in LLDB?

I generally sync llvm/clang in the AM, locked, and work with that throughout the day. If I kept up with TOT on all, all day long, I’m pretty sure my work machine, big as it is, would be building all day long :wink:

The only time this has bitten me is when something LLDB depends on changes. Then I fix that or synch to the fix requirement that somebody else made.

Are you suggesting something different?

-Todd

I generally sync llvm/clang in the AM, locked, and work with that
throughout the day. If I kept up with TOT on all, all day long, I'm pretty
sure my work machine, big as it is, would be building all day long :wink:

This certainly isn't true for LLVM, Clang, and LLD themselves. With
cmake+ninja, it is not at all burdensome. I'm on the extreme end and will
routinely update over 40 or 50 times a day.

The only time this has bitten me is when something LLDB depends on
changes. Then I fix that or synch to the fix requirement that somebody else
made.

Are you suggesting something different?

I'm suggesting a) *always* sync in or order to "fix" so that it is easy to
make cross-cutting changes without people wasting time inventing a
compatible way of doing it, and b) to including syncing every repo as the
first step of any "i have tests failing in a clean build?" sanity check.
Certainly, that seems more productive than asking people to stop committing.

In LLVM land we have build bots that make sure that if anyone breaks tests,
the patch is reverted. Really, really fast. As a consequence, there is
never a need to "stop committing". I think that's a much healthier plan
especially with increasingly distributed contributors to LLDB.

Just my 2 cents though. As I said, I'm just lurking here. =D

All good to hear.

Let me know when we have hardware and I will get them build bots a-running :slight_smile:

-Todd

Certainly, that seems more productive than asking people to stop committing.

To be fair, it is very rare for a test break in the lldb code (without build bots being very effective at the moment) to be due to a change in llvm or clang.

Obviously the build bots will help a lot here!

If I'm working on something like stepping or process control or whatever, I don't really need to know whether there's some change in llvm land, I'm not touching those code paths. There is quite a lot of lldb that doesn't go through the expression evaluator, or only requires that you have some working version, not the most recent one. So I go for days quite happily not updating my llvm/clang checkout. I only bother about that if I'm working on the type system or expression evaluator. Moreover, I don't really want to know that somebody broke something in clang/llvm and then fixed it a couple of hours later. That is just noise that is not helpful to the work I am doing.

So I tend to not update my clang/llvm checkouts till something - usually some interface change that somebody else checks into lldb - forces me to.

Jim

FWIW, this doesn't really happen these days. Something broken in LLVM
staying in tree for an hour is *extremely* rare, and usually has 10s of
people up in arms trying to get it fixed on the list. We have build bots
and other systems which ensure that the tree is in a working state at all
times.

For what it's worth, the FreeBSD buildbot reports r214094 as good and
r214138 as broadly broken. (I'm waiting on Galina to add LLDB to the
"official" FreeBSD builder.)

One problem we have in LLDB though is that there are a handful of
intermittently failing tests, so a red buildbot isn't necessarily a
sign of a bad commit.

This has been improving over time, and I suspect once a decent set of
fast LLDB buildbots exist there will be more motivation to fix the
remaining cases.

Excellent! But except for a very few parts of lldb, llvm is really better viewed as a library we use, not as code we are developing. So you really shouldn't have to update frequently except when working on that code, when the interfaces change, or when you want to verify that someone hasn't broken one of its functions. It won't do any harm, of course, but there are already enough little interruptions in the course of an ordinary day, I don't feel the need to add more...

Jim

I suspect this is also somewhat a consequence of the Xcode LLDB build,
where Clang/LLVM is treated as a separate standalone library, not part
of a whole. (I'm still not quite sure how to map my usual directory
layout for cmake builds into what's expected by the Xcode build.)

Hey Ed,

I’ve actually got some build scripts I use to build lldb/clang/llvm on a MacOSX and rsync to Linux and FreeBSD VMs, doing all the conversions of directory structures and warnings/errors so that everything shows up in Xcode, regardless of compiler used on the remote end (clang/gcc). It has really helped my productivity when navigating code. (Something similar would be the case if I was in VS on Windows).

The short version is you need this:

MacOSX side with Xcode:
lldb

  • llvm
  • tools/clang

On the Linux/FreeBSD, everything-else side, you typically want to do this (as you are very familiar):

  • llvm
    -tools
  • clang
  • lldb

I am planning on cleaning up the build script a bit and putting it in our scripts dir. It takes care of all the dirty bits of moving files seamlessly between machines and having one of them be the “master”, making it easy to test changes everywhere, and all the architecture configurations can be built simultaneously. It’s based on a script that doesn’t have to be run via Xcode, it’s just possible to do so.

Currently the “master” bit is really setup to just be MacOSX, so the MacOSX xcode-based tree structure. But I could extend it to assume the main side is also in the other configuration.

Unfortunately this won’t go up until after I get back from a vacation (leaving end of day tomorrow, back in a little under 2 weeks).

Note, also, on Mac OS X, if you do:

svn co https://llvm.org/svn/llvm-project/lldb/trunk lldb
cd lldb
xcodebuild -configuration Debug

It will check out all the needed llvm/clang bits, put them in the structure Todd described, and build the whole thing for you.

Jim