[MacPorts] #45251: request for lldb

[René J.V. Bertin]

On Friday September 09 2016 17:07:48 MacPorts wrote:

>  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. Of course I can only tell if it has any benefits over my current approach once I've gotten it to work ;)

>  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?

R.