[MacPorts] #45251: request for lldb

[MacPorts]

#45251: request for lldb
--------------------------+----------------------
  Reporter:  rjvbertin@…  |      Owner:  larryv@…
      Type:  request      |     Status:  assigned
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:
      Port:  lldb         |
--------------------------+----------------------

Comment (by rjvbertin@…):

 [this inadvertently went out as an email first, sorry about that]

 >  I'm ok with splitting up the port and would be happy do to so if we can
 >  avoid build time regressions and setup sane dependencies.

 Building a redistributable, standalone libclang is a bit of a separate
 issue, no?
 That said, it's also supposed to speed up compile times when using clang,
 as there are less shared libraries to load at each invocation.


 >  I don't like
 >  the current situation in which clang rebuilds libLLVM.dylib at build
 time
 >  instead of using llvm-config to find the installed one to build and
 link
 >  against.

 No, I agree (all the more since build times for 3.9 appear to be almost
 50% longer than the ones for 3.8).

 That said, I tried my trick of calling make in the tools/clang. For once
 it doesn't work, probably because there are apparently 3 parallel
 directories that have to be built in the right order.

 You probably saw my thread about standalone building of lldb. In short: it
 almost works. I copied the missing CheckAtomic.cmake file into the
 installed cmake/llvm directory, and tried to build lldb. It aborted
 because of trying to include a headerfile from the llvm source:

 {{{
 In file included from /opt/local/var/macports/build/_opt_local_site-
 ports_lang_llvm-3.9/lldb-3.9/work/llvm-3.9.0.src/tools/lldb/tools/lldb-
 mi/MICmdCmdData.cpp:45:
 /opt/local/var/macports/build/_opt_local_site-
 ports_lang_llvm-3.9/lldb-3.9/work/llvm-3.9.0.src/tools/lldb/tools/lldb-
 mi/MIUtilParse.h:13:10: fatal error:
       '../lib/Support/regex_impl.h' file not found
 #include "../lib/Support/regex_impl.h"
          ^
 1 error generated.
 }}}

 But, the extrapolated build time would be around 45 minutes (against IIRC
 almost 1h15 for my current approach) and the extrapolated build directory
 size is over 2x smaller.

 >  If that is needed, it should be addressed as a patch to the build
 system
 >  that can be integrated upstream.  Using install_name_tool can introduce
 a
 >  dependency on cctools, which is a pain point as it can cause a
 dependncy

 Can you explain? Why would that the be case as long as we don't tell the
 port to use the copy from cctools?


 >  Let's track that in a separate bug (I filed #52196).  I'm of the
 opinion
 >  that `llvm-config --ldflags` should "do the right thing" but it doesn't
 >  setup rpath.

 I've thought about this a bit more, and it may be a moot point. The
 official Linux builds I have on my Ubuntu rig also install libclang,
 libLLVM etc. somewhere that's not part of the standard ldconfig search
 path. IOW, cross-platform code already has to add the path to those
 libraries to its rpath, which should solve the issue on OS X too. No?

-- 
Ticket URL: <https://trac.macports.org/ticket/45251#comment:28>
MacPorts <https://www.macports.org/>
Ports system for macOS