Were you told to "clone the repository and build it" without knowing what to do next? We will show you how to run this program on GitHub on Linux, even if you are a beginner.
The instructions that make up a computer program are written, edited and saved in text files. A program called compiler then processes these files. This produces the executable version from the program. The text files of instructions are called the source code. The version of the program that can actually run on a computer calls the binary or the executable.
It is a simplified version of the events, but it gives a correct picture – if it is generalized -. In practice, you will find all kinds of variations on this model. Sometimes other programs generate text files. Other times, the source code runs inside of an interpreter and does not need to be compiled, etc.
However, the universal truth in all software projects is this: the source code files are the jewels of the crown, and they must be treated with such care.
Version Control Programs
All source code files in a project call the code base. Large projects often have many developers working on the code base. Each code change must be followed and identifiable. If necessary, the modifications must be reversible. If different developers make changes to the same source code file, their editions must be merged.
It is therefore not surprising that software called version control systems exist to facilitate the management of changes to the code base. Version control systems retain all previous versions of each file in the code base and each change is recorded, commented, and followed.
A little thing called Git
Linus Torvalds, the creator of the Linux kernel, has developed a version control program called Git to administer the core code of the Linux kernel. It is now the most widely adopted version control software in the world. Millions of people use it – literally.
With Git, the code base of a project is stored in repositories. In addition to the local repositories installed on the developers' computers and possibly on a central server on the network, it is recommended to have an off-site or remote repository.
And that's where GitHub comes in.
GitHub was created as a result of the success of git 's. The founders saw the growing need for remote git repositories hosted securely. They started a business provide a cloud platform Allow development teams to host remote repositories. Since April 2019, GitHub has hosted over 100 million repositories.
If an application is an open-source project, there is a good chance that it is hosted on GitHub. There are other repository platforms available, such as BitBucket and GitLab, but GitHub holds the lion's share of open source repositories.
Anatomy of a repository
A GitHub repository consists of folders containing files such as very important source code files. Generally, there are many other types of files in the repository. There may be documentation files, man pages, software license files, build instructions, and shell script files. There are no rules regarding what a repository should or should contain, but there are some conventions.
If you know a kitchen, you can navigate in any kitchen. It's the same with the deposits. Once you understand the conventions, you know where to find what you need.
So, how do you get a copy of the repository on your computer and how do you build the program in a binary executable?
The readme file
It is customary to include a readme file in a repository. It can be called readme, readme or README. It can have an extension ".md" or no extension at all.
Let's look at the GitHub repository for the Atom publisher. You see a long list of folders and files. Scroll down to view the contents of the README.md file.
GitHub automatically places the contents of the readme file on the repository home page. If the readme file has an ".md" extension, it will contain Marking language. This allows developers to use style elements, such as fonts, bullets, and images.
Typically, a readme file has sections that describe the project, its type, the type of license, who maintains it, how to get involved, and how to create and run the application.
If it does not list construction instructions, it will tell you where to find this information. Other useful information for creating the application, such as the required build tools and other dependencies, can be listed here or a link can direct you to that information.
The repository boxes
Our mission is to clone the box depot, and then compile the application boxes.
The repository follows the same presentation as that of the Atom. There is a list of folders and files and below is the contents of the Readme file. It follows the standard layout of a repository, but it's a smaller project, so fewer folders and files.
The Readme file is also shorter. It has a section called "Development". This section contains a link titled "Building from the Source". If we follow this link, we should find the information we need.
It is usually necessary to do some light research to navigate the repository and find the desired information, but it is not difficult. Read carefully everything on the repository page. Sometimes the information is there but may not be displayed prominently.
The build instructions say to issue the make command, so we will also need make.
The tools needed to create this application are a C, Bison, Flex, make and Git compiler (to clone the repository on your computer).
This article has been studied on computers running Linux Ubuntu, Fedora and Manjaro distributions. All the tools in the distribution had not been installed – something had to be installed on each one.
Installing the toolset
Ubuntu had to have Git, Flex, Bison and make installed. Here are the commands:
sudo apt-get install git
sudo apt-get install flex
sudo apt-get install bison
sudo apt-get install brand
Fedora had to have Flex, Bison and have it installed. Here are the commands:
sudo dnf install flex
sudo dnf installs bison
sudo dnf install brand
Manjaro had to have the GCC compiler, Flex and Bison installed. Here are the commands:
sudo pacman -Syu gcc
sudo pacman -Syu flex
sudo pacman -Syu bison
Cloning the repository
Each GitHub repository has a specific web address used with Git to clone the repository on your computer. On the main box repository page, a green button labeled "Clone or download" is displayed.
Click the button to see the web address. This is the address we need to pass to the git command when we clone the repository.
Navigate to the directory where you want the repository to be cloned, and then use this command. If your device window supports it, you can copy and paste the web address into the command. Press Ctrl + Shift + V to paste into a GNOME terminal window.
Git clones the remote repository and creates one on your computer. He tells us that he is cloning into a directory called "boxes".
The boxes directory is created in the directory from which you issued the git command. If we go to the boxes directory and look at the contents, we see the same list of files and folders as seen on the GitHub page.
Awesome! We managed to clone the source code and other files on our computer. Now we have to build the application.
Build the application
To build the application, we must follow the instructions of the GitHub repository. Sometimes we will run a particular shell file and others, make. The build instructions we follow told us to execute make.
The make utility reads and executes a set of instructions from a makefile. These instructions show how to compile the program and bind it. make passes the instructions to the compiler and other builders.
The command we are told to use will call make twice. The first call to make builds the application and the second runs a test suite.
The order that the construction instructions told us to use is as follows:
make && make test
Many output lines scroll quickly through the terminal window. In a minute or two, you will be returned to the command prompt.
Deploying the application boxes
The application has been built and we have an executable binary. We now have to copy the binary to the / usr / bin / directory. This allows the shell to find it when we try to use it.
For some applications, it may be all you have to do. In other cases, you may need to copy additional files, such as man pages and configuration files, into file system locations. This is what we have to do with our new application as it was in the building instructions.
Use sudo to execute these commands. The first command copies a manual page to the man1 directory:
sudo cp doc / boxes.1 / usr / share / man / man1
Then, copy the global configuration file to a directory of / usr / share /:
sudo cp boxes-config / usr / share / boxes
Finally, copy the binary into / usr / bin:
sudo cp src / boxes / usr / bin
Test Application Boxes
Let's see if everything works! Try to open the manual page for the boxes command.
It's encouraging! A manual page tells you how to use the boxes command.
Press "Q" to exit the man system and try using the boxes command.
echo How-To Geek | boxes
And we get the answer:
This may sound a little disappointing given all the effort you've made, but the purpose of this exercise was to guide you through the process of removing a GitHub repository and creating the application.
The box command allows you to wrap text that is transmitted to it in a wide variety of frames. Some of them could be used as comments in the source code files. The format above would work as a comment in a C source code file, for example. Others are purely decorative. The -d (design) option lets you choose the style of the frame.
echo How-To Geek | boxes -d whirly
echo How-To Geek | boxes -d c-cmt2
There is a long list of models from which you can choose. To see them all, use this command:
boxes -l | less
The steps to compile from the source are usually simple:
See the build instructions on the repository.
Make sure you have the required tools installed and install the missing ones.
Clone the repository on your computer.
Follow the build instructions, which are often as simple as typing make.
Copy the file (s) to the required locations.
If some steps in the build instructions are not clear, see if the project has a forum or community to which you can post a question. If the app has a website, it is possible that it has a "Contact Us" page. The developer who manages the box project has their email address on the "About" page of the site of the boxes. It is a generous gesture on his part, typical of the open source community in the broad sense.