Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (882bb47) 64.62% compared to head (9de179f) 65.29%.
Report is 1 commits behind head on master.

@@            Coverage Diff             @@
##           master    #1305      +/-   ##
==========================================
+ Coverage   64.62%   65.29%   +0.67%     
==========================================
  Files         225      225              
  Lines       23856    23968     +112     
==========================================
+ Hits        15418    15651     +233     
+ Misses       8438     8317     -121     

@yuleisui did you have another chance to take a look at these changes? I think it should all be properly functional now! :)

This looks to be a major change to the cmake. I would like to keep this posted for sometime so that anyone else could review before I merge it. @xudon9 could you also take a look?

I am not an expert in CMake. After your change, I am wondering about how an SVF subproject could utilize find_package(SVF). Could you help with the CMake configuration for this SVF example project?"

https://github.com/SVF-tools/SVF-example

Of course! I submitted the changes as a pull request, please let me know what you think!

Note that I also changed some of the symbols that were exported through the CMake package (e.g. now SVF's build type is accessible when importing the SVF package), as well as enabling LTO & compiling with Position Independent Code so that transitive references are properly locatable.

Thanks for the update. Once the main SVF repo is updated, a new SVF-npm is uploaded. In SVF-example and many other subprojects, SVF is installed via npm. I assume there is no need to change the folder layout of SVF-npm or any environment variables here: https://github.com/SVF-tools/SVF-npm?

No problem!

I assume there is no need to change the folder layout of SVF-npm or any environment variables here (...)

I don't think so, no. Nothing has been changed about the way the files are laid out during the build phase. The only difference is that, with these changes, people are able to use SVF as a regular CMake package (in the same way that you'd include something like LLVM in a project) if they want to. The old way of using SVF (i.e. explicitly using directories like Release-build for finding the library files, or the svf/include and svf-llvm/include directories for the headers) still works the exact same way!

No problem!

I assume there is no need to change the folder layout of SVF-npm or any environment variables here (...)

I don't think so, no. Nothing has been changed about the way the files are laid out during the build phase. The only difference is that, with these changes, people are able to use SVF as a regular CMake package (in the same way that you'd include something like LLVM in a project) if they want to. The old way of using SVF (i.e. explicitly using directories like Release-build for finding the library files, or the svf/include and svf-llvm/include directories for the headers) still works the exact same way!

Thanks and will merge towards end of this week or early next.

@Johanmyst I have just merged your cmake patch. It has a problem with this error https://github.com/SVF-tools/SVF/actions/runs/7537407715/job/20516284438#step:5:14006

It looks to me that the FILE_SET variable is not defined:

FILE_SET

FILE_SET is only supported after cmake 3.2.3 which most ubuntu and windows do not support. Could you remove FILE_SET and use something else?

FILE_SET

FILE_SET is only supported after cmake 3.2.3 which most ubuntu and windows do not support. Could you remove FILE_SET and use something else?

This patch looks to be a workaround solution: #1328

@yuleisui Can I assume this is resolved then?

Yes, that issue is resolved. However, assistance is still needed to modify CMake so that the folder layout generated in both Release-Build and Debug-Build is consistent with the layout in the installation directory. This would be good for any developer would like to debug locally compiled SVF without modifying the environmental variables. It is also good for us to copy the Release-Build folder directly to npm without installing...

Could you help ensure that the folder layout in Release-Build mirrors that of the installation directory? This includes placing 'svfllvm.a' and 'svfcore.a' under the 'lib' directory, as well as putting the *.cmake files under 'cmake/SVF'.

Layout under Release-Build:

Layout under the Install directory:

I've made some changes to the build system (see commit #47c14a0), but I don't really see how modifying the default build directory layout would be beneficial. Of course, some files could be relocated during the build phase (e.g. similar to how svf-llvm/tools/... are built to [Debug|Release]-build/bin), but that would still leave the header files separate (they are not copied during the build phase).

If anything, I'd argue no longer building the tools in svf-llvm/tools to <build_dir>/bin and just following the default build layout makes more sense, and to use the installation directory layout when desired by just using the installed version. For example, wouldn't it be easier to actually install the CMake package to a directory (e.g. with cmake --install <build_dir> --prefix <install_dir>) so that the "normal" layout with install/bin, install/lib, and install/include exist, and to copy that directory for creating the npm package rather than copying the build directory, some parts of the source directories, etc?

I've made some changes to the build system (see commit #47c14a0), but I don't really see how modifying the default build directory layout would be beneficial. Of course, some files could be relocated during the build phase (e.g. similar to how svf-llvm/tools/... are built to [Debug|Release]-build/bin), but that would still leave the header files separate (they are not copied during the build phase).

If anything, I'd argue no longer building the tools in svf-llvm/tools to <build_dir>/bin and just following the default build layout makes more sense, and to use the installation directory layout when desired by just using the installed version. For example, wouldn't it be easier to actually install the CMake package to a directory (e.g. with cmake --install <build_dir> --prefix <install_dir>) so that the "normal" layout with install/bin, install/lib, and install/include exist, and to copy that directory for creating the npm package rather than copying the build directory, some parts of the source directories, etc?

The reason for maintaining a consistent layout is that when the SVF repository and a sub-project coexist on someone's local machine, differing layouts can lead to confusion about which executable to debug. This is because you have to run 'make install' each time you want to debug your svfllvm library through a subproject, which significantly hampers local debugging efficiency. Personally, I prefer to have the same layout, where the binaries are already in place, requiring only minor adjustments for libraries. As for the headers, they should not pose an issue, as we can easily upload them to SVF's npm by copying the ones from the root of the source folder.