Re: [lldb-dev] [OS X]: building lldb with cmake

2016-09-10 Thread René J . V . Bertin via lldb-dev
On Friday September 09 2016 20:00:34 Zachary Turner wrote:
>To be completely honest with you I don't even know why this class exists.
>All it needs to do is use llvm's regex class.  The entire MIUtilParse.h /
>.cpp files can be deleted as far as I'm concerned.

That clearly needs a bit more work, it provides a class that's used. It also 
needs access to the private header; the public Regex.h header lacks the 
definition for a private type.
I'll leave this to someone else to figure out. I was trying a standalone build 
with the lldb source tree at its usual location so I could simply correct the 
include statement (#include "../../../lib/Support/regex_impl.h"). 

I must say that there is a significant advantage to doing a standalone build if 
you already have all dependencies in place. The resulting build directory is 
over twice smaller than it is when you do an official/full configure and then 
invoke make in the tools/lldb subdirectory. The build time must be 
proportionally shorter.

R.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] [OS X]: building lldb with cmake

2016-09-10 Thread René J . V . Bertin via lldb-dev
There's another issue with the standalone build.

I call cmake with -DDCMAKE_INSTALL_PREFIX=/opt/local/libexec/llvm-3.9, so that 
lldb gets installed with the rest of llvm 3.9, into /opt/local/libexec/llvm-3.9 
. It looks like liblldb.${version} is generated with the wrong install path 
recorded:

%> otool -L /opt/local/libexec/llvm-3.9/lib/liblldb.dylib 
/opt/local/libexec/llvm-3.9/lib/liblldb.dylib:
/opt/local/lib/liblldb.3.9.0.dylib (compatibility version 0.0.0, 
current version 3.9.0)
/opt/local/lib/libedit.0.dylib (compatibility version 1.0.0, current 
version 1.51.0)
/opt/local/lib/libncurses.6.dylib (compatibility version 6.0.0, current 
version 6.0.0)
/opt/local/lib/libform.6.dylib (compatibility version 6.0.0, current 
version 6.0.0)
/opt/local/lib/libpanel.6.dylib (compatibility version 6.0.0, current 
version 6.0.0)
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Python 
(compatibility version 2.7.0, current version 2.7.0)
/opt/local/lib/libxml2.2.dylib (compatibility version 12.0.0, current 
version 12.2.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 
(compatibility version 2.0.0, current version 157.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 
(compatibility version 300.0.0, current version 1056.17.0)

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
(compatibility version 150.0.0, current version 855.17.0)

/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 
(compatibility version 1.0.0, current version 59.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security 
(compatibility version 1.0.0, current version 55471.14.40)

/System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols
 (compatibility version 1.0.0, current version 106.0.0)
/opt/local/lib/libffi.6.dylib (compatibility version 7.0.0, current 
version 7.4.0)
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current 
version 1.2.8)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1197.1.1)
/opt/local/libexec/llvm-3.9/lib/libLLVM.dylib (compatibility version 
1.0.0, current version 3.9.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
120.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 
228.0.0)

and thus

%> otool -L /opt/local/libexec/llvm-3.9/bin/lldb
/opt/local/libexec/llvm-3.9/bin/lldb:
/opt/local/lib/liblldb.3.9.0.dylib (compatibility version 0.0.0, 
current version 3.9.0)
/opt/local/lib/libncurses.6.dylib (compatibility version 6.0.0, current 
version 6.0.0)
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current 
version 1.2.8)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1197.1.1)
/opt/local/libexec/llvm-3.9/lib/libLLVM.dylib (compatibility version 
1.0.0, current version 3.9.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
120.0.0)

so

%> /opt/local/libexec/llvm-3.9/bin/lldb
dyld: Library not loaded: /opt/local/lib/liblldb.3.9.0.dylib
  Referenced from: /opt/local/libexec/llvm-3.9/bin/lldb
  Reason: image not found
Trace/BPT trap

