= Ybuild – it comes after X but before Z and is not K

Ybuild is intended to be a set of Makefiles inspired by Kbuild for hassle free building of complex projects.

== Conceptual differences to Kbuild

The main conceptual difference is, that Ybuild shall treat multiple product build configurations as first class citizens.

This is in contrast to Kbuild, which is aimed at building a single target (the Linux kernel -- kernel modules are treated as constituents of that single target, that are just linked in later at runtime). User space applications are second class citizens in Kbuild.

== Structure of a (private) project that influences design decisions

Ybuild's design ATM is influenced by the structure of a private, not to be published project of the author, in development at the time of writing this README (Dec 2020). It is hence strongly suggested to understand this structure, before working on or with Ybuild.

The general code structure layout is outlined to strictly reflect the relative installation destinations of the targets. The preferred layout loosly reflects the directory layout of the LSB with category directories, later on referenced by ${CATEGORY}:

  • ./bin/${PROJECT} – user facing executables.
  • ./share/${PROJECT} – non executable runtime data.
  • ./lib/${PROJECT} – code shared among executables of this project.
  • ./libexec/${PROJECT} – internally used executables.

The reasoning here is, that installation of the final product is as simple as extracting the release archive in one of the usual destinations (/opt/${PROJECT}, /usr, /usr/local, C:\Program Files\${PROJECT}, you get the idea).

All source inputs that go into the creation of a release package go into ${BASE}/src.

Contents of ./share may be turned into target dependent intermediaries, for example by wrapping data into object files to link them into the binaries that require them.

Sources for build helper tools, that will not end up in the release package proper are placed inside ${BASE}/src. Following the general category structure is recommended, but not required.

Intermediary build steps go into ${BUILD}/${TARGET}/${CATEGORY} If a build intermediary is target independent (think graphical resources, UI description files, etc.) it goes into ${BUILD}/....

The final results are linked and packaged together into ${INSTALL}/${TARGET}/${CATEGORY}/${PROJECT}.

=== Example project structure and outline of the build process.

1st non executable runtime resources are processed into distribution form. For example textures may be compressed (in a GPU ingestible, compressed format):




Some of these resourced may be wrapped in an object file, so that they can be linked right into the executable binary:



Sources of executable targets are compiled:






Intermediary files are linked/copied into the installation release directory; take note, that the final executables are not considered intermediaries that shall be created in the build directory first. In the same way files that go into the installation destination without intermediary processing are copied there directly from source:



The 48x48 icon in this example is not linked into any binary and is not generated from any intermediaries, so it's created directly from the source.


In this example the libexample-gfx shared library also contains the iconsheet:

${BUILD}/${TARGET}/share/${PROJECT}/textures/iconsheet.dxtc.o ${BUILD}/${TARGET}/lib/${PROJECT}/libexample-gfx.o${INSTALL}/${TARGET}/lib/${PROJECT}/libexample-gfx.{so,dll}

The example-helper links just against libexample-gfx but carries no own resources

${BUILD}/${TARGET}/libexec/${PROJECT}/example-helper-auxiliary.o ${BUILD}/${TARGET}/libexec/${PROJECT}/example-helper-main.o${INSTALL}/${TARGET}/libexec/${PROJECT}/example{,.exe}

Similarly the example application will contain its DXCT compressed icon:


== Q&A / Rationale