1
0

docs: update readme
All checks were successful
Deploy Tools / build-package (push) Successful in 22s

This commit is contained in:
Jonathan Hoffstadt 2024-09-06 06:47:10 -05:00
parent 53585cc906
commit 1d62f31583

View File

@ -1,52 +1,35 @@
## Pilot Light Build
<h1 align="center">
Pilot Light
</h1>
### Background
The **pl-build** project is a child of the larger [Pilot Light](https://github.com/PilotLightTech/pilotlight) project. In this larger project, we do not have a "build system" per se. Instead we prefer to write batch/bash scripts that directly call the compiler. If the project was an end user product, this would be the end of it. However, this is not the case. It is meant to be easily extended through adding additional extensions and being used as a "pilot light" to start new projects. With this comes a couple issues. Extensions are meant to be cross platform so users need the ability to easily add new binaries for all target platforms with minimal duplication. Users shouldn't need to be bash or batch scripting experts to build new targets for all platforms and shouldn't need to test the build scripts continuously on each platform.
<p align="center">A lightweight game engine with minimal dependencies.</p>
### Requirements
* minimize duplicated information
* fine-grained control over compilation settings
* support unity builds
* support hot reloading
* generate scripts that can be used separately
* easily extended
* easy to add new platforms and compilers
* extremely light weight
* easy to customize and extended
* no preference on editor/IDE
* doesn't pretend different platforms don't exist
* entire build system can be understood in an hour
<h1></h1>
Another way of putting it, is we want to focus on what matters to build binaries. Ultimately this is just compiler & linker settings. We don't want to think about the differences in bash/batch syntax.
<p align="center">
<a href="https://github.com/PilotLightTech/pilotlight/actions?workflow=Build"><img src="https://github.com/PilotLightTech/pilotlight/actions/workflows/build.yml/badge.svg?branch=master" alt="build"></a>
<a href="https://github.com/PilotLightTech/pilotlight/actions?workflow=Static%20Analysis"><img src="https://github.com/PilotLightTech/pilotlight/actions/workflows/static-analysis.yml/badge.svg?branch=master" alt="static-analysis"></a>
<a href="https://github.com/PilotLightTech/pilotlight/actions?workflow=Tests"><img src="https://github.com/PilotLightTech/pilotlight/actions/workflows/tests.yml/badge.svg?branch=master" alt="tests"></a>
</p>
### Benefits Over Raw Scripts
Prior to this system, when we were writing scripts directly, we did what every developer does and began overengineering the build scripts to improve things like information duplication, configuration options, etc. However, this led to more compilicated scripts that were harder to debug and heavily deviated between platforms since batch/command are very different in features and syntax. It became hard for newcomers to work on and encouraged differences to creep in between the way individual build scripts worked.
<p align="center">
<a href="#information">Information</a>
<a href="#developer-notes">Developer Notes</a>
<a href="#license">License</a>
<a href="#gallery">Gallery</a>
<a href="#inspiration">Inspiration</a>
</p>
Using pl-build allows the clever/overengineered solutions to be accomplished at a higher level by the user in python. In the end, build scripts are output that are very straight forward and much easier to debug. It also makes it easier to implement new backends to target new compilers, platforms, scripting languages, etc.
<p align="center">
<a href="https://github.com/PilotLightTech/pilotlight-assets"><img src="https://github.com/PilotLightTech/pilotlight-assets/blob/master/images/tooling2.png" alt="Tooling Image"></a>
</p>
### Alternatives
## Information
Under construction.
Keep in mind, **we don't want a build system**. We don't want to hide away details or abstract away control. We ultimately just need a tool to assist in generating the scripts for each platform.
## Developer Notes
Information for developers can be found in the [wiki](https://github.com/PilotLightTech/pilotlight/wiki). This includes:
* [building](https://github.com/PilotLightTech/pilotlight/wiki/Building)
* [contributing](https://github.com/PilotLightTech/pilotlight/wiki/Contributing)
* [style guide](https://github.com/PilotLightTech/pilotlight/wiki/Style-Guide)
What about other CMake (and others)? They are bloated over complicated messes. They are also overkill for what we need (see Requirements section above).
## License
Pilot Light is licensed under the [MIT License](https://github.com/PilotLightTech/pilotlight/blob/master/LICENSE).
## Gallery
<p align="center">
<a href="https://github.com/PilotLightTech/pilotlight"><img src="https://github.com/PilotLightTech/pilotlight-assets/blob/master/gifs/sponza0.gif" alt="Sponza 0" width="2553"></a>
</p>
## Inspiration
This project is inspired by:
* [Omar Cornut](http://www.miracleworld.net/) & [Dear ImGui](https://github.com/ocornut/imgui).
* Casey Muratori & [Handmade Hero](https://handmadehero.org/)
* Turánszki János & [Wicked Engine](https://wickedengine.net/)
* [Sean Barrett](https://nothings.org/) & his [stb](https://github.com/nothings/stb) libraries
* _The Machinery_ before they were abducted
## Documentation
Documentation can be found [here](https://github.com/PilotLightTech/pilotlight/wiki/Build-System).