Also: note that the coverage checks fail for this pull request because a necessary fix (in this pull request (#1702)) to the coverage test flags is not included in this pull request. That pull request fixes the flags to ensure trying to delete coverage information when it doesn't exist doesn't throw a fatal error (as it does here).

Will your new build system impact other projects using SVF as a library, such as

https://github.com/SVF-tools/SVF-example
https://github.com/SVF-tools/Software-Security-Analysis/tree/main

If so, please submit a pull request to fix their cmake on these projects.

Also: note that the coverage checks fail for this pull request because a necessary fix (in this pull request (#1702)) to the coverage test flags is not included in this pull request. That pull request fixes the flags to ensure trying to delete coverage information when it doesn't exist doesn't throw a fatal error (as it does here).

Thanks for this note. It looks good now

Also: note that the coverage checks fail for this pull request because a necessary fix (in this pull request (#1702)) to the coverage test flags is not included in this pull request. That pull request fixes the flags to ensure trying to delete coverage information when it doesn't exist doesn't throw a fatal error (as it does here).

Thanks for this note. It looks good no

Also: note that the coverage checks fail for this pull request because a necessary fix (in this pull request (#1702)) to the coverage test flags is not included in this pull request. That pull request fixes the flags to ensure trying to delete coverage information when it doesn't exist doesn't throw a fatal error (as it does here).

Thanks for this note. It looks good now

Oops, it still has this error after merging your first PR.

I rebased from upstream now; should pass now I think

I rebased from upstream now; should pass now I think

Thanks. Could you take a look at SVF-example and SVF courses? We may need to change their make too.

Codecov Report

Attention: Patch coverage is 50.00000% with 1 line in your changes missing coverage. Please review.

Project coverage is 63.67%. Comparing base (0f8a828) to head (812a9ca).
Report is 6 commits behind head on master.

@@            Coverage Diff             @@
##           master    #1703      +/-   ##
==========================================
- Coverage   63.68%   63.67%   -0.01%     
==========================================
  Files         244      244              
  Lines       25975    25980       +5     
  Branches     4574     4575       +1     
==========================================
+ Hits        16541    16543       +2     
- Misses       9434     9437       +3     

Thanks for your pull request. Now I have some issue when I use the output of SVF as dependency to build other code. You could see compared to baseline, the new version misses some key environment variables.

Thanks for your pull request. Now I have some issue when I use the output of SVF as dependency to build other code. You could see compared to baseline, the new version misses some key environment variables.

@Johanmyst, we would like to merge your build system if you could take a look and fix the above issue. Looks to me that the current build system has to work together with the projects using SVF as a lib.

Thanks for your pull request. Now I have some issue when I use the output of SVF as dependency to build other code. You could see compared to baseline, the new version misses some key environment variables.

Thanks for testing & giving feedback! While some of these variables would be trivial to add back, I removed some others on purpose as they don't work well with how (modern) CMake is structured, specifically w.r.t. relocation.

More specifically, CMake is typically used by (1) configuring (cmake -G "Ninja" -B build ...), (2) building (cmake --build build), and (3) installing a package (cmake --install build). By default, the installation prefix used by CMake is /usr/local. When running cmake --install <build_dir>, executables will be installed to <prefix>/bin/..., libraries to <prefix>/lib/..., etc. CMake currently provides 3 ways to set the installation prefix:

1. Passing --install-prefix <prefix> during configuration
2. Passing -DCMAKE_INSTALL_PREFIX=<prefix> during configuration
3. Passing --prefix <prefix> during installation

While prefixes set by (1) and (2) are visible during configuration, overriding the prefix at installation (3) is not. Consequently, any paths derived from the installation prefix during configuration (i.e., when the variables you highlighted are set) could be incorrect, possibly causing issues for end-users. This is why I removed the "hardcoded" (i.e., explicitly relying on ${CMAKE_INSTALL_PREFIX}) installation paths from the exported CMake package and instead relied on CMake's package configuration helpers.

In the changes I proposed, these paths are not necessary when using the SVF CMake package. Instead, SVF's CMake package can simply be found with find_package(SVF), after which it can be linked to any target with target_link_libraries(Foo SVF::Core SVF::LLVM). CMake will then internally resolve all compiler definitions, ABI flags, include paths, dependencies, library paths, and whatever else. Manually adding target_include_directories(Foo ${SVF_INSTALL_INCLUDE_DIR}) should thus never be necessary. Hence why I omitted this from my original pull request.

However, I suppose they also can't do any harm to include. I'll create a fairly simple modification to re-add those paths explicitly, including some other optimisations. I'll test it and add it to this pull request when I'm done!

I've integrated your requested changes and made sure all existing use cases are fully supported, please see [640b3c9] for details. The main changes are:

• Defined explicit FindZ3.cmake module to reliably find system or local Z3 instance transparently
• Fixed minor inconsistency in generated pkgconfig definition
• Integrated requested changes and ensured all existing variables are supported as expected (but relocatable)
• Updated CMake logging (existing still referenced some non-existent variables/missed new options)
• Updated generated config.h with latest options & variables
• Simplified LLVM linking to modern LLVM recommended way of linking
• Minor formatting fixes

Please let me know if there are any other parts you'd prefer changed or would like further clarification on!

NB: Should I update the "Setup guide" wiki page to reflect this installation method & usage?

• Defined explicit FindZ3.cmake module to reliably find system or local Z3 instance transparently

Thanks. When locating z3, can you make sure we need to first search for the executable from Z3HOME, and then the system-installed one, to avoid version issues.

Sorry. Still some environment variable error.

SVF_DIR= <Your SVF Root Folder>
LLVM_DIR= <Should be SVF_DIR/llvm-16.0.0.obj>
Z3_DIR= <Should be SVF_DIR/z3.obj>

git clone https://github.com/SVF-tools/SVF-example
cd SVF-example
mkdir Release-build
cd Release-build
cmake .. -DSVF_DIR=$SVF_DIR -DLLVM_DIR=$LLVM_DIR -DZ3_DIR=$Z3_DIR

You could see this. Thank you so much.

• Defined explicit FindZ3.cmake module to reliably find system or local Z3 instance transparently

Thanks. When locating z3, can you make sure we need to first search for the executable from Z3HOME, and then the system-installed one, to avoid version issues.

Sure, no problem

Sorry. Still some environment variable error.

SVF_DIR= <Your SVF Root Folder>
LLVM_DIR= <Should be SVF_DIR/llvm-16.0.0.obj>
Z3_DIR= <Should be SVF_DIR/z3.obj>

git clone https://github.com/SVF-tools/SVF-example
cd SVF-example
mkdir Release-build
cd Release-build
cmake .. -DSVF_DIR=$SVF_DIR -DLLVM_DIR=$LLVM_DIR -DZ3_DIR=$Z3_DIR

You could see this. Thank you so much.

This error actually looks to be the result of using the SVF CMake package in the build tree instead of the installation tree. The find_package() macro in CMake first searches paths passed in HINTS, so this snippet will cause CMake to search for SVFConfig.cmake in $SVF_DIR/[Release|Debug]-build before any installation directories (e.g., the standard installation prefix /usr/local and thus finding /usr/local/lib/cmake/SVFConfig.cmake).

However, the CMake macros to create (relocatable) packages only run during installation, so the paths set here are not valid. Because set_and_check is used, an error is thrown. Previously, these paths were not relocatable and simply used the CMAKE_INSTALL_PREFIX available during configuration of the SVF build. While this meant they were set — and the manual linking by adding linker flags -lSvfLLVM and -lSvfCore — they would be incorrect and fail if a user were to change the installation prefix after configuration (e.g., with the standard command-line flags: cmake --install Release-build --prefix <new_prefix>). To ensure the CMake package behaves as expected, set_and_check verifies that the paths exist and are valid, so that any linking/searching done by CMake will happen as expected.

I've modified the using-SVF-as-a-library-example locally, and this minimal CMakeLists.txt works perfectly fine:

cmake_minimum_required(VERSION 3.23)

set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

project(
  SVF-example
  VERSION 1.0
  DESCRIPTION "An external project example using SVF as a library"
  HOMEPAGE_URL "https://github.com/SVF-tools/SVF-example"
  LANGUAGES C CXX)

# Find the SVF CMake package (pass $SVF_DIR as a (prioritised) hint) Set
# $SVF_DIR to the installation prefix used to install SVF
find_package(
  SVF
  3.0
  REQUIRED
  CONFIG
  HINTS
  ${SVF_DIR}
  $ENV{SVF_DIR})

# Define the primary (minimal) example using SVF as library in an executable
add_executable(svf-example src/bin-example.cpp)

# Only link against SVF; LLVM & Z3 dependencies are resolved internally
target_link_libraries(svf-example PRIVATE SVF::SvfCore SVF::SvfLLVM)

# Set the executable example to install to the local directory (as prefix)
install(TARGETS svf-example RUNTIME DESTINATION bin)

# Generate <prefix>/data/input.ll from src/input.c whenever BinExample is built
add_custom_command(
  TARGET svf-example
  POST_BUILD
  COMMAND ${CMAKE_COMMAND} -E make_directory ${CMAKE_INSTALL_PREFIX}/data
  COMMAND
    clang -S -c -Xclang -disable-O0-optnone -fno-discard-value-names -emit-llvm
    ${CMAKE_CURRENT_SOURCE_DIR}/src/input.c -o
    ${CMAKE_INSTALL_PREFIX}/data/input.ll
  COMMAND opt -S -p=mem2reg ${CMAKE_INSTALL_PREFIX}/data/input.ll -o
          ${CMAKE_INSTALL_PREFIX}/data/input.ll
  COMMENT "→ generating LLVM IR for src/input.c → data/input.ll")

This script can simply be used like this:

# Configure, build, and install the example (also generated input.ll)
cmake -S ./ --install-prefix=$(pwd) -B build
cmake --build build
cmake --install build

# Run the example
./bin/svf-example ./data/input.ll

This assumes SVF was built and installed in the standard CMake way (which will install SVF to ~/SVF/install):

https://github.com/SVF-tools/SVF.git ~/SVF
cd ~/SVF
cmake -G "Ninja" -S ./ -B Release-build -DCMAKE_BUILD_TYPE=Release <other_options> --install-prefix=$(realpath ./install)
cmake --build Release-build
cmake --install Release-build

If the installation prefix was kept as the default (i.e., /usr/local), CMake would already find the SVF package. However, in this example I installed SVF to ~/SVF/install, so I'd need to make sure CMake can find the non-standard installation location, for example by adding ~/SVF/install to $CMAKE_PREFIX_PATH, passing ~/SVF/install to the find_package(SVF ...) invocation, or by setting $SVF_DIR to ~/SVF/install.

Of course, using SVF in its build tree is still possible by manually including & linking the build tree (e.g., when using SVF from a non-CMake build system) with environment variables like $PATH and $LD_LIBRARY_PATH, or by passing flags like -L<path/to/SVF/build>/lib or -I<path/to/SVF/build>/include. However, using the CMake package within the build tree is not how CMake is meant to be used and can lead to unexpected behaviours and errors, so I'm not sure supporting these cases silently is the best approach, especially since it requires breaking relocatability and default CMake flags for setting the installation prefix like --prefix. What do you think?

• Defined explicit FindZ3.cmake module to reliably find system or local Z3 instance transparently

Thanks. When locating z3, can you make sure we need to first search for the executable from Z3HOME, and then the system-installed one, to avoid version issues.

Sure, no problem

Sorry. Still some environment variable error.

SVF_DIR= <Your SVF Root Folder>
LLVM_DIR= <Should be SVF_DIR/llvm-16.0.0.obj>
Z3_DIR= <Should be SVF_DIR/z3.obj>

git clone https://github.com/SVF-tools/SVF-example
cd SVF-example
mkdir Release-build
cd Release-build
cmake .. -DSVF_DIR=$SVF_DIR -DLLVM_DIR=$LLVM_DIR -DZ3_DIR=$Z3_DIR

You could see this. Thank you so much.

This error actually looks to be the result of using the SVF CMake package in the build tree instead of the installation tree. The find_package() macro in CMake first searches paths passed in HINTS, so this snippet will cause CMake to search for SVFConfig.cmake in $SVF_DIR/[Release|Debug]-build before any installation directories (e.g., the standard installation prefix /usr/local and thus finding /usr/local/lib/cmake/SVFConfig.cmake).

However, the CMake macros to create (relocatable) packages only run during installation, so the paths set here are not valid. Because set_and_check is used, an error is thrown. Previously, these paths were not relocatable and simply used the CMAKE_INSTALL_PREFIX available during configuration of the SVF build. While this meant they were set — and the manual linking by adding linker flags -lSvfLLVM and -lSvfCore — they would be incorrect and fail if a user were to change the installation prefix after configuration (e.g., with the standard command-line flags: cmake --install Release-build --prefix <new_prefix>). To ensure the CMake package behaves as expected, set_and_check verifies that the paths exist and are valid, so that any linking/searching done by CMake will happen as expected.

I've modified the using-SVF-as-a-library-example locally, and this minimal CMakeLists.txt works perfectly fine:

cmake_minimum_required(VERSION 3.23)

set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

project(
  SVF-example
  VERSION 1.0
  DESCRIPTION "An external project example using SVF as a library"
  HOMEPAGE_URL "https://github.com/SVF-tools/SVF-example"
  LANGUAGES C CXX)

# Find the SVF CMake package (pass $SVF_DIR as a (prioritised) hint) Set
# $SVF_DIR to the installation prefix used to install SVF
find_package(
  SVF
  3.0
  REQUIRED
  CONFIG
  HINTS
  ${SVF_DIR}
  $ENV{SVF_DIR})

# Define the primary (minimal) example using SVF as library in an executable
add_executable(svf-example src/bin-example.cpp)

# Only link against SVF; LLVM & Z3 dependencies are resolved internally
target_link_libraries(svf-example PRIVATE SVF::SvfCore SVF::SvfLLVM)

# Set the executable example to install to the local directory (as prefix)
install(TARGETS svf-example RUNTIME DESTINATION bin)

# Generate <prefix>/data/input.ll from src/input.c whenever BinExample is built
add_custom_command(
  TARGET svf-example
  POST_BUILD
  COMMAND ${CMAKE_COMMAND} -E make_directory ${CMAKE_INSTALL_PREFIX}/data
  COMMAND
    clang -S -c -Xclang -disable-O0-optnone -fno-discard-value-names -emit-llvm
    ${CMAKE_CURRENT_SOURCE_DIR}/src/input.c -o
    ${CMAKE_INSTALL_PREFIX}/data/input.ll
  COMMAND opt -S -p=mem2reg ${CMAKE_INSTALL_PREFIX}/data/input.ll -o
          ${CMAKE_INSTALL_PREFIX}/data/input.ll
  COMMENT "→ generating LLVM IR for src/input.c → data/input.ll")

This script can simply be used like this:

# Configure, build, and install the example (also generated input.ll)
cmake -S ./ --install-prefix=$(pwd) -B build
cmake --build build
cmake --install build

# Run the example
./bin/svf-example ./data/input.ll

This assumes SVF was built and installed in the standard CMake way (which will install SVF to ~/SVF/install):

https://github.com/SVF-tools/SVF.git ~/SVF
cd ~/SVF
cmake -G "Ninja" -S ./ -B Release-build -DCMAKE_BUILD_TYPE=Release <other_options> --install-prefix=$(realpath ./install)
cmake --build Release-build
cmake --install Release-build

If the installation prefix was kept as the default (i.e., /usr/local), CMake would already find the SVF package. However, in this example I installed SVF to ~/SVF/install, so I'd need to make sure CMake can find the non-standard installation location, for example by adding ~/SVF/install to $CMAKE_PREFIX_PATH, passing ~/SVF/install to the find_package(SVF ...) invocation, or by setting $SVF_DIR to ~/SVF/install.

Of course, using SVF in its build tree is still possible by manually including & linking the build tree (e.g., when using SVF from a non-CMake build system) with environment variables like $PATH and $LD_LIBRARY_PATH, or by passing flags like -L<path/to/SVF/build>/lib or -I<path/to/SVF/build>/include. However, using the CMake package within the build tree is not how CMake is meant to be used and can lead to unexpected behaviours and errors, so I'm not sure supporting these cases silently is the best approach, especially since it requires breaking relocatability and default CMake flags for setting the installation prefix like --prefix. What do you think?

@Johanmyst thanks, would you like to make a pull request to fix the current cmake on SVF-example

No problem, please see pull request #72 for the updates! Also, please note the comment I included there about SVF's NPM package.

0001-fix-for-external-dependency.patch
Could you apply this patch? some changes.

1. refactor the cmake install folder.

|-- bin
|   |-- ae
|   |-- cfl
|   |-- dvf
|   |-- llvm2svf
|   |-- mta
|   |-- saber
|   |-- svf-ex
|   `-- wpa
|-- include
|   |-- AE
|   |   |-- Core
|   |   |   |-- AbstractState.h
|   |   |   |-- AbstractValue.h
|   |   |   |-- AddressValue.h
|   |   |   |-- ICFGWTO.h
|   |   |   |-- IntervalValue.h
|   |   |   |-- NumericValue.h
|   |   |   |-- RelExeState.h
|   |   |   `-- RelationSolver.h
|   |   `-- Svfexe
|   |       |-- AEDetector.h
|   |       |-- AbsExtAPI.h
|   |       `-- AbstractInterpretation.h
|   |-- CFL
|   |   |-- CFGNormalizer.h
|   |   |-- CFGrammar.h
|   |   |-- CFLAlias.h
|   |   |-- CFLBase.h
|   |   |-- CFLGramGraphChecker.h
|   |   |-- CFLGraphBuilder.h
|   |   |-- CFLSVFGBuilder.h
|   |   |-- CFLSolver.h
|   |   |-- CFLStat.h
|   |   |-- CFLVF.h
|   |   `-- GrammarBuilder.h
|   |-- DDA
|   |   |-- ContextDDA.h
|   |   |-- DDAClient.h
|   |   |-- DDAPass.h
|   |   |-- DDAStat.h
|   |   |-- DDAVFSolver.h
|   |   `-- FlowDDA.h
|   |-- FastCluster
|   |   `-- fastcluster.h
|   |-- Graphs
|   |   |-- BasicBlockG.h
|   |   |-- CDG.h
|   |   |-- CFLGraph.h
|   |   |-- CHG.h
|   |   |-- CallGraph.h
|   |   |-- ConsG.h
|   |   |-- ConsGEdge.h
|   |   |-- ConsGNode.h
|   |   |-- DOTGraphTraits.h
|   |   |-- GenericGraph.h
|   |   |-- GraphPrinter.h
|   |   |-- GraphTraits.h
|   |   |-- GraphWriter.h
|   |   |-- ICFG.h
|   |   |-- ICFGEdge.h
|   |   |-- ICFGNode.h
|   |   |-- ICFGStat.h
|   |   |-- IRGraph.h
|   |   |-- SCC.h
|   |   |-- SVFG.h
|   |   |-- SVFGEdge.h
|   |   |-- SVFGNode.h
|   |   |-- SVFGOPT.h
|   |   |-- SVFGStat.h
|   |   |-- ThreadCallGraph.h
|   |   |-- VFG.h
|   |   |-- VFGEdge.h
|   |   |-- VFGNode.h
|   |   `-- WTO.h
|   |-- MSSA
|   |   |-- MSSAMuChi.h
|   |   |-- MemPartition.h
|   |   |-- MemRegion.h
|   |   |-- MemSSA.h
|   |   `-- SVFGBuilder.h
|   |-- MTA
|   |   |-- LockAnalysis.h
|   |   |-- MHP.h
|   |   |-- MTA.h
|   |   |-- MTAStat.h
|   |   `-- TCT.h
|   |-- MemoryModel
|   |   |-- AbstractPointsToDS.h
|   |   |-- AccessPath.h
|   |   |-- ConditionalPT.h
|   |   |-- MutablePointsToDS.h
|   |   |-- PersistentPointsToCache.h
|   |   |-- PersistentPointsToDS.h
|   |   |-- PointerAnalysis.h
|   |   |-- PointerAnalysisImpl.h
|   |   |-- PointsTo.h
|   |   `-- SVFLoop.h
|   |-- SABER
|   |   |-- DoubleFreeChecker.h
|   |   |-- FileChecker.h
|   |   |-- LeakChecker.h
|   |   |-- ProgSlice.h
|   |   |-- SaberCheckerAPI.h
|   |   |-- SaberCondAllocator.h
|   |   |-- SaberSVFGBuilder.h
|   |   |-- SrcSnkDDA.h
|   |   `-- SrcSnkSolver.h
|   |-- SVF-LLVM
|   |   |-- BasicTypes.h
|   |   |-- BreakConstantExpr.h
|   |   |-- CHGBuilder.h
|   |   |-- CppUtil.h
|   |   |-- DCHG.h
|   |   |-- GEPTypeBridgeIterator.h
|   |   |-- ICFGBuilder.h
|   |   |-- LLVMLoopAnalysis.h
|   |   |-- LLVMModule.h
|   |   |-- LLVMUtil.h
|   |   |-- ObjTypeInference.h
|   |   |-- SVFIRBuilder.h
|   |   `-- SymbolTableBuilder.h
|   |-- SVFIR
|   |   |-- ObjTypeInfo.h
|   |   |-- PAGBuilderFromFile.h
|   |   |-- SVFIR.h
|   |   |-- SVFStatements.h
|   |   |-- SVFType.h
|   |   |-- SVFValue.h
|   |   `-- SVFVariables.h
|   |-- Util
|   |   |-- Annotator.h
|   |   |-- BitVector.h
|   |   |-- CDGBuilder.h
|   |   |-- CallGraphBuilder.h
|   |   |-- Casting.h
|   |   |-- CommandLine.h
|   |   |-- CoreBitVector.h
|   |   |-- CxtStmt.h
|   |   |-- DPItem.h
|   |   |-- ExtAPI.h
|   |   |-- GeneralType.h
|   |   |-- GraphReachSolver.h
|   |   |-- NodeIDAllocator.h
|   |   |-- Options.h
|   |   |-- PTAStat.h
|   |   |-- SVFBugReport.h
|   |   |-- SVFLoopAndDomInfo.h
|   |   |-- SVFStat.h
|   |   |-- SVFUtil.h
|   |   |-- SparseBitVector.h
|   |   |-- ThreadAPI.h
|   |   |-- WorkList.h
|   |   |-- Z3Expr.h
|   |   |-- cJSON.h
|   |   |-- config.h
|   |   |-- iterator.h
|   |   `-- iterator_range.h
|   `-- WPA
|       |-- Andersen.h
|       |-- AndersenPWC.h
|       |-- CSC.h
|       |-- FlowSensitive.h
|       |-- Steensgaard.h
|       |-- TypeAnalysis.h
|       |-- VersionedFlowSensitive.h
|       |-- WPAFSSolver.h
|       |-- WPAPass.h
|       |-- WPASolver.h
|       `-- WPAStat.h
`-- lib
    |-- cmake
    |   `-- SVF
    |       |-- Modules
    |       |   `-- FindZ3.cmake
    |       |-- SVFConfig.cmake
    |       |-- SVFConfigVersion.cmake
    |       |-- SVFTargets-debug.cmake
    |       `-- SVFTargets.cmake
    |-- extapi.bc
    |-- libSvfCore.a
    |-- libSvfLLVM.a
    `-- pkgconfig
        `-- SVF.pc

2. Add some extra env variables like SVF_ENBALE_RTTI and SVF_ENABLE_EXCEPTIONS.
3. Sometimes Z3 libz3.so would be in bin folder instead of lib, so we'd better support both.

Thank you

1. refactor the cmake install folder.

<...>

I think installing public header files into a dedicated project subdirectory is actually considered better & cleaner (e.g., see #268), and fairly standard (e.g., LLVM installs its headers into <prefix>/include/llvm/...). This ensures a users install tree remains clean & tidy, and uninstalling SVF when the install_manifest.txt file is lost can be done by simply removing the entire <prefix>/include/SVF directory (as well as the binaries & library files but there are considerably fewer of those). As SVF has a fairly large number of public header files, I think it would be much cleaner to continue to use the SVF prefix during installation.

Note that this only concerns the install tree. Internally, SVF still includes its own files without the SVF prefix. Users that build SVF as part of their build tree (i.e., use SVF by cloning it into their own project and adding add_subdirectory(SVF) to their own project's CMakeLists.txt file), or embed themselves into SVF, would also be able to include SVF this way. As with LLVM, users that want to use SVF as a library, however, would include SVF headers like, for example, this: #include <SVF/WPA/Andersen.h>.

Instead, I propose (and included in the commit) allowing users to override this behaviour with the SVF_INSTALL_INCLUDEDIR build configuration parameter. This parameter defaults to include/SVF, but can be overridden if desired. Setting this variable to a bare include (e.g., cmake -B Release-build <...other flags...> -DSVF_INSTALL_INCLUDEDIR=include) would ensure SVF's headers are instead installed in the structure you described. Would that be a good approach?

2. Add some extra env variables like `SVF_ENBALE_RTTI` and `SVF_ENABLE_EXCEPTIONS`.

Their inverses were already being exposed, but I changed it the variables you requested. Also added some warning messages in case the configured mode of the LLVM instance used doesn't match SVF's build configuration (e.g., the LLVM instance used could throw an exception but the SVF build is set to explicitly not support handling exceptions).

Note, by the way, that these are — when necessary — publicly exposed. As in: when a user links against SVF with target_link_libraries(Foo SVF::SvfCore) and SVF was compiled without RTTI support, the user (i.e., Foo) would automatically inherit the -fno-rtti flag as well. These are exposed through the interface library SvfFlags. While the installation tree only exposes "necessary" flags, in-tree users of SVF also inherit SVF's build flags (e.g., -Wall).

3. Sometimes Z3 libz3.so would be in `bin` folder instead of `lib`, so we'd better support both.

Sure, I've added explicitly searching both the bin, lib, ${CMAKE_INSTALL_BINDIR}, and ${CMAKE_INSTALL_LIBDIR} suffixes to the library search.

@Johanmyst Thanks and merged it.