Developed on NetBSD with pkgsrc.
@labath feel free to disagree with the regex files. It was copied from LLVM. If you disagree, help me please to export it in LLVM build for everybody or find a better solution.
pkgsrc-wip commit affirming that it works:
Without this patch I'm falling asleep in front of the computer waiting for build to be finished.
It seems to follow what clang does here, so I think it should be ok.
However, I'm not actually using the standalone build... I've added some people who I think might be using it. Let's give them a bit of time to respond. If there are no objections, then I'll commit this..
@labath, can you point out where clang is doing the same thing? I searched for files named regcomp.c for example, and only found the one copy in llvm. Duplicating code seems like a blocking issue to me, this will make the THIRD regex implementation in LLDB if we do this.
Standalone build does not mean you don't need to link against LLVM libraries.
Hmm.. you are right, of course.. I was only looking at the second version of the patch, which seems to omit the regex files. However that seems to by accidental, as they are still references in the CMake files.
I agree that we should not copy the files over.
@krytarowski, I assume that the problem is that the regex headers are in llvm/lib (instead of include/llvm), which means they are not installed, and you cannot include them later. Is that correct?
It seems that is being done on purpose, so I guess it's a question whether lldb-mi should have been using them in the first place. We'll need to think about this more.
lldb-mi is including from the source tree, it should be including from the incldue tree.
In other words, the incldue should be changed to:
and the code should be updated to use llvm::Regex instead of the raw c functions.
OK, llvm seems to export the regex interface via include/llvm/Support/Regex.h. I think we should fix lldb-mi to use this interface instead, and then our problem will go away. The MI wrapper seems to be very simple, so it should not be a big problem to port it over.
I build LLVM/Clang with LLVM_ENABLE_WARNINGS=ON, so I'll need to use llvm-config from build directory. I'm not sure how well find_program will work if path to <build directory>/bin will be not added to PATH, so probably will be good idea to allow LLVM_CONFIG to be set in Cmake command line and use find_program only if LLVM_CONFIG is not set.
But it's necessary to pass path from CMake command line argument to find_program after PATHS. Another problem if default OS location (if Clang installed and of old version) will be returned instead of build one.
I don't know what would be the idiomatic cmake-fu to achieve that, but I'd just pass the the full path to the llvm-config binary, including the name. This way, we could also handle cases when the binary has a version suffix (e.g., debian likes to ship the binary as llvm-config-3.x).
|85 ↗||(On Diff #55742)|
When I am including conditionally include(FindPythonInterp) with this PYTHON_EXECUTABLE STREQUAL "" conditional I'm facing the said issue with:
CMake Error at scripts/cmake_install.cmake:31 (file): file INSTALL cannot find "/tmp/pkgsrc-tmp/wip/lldb-git/work/build/lib/python.". Call Stack (most recent call first): cmake_install.cmake:37 (include) *** Error code 1
If I put here include(FindPythonInterp) unconditionally, there is no error in cmake_install.cmake:37.
Good question. I don't really have an opinion on that... Is it just that single line? (this would be simpler if you uploaded the final version :) ). If it just that single line, then I think it's fine. If you also need to play with the ADDITIONAL_VERSIONS and such, then we should think about making a macro or doing something else to avoid code duplication (there is already a FIXME in scripts/Python/modules/readline mentioning the additional versions).
I'm not sure about Clang make files, but I built Clang with LLVM. LLDB is more problematic, so I build it standalone with previously build Clang. This why I'd like to specify path in CMake parameters, not relying in find_program().
From cmake documentation on find program:
This command is used to find a program. A cache entry named by <VAR> is created to store the result of this command. If the program is found the result is stored in the variable and the search will not be repeated unless the variable is cleared.
So, I think the functionality you request is already baked into find_program and we should not duplicate it. I made a quick test and setting the variable via -DLLVM_CONFIG on the cmake command line does indeed prevent find-program from doing anything. (which is not surprising, as it is a fairly common use case for people to want to specify their own paths to things...)
I think this is good to go know. I don't think we need to wait for @zturner, as his objections were about the regular expression thing, which has been removed now.