I have a vivado project directory that I want to check into git. I have all my VHDL source files one directory up from the "vivado project" directory under "../hdl/".
My guess is that I only need to check in:
git add ./hdl/*.vhd
git add ./hdl/*.xdc
git add ./vivado_project/vivado_project.xpr
git add ./vivado_project/vivado_project.srcs/
The reset of the files generated by vivado doing compile are output garbage that can be recreated again by running the compile on the checked in git files?
Is this correct???
That basically mean that the following vivado directories are output garabage that can be thrown away and deleted, because they will be recreated again when recompiling fresh from a git checkout:
So basically "rm -rf" and ".gitignore" the following vivado project file:
*.cache/
*.runs/
*.sim/
*.hw/
*.ip_user_files/
*.jou
*.log
*.str
No, you would need to version control a lot more of the project files. Many of them are binary.
The recommended approach for version controlling Vivado projects is to not version control any of the project files.
Instead, you export a project TCL file from Vivado, and version control just that TCL file, and your source code.
Vivado can recreate the entire project from the TCL file, and TCL is a text file, so it supports diff, merge, and so on.
There are more details here:
http://www.fpgadeveloper.com/2014/08/version-control-for-vivado-projects.html
Related
I made a Rails application.
Do i need to push these files to Github?
.browserslistrc
.gitattributes
.rspec
.ruby-version
The short answers are "if you want", and "there's no reason not to".
All of these files do something to make it easier to replicate your code base and setup on another machine. None of them contain secrets that shouldn't be shared.
.browserslistrc
The config to share target browsers and Node.js versions between different front-end tools.
.gitattributes
a simple text file that gives attributes to pathnames.
These attributes affect how the contents stored in the repository are copied to the working tree files when commands such as git switch, git checkout and git merge run. They also affect how Git stores the contents you prepare in the working tree in the repository upon git add and git commit.
.rspec
Read command line configuration options from files
.ruby-version
Many Ruby (or Rails) projects will include a simple .ruby-version file, which simply specifies a version number
I have made a ROS workspace and inside a package.
I did catkin_make and everything is working well.
I would like to give this package (or should I give the entire workspace?) to another person.
I am thinking to give him a zip file of the files and folders (it contains launch files, python scripts, rviz files etc) so I am expecting he will unzip it in his machine
I would like he can run the launch files without problems
What is what he needs to do for this? (of course he will have ROS installed, that is no problem)
I am thinking perhaps he should do source devel/setup.bash but is this enough?
When sharing a workspace with somebody only the source space src has to be shared. It should contain all our packages with their launch files (*.launch), Python (*.py) and C++ nodes (*.cpp, *.hpp), YAML configuration files (*.yaml), RViz configurations (*.rviz), robot descriptions (*.urdf, *.xacro) and describe how each node should be compiled in a CMakeLists.txt. Additionally you are supposed to keep track of all the Debian packages you install inside the package.xml file of each package.
If for some obscure reason there are things that I have to do that can't be accommodated in the standard installation instructions given above, I will actually write a bash script that performs these steps for me and add it either to the package itself or the workspace. This way I can automate also more complex steps such as installing OpenCV or modifying the .bashrc. Here a small example of what such a minimal script (I generally name them install_dependencies.sh) might look like:
#!/bin/bash
# Get current workspace
WS_DIR="$(dirname "$(dirname "$(readlink -fm "$0")")")"
# Check if script is run as root '$ sudo ...'
if ["$EUID" -ne 0]
then
echo "Error: This script has to be run as root '$ sudo ./install_dependencies.sh'
exit 1
fi
echo "Installing dependencies..."
# Modify .bashrc
echo "- Modifying '~/.bashrc'..."
echo "source ${WS_DIR}/devel/setup.bash" >> ~/.bashrc
echo ""
echo "Dependencies installed."
If for some reason even that is not possible I make always sure to document it properly either in a Markdown *.md read-me either in a /doc folder inside your package, in the read-me.md inside the base folder of your repository or inside the root folder of your workspace.
The receiver then only has to
Create a new workspace
Copy or clone the package files to its src folder
Install all the Debian package dependencies listed in the package.xml files with $ rosdep install
(If any: Execute the bash scripts I created by hand $ sudo ./install_dependencies.sh or perform the steps given in the documentation)
Build the workspace with $ catkin_make or $ catkin build from catkin-tools
Source the current environment variables with $ source devel/setup.bash
Make sure that the Python nodes are executable either by $ chmod +x <filename> or right-clicking the corresponding Python nodes (located in src or scripts of your package), selecting Properties/Permissions and enabling Allow executing file as program.
Run the desired Python or C++ nodes ($ rosrun <package_name> <executable_name>) and launch files ($ roslaunch <package_name> <launch_file_name>)
It is up to you to share the code as a compressed file, in form of a Git repository or a more advanced way (see below) but I will introduce some best practices in the following paragraphs that will pay off in the long run with larger packages.
Sharing a package or sharing a workspace?
One can either share a single package or an entire workspace. I personally think that most of the time one should share the entire workspace instead of the package alone even if you only cloned the other packages from a public Github repo. This might save the receiver a lot of headache e.g. when checking out the wrong branch.
Version control with Git
Arguably the best way to arrange your packages is by using Git. I'd actually make a repository for every package you create (if a couple of packages are virtually inseparable you can also bundled them to a single Git repo or better use metapackages). Then create an additional repository for your workspace and include your own packages and packages from other sources as submodules. This allows your code to be modular and re-usable: You can share only a package or the entire workspace!
As a first step I always add a .gitignore file to each package repository which excludes *.pyc files and another one to the workspace repository that ignores the build, devel and install folders.
You can add a particular repository as submodule to your workspace Git repository by opening a console inside the src folder of your workspace repository and typing
$ git submodule add -b <branch_name> <git_url_to_package> <optional_directory_rename>
Note that you can actually track a particular branch of a repository that you include as a submodule. In case you need a submodule at some point follow this guide.
If you share the workspace repository with someone they will have to have access to each individual submodule repository and they will have to not only pull the repository but also update the submodules with
$ git clone --recurse-submodules <git_url_to_workspace_repository>
and potentially update them to the latest commit with
$ git submodule update --remote
After these two steps they should have a full version of the repository with submodules and they should be able to progress with the steps listed in the section above.
1.1 Unit-testing and continuous integration
Before sharing a repository you will have to verify that everything is working correctly. This can take a decent amount of time, in particular if the code base is large and you are modifying it frequently. In the ideal case you would have to install it on a brand new machine or inside a virtual box in order to make sure that the set-up works which would take quite some time. This is where unit testing comes into play: For every class and function you program you will write a test. This way you can simply run these tests and make sure everything is working correctly. Generally these unit tests will be performed automatically and the working branches merged continuously. Generally the test routines are written with the libraries Boost::Test (C++), GoogleTest (generally used in ROS with C++), unittest (for Python) and QtTest (for GUIs). For ROS launch files there is additionally rostest. How this can be done in ROS is described here and here.
ROSjects
If you do not even want the person you are sending the code to to go through the hassle to set it up you might consider sending them a ROSject. A ROSject is an online virtual ROS environment (by the guys behind The Construct, the main source of ROS courses and of ROS tutorials on Youtube) that can be created and shared very easily from your existing Git repository as can be seen here. The simulation runs entirely in the cloud on a virtual machine. This way the potential of failure is very low but it is not a choice if your code is supposed to run on hardware and not only in simulation.
Docker
If your installation procedure is complex you might as well use a container such as a Docker.
More information about using Docker in combination with ROS can be found here. The Docker container might introduce though a bit of overhead and it is probably no choice for code which should have real-time priority in combination with a real-time patched operating system.
Debian or snap package
Another way of sending somebody a ROS package is by packing it into a Debian or snap package. This process takes a while and is in particular favourable if you want to give your code to a large number of users that should use the code out of the box. Instructions on how this can be done for Debian packages can be found here and here, while a guide for snap can be found here.
I am using git with Xcode but when i commit files using Xcode (not command line) after committing and pushing to remote, when i use git status this is the result.
What are Untracked Files. What should i do with them?
And what about Changes not staged for commit part? What are they?
These untracked files are files that have been added to your directory structure (e.g. it would appear that you did a pod install), but you have neither added them to source control nor told git to ignore them. (I would tell git to ignore them, personally.)
But you have to decide whether you want to add the Pods directory to your repo or whether you'd like to ignore them. See https://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control. (I personally don't put Pods into source control, just the Podfile and Podfile.lock. There are many opinions on that topic, though.)
Re the .DS_Store, we often have a ~/.gitignore_global that tells it to ignore those, too. Once you tell it to ignore these, they will be removed from the “untracked” files list. See .gitignore all the .DS_Store files in every folder and subfolder.
Re the unstaged .DS_Store it looks like your repo already had that one .DS_Store in the repo. I would suggest removing it from the repo. See How can I Remove .DS_Store files from a Git repository?.
In short, it looks like you have a project with no .gitignore file (or it is missing entries). It also looks like you don’t have a ~/.gitignore_global to ignore .DS_Store files.
For an example of a .gitignore that you might use for Swift projects, see https://github.com/github/gitignore/blob/master/Swift.gitignore (though, like I said, I generally would uncomment the Pods from that particular .gitignore).
I had not heard of this file until I randomly checked git status in an old repository and there it was, a file I had not edited myself nor ever seen before. I do not know how it got there.
It seems it's common asked about - mostly how to remove it (e.g. here and here).
What is this file, and what created it?
.idea is the dir for saving the project configurations for all Jetbrains IDES (RubyMine , Pycharm , PHPStorm , WebStorm ..etc)
you can handle it using two ways if you don't want to commit it to the repo
Ignore it only for yourself
in .git/info/exclude
add /.idea
Ignore it in .gitignore so it will be ignored for everyone who uses the repo
by adding /.idea to .gitignore
if the dir .idea already tracked by git you will need to remove it first from the cached files before ignoring by git rm -r --cached .idea
This folder can include important configuration if you did any custom configuration for the project and also include the indexed data for the IDE which helps it to provide quick autocomplete and in certain cases would be better to commit it to the repo but I always ignore it because the other developers in the team don't use RubyMinee
I created a project in CppCheck named CppCheck_MainRls.cppcheck
that includes several directories, i can run the project from the gui and it's working.
my project is huge so i only need a few directories to pass through CppCheck and export the result into xml file (later to be read by jenkins)
The current command line is:
"C:\Program Files (x86)\Cppcheck\CppCheck.exe" --enable=all --xml-version=2 "C:\Program Files (x86)\Jenkins\jobs\MainRls\workspace\Labs\VC++\AllShared" 2> cppcheck_result.xml
which is working great for the "AllShared" directory, how can i change it to read my project file?
I am a cppcheck developer. Currently, you can't use a gui project file directly in the shell client. However it is a good idea to allow it.
As of April 2020 (cppcheck v1.90), this is supported per the cppcheck manual (PDF) section 3.1:
3.1 Cppcheck GUI project
You can import and use Cppcheck GUI project files in the command line tool:
cppcheck --project=foobar.cppcheck