I also seems that the actual path to liblldb is not added to lldb's rpath.

R.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] [OS X]: building lldb with cmake

2016-09-10 Thread Zachary Turner via lldb-dev
Agree that a standalone build would be great to have working, it just
requires someone willing and able to come along and fix it :)

On Sat, Sep 10, 2016 at 1:00 AM René J.V. Bertin 
wrote:

> On Friday September 09 2016 20:00:34 Zachary Turner wrote:
> >To be completely honest with you I don't even know why this class exists.
> >All it needs to do is use llvm's regex class.  The entire MIUtilParse.h /
> >.cpp files can be deleted as far as I'm concerned.
>
> That clearly needs a bit more work, it provides a class that's used. It
> also needs access to the private header; the public Regex.h header lacks
> the definition for a private type.
> I'll leave this to someone else to figure out. I was trying a standalone
> build with the lldb source tree at its usual location so I could simply
> correct the include statement (#include
> "../../../lib/Support/regex_impl.h").
>
> I must say that there is a significant advantage to doing a standalone
> build if you already have all dependencies in place. The resulting build
> directory is over twice smaller than it is when you do an official/full
> configure and then invoke make in the tools/lldb subdirectory. The build
> time must be proportionally shorter.
>
> R.
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] [OS X]: building lldb with cmake

2016-09-10 Thread Michał Górny via lldb-dev
On Fri, 09 Sep 2016 12:37:01 -0700 (PDT)
René J.V. Bertin via lldb-dev  wrote:

> Hi,
> 
> I wanted to see how far I could get with a standalone build, so I copied the 
> missing CheckAtomic.cmake file into the installed cmake/llvm directory, and 
> tried to build lldb. 
> It aborted at 93% because it tried 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.
> }}}
> 
> To be honest, I'm not sure how this could have worked with my approach of 
> calling make in build/tools/lldb, but that looks like a clear bug if 
> standalone builds are to be possible.

This class should no longer be used anywhere (unless someone re-added
uses of it in the last few days). https://reviews.llvm.org/D23883
removes it completely.

-- 
Best regards,
Michał Górny



pgpmWUXr5lWCx.pgp
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] [OS X]: building lldb with cmake

2016-09-10 Thread Michał Górny via lldb-dev
On Sat, 10 Sep 2016 15:09:13 +
Zachary Turner via lldb-dev  wrote:

> Agree that a standalone build would be great to have working, it just
> requires someone willing and able to come along and fix it :)

I have it on my TODO but honestly speaking, LLDB is a bit of a mess
right now and I'm not even sure where to start. So far I'm focusing
on the other LLVM components but I should be able to get to LLDB soon.
Though I can't promise much since my time is quite limited.

-- 
Best regards,
Michał Górny



pgpGRLsKkUI8F.pgp
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] [OS X]: building lldb with cmake

2016-09-10 Thread René J . V . Bertin via lldb-dev
On Saturday September 10 2016 17:26:26 Michał Górny wrote:

Re: MIUtilParse: I'm building the 3.9.0 release so no worries that the class 
has been added back supposing it was removed *after* the release.

>> Agree that a standalone build would be great to have working, it just
>> requires someone willing and able to come along and fix it :)
>
>I have it on my TODO but honestly speaking, LLDB is a bit of a mess
>right now and I'm not even sure where to start. So far I'm focusing
>on the other LLVM components but I should be able to get to LLDB soon.
>Though I can't promise much since my time is quite limited.

There really isn't much to be done to get it to work, esp. if the 
abovementioned class is already removed:

- fix finding CheckAtomic.cmake (or just install it with LLVM)
- fix the install location as recorded in liblldb and make sure that location 
gets added to the rpath in lldb, lldb-mi and other dependents.

There's also an issue finding the proper Python library, at least when building 
MacPorts. It finds the correct framework binary when doing a complete build 
using the toplevel CMake file, but apparently goes for the latest version if 
you use the standalone build.

R.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev