Fixing messed-up include lines

Hi everyone,

The current LLDB source code contains a lot of include lines like the following:
#include <LLDB/SBDefines.h>

I'm not entirely sure how that works with the Xcode build system, but
it won't work correctly with a more usual make-based system which I'm
working on. Attached is a patch which fixes such #include lines in
the include/lldb/API directory. Will this (or other patches like it)
break the Xcode build system?

-Eli

APIincludes.txt (14.4 KB)

Hi Eli,

This patch is fine. If it breaks the Xcode build I'll fix it.

Thanks,

J

Looks like Driver.cpp needs the include directory but that's it.

-eric

Okay, thanks.

-Eli

Yes, as it would be for all projects that would like to use the LLDB framework. This is unfortunate as this is not the way it works with frameworks on OS X :frowning:

-- Jean-Daniel

Yeah, lldb builds an LLDB.framework which probably explains the #include <LLDB/...> pathnames. We'll see if it still builds with more traditional pathnames Eli checked in. I'm waiting for the 42MB llvm.zip file to download to my computer right now. :slight_smile:

J

Yeah, it doesn't :slight_smile:

Since you're looking though I'll let you worry. :slight_smile:

-eric

Just a though, but as the OS X syntax is only useful when working with the framework, one way to workaround this problem may be to add a new "script build step" after the "Copy Headers" step in the Xcode framework target to patch the installed headers.

A sed script like the following one should do the trick:

sed -e 's/\(#include[ ]*\)"lldb\/\(API\/\)\{0,1\}\(.*\)"/\1 <LLDB\/\3>/1' *.h

-- Jean-Daniel

Thanks for that Jean-Daniel, I will work this into the Xcode project for the framework build.

Thanks. Just in case, in the previous command, I meant "sed -i ‘’ " not “sed -e”.

sed -i ‘’ ‘s/(#include[ ])"lldb/(API/){0,1}(.)"/\1 <LLDB/\3>/1’ “$(TARGET_BUILD_DIR)/$(PUBLIC_HEADERS_FOLDER_PATH)/*.h”

And as I’m not a sed expert, this script may possibly be improved :wink:

– Jean-Daniel

Hi Eli,

This patch is fine. If it breaks the Xcode build I'll fix it.

Looks like Driver.cpp needs the include directory but that's it.

Yes, as it would be for all projects that would like to use the LLDB
framework. This is unfortunate as this is not the way it works with
frameworks on OS X :frowning:

Yeah, lldb builds an LLDB.framework which probably explains the #include
<LLDB/...> pathnames. We'll see if it still builds with more traditional
pathnames Eli checked in. I'm waiting for the 42MB llvm.zip file to
download to my computer right now. :slight_smile:

Yeah, it doesn't :slight_smile:

Since you're looking though I'll let you worry. :slight_smile:

Just a though, but as the OS X syntax is only useful when working with the
framework, one way to workaround this problem may be to add a new "script
build step" after the "Copy Headers" step in the Xcode framework target to
patch the installed headers.

A sed script like the following one should do the trick:

sed -e 's/\(#include[ ]*\)"lldb\/\(API\/\)\{0,1\}\(.*\)"/\1 <LLDB\/\3>/1'
*.h

Thanks for that Jean-Daniel, I will work this into the Xcode project for the
framework build.

Thanks. Just in case, in the previous command, I meant "sed -i '' " not "sed
-e".
sed -i '' 's/\(#include[ ]*\)"lldb\/\(API\/\)\{0,1\}\(.*\)"/\1 <LLDB\/\3>/1'
"$(TARGET_BUILD_DIR)/$(PUBLIC_HEADERS_FOLDER_PATH)/*.h"
And as I'm not a sed expert, this script may possibly be improved :wink:
-- Jean-Daniel

if you add this as a step in the build process, and someone's build
and source directories are the same, won't that make subversion want
to commit the xCode compatible headers?

yours,
Bobby

if you add this as a step in the build process, and someone's build
and source directories are the same, won't that make subversion want
to commit the xCode compatible headers?

(sorry if this goes through twice)

yours,
Bobby

No, it will be acting upon the header files which have already been copied into the build folder that contains LLDB.framework (which contains a copy of the header files).

So no harm should come to the original headers.

excellent. thanks for the clarification.