Every time I'm learning a new technology or a new language, I feel the need to create a reproducible template project that has already the basics built in. The idea is to have a somewhat abstracted away template, such that I can in the future use it as a basis for an actual project without having to remember fine details and commands to the specific tech stack at hand. There are also tutorials mixed among templates, which are always correctly giving props to the respective authors or sources, since they serve similar purposes as boilerplate/template projects.
Since that was becoming a strong habit and there were numerous little template projects littered throughout my profile, I took the liberty to unify them under a single repository. They hopefully have the basics covered, as in a language it should have compiling, running, testing and debugging as targets or at least documentation on how to perform these actions for the given template.
- Go
- Rust
- Lua
- C
- C w/ Lua
- Cpp
- Haskell
- Common Lisp
- Java
- Latex
- GHDL
- Python
- Travis-CI
- Jenkins
- Dockerfile
- ClangFormat
- Git Hooks
- Python CFFI
- C/Lua SDL2
- C++ OpenMPI
- Google Test
- Pytest
$ sudo pacman -S go
$ go install https://github.com/derekparker/delve # if debugging is wanted
$ go install golang.org/x/tools/cmd/godoc # if documentation is wanted
$ make # build's project
$ make build # also build's project
$ make run # runs binary
$ make debug # runs binary with debugger
$ make test # unit testing
$ make cover # test with coverage information
$ make docs # generate documentation
$ make fmt # format go files
$ sudo pacman -S rustup
$ rustup update stable
$ rustup component add rls rust-src # for lsp to be used with your editor
$ cargo build # build's project
$ cargo build --release # stores executable in target/release and performs optimizations
$ cargo check # checks if project compiles without building
$ cargo run # builds project and runs binary
$ cargo test # unit testing
$ cargo fmt # format go files
$ sudo pacman -S luarocks
$ sudo luarocks install luacheck
$ cargo install stylua # needs rust installed
$ make # runs lua project
$ make style # runs stylua and styles project accordingly
$ make lint # runs styling first, then lints the project
sudo pacman -S cmake
With CMake it is possible to abstract away much of the flags and command line arguments needed within a large project. To be able to build said project, these are the necessary steps:
$ cd build
$ cmake ..
$ make
Additionally, there are two bakes in targets called run
and debug
. How they are setup can be seen in the
.cmake
files found in the cmake folder within the template project. They do as their name suggest, however to
be able to successfully use the debugger, one needs gdb installed in their system.
$ sudo pacman -S cmake lua
It's the same process as in the C template, the only difference is that the c binary is communicating with the lua virtual machine which of course also was written in C. Essentially, C can call functions and read/write variables within lua and vice versa. This can be very powerful and lead to interesting applications.
$ cd build
$ cmake ..
$ make
sudo pacman -S cmake
Almost a 1 to 1 copy of the C template. If it is necessary to specify a version of the language change the following line within CMakeLists.txt
:
set (CMAKE_CXX_STANDARD 11)
An interesting functional language, seemingly very beloved by its community. This project template was derived from a great repository which is mentioned in the README. Also, there is also mentioned the cabal build system, which stack uses under the hood. However, it was found by me to be much easier to use stack.
Great documentation on stack can be found here, also a simple tutorial can be found here.
$ make build # runs stack build
$ make run # runs the binary, runs stack exec <project name>
$ make test # runs stack test to perform unit testing, untested!
$ make fmt # formats haskell files
$ make clean # runs stack clean
$ make purge # runs stack purge
$ make docs # runs cabal haddock, untested!
Minimal template project for common lisp applications. Uses the asdf build tool to manage the project, it's dependencies and testing. The testing library used here is prove.
$ make # compiles and runs application
$ make test # runs prove unit testing
$ make clean # cleans project
The best resource will of course be found in the gradle's official website. However this folder can be used either as a starting point or an illustration of a simple java application that
sudo pacman -S jdk-openjdk gradle
$ make # runs application
$ make build # builds/packages application
$ make test # runs unit tests application
$ make clean # cleans project
The idea was to create a latex project that did not need to require an installation of tex and it's huge libraries. Using a containerized docker that takes care of this work, it becomes very easy to work with latex in a OS agnostic manner. The docker build in question is docker-texlive.
sudo pacman -S docker
Docker may need special rights to be able to be run without sudo
.
make # does it all, pulls docker if necessary, builds the main.tex into a main.pdf
make clean # cleans project
make reset # deletes a running docker if there is one and the pulled docker image.
Project is working, however I need to document the steps and dependencies.
TODO
Python example project with unit-tests and a Makefile. Targets include venv setup and installation of the project in developer mode. The boilerplate is also ready to be installed from github as well.
Depends on the project in question. Here, as an example a regular cpp
CMake project is used.
sudo pacman -S cmake
An account has to be created at travis-ci. Following to that, one would have to give permissions to the travis-ci bot within github. That way, any project that is pushed and contains a travis.yml
file will be evaluated by the travis bot. The pipeline steps examples are listed in the above mentioned file, once again as an example of what one could do. Also further configuration
can be done in one's travis account.
There are two project examples at hand. One is the use of jenkins within a docker, which eliminates the dependency
of jenkins directly. Also theoretically shows the use of a containerized deployment of this CI/CD program. The other one
is a regular cmake project that simply has a Jenkinsfile
that directs how the pipeline should be executed. However, for the
latter's case one has to configure jenkins to look at this project either locally or through a git-based portal and order
it to deploy the pipeline when needed.
sudo pacman -S docker
$ make build # pulls and builds the jenkins docker
$ make run # runs the docker at port 8080
$ make log # shows the log output of the running docker
$ make stop # stops docker
$ make restart # restarts docker
$ make clean # stops and deletes the jenkins docker
$ make reset # stops docker, deletes it, and then its image
sudo pacman -S jenkins cmake
The Jenkinsfile details very explicitly how the pipeline is executed.
An example use of a dockerfile. The idea is to show how one can write a dockerfile for a given linux OS with countless dependencies, environment variables, file structures and volume instantiations. There is also the use of an entrypoint script to show what could be done within the docker, since with a shell script the possibilities are endless.
sudo pacman -S docker
$ make build # builds the custom docker with a tag and a repo
$ make run # runs the docker through the given entrypoint script
$ make clean # deletes the docker
$ make reset # deletes the docker and then its image
An example toy C project and how to format it using clang-format
. Possible styles are:
- gnu
- llvm
- chromium
- mozilla
- webkit
- microsoft
paru -S clang-format-all-git
$ make # default, formats the given toy C project within google's style
$ make STYLE=<style> # style according to the given variable
A small repo to exemplify what one could do with git hooks
. Also gives a minor
explanation to what specific hooks do, when they are activated and how they could
be used. Based on this.
sudo pacman -S git
Not straightforward, please read through README.
Example project template that implements a C++
backend exposed through the use of CFFI
.
The idea is to be able to use the flexibility of Python
, but still harness the heavy
lifting or speed from C++
through using bindings to connect data between the two stacks.
The backend compilation, packaging and installation is managed through CMake
. Finally
through a couple of simple Makefiles
, the different capabilities of the project are
abstracted away.
sudo pacman -S cmake
pip install cffi pytest
$ make build # builds backend, installs it and compiles the C++-to-Python binding interface
$ make run # runs the example python program that interfaces with the toy `C++` backend
$ make test # runs unit-tests that ultimately test the python-wrappers that call upon the `C++` backend
$ make clean # cleans project
Boilerplate code for small projects that need graphics with easy extendibility. Here it is done with
the Lua
scripting language. This is also a learning project to look at the capabilities
of a work written in C/C++
which can be scripted by users or extended with Lua
.
The underlying graphics library is SDL2
, which makes the project written in C.
This is also the chosen language since the Lua
VM has a clean and powerful C API,
which was a language design goal. Lua
was made to be embedded and further the capabilities of
a language such as C
. The project would also be maintained by a portable build system like CMake.
sudo pacman -S cmake lua sdl2 sdl2_gfx sdl2_image sdl2_mixer sdl2_ttf
- Build
$ cd build
$ cmake ..
$ make
- Run
$ make run
The Open MPI Project is an open source Message Passing Interface implementation that is developed and maintained by a consortium of academic, research, and industry partners.
The source files are not made by me and are taken from this tutorial, authored by Wes Kendall. This template serves as an easy way to compile all projects through CMake and be able to visualize their functionalities and capabilities.
sudo pacman -S cmake openmpi
- Build
$ cd build
$ cmake ..
$ make
- Run
$ ../bin/<binary name>
There are two example templates in this repo. One that attacks this problem through CMake and another that does so through Bazel.
Simple project template that aims:
- To write code in
C
that is compiled/built with CMake. - Test the project using GoogleTest's
C++
framework, which is also mantained throughCMake
. - Obtain coverage reports of said tests using GNU's
gcov/lcov
. - Integrates all goes through targets in CMake.
sudo pacman -S cmake lcov
- Build Toy Project
$ cd build
$ cmake ..
$ make
- Build Tests
$ cd test/build
$ cmake ..
$ make
- Get Test Report
$ make report
- Get Coverage Report
$ make coverage
- Generate documentation for both
$ make docs
Similar goals to the CMake version, however done so with Bazel.
sudo pacman -S bazel lcov
- Building
bazel build ...
- Running Tests and Obtaining Test Report
python test.py
Example use of pytest in a quick and dirty project. Should be changed to use a proper initialized python module, not a c-like src file.
TODO
sudo pacman -S python
pip install pytest
$ make # runs project
$ make test # unit testing
$ make clean # cleans project
This project is released under the GNU Public license 3.0. See LICENSE.
I have a ko-fi and a buy-me-a-coffee account, so if you found this repo useful and would like to show your appreciation, feel free to do so!