[Lldb-commits] [PATCH] D48060: Introduce lldb-framework CMake target and centralize its logic

[Alex Langford via Phabricator via lldb-commits]

xiaobai added a comment.

I think this is in a pretty good state. I built LLDB.framework with xcodebuild and compared it. There are still some discrepancies but this brings us a step closer to a final working solution.



================
Comment at: cmake/modules/LLDBFramework.cmake:45
+
+  add_dependencies(lldb-framework liblldb lldb-argdumper lldb-server lldb-framework-headers)
+  add_dependencies(finish_swig lldb-framework)
----------------
xiaobai wrote:
> labath wrote:
> > xiaobai wrote:
> > > labath wrote:
> > > > xiaobai wrote:
> > > > > labath wrote:
> > > > > > Maybe lldb-argdumper and lldb-server dependencies should be handled as a part of INCLUDE_IN_FRAMEWORK argument to add_lldb_executable? Or do you have other plans for that?
> > > > > One of the goals I had in centralizing the framework generation code would be to centralize and make explicit which tools went into the framework. The idea I had was to get rid of the INCLUDE_IN_FRAMEWORK argument to add_lldb_executable. Since add_lldb_executable builds the binary differently when building for the framework (modifying the rpath, changing the output destination and symlinking it to your build tree's bin dir), it should be sufficient just to check for LLDB_BUILD_FRAMEWORK.
> > > > > 
> > > > > What do you think of this?
> > > > Both of the approaches sound reasonable to me. If you want to go this way, then I'm fine with that.
> > > I've begun refactoring to remove `INCLUDE_IN_FRAMEWORK` but I've started thinking about some possibly negative repercussions. I'm wondering what you think of this:
> > > 
> > > `add_lldb_tool` (which invokes `add_lldb_executable`) can be used to add lldb executables that won't be included in the framework AFAICT (e.g. lldb-mi). What I was going to do was remove `INCLUDE_IN_FRAMEWORK` option so that every tool will get put into the framework and symlinked to `$BUILD_DIR/bin` when you run cmake with `LLDB_BUILD_FRAMEWORK=1`. This will mean that lldb-mi will be put in the framework if you do something like `make lldb-mi` after configuring with `LLDB_BUILD_FRAMEWORK=1`.
> > > 
> > > In that case, do you think it makes sense to keep `INCLUDE_IN_FRAMEWORK` as an option and use that to build part of the dependency tree for the lldb-framework target? Or do you think this is an unlikely enough example that it shouldn't matter?
> > I think this is an important issue. We shouldn't have our install artifacts depend on what other targets the user happened to build. And it's not just the user typing "make lldb-mi" thats the problem. He can just decide to type "make" to build all targets, and then he'll end up with the same issue.
> > 
> > I think it still may be possible to have framework management centralized if you would make the list of targets that go into the framework explicit here. Something like:
> > ```
> > foreach(target in ${TOOLS_THAT_GO_INTO_THE_FRAMEWORK})
> >   do_whatever_add_lldb_tool_would_have_done()
> > endforeach()
> > ```
> > But, as I said, I think that keeping this part of the logic inside add_lldb_tool is fine too. If you decide to keep INCLUDE_IN_FRAMEWORK arg, then I think it is natural for the dependency management to be done there too. (Basically, I want to avoid the knowledge of what tools go into the framework to be defined in more than one place).
> I'm going to attempt to make centralization work just because I would like to avoid knowledge of what goes into the framework scattered. Thanks for the help.
Decided to keep `INCLUDE_IN_FRAMEWORK` as removing it would introduce more boilerplate and wrapping that works around the problem instead of fixing it.


https://reviews.llvm.org/D48060