Use proper cmake techniques to detect where the libedit package resides.
This allows for the use of libedit from an alternative location which is
needed for supporting cross-compilation.
The patch looks quite nice, though I can't say I know much about how find_package modules are supposed to be written. I won't click accept yet to see if anyone with more cmake knowledge steps in to review. In the mean time, I have two nitty comments.
Should we make the capitalization of these match the file name (LibEdit_FOUND) ?
Do you really need to unset these? I would hope that this file is evaluated in a fresh context, and it won't pollute the callers namespace or anything..
Ok, whatever you prefer.
I just tried removing these and putting a message command after the find_package call. The variables did not get exported.
However, I think we have a bigger issue here. If I apply your patch without any modifications, I get an error first time I run it because of unrecognised sequences in the regular expressions (\s, \d). I guess that's why you've changed these to [ \t] and [0-9] in the first regex.
What particularly worries me is that the second time I ran cmake, without any modifications, it succeeded, presumably because we took the true branch in the if statement at the top. This looks wrong.
I think we should just remove the if check -- find_path and find_library should already have caching internally, and if you want to cache the version computation, then that should be guarded by a separate variable.
Sure, fixed the regex. I think that we need to actually handle this this way unfortunately as otherwise we would not be able to specify the values at the command line to avoid the pkg-config search.
Should this be under if (NOT LLDB_DISABLE_LIBEDIT) ?
used as include directory in directory /x/eng/rtpbld01/scratch/laurentn/llvm-wss/sources/llvm_import_from_git_rtp3/llvm/tools/lldb/scripts/Python/modules/readline