lldb tests w/CMake+OSX

Hi all,

Does anyone know if it is possible to successfully run the lldb unit tests on OSX from a CMake build?

This is what I do to run the tests after an Xcode build:

ROOT_DIR=$HOME/ll/svn
LLDB_CONFIG=Debug
LLDB_BIN=$ROOT_DIR/lldb/DerivedData/lldb/Build/Products/$LLDB_CONFIG
PYTHONPATH=“$LLDB_BIN/LLDB.framework/Versions/A/Resources/Python”
DOTEST_OPTS=“–executable $LLDB_BIN/lldb --framework $LLDB_BIN/LLDB.framework -A x86_64 -C clang -s $ROOT_DIR/lldb/DerivedData/lldb-test-results”

cd $ROOT_DIR/lldb/test
./dosep.py --options “$DOTEST_OPTS”

But the CMake build doesn’t generate a --framework so I’m not sure what to do.

Vince

The correct way to test is to use the Xcode build.

The Xcode build can be done from the command line:

% cd lldb
% xcodebuild -configuration Release -target lldb-tool
% cd test
% ./dotest.py

Totally understood and agreed. But someone asked me to fix an issue in the CMake build files and I want to make sure that the binaries actually work =)

Greg Clayton <gclayton <at> apple.com> writes:

The correct way to test is to use the Xcode build.

Last I checked, the XCode build didn't build lldb-mi so that was not
an option. Does it now?

>
> Does anyone know if it is possible to successfully run the lldb unit

tests on OSX from a CMake build?

We run the tests but we don't pass a framework. I've asked if that was an
issue in a previous post (from dawn@burble.org). No one seemed to know. I
remember running dtrace on a debug session and things looked OK. We build
and run the tests as follows (lines wrapped due to gmane's 80 char limit):

Checkout with lldb and clang under llvm/tools.
cd llvm
mkdir build_ninja && cd build_ninja
cmake -G Ninja .. "-DLLVM_TARGETS_TO_BUILD=ARM;X86;AArch64"
    -DCMAKE_CXX_FLAGS="-std=c++11 -stdlib=libc++"
    -DCMAKE_BUILD_TYPE=Debug
ninja
export BUILDDIR=`pwd`
export LLDB_DEBUGSERVER_PATH=$BUILDDIR/bin/debugserver
    (if this debug server gives you problems use Apple’s instead :
     export LLDB_DEBUGSERVER_PATH=/Applications/Xcode.app
        /Contents/SharedFrameworks/LLDB.framework/Resources/debugserver)
cd ~/llvm/tools/lldb/test
./dotest.py --executable $BUILDDIR/bin/lldb

-Dawn

The --framework option should not be needed. So far as I can tell, it was only used to find the path to the lldb python module, but
we added the -P option to the lldb driver a while back so that lldb could tell you where it's Python directory is. If that's working properly, then we don't need to know where the framework is. If it isn't returning the correct value for the cmake built lldb, then we should fix that.

Jim

Btw, i think it’s important to keep the CMake build working for Mac. The reason being that since it’s what the rest of LLVM uses, having a familiar path to getting started hacking on it really encourages people to contribute (or at the very least, doesn’t DIScourage people from contributing). A MacOSX CMake builder would be great, but it would take some serious motivation from someone to make that happen

I'm motivated because my company uses CMake for the rest of our OS X
LLVM/Clang builds and it was easier to integrate a CMake LLDB into
that than to try to use the Xcode build. I've also seen a lot of OS X
CMake build breakage over the last year. I might be able to convince
the Boss People to get a build bot set up.

Cheers,
Jevin

P.S. Has anyone built LLDB without *any* dependencies on Python? Build
dependencies are fine but I'd really like to get rid of any runtime
dependencies.

I routinely build LLDB without python dependency (at runtime), but admittedly it gets broken quite frequently and I believe current trunk as broken as well module a small patch I have lying around somewhere.

The tests won’t run without a runtime dependency on python. Not sure if that’s a problem for you.

When I first started working on Windows python was broken, and LLDB_DISABLE_PYTHON=1 was the only way I could build. Not sure about now, but I’ve definitely done it in the past.

Having a test build that uses Python and then distributing a
python-less release version would work fine with me. I need to play
around with the various Python knobs again to see exactly what breaks
and what works.

Cheers,
Jevin

Greg Clayton <gclayton <at> apple.com> writes:

The correct way to test is to use the Xcode build.

Last I checked, the XCode build didn't build lldb-mi so that was not
an option. Does it now?

It does now:

Author: gclayton
New Revision: 226530

URL: http://llvm.org/viewvc/llvm-project?rev=226530&view=rev
Log:
Added an Xcode target so we build the "lldb-mi" executable as part of the "desktop" and "desktop no xpc" targets.

Include paths were switched to be user include paths, if this breaks the linux build we will need to fix the Makefiles/cmake stuff.

<rdar://problem/19198581>

Would that breakage be related to the significant CMake 3.1 changes *) in the way things are done on OS X?

*) those came up on the MacPorts MLs and on MacPorts trac (#46493 (Update: cmake 3.1.0) – MacPorts but doesn't have as much detail as I thought I remembered)

R.