I recently discovered Yocto. I'm able to successfully build an image using the command bitbake fsl-image-gui. But now, I would like to browse the code, the project specific code and the Kernel code for the fsl-image-gui but I cannot figure how ?
Where is the source code when I build my Yocto project and how could I browse it ?
There are two halves of the Yocto setup:
The sources/ directory, containing the bitbake recipes and supporting configuration, and
The build/ directory, where the actual builds take place.
Each of the bitbake recipes (i.e. *.bb files found in a structure under the sources/ directory) that you run should be constrained to a directory structure like:
build/
tmp/
work/
< platform name >/
< recipe name >/
< version >/
...juicy stuff here...
Underneath the < version >/ directory, you should find a structure like:
build/
image/
package/
packages-split/
temp/
your_unpacked_source_directory/
...and others
...where your_unpacked_source_directory is determined by the directory structure contained in the downloaded and unpacked source. (e.g. as contained in the .tgz file)
All of the build logs and scripts generated during the build are contained in the temp/ directory.
The package/ directory contains all of the files that are to be packaged as a result of this recipe. The packages-split/ divides the files into their separate packages, e.g. base package, -dev package, -dbg package, -staticdev package.
Well, have you looked around in the build tree?
You'll have a downloads directory, in which all downloaded tarballs are stored, as well as all cloned repositories.
The actual unpacking and building takes place in subdirectories under build/tmp/work/<arch>/.
Related
I have a local Go project which requires another data file to live with it, as in
my_project/
go.mod
my_tool.go
data.txt
go.mod:
module my_project/my_tool
go 1.19
Until today, I had the path to my_project directory inserted in the $PATH environment variable so I could build the executable file with go build and run it from anywhere.
Then I wanted to try and run go install (with no arguments, as shown in this tutorial) from my_project directory. So I did and noticed that the command does two things:
go install builds the executable file just like go build does;
go install moves the executable file —the file itself, not its symlink— to the $GOPATH/bin directory.
But the go install command does not put any other project file to $GOPATH/pkg/mod — which is a no-go for my tool which requires its buddy data.txt file to be located in the same filepath.Dir(os.Executable()) directory as the executable file.
Neither does the go install my_project/my_tool command. Hence the question:
Is it possible to install a local Go package in the $GOPATH directory in such a way that it can find the location of the other files belonging to the project without me having to add the project directory to $PATH?
Having the following Go project layout with shared library functions in lib and several binaries in cmd using these library functions and having external dependencies:
root
|
lib
cmd
|
binary1
|
main.go
binary2
|
main.go
...
Searching for a simple way to handle project dependencies with dep tool. What is the expected usage pattern: having multiple Gopkg.* files in each binaryX directory or using a pair of Gopkg.toml and Gopkg.lock files for all these binaries? In the second case how would we compile these binaries knowing that vendor directory will be in project root instead of binaryX directories?
Normally, you'd just have a single root/vendor directory that all your various deps that are referenced by the lib and cmd code
When compiling, just do it like normal.
go install ./cmd/...
(or however you want to build)
I have a project structure that looks like so:
I was planning on just using a shell script (build.sh) to set GOPATH and build the project.
I am not sure how to build a Golang project properly, my short term goal is to just to build the packages in the src directory and put the binaries into the bin directory.
I am not sure what go build command can do that, I have tried a few things.
So first my question is - is this a reasonable project structure and second, how can I compile my src directory to bin?
What I have gives me the following error:
can't load package: package .: no buildable Go source files in /home/oleg/WebstormProjects/oresoftware/stack-server
So I believe I need to tell Go to look in the src directory, because Go is only looking for .go files in the project root, but I am not sure how to do that.
If it matters, the main.go file has a package name of "main".
GOPATH=$PROJECT_DIR && cd $PROJECT_DIR && go install main
Also move your main.go file into src/main/main.go.
This will produce a bin/main executable.
If you have multiple executables you wanna build, you have to put each main.go file into a separate folder/package. The name of the generated executable is taken from the directory name the file is inside. The package name of the main.go files must always be main if it should create a binary.
To compile multiple executables you have to use:
GOPATH=$PROJECT_DIR && cd $PROJECT_DIR && go install ...
The ... matches all folders/packages.
Right now I'll just run go build __.go, but I'm wondering if it's possible to have that file built in a subdirectory (e.g. a /bin folder). It would just make gitignoring the binary files a lot cleaner, and right now I'm not really sure what else is a good approach as I'm also struggling to create a working gitignore exception rule that isn't just "Ignore all files, except .go files".
My current solution is naming the binary files every time I build them (e.g. go build -o hello.bin hello.go), but this seems laborious.
you can use the -o flag.
cd to the directory where you have the main.go file.
use this command - go build -o DirectoryPath
Where DirectoryPath is the location where you want to create the binary file to.
Instead of using go build *.go, you can do following:
Setup Go workspace, using this official go resource: How to write go code
Define GOBIN and GOPATH environment variable.GOBIN environment variable will point to the directory where you want to store your executables.GOPATH environment variable will point to the directory, where you've setup go workspace.
Now, instead of doing go build *.go, you can use go install {YourCodePath}, where {YourCodePath}, is relative path of your code in go workspace. And if the build is successful, you can find your executable in directory, pointed by GOBIN.
I'm relatively new to Go and I've recently created a project that's going up on GitHub. I've tried to follow guides but there's a pressing question of why my binaries end up in src/?
My layout is like this:
ssm/ - Name of project
LICENSE
README.md
src/ - Source Code
files.go - All my source code is here.
src - The compiled binary ends up here
bin/ - Binaries
I set my $GOPATH to ~/Documents/Programming/Go/. From my gopath, I can't type go build ssm because it cannot find package. If I cd into the directory, it complains it can't load package: package .: no Go source files.
I have to actually go into src and compile there, which means the binary isn't in bin/.
What am I doing wrong?
See https://code.google.com/p/go-wiki/wiki/GithubCodeLayout
To be compatible with go get, your project's package name needs to be fully-qualified under the github.com domain:
$GOPATH/
src/github.com/<user>/ssm/
.git
LICENSE
README.md
files.go
bin/
Note that the base of the git repository (.git) is not the same as the $GOPATH.
Also, go build <package> will output a compiled executable to the current directory. If you want the exe to go to bin/, use go install <package> instead.
Your go code you can kept in a workspace. A workspace contains many source files (git, hg, svm, etc.). The Go tool understand the layout. We don't require Makefile or build.xml here. The basic directory layout is everything. If in any case if you are going to change the file layout, accordingly you need to change the build.
This is the general structure you can follow,
$GOPATH/
src/
github.com/username/repo/
mypkg/
mysrc1.go
mysrc2.go
cmd/mycmd/
main.go
bin/
mycmd
And, this is the standard workspace
$GOPATH/
bin/fixhub # installed binary
pkg/darwin_amd64/ # compiled archives
code.google.com/p/goauth2/oauth.a
github.com/...
src/ # source repositories
code.google.com/p/goauth2/
.hg
oauth # used by package go-github
...
github.com/
golang/lint/... # used by package fixhub
.git
google/go-github/... # used by package fixhub
.git
dsymonds/fixhub/
.git
client.go
cmd/fixhub/fixhub.go # package main
go get fetch many repositories whereas go install builds a binary out of them. It's convenient and easy to go for go development quickly. And, everyone in the go community follows the same. This puts src, bin and pkg into the home directory. And, $HOME/bin is already in our path before creating our workspace.