I'm building a simple project in Meson Build.
While it is well documented how to create a dependency in Meson Build Documentation (With implicit assumption of UNIX / LINUX system) it is not clear how to link against arbitrary not on path library.
Let's I have the following project on Windows:
- ProjectFolder
- SrcFiles
- SrcFile1.c
- SrcFile2.c
- Lib
- MyLib1.lib
- MyLib2.lib
I want to create an executable based on SrcFile1.c and SrcFile2.c which is linked against pre built MyLib1.lib and MyLib2.lib.
What is the correct way to do so?
OK, I found solution on MesonBuild: How to define dependency to a library that cannot be found by pkg-config? on Yasushi Shoji's answer.
The only issue the dirs property requires Absolute Path.
Hence this is a sketch of what can be done:
# Constants
projectDir = meson.current_source_dir() # MESON_SOURCE_ROOT
buildDir = meson.current_build_dir() # MESON_BUILD_ROOT
lib1Path = join_paths(projectDir, 'Lib')
lib2Path = join_paths(projectDir, 'Lib')
objCCompiler = meson.get_compiler('c')
MyLib1 = objCCompiler.find_library('MyLib1', dirs : lib1Path)
MyLib2 = objCCompiler.find_library('MyLib1', dirs : lib1Pat2)
Now just to define the target build with the proper dependencies.
Related
I'm trying to run some grpc tests with bazel.
I'm using "google.golang.org/grpc/credentials/insecure" to dial insecurely.
When running bazel test ..., I get the following error:
no such package '#org_golang_google_grpc//credentials/insecure': BUILD file not found in directory 'credentials/insecure' of external repository #org_golang_google_grpc. Add a BUILD file to a directory to mark it as a package. and referenced by '//go/internal/handlers/helloworld:helloworld_test'
I am generating my BUILD files with gazelle which outputs this for the go_test
go_test(
name = "helloworld_test",
srcs = ["helloworld_test.go"],
deps = [
":helloworld",
"//protos/helloworld",
"#com_github_stretchr_testify//assert",
"#org_golang_google_grpc//:go_default_library",
"#org_golang_google_grpc//credentials/insecure",
"#org_golang_google_grpc//test/bufconn",
"#org_uber_go_zap//:zap",
"#org_uber_go_zap//zaptest",
],
)
My go.mod file contains the dep:
google.golang.org/grpc v1.47.0
My deps.bzl is auto generated by gazelle:
go_repository(
name = "org_golang_google_grpc",
importpath = "google.golang.org/grpc",
sum = "h1:9n77onPX5F3qfFCqjy9dhn8PbNQsIKeVU04J9G7umt8=",
version = "v1.47.0",
)
What am I missing?
In the WORKSPACE, the local go_repositories() generated by gazelle must be called before gazelle_dependencies(), which will
define an ancient version of org_golang_google_grpc if it doesn't
exist yet and the local go_repository for the newer version will be
silently ignored. Reference
I'm following the ROS-tutorial and I am facing the following behavior after creating my own package:
If try to execute any installed package (e.g. any_package), I get the following error:
[rosrun] Couldn't find executable named <any_package> below /opt/ros/kinetic/share/<any_package>
[rosrun] Found the following, but they're either not files
[rosrun] or not executable:
[rosrun] /opt/ros/kinetic/share/<any_package>
Any help?
EDIT:
If I execute catkin_find --without-underlays --libexec --share <any_package>, it gives me the following output:
Multiple packages found with the same name "my_package":
- my_new_package/my_package
- my_new_package/my_package_2
I assume that you have a tainted workspace.
I assume that you've just copied the my_package to my_package_2 without editing the package.xml file in my_package_2.
It is not really mentioned in the tutorial, since it assumes that you use the proper commands which creates a manifest file with a unique package name.
Just edit the name-tag as follows:
<name>my_package</name>
to
<name>my_package_2</name>
in the corresponding folder.
You have to make sure you edit CmakeLists.txt according to your compile version, c++ executable declaration & Specify libraries to link a library
Below are step step modification and then run catkin_make before running your project:
step 1
add_compile_options(-std=c++11)
step 2
## Declare a C++ executable
## With catkin_make all packages are built within a single CMake context
## The recommended prefix ensures that target names across packages don't collide
add_executable(${PROJECT_NAME}_node src/myproject_node.cpp)
step 3
## Specify libraries to link a library or executable target against
target_link_libraries(${PROJECT_NAME}_node
${catkin_LIBRARIES}
)
I'm currently working with a third party library, which has headers declared using angular brackets, like a standard library :
#include <header.h>
However, these headers are installed in a non standard place, something like /opt/company/software/version/part_software/include
With a more traditional builder like MAKE, I can just use CXXFLAGS to indicate to g++ to look in this folder too for libraries, which finally comes down to pass a -I/opt/company/software/version/part_software/include option to g++.
When trying to do the same thing in bazel, using copts = [ "-I/opt/company/software/version/part_software/include" ], I get a "path outside of the execution root" error.
It's my understanding that bazel don't like the place where the lib is installed because the build needs to be reproducible, and including a library located outside the execution root violate this constraint.
A ugly hack I've come with is to create symbolic link of the headers in /usr/local/include, and use copts = [ "-I/usr/local/include" ] in the bazel build. However, I find this approach very hacky, and I'd like to find a more bazely approach to the problem.
Note : I can't install the program during the bazel build, as it uses a closed installer on which I have no control over. This installer can't be run in the bazel's sandboxed environment, as it needs to write on certain paths not accessible within the environment.
So, it turns out that the bazelesque way of including a third part library is simply to create package encapsulating the library.
Thanks to this useful discussion, I've managed to create a package with my third party library.
First we need a BUILD file, here named package_name.BUILD
package(
default_visibility = ["//visibility:public"]
)
cc_library(
name = "third_party_lib_name", #name to reference the third party library in other BUILD files
srcs = [
"external/soft/lib/some_lib.so", #.so files to include in the lib
"software/lib/os/arch/lib_some_plugin.so",
],
hdrs = glob([ # the glob takes all the headers needed
"software/include/**/*.h",
"software/include/**/*.hpp",
]),
includes = ["software/include/"], # Specify which files are included when we use the library
)
Now we need to reference the lib a a submodule in the WORKSPACE file :
new_local_repository(
name = "package_name",
path = "opt/company/software/version",
# build_file: path to the BUILD file, here in the same directory that the main WORKSPACE one
build_file = __workspace_dir__ + "/package_name.BUILD",
)
Now, instead of using copt to references the needed headers, I'm just adding a line to the deps of the cc_rule when needed, e.g :
cc_library(
name="some_internal_lib",
srcs = ["some_internal_lib.cc"],
deps = [
"#package_name//:third_party_lib_name", #referencing the third party lib
],
)
Whenever I set my build options in Qt for a specific folder and I compile using MVSC it creates a release and debug folder and puts the output exe file inside that folder. If I compile in linux it usually just puts the final executable file in the folder that I specify. Is there a way to get this last behaviour (that is to stop the creation release and debug folder)?
You can set CONFIG -= debug_and_release in your .pro file and it will stop doing so.
With qmake you can actually specify a destination directory for your binary(ies), and other generated output as well. For example:
DESTDIR = $${OUT_PWD}/bin # this is where the binaries ('target' files) go
OBJECTS_DIR = $${OUT_PWD}/obj # compiled objects
MOC_DIR = $${OUT_PWD}/moc # generated MOC files
UI_DIR = $${OUT_PWD}/ui # generated C++ code from .ui files
RCC_DIR = $${OUT_PWD}/rcc # generated C++ code from .qrc files
OUT_PWD is a built-in variable specifying the current build directory. You could actually use any valid path here.
Reference: http://doc.qt.io/qt-5/qmake-variable-reference.html
Is there a way to link with a library that's not in the current package path.
This link suggests placing everything under the local directory. Our packages are installed in some repository elsewhere. I just want to specify the libpath to it on windows.
authors = ["Me"]
links = "CDbax"
[target.x86_64-pc-windows-gnu.CDbax]
rustc-link-lib = ["CDbax"]
rustc-link-search = ["Z:/Somepath//CPP/CDbax/x64/Debug/"]
root = "Z:/Somepath//CPP/CDbax/x64/Debug/"
But trying cargo build -v gives me
package `hello v0.1.0 (file:///H:/Users/Mushfaque.Cradle/Documents/Rustc/hello)` specifies that it links to `CDbax` but does not have a custom build script
From the cargo build script support guide, it seems to suggest that this should work. But I can see that it hasn't added the path. Moving the lib into the local bin\x68_64-pc-windows-gnu\ path works however.
Update
Thanks to the answer below, I thought I'd update this to give the final results of what worked on my machine so others find it useful.
In the Cargo.toml add
links = "CDbax"
build = "build.rs"
Even though there is no build.rs file, it seems to require it (?) otherwise complains with
package `xxx v0.1.0` specifies that it links to `CDbax` but does not have a custom build script
Followed by Vaelden answer's create a 'config' file in .cargo
If this is a sub crate, you don't need to put the links= tag in the parent crate, even though it's a dll; even with a 'cargo run'. I assume it adds the dll path to the execution environment
I think the issue is that you are mistaking the manifest of your project with the cargo
configuration.
The manifest is the Cargo.toml file at the root of your project. It describes your project itself.
The cargo configuration describes particular settings for cargo, and allow for example to override dependencies, or in your case override build scripts. The cargo configuration files have a hierarchical structure:
Cargo allows to have local configuration for a particular project or
global configuration (like git). Cargo also extends this ability to a
hierarchical strategy. If, for example, cargo were invoked in
/home/foo/bar/baz, then the following configuration files would be
probed for:
/home/foo/bar/baz/.cargo/config
/home/foo/bar/.cargo/config
/home/foo/.cargo/config
/home/.cargo/config
/.cargo/config
With this structure you can specify local configuration per-project,
and even possibly check it into version control. You can also specify
personal default with a configuration file in your home directory.
So if you move the relevant part:
[target.x86_64-pc-windows-gnu.CDbax]
rustc-link-lib = ["CDbax"]
rustc-link-search = ["Z:/Somepath//CPP/CDbax/x64/Debug/"]
root = "Z:/Somepath//CPP/CDbax/x64/Debug/"
to any correct location for a cargo configuration file, it should work.