How can I build a Go project from source, instead of using go get domain.com/dir/project? For example, instead of
go get github.com/kr/godep
I want to build from the source:
git clone https://github.com/kr/godep.git
cd godep
GOPATH=/tmp/godep go build
The commands above will result in
dep.go:4:2: cannot find package "code.google.com/p/go.tools/go/vcs" in any of:
/usr/local/Cellar/go/1.2/libexec/src/pkg/code.google.com/p/go.tools/go/vcs (from $GOROOT)
/Users/hanxue/Source/godep/godep/src/code.google.com/p/go.tools/go/vcs (from $GOPATH)
save.go:5:2: cannot find package "github.com/kr/fs" in any of:
/usr/local/Cellar/go/1.2/libexec/src/pkg/github.com/kr/fs (from $GOROOT)
/Users/hanxue/Source/godep/godep/src/github.com/kr/fs (from $GOPATH)
Note: go 1.2 is installed in /usr/local/Cellar/go/1.2 with a link from /usr/local/Cellar/go/1.2/bin/go to /usr/local/bin/go
You need the GOPATH configured correctly. Sometimes a project doesn't have to be checked out in the "sub path" it expects, but often it does and certainly things that depend on it will expect to find it there. So instead of "go get" you can
mkdir -p /tmp/go/src
export GOPATH=/tmp/go
cd $GOPATH/src
mkdir -p github.com/kr/godep
cd github.com/kr/godep/..
git clone http://github.com/kr/godep.git
cd godep
go build
... now rinse and repeat for each dependency!
cd $GOPATH/src
mkdir -p code.google.com/p/
cd code.google.com/p
hg clone https://code.google.com/p/go.tools/
Yes, the vcs dependency was in "go.tools" and needed to be cloned with hg instead. It took a bit of web browsing to figure out. Okay, I think you can see why that's annoying to do by hand.
I'll leave the rest of the dependencies as an exercise for the reader, or you can just use "go get". :-)
A bonus tip that might be what you are really looking for: After checking out the first project, you can use "go get" in that directory to download the dependencies of the project. Sometimes if you have something that's not "go get'able" that's useful if the dependencies are.
Related
Right now, I'm trying to build a tool from source and use it to build a C++ project. I'm able to extract the tar file (gcc-arm-none-eabi). But, when I try to add it to path (using $GITHUB_PATH, not add-path), the path doesn't apply on my next action and I can't build the file. The error states that it can't find the gcc-arm-none-eabi toolset, which means that it didn't go to path.
Here's the script for the entrypoint of the first function (make is ran in the next action to allow for path to apply)
echo "Downloading ARM Toolchain"
# The one from apt isn't updated so I have to build from source
curl -L https://developer.arm.com/-/media/Files/downloads/gnu-rm/10-2020q4/gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux.tar.bz2 -o gcc-arm-none-eabi.tar.bz2
tar -xjf gcc-arm-none-eabi.tar.bz2
echo "/github/workspace/gcc-arm-none-eabi-10-2020-q4-major/bin" >> $GITHUB_PATH
I can't even debug by seeing what's in the path because running echo $(PATH) just says that PATH cannot be found. What should I do?
I can't even debug by seeing what's in the path because running echo $(PATH) just says that PATH cannot be found. What should I do?
First, PATH is not a command so if you want to print its value, it would be something like echo "${PATH}" or echo "$PATH"
Then, if you want to add a value to an existing environment variable, it would be something like
export PATH="${PATH}:/github/workspace/gcc-arm-none-eabi-10-2020-q4-major/bin"
EDIT: seems not a valid way to add something to the path using Github Actions, meanwhile it seems correct in the question. To get more details: https://docs.github.com/en/free-pro-team#latest/actions/reference/workflow-commands-for-github-actions#adding-a-system-path . Thanks to Benjamin W. for pointing this out in the comments.
Finally I think it would be a better fit if you use a docker image that already contains that kind of dependancies (you could easily write your own Dockerfile if this image doesn't already exists). Github action is designed to use docker (or OCI containers) image that contains the dependancies you need to perform your build actions. You should take a look here: https://docs.github.com/en/free-pro-team#latest/actions/creating-actions/dockerfile-support-for-github-actions
I am starting out with F# and trying to get it to work with Sublime Text 3 with a package, https://github.com/fsharp/sublime-fsharp-package. After installing the package using Package Control, I see F# appear as an available language to use in Sublime Text's bottom bar, and syntax highlighting appears to work more or less, from what I can tell, but the build system for F# fails to appear as it should.
So, trying to fix things, I run "build.sh install" and get an error, "Cannot open assembly '.paket/paket.bootstrapper.exe': No such file or directory." I am sort of stuck. Many thanks for any help.
From the comments you've made, you appear to be a little unfamiliar with the Unix underpinnings of OS X. I'll explain those first, then I'll suggest something for you to try that may fix your problem.
Technically, files or directories whose name starts with . are not "reserved for the system" as you put it; they're hidden. Now, it's true that Finder won't allow you to create files or directories whose name starts with ., because Apple didn't want to have to field all the tech-support calls from people who didn't know about the hidden-files feature: "I named my file ... more important stuff for work and now it's gone! Help!!!" But if you're in the Terminal app, then you can easily create files or directories with . as their first letter: mkdir .foo should work. You won't see it when you do ls, but ls -a (a for "all") will show you all files, including hidden files. And you can also do cd .foo and create files inside the hidden .foo directory -- and while the .foo folder won't show up in Finder, it will be perfectly accessible in the Terminal, and to any F# programs you might write.
So when you say that you cloned https://github.com/fsprojects/Paket but it failed to include the .github and .paket directories, I think you just don't know how to see them. You can't see them in the Finder (well, you can if you jump through a couple of hoops but I don't think it's worth the effort), but you can see them with ls -a. Just open your terminal, run cd /Users/Username/Paket, and then run ls -a and I think you'll see that the .paket and .github directories were indeed created by your git clone command.
So what you should probably try is this:
Go to https://github.com/fsprojects/Paket/releases/latest
Download the paket.bootstrapper.exe and paket.exe files. Put them in /Users/Username/Downloads (or wherever the default OS X Downloads directory is if it's different -- just as long as it's somewhere where you can find them easily).
Open the Terminal app.
Go to the directory where you've unpacked the Sublime Text 3 package. I.e., in the Terminal app, run cd /Users/Username/Library/Application\ Support/Sublime\ Text\ 3/Packages/sublime-fsharp-package-master.
Run ls -a and see if there's a .paket directory.
If it does not exist, run mkdir .paket.
Now do cd .paket so you're in the hidden .paket directory under sublime-fsharp-package-master.
Now do ls and see if there's a paket.bootstrapper.exe file.
If it doesn't exist, then copy in the .exe files you downloaded earlier:
cp /Users/Username/Downloads/paket.bootstrapper.exe .
cp /Users/Username/Downloads/paket.exe .
Important: Now do cd .. to go back up to the /Users/Username/Library/Application\ Support/Sublime\ Text\ 3/Packages/sublime-fsharp-package-master/ directory.
Now instead of running /Users/Username/Library/Application\ Support/Sublime\ Text\ 3/Packages/sublime-fsharp-package-master/build.sh install, try running it as ./build.sh install. (And also try ./build.sh Install, since I'm pretty sure the capital I is necessary).
(BTW, If you're not familiar with the syntax that I used in steps 9, 10 and 11, where I used a single . or two dots .. in commands, those are a long-standing Unix idiom: . means "the current directory", and .. means "the parent directory".)
I just looked at the build.sh script that you've been running, and it seems to assume that you've done a cd into the package's base directory (the sublime-fsharp-package-master directory) before running the script. So that could explain why it was failing: you were running it from a different directory, rather than doing a cd first. Hence why I marked step 10 as important: I think that was the root cause of the problem.
I'll try to explain it as easy as I can. I tried to include and build package "A" in my Yocto image, but package A depends on libftdi and ftdi-eeprom. Now, "ftdi-eeprom" depends on the "libftdi".
In the newer versions of the "libftdi" the tarball also includes the ftdi-eeprom sources too and when you build the libftdi it builds both of the packages. Although because of the way that package "A" is configured I need two different recipes for each of the dependencies.
long story short, I made the two bitbake recipes as best as I could and successfully built "libftdi". Now when I run the "ftdi-eeprom" recipe, it wants to populate some files into the sysroot that are already installed there by libftdi. Here is where the error occurs... duplicates!
Apparently I need to set a SSTATE_DUPWHITELIST variable and declare that these duplicate files are safe to replace the old ones in the image (this overwrite must happen). Can someone please help me with configuring the SSTATE_DUPWHITELIST? I am not that pro working with Yocto.
Errors that I get on screen are uploaded in Dropbox
Thanks in advance!
The answer is to not use SSTATE_DUPWHITELIST for this at all. Instead, in the libftdi recipe's do_install (or do_install_append, if the recipe itself doesn't define its own do_install) you should delete the duplicate files from within ${D} and then they won't get staged and the error won't occur.
I got it to work by using:
SSTATE_DUPWHITELIST = "/"
Dont forget the quotes. Here's my bb excerpt:
SSTATE_DUPWHITELIST = "/"
DEPENDS = ""
do_unpack() {
mkdir -pv ${S}
tar xvf ${DL_DIR}/${FILENAME}.tar -C ${S}
}
do_install() {
install -d -m 755 ${D}${includedir}
install -m 644 ${S}/${MYPATH}/inc/myHeader1.h ${D}${includedir}
install -m 644 ${S}/${MYPATH}/inc/myHeader2.h ${D}${includedir}
install -m 644 ${S}/${MYPATH}/inc/myHeader3.h ${D}${includedir}
}
I managed to solve this problem by adding the SSTATE_DUPWHITELIST to the bitbake recipe of the package as follows:
SSTATE_DUPWHITELIST = "${TMPDIR}/PATH/TO/THE/FILES"
I added the absolute path of all of the 6,7 files that had the conflict to the list. I did that because they were basically coming from a same source and it was all safe to do that. correct me if there is a better way though.
Hope this helps someone!
I´m trying to build my gradle projects from other locations than the project folder itself, but it always says it couldn´t find build task.
What I´ve tried so far:
sudo ./myprojects/myapp/gradlew build
sudo ./myprojects/myapp/gradlew ./myprojects/myapp/build
How can I execute a gradle build task from any location?
Various people have written (and published) scripts to execute gradlew from any subproject directory (in a multi-project build). To reliably execute Gradle from any subdirectory, it is necessary to set the "current project directory" via -p. It would be nice to have this restriction lifted (this would make a good feature request).
You may try this script, which is 90-lines long: https://github.com/dougborg/gdub
Or use this straightforward one-liner I use myself:
function lookupgradle() {
find . .. ../.. ../../.. ../../../.. ../../../../.. ../../../../../.. -maxdepth 1 -name 'gradlew' -executable -print -quit
}
alias g='$(lookupgradle)'
If you'll find out that it is still required to specify project directory, add -p .:
alias g='$(lookupgradle) -p .'
./usmobile-microservice/gradlew -p ./usmobile-microservice clean buildUI
./project_directory/gradlew -p ./project_directory clean build
worked for me
I use git to interface with an SVN repository. I have several git branches for the different projects I work on.
Now, whenever I switch from one branch to another using 'git checkout ', all the compiled executables and object files from the previous branch are still there. What I would like to see is that switching from branch A to B results in a tree with all object files and binaries from the last time I worked on branch B.
Is there a way to handle this without creating multiple git repositories?
Update: I understand that executables and binaries should not end up in the repository. I'm a bit disappointed in the fact that all the branching stuff in git is useless to me, as it turns out I'll have to clone my proxy git repository for every branch I want to start. Something I already did for SVN and hoped to avoid with git. Of course, I don't have to do it, but it would result in me doing a new make most of the time after switching between branches (not fun).
What you want is a full context, not just the branch... which is generally out of scope for a version control tool. The best way to do that is to use multiple repositories.
Don't worry about the inefficiency of that though... Make your second repository a clone of the first. Git will automatically use links to avoid having multiple copies on disk.
Here's a hack to give you want you want
Since you have separate obj directories, you could modify your Makefiles to make the base location dynamic using something like this:
OBJBASE = `git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/\1\//'`
OBJDIR = "$(OBJBASE).obj"
# branch master: OBJBASE == "master/", OBJDIR == "master/.obj"
# non-git checkout: OBJBASE == "", OBJDIR == ".obj"
That will but your branch name into OBJBASE, which you can use to build your actual objdir location from. I'll leave it to you to modify it to fit your environment and make it friendly to non-git users of your Makefiles.
This is not git or svn specific - you should have your compiler and other tools direct the output of intermediate files like .o files to directories that are not under version control.
To keep multiple checkouts of the same repo, you can use git --work-tree.
For example,
mkdir $BRANCH.d
GIT_INDEX_FILE=$BRANCH.index git --work-tree $BRANCH.d checkout $BRANCH
You could set your IDE compiler to generate all private temporary files (.class and so on) in <output>\branchName\....
By configuration your compilation setting branch by branch, you can register the name of the branch in the output directory path.
That way, even if though private files remain when you git checkout, your project on the new branch is ready to go.
In the contrib/ directory of the git distribution, there is a script called git-new-workdir that allows you to checkout multiples branches in different directories without cloning your repository.
Those files aren't tracked by Git or Subversion, so they're left alone on the assumption that they are of some use to you.
I just do my checkouts in different directories. Saves me the trouble of doing cleanup.
A make clean should not be necessary because files that are different between different branches get checked out with the actual date!!!
This means that if your Makefile is correct, only those object-files, libs and executables are compiled again that really changed because of the checkout. Which is exactly the reason a makefile is there in the first place.
The exception is if you need to switch compiler options or even compilers in different branches. In that case probably git-new-workdir is the best solution.
If the compiled executables are files that have been checked in
then git stash solves the problem.
[compile]
git stash save "first branch"
git checkout other_branch
[Fiddle with your code]
[compile]
git stash save "second branch"
git checkout first_branch
git stash apply [whatever index your "first branch" stash has]
# alternatively git stash pop [whatever index...]
If the compiled executables are files that have not and will not be checked in
then simply add them to .gitignore