proto_factory

Proto Factory

An attempt at making a project starter to stop being stuck at this step.

Rationale

I'm currently being stuck at this step in many of my current projects. By trying to make a proper starter kit, I'm trying to unblock myself from this blank sheet block.

• Q: Will there be the [abc] library? A: Only if I'm going to use it.
• Q: Will the libraries be supported A: Not actively, but I'll try to bump up the setups if I'm working on a downstream project.
• Q: Isn't it overkill? A: Definitely so. All my projects are falling in that overkill domain. This one isn't an exception.

Pre-requisites

You will need premake5, your favorite toolchain and eventually download the libraries you'll want to use.

Project structure

The base structure is composed of two projects : core and main. Most of the projects I have seen have a base library for common operations and algorithm. The name will vary on them but for personal reasons, I'm going to stick with "core".

Ultimately, when you're not going to make plenty of libraries to split the codebase into reusable parts, core can act like a common ground between multiple libraries or executables in the same workspace. That's how I envision its usage.

Modules

Somes libraries are vaguely ready-to-use by including the proper module file from the prelude folder and using them as dependencies in your project configuration.

This structure is currently optimized for source-based libraries. Already built libraries aren't supported yet nor are system libraries.

Here's a minimal example of how a library can be easily included once it has its own module.

-- ...
local prelude = require "prelude"
local portaudio = require "prelude.libraries.portaudio"
-- ...

workspace "yourproject"
    -- ...
    portaduio:use "SharedLib"
    -- ...

    project "Main project"
        -- ...
        prelude.link_against_modules {portaudio}
        -- ...

The current module format allows not only to pass to depending projects the public include folders but also pass along defines or platform-specific configuration when needed. It required a bit of repetitive boilerplate, but that'd be an excellent candidate for magic-based refactoring.

Current managed libraries

• PortAudio : because I have plans around generating live audio
  • Clone the git repo into external/portaudio
• PhysicsFS : the ready-toè-use library to easily abstract filesystems
  • Unzip the tarball into external/physfs
• GLM : I don't trust myself enough to rebuild a math lib from scratch.
  • Clone its git repo into external/glm
• LibXMP-lite : I would like to prototype some stuff out of module playback.
  • Download the tarball into external/libxmp-lite
• EASTL : No need to introduce it I guess
  • Download the last release version into external/eastl and last EABase's version in external/eabase

Obviously, more are going to come.