Our current project structure is as follows:
thirdparty(ws_root)
|_WORKSPACE
|_comp1
| |_BUILD
| |_src
| |_ a.c
| |_include
| |_ a.h
|_comp2
| |_BUILD
| |_src
| |_ b.c
| |_include
| |_ b.h
|_inc
| |_comp1
| |_a.h
| |_comp2
| |_b.h
Contents of a.c :
#include <comp1/a.h>
With our current build system the header file under thirdparty/comp1/include/a.h is staged with the following path:
thirdparty/inc/comp1/a.h
Here the thirdparty/inc folder is a global location where all header files in the workspace are staged under the respective components.
I would like to know if Bazel provides a mechanism by which we can stage the header files in a similar manner.
I'm not sure I understand, by "global location" you mean a folder in each library (library in the Bazel sense, you might call it component or package)? That's what I understood from the example. If that is the case, and each library just provides a -isystem include to all its dependents, that is possible in bazel, look for includes attribute.
Related
I have projects with a directory structure like that
---root
| |--src
| |--project1
| |--model
| | |--incude
| | | |--model
| | | |--modelA.hpp
| | | |--modelB.hpp
| | |--modelA.cpp
| | |--modelB.cpp
| | |--BUILD #1
| |...
| |--view
| |...
| |--common
| | |--include
| | |--common
| | |--data_type.hpp
| |--BUILD #2
|--WORKSPACE
As I have other package in this project and some of them use the same self-defined data type, I defined them in a package named common.
Now I include the data_type.hpp in file modelA.hpp
...
#include "common/data_type.hpp
...
Refering to the stage3 example in the tutorial, the BUID(#1) is like that
cc_library(
name = "modelA",
hdrs = "include/model/modelA.hpp",
deps = ["//src/project/common:data_type"],
copts = ["-Isrc/project/common/include"],
)
and the BUILD(#2) which defines the depedency module data_typeis like that
cc_library(
name = "data_type",
hdrs = ["include/common/data_type.hpp"],
visibility = ["//visibility:public"],
)
However, when I built the code, I got
src/project/model/include/model/modelA.hpp: fatal error: common/data_type.hpp: No such file or directory
Why I have defined copts = ["-Isrc/heimdallr/common/include"] but still got this error?
Please check the Header inclusion checking section of C/C++ Rules from the Bazel document. Relative to the workspace directory, all include paths should be created. Kindly refer to this issue for more information. Thank you!
I am trying to build my custom ROS services. They are inside a another parent package
the structure is as follows:
|--catkine_ws
| |--src
| | |--Parent
| | | |--CMakeLists.txt
| | | |--package.xml
| | | |--ChildA
| | | | |--CMakeLists.txt
| | | | |--package.xml
| | | | |--srv
| | | | | |--SomeService.srv
| | | |--ChildB
The packages are building correctly and I am able to use them in other nodes and packags.
however when I try to use rossrv list the custom services do not appear. I think that this is causing some issues when I try to build my Simulink controller and it cannot find the service message definition.
Does any one have any idea what is going on?
I was able to fix the problem, while not obvious, the solution was rather simple. I had to change the slightly change the structure of the package by making the parent package a meta package then do some handling to make sure that the sub packages still had access to the cmakes to locate my external packages.
I have several modules's directories. For each module, I have include (containing *.hrl files) and src (containing *.erl files) folder separeated. How can I share *.hrl file from a module to another without duplicating them?
With rebar, I added {erl_opts, [{i, "folderContainsIncludeFile"}]} and it worked.
But with rebar3, the compilation is failed by saying can't find include file "include/xx.hrl"
I take it then you don't have an umbrella project, you just have multiple directories at the same level, each one with its own project managed with rebar3.
Something like:
root_folder
|- project1
| |- src
| |- include
| | `- one.hrl
| `- rebar.config
|- project2
| |- src
| | `- two.erl
| |- include
| `- rebar.config
…
And you want to include one.hrl into two.erl.
If that's the case, you should consider one of these alternatives:
A. Moving to an umbrella project structure, like…
root_folder
|- rebar.config <<<<<<<< notice this file is here now
`- apps
|- project1
| |- src
| `- include
| `- one.hrl
|- project2
| |- src
| | `- two.erl
| `- include
…
B. Using individual repos for each project and configuring them as dependencies from each other. The structure is like the one you currently have, but now you have to add deps to rebar.config's. For instance, in our example, you should add the following line to project2's rebar.config:
{deps, [project1]}.
(if you manage to publish project1 in hex.pm)
C. Properly setting $ERL_LIBS so that it includes the paths where your apps are built with rebar3. Something like…
ERL_LIBS=$ERL_LIBS:/path/to/root_folder/project1/_build/lib:/path/to/root_folder/project2/_build/lib:…
Hope this helps :)
We are working on grails and also have microservices. There is a logging service in grails folder and log4j2.xml in grails-app/conf. Now we want to migrate logging service to jar(means outside of grails to one of microservices). So added log4j.xml in our resources folder of maven project. But it is not detecting the configuration file, so logging only to consoles.
Tried several things like
1. Setting system property in code
2. renaming log4j.xml file as log4j2.xml (but it gives error in grails startup)
Edit: Project Structure
Project
|
+-- grails-app
| |
| +-- conf
| |
| +--log4j2.xml
| +-- services/OldLoggingService.groovy
|
+--logevent(mavenproject)
| |
| +-- src/main/groovy/com/log/LogEventProducer.groovy
| +-- src/main/resources/log4j.xml
xml configuration file link
it is not showing any error (just writing logs to console only)
According to documentation, it should be possible to include *.txt file with help/documentation:
(root)
+- src # Groovy source files
| +- org
| +- foo
| +- Bar.groovy # for org.foo.Bar class
+- vars
| +- foo.groovy # for global 'foo' variable/function
| +- foo.txt # help for 'foo' variable/function
+- resources # resource files (external libraries only)
| +- org
| +- foo
| +- bar.json # static helper data for org.foo.Bar
...
The vars directory hosts scripts that define global variables
accessible from Pipeline scripts. The basename of each *.groovy file
should be a Groovy (~ Java) identifier, conventionally camelCased. The
matching *.txt, if present, can contain documentation, processed
through the system’s configured markup formatter (so may really be
HTML, Markdown, etc., though the txt extension is required).
Unfortunately it hasn't worked for me by simply creating *.txt with some arbitrary content.
Am I missing something? Or does Global Shared Library doesn't shown documentation in usual Jenkins places:
Please note that the PipelineSyntax/Global Variables Reference page is ONLY updated when the pipeline's run is successful. And therefore ONLY for this pipeline (and not any others).
Here's a link!