cc lldb-dev since the original message cc'd it.
On 11/9/18, 12:31 PM, "Alex Langford" wrote:
Hi Stefan,
Thanks for taking the time to improve LLDB's CMake infrastructure!
(1) I don't entirely remember the reason I had separated them out into
separate targets. A post-build step would be fine, so feel free to merge these.
(2) I have no problems with this. If I remember correctly, I wanted to put
everything into LLDBFramework.cmake originally and include it if
LLDB_BUILD_FRAMEWORK got set, but that proved more difficult than I realized. I
think what you are suggesting is better than what I ended up doing. Feel free
to make that change.
(3) I think this is a good idea. I found this confusing as well.
(4) If that is the case, I think I agree that the Xcode behavior is better.
(5) I'm not sure that this is going to actually simplify things. I don't
think it's possible to do in source/API/CMakeLists.txt because the tools
haven't been added as targets yet. With the current CMake logic, you could pull
this logic into its own section that happens after the tools are added as
targets. I don't find this any better than what we have now.
(6) I'm not sure why this is the case actually. I believe this was added by
beanz originally, I just moved this check to be closer to the beginning of the
build. If it works with CMake versions less than 3.7 then I have no issues with
removing it.
Let me know if something is unclear or you have further questions/concerns.
Alex
On 11/9/18, 9:38 AM, "sgraen...@apple.com on behalf of Stefan Gränitz"
wrote:
Hello Alex, hello Pavel
I spent some time creating/streamlining our CMake infrastructure
downstream of LLDB and learned a few things about bundles, versions,
code-signing etc. (mostly on the Darwin side of things). I am currently sorting
out what can be upstreamed and prepare reviews.
Some work is still todo for the LLDB shared library/framework (for
simplicity I will call it LLDB.framework). It would be great to know, if you
have concerns or comments on the following points:
(1) The liblldb target builds the actual LLDB.framework, while the
lldb-framework target adds headers, symlinks, etc. What is the reason for this
separation? Can I merge that into one target with post-build steps?
(2) In previous reviews there was an effort to centralize the code for
building LLDB.framework, which makes sense to me. With the current
LLDBFramework.cmake approach, however, it’s spread over at least 3 different
files (lldb/CMakeLists.txt for init and lldb/source/API/CMakeLists.txt for
actual definition). In a similar case downstream, I did all that in a single
CMakeLists.txt in the source folder. While I see that LLDBFramework affects the
whole project, I don’t see why we need a separate LLDBFramework.cmake (BTW
upstream it’s included only once). Do you think I can move things to
lldb/source/API/CMakeLists.txt where possible?
(3) Currently the build directory for LLDB.framework is determined from
LLDB_FRAMEWORK_INSTALL_DIR, which I think is a little confusing. Can I clean
this up? (e.g. having a LLDB_FRAMEWORK_BUILD_DIR)
(4) With Xcode, executables are emitted in bin and copied to
LLDB.framework where necessary. CMake emits them into LLDB.framework directly
and creates symlinks to bin. With LLVM_EXTERNALIZE_DEBUGINFO on Darwin, this
has the effect, that by default their dSYMs will end up in LLDB.framework.
Thus, I would prefer the Xcode behaviour here.
(5) Couldn’t (4) also simplify the INCLUDE_IN_SUITE logic? I would
consider it to be LLDB.framework’s responsibility to set dependencies and
adjust RPATHs for all required artefacts. The tools wouldn’t need to care about
that (though, they could still check LLDB_BUILD_FRAMEWORK). The RPATH-login for
case ARG_INCLUDE_IN_SUITE && LLDB_BUILD_FRAMEWORK is quite complicated though
and I wonder if there are strong reasons not to do that. What do you think?
(6) Just out of interest: why is LLDB_BUILD_FRAMEWORK is not supported
on CMake < 3.7?
Best
Stefan
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
