I have small project and after building it he layout looks like this.
|-- BUILD
|-- README.md
|-- VERSION
|-- WORKSPACE
|-- bazel-bin -> /home/bkch/.cache/bazel/_bazel_bkch/172376ca1288bc6e93208fc2d53c0b74/execroot/distroless/bazel-out/k8-fastbuild/bin
|-- bazel-distroless -> /home/bkch/.cache/bazel/_bazel_bkch/172376ca1288bc6e93208fc2d53c0b74/execroot/distroless
|-- bazel-out -> /home/bkch/.cache/bazel/_bazel_bkch/172376ca1288bc6e93208fc2d53c0b74/execroot/distroless/bazel-out
|-- bazel-testlogs -> /home/bkch/.cache/bazel/_bazel_bkch/172376ca1288bc6e93208fc2d53c0b74/execroot/distroless/bazel-out/k8-fastbuild/testlogs
|-- debian_archives.bzl
bazel-bin, bazel-out, bazel-distroless, bazel-testlogs are symbolic links to .cache in user root folder. Instead of the symbolic links I would like to build them in current workspace directory.
From the documentation I tried using --output_base=$PWD/output or --output_user_root=$PWD/output . The moment I use these options the bazel build is failing of various random reasons. But when I use bazel build //... with out these options the build succeeds.
I guess the answer might lie here... github.com/bazelbuild/bazel/issues/13601 we just need to have folder outside the project folder --output_base=$PWD/../output
Related
I'd like to use a few classes from the LLVM project in my own Objective-C app. Specifically, I want to use the classes declared in BitstreamReader.h and BitstreamWriter.h. Unfortunately, I don't have much experience linking C++ libraries, so I don't really know where to begin. I started by installing llvm through Homebrew with brew install llvm#14. Then, in my Xcode project, I tried linking the libraries in /opt/homebrew/opt/llvm#14/lib, and adding /opt/homebrew/opt/llvm#14/include/** to my HEADER_SEARCH_PATHS.
Now I'm completely stuck. I have a bunch of build errors in Xcode like:
"Reference to unresolved using declaration"
"No member named 'ldiv' in the global namespace"
"Use of undeclared identifier 'wcspbrk'"
...
Any help at all would be greatly appreciated. Thanks!
In C++ world there are quite a few ways to incorporate a dependency into your project, I'll outline some of them, but will try to describe in details one which I find the most suitable for your scenario:
1. Installing libraries system/user-wide
This is the most classic approach, when you have the libraries pre-compiler and pre-installed for your specific platform so they are available under default library search-path. It's similar to how system frameworks in iOS are used - you only add linker command to the project, while the frameworks (libraries) exist independently from it (or don't exist, which causes linker error). The problem with this approach, is that you cannot really use the libs for restricted systems, where "default" libraries are unchangeable (iOS, tvOS, iPadOS)
2. Embedding static libraries
Another approach is to precompile all libraries you need into archives for all platforms the libraries are supposed to be used and then just embed one of the library version which is required into your final app binary. This approach is somewhat cumbersome and unportable because it will require you to compile the lib and re-embed it manually each time you need some parts of library changed or new platform supported.
3. Embedding an xcframework
This approach is very similar to the previous one with a few benefits that you can wrap binaries for all platforms under one package and even release it in SPM.
4. Using CMake build system
Many projects (and LLVM is not an exception) in C++ are made with use of so-called CMake tool. It's widely adopted multi-platform build system and one of the benefits you can employ is that you can easily include any other project as part of your own. At the same time CMake is not widespread at all in the world of mobile development, so you may have hard time finding relevant information for these platforms.
5. Using Xcode workspaces
This is the solution I'd like to describe in more details. In a nutshell this approach consists of 6 steps:
Download LLVM project repo;
Generate Xcode project for required LLVM libraries with use of CMake;
Make an Xcode workspace and add the newly generated project to it;
Add your own project to the same workspace;
Add required dependencies from LLVM project to your own;
Adjust project settings to make it compatible with the dependencies.
The benefits of this approach is that it gives the most consistent experience (after generating project, all parts are configurable from Xcode), freedom of managing the source code (the LLVM project files can be altered however you want), and luxury of built-in dependency graph (all libraries required to build a target are given under Xcode settings).
Downloading LLVM project
You can clone the project from here. Be advised that this has to be in the same folder your future workspace will be in, so you better prepare it in advance:
% mkdir MyWorkspace && cd MyWorkspace
% git clone git#github.com:llvm/llvm-project.git
Generating LLVM Xcode Project
First, ensure you have CMake installed (it doesn't come out of the box with macOS). You can use brew or just download the app from the official site. After that create a new folder for the future Xcode project next to llvm-project repo folder and run cmake on the LLVM toolkit project:
% mkdir LLVM && cd LLVM
% cmake -GXCode ../llvm-project/llvm
Creating Xcode workspace
Nothing fancy here, just open Xcode and navigate to File/New/Workspace menu (Ctrl+Cmd+N shortcut). Ensure that your workspace is created in the MyWorkspace folder. You can just do it from Xcode:
Then, add the LLVM project created on the previous step. Open File/Add Files to "MyWorkspace"... menu (Option+Cmd+A) and select the Xcode project file:
If Xcode suggests to auto-create schemes I recommend accepting this suggestion so you don't have to deal with it yourself later on.
Adding your own project
This step mimics the previous one with exception that you add your own project to the workspace. I didn't have an existing project for that, so I just created a new one (in my case macOS command-line app) in the workspace directory. If you do the same, ensure that the project is added to "MyWorkspace" and the folder is correct:
Eventually your workspace "Project Navigator" should look something like this:
And here is how the directory tree looks like in a nutshell:
% tree -L 2
.
|-- LLVM
| |-- $(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)
| |-- CMakeCache.txt
| |-- CMakeFiles
| |-- CMakeScripts
| |-- CPackConfig.cmake
| |-- CPackSourceConfig.cmake
| |-- Debug
| |-- LLVM.xcodeproj
| |-- MinSizeRel
| |-- RelWithDebInfo
| |-- Release
| |-- benchmarks
| |-- build
| |-- cmake
| |-- cmake_install.cmake
| |-- docs
| |-- examples
| |-- include
| |-- lib
| |-- llvm.spec
| |-- projects
| |-- runtimes
| |-- test
| |-- third-party
| |-- tools
| |-- unittests
| `-- utils
|-- MyProject
| |-- MyProject
| `-- MyProject.xcodeproj
|-- MyWorkspace.xcworkspace
| |-- contents.xcworkspacedata
| |-- xcshareddata
| `-- xcuserdata
`-- llvm-project
|-- CONTRIBUTING.md
|-- LICENSE.TXT
|-- README.md
|-- SECURITY.md
|-- bolt
|-- clang
|-- clang-tools-extra
|-- cmake
|-- compiler-rt
|-- cross-project-tests
|-- flang
|-- libc
|-- libclc
|-- libcxx
|-- libcxxabi
|-- libunwind
|-- lld
|-- lldb
|-- llvm
|-- llvm-libgcc
|-- mlir
|-- openmp
|-- polly
|-- pstl
|-- runtimes
|-- third-party
`-- utils
Adding dependencies to your project
From this point forward you'll only need Xcode to finish the job. First, let's link the libraries you need to the project and start from the Bitstream archive. Open your project's target General tab settings and under Framework and Libraries click the + sign which should take you to the screen with all local dependencies currently available. It's quite a long list of tools from the LLVM project + native Apple libs, so you may want to filter it as needed to find the required position:
Now the tricky part. You might not actually be required to do that, but if the LLVMBitstreamReader target itself relies on symbols of other libraries (and exposes such a dependency with explicit use of the libraries symbols) the project linking will fail, so to be safe go to the LLVMBitstreamReader build settings and check what it depends on under Target Dependencies section:
Now add these dependencies to your project as well. Eventually your Frameworks and Libraries section should look like this:
Adjusting project settings
CMake generated Xcode projects come with peculiarities. In our case the build folders for the LLVM project targets are located under the project directory with the name matching selected configuration (Debug/Release/MinSizeRel/RelWithDebInfo). In order for your own project's targets to find the libraries built with the given configuration you either have to adjust the LLVM project/targets settings, which I don't recommend because it's a lot of manual work, or just add custom library search path to your project. For the latter go the Build Settings of the target where you added the dependencies at the previous step, find Library Search Path item and add $(SRCROOT)/../LLVM/$(CONFIGURATION)/lib as a new item:
Another tricky part is that dependent targets won't make dependencies to build if the dependencies' targets have incompatible build settings. Incompatible is a vague term here, but commonly it means matching the Architectures section. Luckily in our case it merely means making Release configuration to build active architecture only (the Debug shouldn't require any changes at all):
Last, but not least, the headers of the library. After generating the LLVM Xcode project, the headers it offers don't (completely) come with the project and are actually located in the repository folder. You may just copy the headers right into your own project, but I suggest adding the repo directory in the System Headers Search paths to stay consistent with the LLVM Xcode Project settings (you can yourself check where the headers search paths are under the the LLVMBitstreamReader Build Settings). Similarly to lib search path, I suggest use help of settings variables and add this path flexibly:
$(SRCROOT)/../llvm-project/llvm/include
$(SRCROOT)/../LLVM/include
Finale
At this point you should be good to use the LLVMBitstreamReader library and classes defined there. I renamed my main.m to main.mm so clang knows i'm going to use C++ in my code, and here is my sample code:
//
// main.mm
// MyProject
//
// Created by Aleksandr Medvedev on 14.12.2022.
//
#import <Foundation/Foundation.h>
#import <llvm/Bitstream/BitstreamReader.h>
#import <iostream>
int main(int argc, const char * argv[]) {
llvm::BitstreamBlockInfo::BlockInfo info;
info.Name = "Hello, LLVM!";
std::cout << info.Name << std::endl;
#autoreleasepool {
// insert code here...
NSLog(#"Hello, World!");
}
return 0;
}
If everything is done right, it should compile without any errors now.
P.S. I many times focused on specific directory hierarchy for a reason - when an XCode project is generated through CMake it often uses absolute paths, not relative and if you move your project to another directory, you will have to either adjust the paths in the build settings of required targets/projects or repeat the step with generating the LLVM Xcode project again.
I would like to configure correctly project's settings.json file to use CMakeLists.txt file of multiple sub-project.
My approach is given below
The structure of the project is as like as follows.
vscode_build_cmake/
`-- task
|-- add
| |-- CMakeLists.txt
| |-- include
| | `-- foo.h
| `-- src
| |-- foo.cpp
| `-- main.cpp
`-- print
|-- CMakeLists.txt
|-- include
| `-- foo.h
`-- src
|-- foo.cpp
`-- main.cpp
Here, add & print are completely isolated sub-project of the main project task. Each sub-project has their own build recipe which is written in their own CMakeLists.txt file. Usual steps to build sub-project is :
cd task/add
mkdir build
cd build
cmake .. && make
Same steps is for task/print.
Right now I would like to perform this build task using VSCode Cmake tool. What I have found that I only need to make a vscode_build_cmake/.vscode/settings.json file where I can point to the directory of CMakeLists.txt file. I am now working with
{
"cmake.configureOnOpen": false,
"cmake.sourceDirectory": "${workspaceFolder}/task/add"
}
I just press ctrl+shift+p and write in the command box run build task and press Enter. That one do the job for me and I can see build, bin, lib directories inside task/add directory.
But the problem, I am facing now is that if I need to build print sub-project I have to manually edit the settings.json file as like as follows
{
"cmake.configureOnOpen": false,
"cmake.sourceDirectory": "${workspaceFolder}/task/print"
}
After that, I have to delete cache and reconfigure and build task which perform now the build task only for print project. This one is very tedious to me.
My desire is to know
Is there any way to point out the both CMakeLists.txt file of add and print in cmake.sourceDirectory? Which can tell me which build task I would like to perform? Eg:
{
"cmake.configureOnOpen": false,
"cmake.sourceDirectory": ["${workspaceFolder}/task/add",
"${workspaceFolder}/task/print"]
}
Or ,
Is there any way to perform build task of both sub-project.(this one is optional. Previous one is important for my case).
I am using CMake Tools v1.13.4.
If you're intent on not having a tasks/CMakeLists.txt that add_subdirectorys add/ and print/, then you can consider using VS Code's multi-root workspace feature, which the vscode-cmake-tools extension supports.
If you have a reason not to use / that you don't like the multi-root workspace approach, you can show your support for vscode-cmake-tools issue #1374 ("Support Multiple CMakeLists.txt without Requiring a Multi-Root Workspace") and the proposed solutions. At the time of this writing, the proposal process is still in earlier stages.
I've started a new c++ project , and I am confused with all the CMake capabilities. I have tried to understand better by looking at examples and CMake tutorials
I should create a new project composed of:
Library: It contains some common classes that will be used by the following module(s) (e.g., vector, matrix, image, etc..)
Module (possibly more than 1 in the future): It contains some module-specific classes (e.g., classifier, estimator, etc.) and a main.
My proposed folder structure is as below:
|-- Root Project
|-- CMakeLists.txt
|
|-- Library
| |-- CMakeLists.txt
| |-- include
| | |-- CMakeLists.txt (?)
| | `-- Lib_Class.h
| `-- src
| |-- CMakeLists.txt (?)
| `-- Lib_Class.h
|
|-- Application 1
| |-- CMakeLists.txt
| |-- include
| | |-- CMakeLists.txt (?)
| | `-- Method.h
| `-- src
| |-- CMakeLists.txt (?)
| |-- Method.cpp
| `-- main.cpp
|
|-- Application 2
| |-- CMakeLists.txt
| |
`
The problem arises when I have to actually add the code to the different CMakeLists.txt files. According to my reasoning, I would have:
Root/CMakeLists.txt: For creating the project and adding the subdirectories of the Library and the Module(s).
Library/CMakeLists.txt: This creates the library with the header (from include folder) and source (from src folder) files.
Module/CMakeLists.txt: This creates an executable from the src/main.cpp file using the Library and the module-specific classes with header files in include folder and source files in src folder.
I have 2 questions:
First, I also found solutions in other replies with CMakeLists.txt files in the Library/src and Module/src folders. But I really don't understand how to use them and what to write inside them, because I would have used only the CMakeLists.txt file in the parent folder.
Second, in case I want to link an external library (e.g., OpenCV or dlib) should I link it in the modules and library, individually, or should I link it in the root CMakeLists.txt file (provided that the library is used everywhere)?
I really need some assistance to try to understand CMAKE. Can someone explain or please direct me to a suitable tutorial on this subject.
Matthieu, thank you very much for your help. According to the explanation you provided me, I came out with the following CMakeLists.txt files:
Root/CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(Project_Name)
add_subdirectory(Library)
add_subdirectory(Application)
Library/CMakeLists.txt
project(Library)
set(LIB_HEADERS
include/Lib_Class.h
)
set(LIB_SOURCES
src/Lib_Class.cpp
)
add_library(Library_Name SHARED ${LIB_SOURCES} ${LIB_HEADERS})
Application/CMakeLists.txt
project(Application)
set(APP_HEADERS
include/Method.h
)
set(APP_SOURCES
src/Method.cpp
src/main.cpp
)
add_executable(Application_Name ${APP_SOURCES} ${APP_HEADERS})
target_link_libraries(Application_Name Library_Name)
Now everything seems to work grat! Thank you again and sorry again for being confusing somethimes!
The root cmakelists should set up all the variables, checking compiler support and library presence.
Then you go to each subfolder and create the libraries and executables based on the source code and the detected libraries. You should also set up all the linked libraries there.
Then cmake will figure out what depends on what.
I have a C++ project that employs unit testing via CppUnit and has the following directory structure:
.
|-- bin
| `-- tests
|-- src
| `-- include
`-- test
`-- include
In the top-level directory resides my Makefile.am file. I would like to use a non-recursive Makefile. I have been able to build the executable of my project in the bin folder and the tests for make check in the bin/tests folder.
The problem is the following:
When make check runs the tests, the current working directory is still the top-level directory (i.e., the directory from which I ran make check). Is it possible to change the working directory specifically for the test suites?
The relevant piece in my Makefile.am file is the following:
$(TESTDIR)=./bin/tests
check_PROGRAMS = $(TESTS)
TESTS = $(TESTDIR)clocktest
__TESTDIR_clocktest_SOURCES = test/clocktest.cpp test/unittest.cpp src/clock.cpp
__TESTDIR_clocktest_CPPFLAGS = $(AM_CPPFLAGS) $(CPPUNIT_CFLAGS) $(TESTCPPFLAGS)
__TESTDIR_clocktest_LDADD = $(CPPUNIT_LIBS)
From make --help:
-C DIRECTORY, --directory=DIRECTORY
Change to DIRECTORY before doing anything.
I think that should do what you're looking for.
I am custom compiling libcurl , libssl and some other library. I don't want to replace system library, because if I am changing it system wise, it is going to create lib conflict and I need to compile all other component depending on these libs.
So I started using RPATH and started structuring like this:
|-- bin
| |-- app.out
|-- lib
| |-- libboost_program_options.so -> libboost_program_options.so.1.49.0
| |-- libboost_program_options.so.1.49.0
| |-- libboost_system.so -> libboost_system.so.1.49.0
| |-- libboost_system.so.1.49.0
| |-- libboost_thread.so -> libboost_thread.so.1.49.0
| |-- libboost_thread.so.1.49.0
| |-- libcares.so -> libcares.so.2.0.0
| |-- libcares.so.2 -> libcares.so.2.0.0
| `-- pkgconfig
`-- sbin
`-- nginx
This approach worked. Now problem is that , We started using PHP and node which require same application version.
|-- bin
| |-- a.out
|-- lib
| |-- libboost_program_options.so -> libboost_program_options.so.1.49.0
| |-- libboost_program_options.so.1.49.0
| |-- libboost_system.so -> libboost_system.so.1.49.0
| |-- libboost_system.so.1.49.0
| |-- libboost_thread.so -> libboost_thread.so.1.49.0
| |-- libboost_thread.so.1.49.0
| |-- libcares.so -> libcares.so.2.0.0
| |-- libcares.so.2 -> libcares.so.2.0.0
| `-- pkgconfig
|-- php_ext
| `-- sqlite3.so
|-- node
| `-- node_modules
| |-- bin
| | |-- node
`-- sbin
`-- nginx
Now , this svn repo is becoming bigger and bigger after every release. Is there a better way to structure this ? without duplicating lib folder in each app ?
As someone who has used both git and svn extensively for years, I'd seriously consider moving to git and using git submodules. Git is hugely more space-efficient (among many, many other benefits). There are also git-svn bridges that you can make if you're stuck using svn at your company.
Failing that, I'd make an svn externals for each group of shared libraries. If you have something that changes often or is logically grouped together, it can go in one svn repo while other libraries that may not change very often.
One of the advantages of git over svn is that git protects you from file corruption. I can painfully remember several occurrences of svn corrupting files (something that wasn't noticed until the client submitted a bug report).
Seriously, save yourself a world of headaches, ditch svn in favour of git.
I was taking a totally different approach when I was working with C++.
I don't treat libs as part of source code. I only want the "dependency" to exist with my source. (It is not appropriate to have "version control" for the lib binary anyway)
I have a separate directory to store all libs in a organized manner, something like libname/version/arch.
In the build script, I am referring to something like $LIB_DIR/libname/version/arch/lib-ver.so.
You can have different way to store/distribute the Lib directory, either put it in a network volume, put that in SVN etc.