I'm writing a recipe that copies some configuration files over to my image (like a cramfs.conf that goes into /etc/modprobe.d to disable cramfs). Here is the structure of my recipe directory:
.
├── compliance-config.bb
└── configs
└── fs
├── 1-1-1-1-cramfs.conf
├── 1-1-1-2-freevxfs.conf
...
In my recipe I do the following:
SRC_URI += "file://fs"
do_install() {
install -d ${D}${sysconfdir}/modprobe.d/
install -m 0644 ${WORKDIR}/fs/*.conf ${D}${sysconfdir}/modprobe.d/
}
This works, but when I change the folder name of fs to something more descriptive (and of course accordingly change the SRC_URI and path in do_install()), it doesn't find the files anymore and gives me (Edit: to clarify, this error happens when I change the directory name from fs to fsconfigs for example, tried different names to make sure I don't accidentally name it in a forbidden way, names like abctest also don't work).
ERROR: compliance-config-1.0-r0 do_fetch: Fetcher failure: Unable to find file file://fsconfigs anywhere. The paths that were searched were:
[...long list of paths...]
So I thought I needed to do a clean build, but running bitbake -c clean <image> or bitbake -fc cleanall <image> beforehand doesn't help.
Why does bitbake not find my files if I change the specified directory?
This is a better :
.
├── compliance-config.bb
└── files
├── 1-1-1-1-cramfs.conf
├── 1-1-1-2-freevxfs.conf
Then add SRC_URI += "file://fsconfigs" for instance.
You should know that the default FILESPATH variable is the default set of directories the OpenEmbedded build system uses when searching for patches and files.
The default value for the FILESPATH variable is defined in the base.bbclass as follow :
FILESPATH = "${#base_set_filespath(["${FILE_DIRNAME}/${BP}", \
"${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
Here ${BP} stand for the base recipe name and your Package Version: ${BPN}-${PV}
If you want the build system to look in directories other than the defaults, the best practiec is to extend the FILESPATH variable by using the FILESEXTRAPATHS variable.
Note that SRC_URI is used to specify files, not directories.
https://docs.yoctoproject.org/ref-manual/variables.html?highlight=filesextrapaths
Related
I am using swagger to develop a new api written in Go. This is my first swagger project. I installed and used this command to create my project from a swagger.yaml. I aim to make reconfigurations I put into the swagger.yaml file part of my pipeline tasks - putting a task in to execute something like swagger-codegen generate -i ./api/swagger.yaml -l go-server by strategically setting up ignores in my .swagger-codegen-ignore file. There is one thing I don't necessarily like but i can't figure out how to change. Any advice? Do i need to live with it?
the generated directory structure looks like this for go-server
.
├── api
│ └──swagger.yaml
├── go #everyting in this directory is part of the "swagger" package
│ ├── a_handler_function_file.go
│ ├── logger.go
│ ├── model_struct_file.go
│ ├── routers.go
│ └── ...
├── Dockerfile
└── main.go
I am not keen on the directory called go or the package it produces called swagger. I want something more meaningful to the project.
Does it go against conventions to rename the directory?
Is there a way to configure the swagger-codegen to rename these what I want? - I am doing research to see if there is a way but I can't find one.
It seems that SEO magic has not really crawled in a way to effectively land on this page in the swagger-codegen git repo https://github.com/swagger-api/swagger-codegen#customizing-the-generator . maybe this Q and A will help.
One can either use add a -D<configParameterName> to the generate command or one can create a config.json file and add it to the generate command using -c config.yaml.
for go-server there are only two parameters available, packageName and hideGenerationTimestamp.
So I tried swagger-codegen generate -i ./swagger.yaml -l go-server -DpackageName="myPackageName" and it worked!!!
I also tried creating a config.json file that looks like this
{
"packageName": "myPackageName"
}
and then generate command that looks like this swagger-codegen generate -i ./swagger.yaml -l go-server -c config.json
and that works too.
As far as changing the go directory - it looks like I will have to live with it
I'm currently developing my own Ansible collection and following the documentation. The directory structure looks like this:
~/.ansible/collections/gertvdijk/mycollection
├── galaxy.yml
├── plugins
│ └── lookup
│ └── mylookup.py
├── README.md
└── tests
└── unit
└── plugins
└── lookup
└── test_mylookup.py
The location ~/.ansible/collections/gertvdijk/mycollection is chosen for convenience so that it's found on the default search paths for collections (COLLECTIONS_PATHS).
The Ansible developer document section Testing collections mentions that I should use ansible-test command from the root of my collection with the given structure.
You must always execute ansible-test from the root directory of a collection.
However, that fails to me, with an error as if I should use this in a project already.
Even running --help fails with the current working directory error:
$ ansible-test --help
ERROR: The current working directory must be at or below:
- an Ansible collection: {...}/ansible_collections/{namespace}/{collection}/
Current working directory: /home/gert/.ansible/collections/gertvdijk/mycollection
Same thing happens by cloning an existing community collection (e.g. community.grafana). The GitHub CI steps include an installation in a ansible_collections/{namespace}/{collection} path (seen here).
Taking that as a work-around for now (I'd like to avoid that); move the repository of the collection to some path that includes /ansible_collections/gertvdijk/mycollection and then run it from there.
This can't be true, right, that the directory name two levels up make or break the ansible-test tool? What am I missing here?
TL;DR: The path for your home collection should be /home/gert/.ansible/collections/ansible_collections/gertvdijk/mycollection
The directories listed in COLLECTION_PATH are actually expected to contain a top level ansible_collections folder. This is linked to the ansible_collections convention used by e.g. module_utils as explained in the documentation
You can also observe how a blank folder gets structured by running e.g.
ansible-galaxy collection install -p /whatever community.grafana
In this case, you will end up with the folder /whatever/ansible_collections/community/grafana.
So your actual home folder collection path should be /home/gert/.ansible/collections/ansible_collections/gertvdijk/mycollection
Related to this question.
In order to customize the kernel configuration I created in my custom layer this structure:
$ tree recipes-kernel/
recipes-kernel/
└── linux
├── files
│ └── <image>-defconfig
└── linux-stm32mp_4.19.bbappend
Where the defconfig file is actually the .config used to manually compile the kernel (see the other question). The bbappend file contains the following code:
SRC_URI += "file://<full-path>/meta-custom-layer/recipes-kernel/linux/files/<image>-defconfig"
KERNEL_DEFCONFIG_stm32mp1_<variant> = "{WORKDIR}/<image>-defconfig"
I'm sure the file is processed because if I change the name of the defconfig bitbake raises a file not found error.
The problem is the compiled kernel does not have my customization.
But if I copy my defconfig to the build directory (i.e. tmp/work/stm32mp1_<variant>-openstlinux_eglfs-linux-gnueabi/linux-stm32mp/4.19-r0/linux-stm32mp1-<variant>-standard-build/.config) and manually bitbake virtual/kernel) it does.
So it seems it searches and finds my defconfig but then it ignores it.
Where is my mistake?
I don't know what is your mistake. But I know what I do.
Instead of trying to overload defconfig I let bitbake generate kernel fragments (diffs from the kernel supplied defconfig): https://edison-fw.github.io/meta-intel-edison/5.1-Bitbake-tricks#configuring-the-kernel-and-grab-the-kernel-fragment
Then I add the fragments to my recipe: https://github.com/edison-fw/meta-intel-edison/blob/warrior/meta-intel-edison-bsp/recipes-kernel/linux/linux-yocto_5.4.0.bb
Go program with the following structure:-
├── app.go
├── bin
│ └── run.go
├── config
│ └── Config.go
└── package1
├── package1_file.go
└── tmpl
└── template.tmpl
Now, in package1_file.go, I've accessed template.tmpl via relative path like:
t, err := template.ParseFiles("./tmpl/template.tmpl")
When I run tests, tests are able to run successfully because my guess is, Go changes the current working directory when running tests for packages. go tests -v ./...
However, when I run (go build -o app && ./app) the program from the root folder, I get error complaining that file doesn't exist.
Error compiling template: open ./tmpl/template.tmpl: no such file or directory
It starts working when I change the path to package2/tmpl/template.tmpl.
The code outside package2 has nothing to do with this template file so I don't want to expose it as a parameter to a function while exposing package2. What are my options?
What is the right way to target support files like these?
You're operating under some mistaken assumptions here - primarily that the project source code or directory structure are in any way relevant at runtime. They aren't.
A Go program compiles to a single binary file that can be executed anywhere, without the source, without Go installed - just the binary. You need to consider that any time you have any kind of files in your project that you will need at runtime:
You need to decide how these files will be located:
You can mandate a path, either relative to CWD at time of execution, or absolute (but you shouldn't)
You can accept the path as a runtime parameter, by CLI, environment variable, config file, etc.
You can embed them into the binary itself using one of the many packages available (seriously - so many that a Google search for go embed static files turns up not only several libraries, but several articles comparing various libraries)
You need to decide how the whole thing will be packaged:
You could zip/tar/whatever the resources alongside the binary
You could zip/tar/whatever the resources and binary all together
As above, you could embed them into the binary as a single file
There are some choices you'll have to make as to how you want to handle this but the key takeaway is don't assume the path in your source code will be at all relevant at runtime. Parameterize at least the root path to the resources so that your code will work wherever they may be, and then your tests can pass in an appropriate path to use for testing.
You can use os.Getwd() to get the path to the root working dir. Then, concat the rest of the path to your template dir. In your case:
wd, err := os.Getwd()
if err != nil {
log.Fatal(err)
}
t, err := template.ParseFiles(wd + "/package1/tmpl/template.tmpl")
Hi all I am fairly new to Golang, I am writing a toy client and server app just to learn the libraries.
But I have the project folder:
philipherron#Philips-iMac {~/workspace/gospace/src/github.com/redbrain/station} $ echo $GOPATH
/Users/philipherron/workspace/gospace
I wanted to have 2 binaries:
client.go
server.go
But when I build I get:
philipherron#Philips-iMac {~/workspace/gospace/src/github.com/redbrain/station} $ go build github.com/redbrain/station/
# github.com/redbrain/station
./server.go:5: main redeclared in this block
previous declaration at ./client.go:5
I guess this is because it looks like I am making to mains in the same package.
So I tried creating a client and a server subdir and have the binaries in each of those, but I get:
philipherron#Philips-iMac {~/workspace/gospace/src/github.com/redbrain/station} $ go build github.com/redbrain/station/client
go install github.com/redbrain/station/client: build output "client" already exists and is a directory
I guess this is because I have the layout of:
$ tree
.
├── client
│ └── client.go
└── server
└── server.go
2 directories, 4 files
Not sure how to get around this, it would just be nice to have the same client and server in the same directory but maybe this is against how I should be doing things in go?
just rename your .go files. The compiler is trying to write to 'client' but 'client' is already taken by the directory.
$ tree
.
├── client
│ └── main.go
└── server
└── main.go
2 directories, 4 files
And/Or create a script that outputs them with a different name go build -o client client/main.go
along with with separate packages as above, if you set the GOBIN=$GOPATH/bin then it will create client and server in the bin dir and it will not collide with dir names