Here we can see, “How to Install Software on Linux Using Git”
Have you been told to “clone the repo and build it” but aren’t sure where to go from there? Even if you’re a beginner, we’ll show you how to get that GitHub programme operating on Linux.
Text files are used to write, update, and save the instructions that make up a computer programme. These files are subsequently processed by a computer known as a compiler. This creates the program’s executable version. The source code refers to the text files that provide instructions. The binary or executable version of a programme is the version that can run on a computer.
That’s a condensed version of events, but it’s accurate—if oversimplified. In actuality, there are numerous modifications to that model. Other programmes are sometimes used to create text files. In other instances, the source code runs inside an interpreter and does not require compilation, and so on.
However, one fundamental principle applies to all software projects: the source code files are the crown jewels, and they must be treated with equal care.
Programs for Version Control
The codebase refers to all of a project’s source code files. Many developers are often working on the same codebase in large projects. Every change to the code must be tracked and identified, and changes must be reversible if they are required. When multiple developers work on the same source code file, their modifications must be merged.
It’s no surprise, then, that software packages called version control systems exist to help with codebase change management. All versions of each file in the codebase are stored in version control systems, and every modification is logged, commented on, and tracked.
Git is a little thing.
Linus Torvalds, the Linux kernel’s designer, created the Git version control programme to manage the Linux kernel codebase. It’s now the most extensively used version control software on the planet. It is used by millions of people—literally.
The codebase of a project is stored in repositories with Git. It’s a good idea to have an off-site, or remote, repository in addition to the local repositories on developers’ PCs and, maybe, on a central server on the network.
That’s where GitHub comes into play.
The success of Git led to the creation of GitHub. The founders saw the growing demand for secure remote git repositories, and they started a company that provides a cloud platform for developers to host remote repositories. GitHub has approximately 100 million repositories as of April 2019.
If a programme is an open-source project, its chances of being hosted on GitHub are relatively high. Other repository sites, such as BitBucket and GitLab, are available. However, GitHub has the largest number of open source repositories.
A Repository’s Anatomy
A GitHub repository is made up of folders that include things like the crucial source code files. There are usually various other file kinds in the Repository, and documentation, man pages, software licencing files, build instructions, and shell script files may be present. There are no hard and fast rules about what should or must be included in a repository; however, there are certain guidelines.
You can navigate any kitchen if you know your way around one. The same is true with repositories, and you’ll know where to look for what you need once you’ve learned the conventions.
So, how do you download a copy of the Repository and compile the software into a binary executable?
The readme File
A readme file is usually included in a repository, and it could be referred to as readme, README, or README. It could have a “.md” extension or no extension at all.
Let’s have a peek at the Atom editor’s GitHub repository. There’s a huge list of folders and files in front of you, and the contents of the README.md file can be found by scrolling down.
The contents of the readme file are automatically displayed on the Repository’s main page by GitHub. The Markdown markup language is used in readme files with the “.md” extension. This permits the developers’ use of style components such as typefaces, bullet points, and images.
A readme file usually contains parts that explain what the project is about, what type of licence it is, who maintains it, how to contribute, and how to build and execute the Application.
It will advise you where to locate this information if it does not include the actual build instructions. Other important information for constructing the programme, such as the build tools and other dependencies, may be listed here, or a link to such information may be provided.
The Repository’s boxes
Our goal is to clone the boxes repository and then create the boxes app.
The Repository has the same layout as the Atom repository. A list of directories and files follows, followed by the contents of the readme file. It has the typical repository layout, but there are fewer directories and files because it is a smaller project.
The readme file is also shorter. There’s a section named “Development” in it, and there’s a link called “building from source” in that part. If we click on that link, we should be able to find the information we require.
Navigating the Repository and finding the information you need usually requires some little digging, but it’s not difficult. Pay close attention to everything on the repository page. The information may be present, but it may not be readily displayed.
The section “Building on Linux” on the “Building from Source” page is just what we require. It specifies that a C compiler, Bison, and Flex must be installed.
Because the make command is mentioned in the construction instructions, we’ll also require to make.
A-C compiler, Bison, Flex, make, and Git is necessary to construct this Application (to clone the Repository to your computer).
This article was tested on PCs running the Linux distributions Ubuntu, Fedora, and Manjaro. None of the distributions had all of these tools installed, and therefore it was necessary to install something on each of them.
Installing the Tool Set
It’s required Git, Flex, Bison, and make to be installed on Ubuntu. The commands are as follows:
sudo apt-get install git
sudo apt-get install flex
sudo apt-get install bison
sudo apt-get install make
Flex, Bison, and make had to be installed on Fedora. The commands are as follows:
sudo dnf install flex
sudo dnf install bison
sudo dnf install make
Manjaro required the installation of the GCC compiler, Flex, and Bison. The commands are as follows:
sudo pacman -Syu gcc
sudo pacman -Syu flex
sudo pacman -Syu bison
The Repository is being cloned.
Each GitHub repository has a unique URL address that you can use with Git to clone it to your PC. A green button labelled “Clone or download” may be seen on the home page of the boxes repository.
To see the website address, click the button. When we clone the Repository, we must supply this address to the git command.
Change to the location where the Repository will be cloned, and then run this command. You can copy and paste the web address into the command if your terminal window allows it. To paste into a GNOME terminal window, press Ctrl+Shift+V.
Git copies the remote Repository to your machine and makes a local copy. It tells us it’s replicating into the “boxes” directory.
Within the directory where you ran the git command, the boxes directory is created. When we look at the contents of the boxes directory, we see the identical list of files and folders that we saw on the GitHub page.
Great! The source code and other files were successfully copied to our machine. We must now construct the Application.
Developing the Program
We must follow the instructions on the GitHub repository to construct the Application. We’ll run a specific shell file at times and make it at other times. We were told to execute make in the build instructions.
A makefile contains a set of instructions that the make utility reads and executes. These instructions explain how to compile and link the software together, and the instructions are passed to the compiler and other build tools by making.
Make twice is the command we’re supposed to use. The first call is used to create the Application, while the second is used to execute a set of tests.
The command to use, according to the build instructions, is:
make && make test
In the terminal window, many lines of output scroll by quickly. You’ll be taken back to the command prompt in about a minute.
Putting the boxes in place Application
We now have an executable binary for the Application that has been built. The binary must now be copied to the /usr/bin/ directory. When we try to use it, the shell will be able to find it.
This may be all you need to do for some applications. In some circumstances, you may need to copy additional files into the filesystem, such as man pages and config files. Because it was specified in the build instructions, we must do the latter with our new Application.
To run these commands, type sudo. The first command creates a man page in the man1 directory, as follows:
sudo cp doc/boxes.1 /usr/share/man/man1
Next, copy the global config file to a directory in /usr/share/:
sudo cp boxes-config /usr/share/boxes
Finally, copy the binary to /usr/bin:
sudo cp src/boxes /usr/bin
Application for box testing
Let’s see if it all comes together! Open the man page for the boxes command and see what you can find.
That’s great news! You come upon a man page that explains how to use the boxes command.
To exit the man system, type “Q” and then try the boxes command.
echo ITechBrand | boxes
Given all of your hard work, this may seem a little underwhelming, but the goal of this exercise was to show you how to grab a repository from GitHub and build an application.
You can use the boxes command to wrap text piped to it in a variety of frames. Some of them could be used in source code files as comments. For example, the format above might be used as a comment in a C source code file. Others are just ornamental. The -d (design) option allows you to select the frame’s style.
echo ITechBrand | boxes -d whirly
echo ITechBrand | boxes -d c-cmt2
There is a large selection of designs from which to choose. Use the following command to see them all:
boxes -l | less
The steps for building from source are usually simple:
- Examine the Repository’s build instructions.
- Check that you have all of the necessary tools installed, and if any are missing, install them.
- Download the Repository to your computer and clone it.
- Follow the build instructions, which are typically as straightforward as entering make.
- Transfer the file(s) to the appropriate locations.
If you have any questions about the build instructions, see if the project has a forum or community where you may ask them. A “Contact Us” page may be available if the Application has a website. The email address of the developer who maintains the boxes project may be found on the boxes website’s “About” page. That’s a wonderful gesture from him, and it’s typical of the open-source community as a whole.
I hope you found this information helpful. Please fill out the form below if you have any queries or comments.
- Does GitHub have a desktop application for Linux?
GitHub does not officially support Github Desktop for GNU/Linux, but a fork hosts a version for Debian/Ubuntu and Red Hat/CentOS/Fedora distributions.
- Do I need to install Git to use GitHub?
You can use Git without GitHub, but you can’t use GitHub without Git. GitLab, BitBucket, and “host-your-own” solutions like gogs and gittea are all viable alternatives to GitHub. These are referred to as “remotes” in git-speak, and they’re all fully optional.
- How does Git work on Linux?
Git is widely used in software development for version/revision management and source code control. It’s a revision control system that’s distributed. Git was invented and developed by Linus Torvalds, the developer of the Linux kernel. Git was first used to update Linux kernel source code from all around the world.
- Questions about using git clone to install the software (vs the package manager)
Questions about installing software via `git clone` (vs the package manager) from linuxquestions
- An Overview of Git and GitHub