Skip to content

aquefir/inbound

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

26 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Inbound

An agnostic software building system.

Inbound

Inbound is a normalisation layer for GNU Make. It is the first stop that good code takes on its run through the developmental quartet; after building with Inbound, it can be packaged with Outbound, distributed with Rebound, and procured with Earthbound—all in an ecosystem-agnostic fashion. In other words, even if you use Inbound alone, you still get the full experience. 😇


Getting started

The way we recommend getting started with Inbound is by procuring it with Earthbound. An Earthbound INI is provided in etc/ to do this.

Alternatively, you can vendor the two necessary sources, prologue.mk and epilogue.mk, from the src/ folder in this repository. Once you have those two files, copy over and open for editing the example Makefile inside etc/. Adjust their include lines so the paths are valid and squadalah, you’re off!

Inbound is structured to keep your main Makefiles as normal and sensible as possible. When you have to change something or compensate for an edge case, things should work all the same – Inbound won’t get in your way.

Host platforms

In general, Inbound is meant to only depend on an operating system that is compliant with POSIX.1-2001. In practise, however, this presently only includes GNU/Linux and Apple macOS, because those are the only POSIX-compliant systems that are also target platforms of Inbound.

GNU/Linux and Apple macOS also have one difference between them: only the former supports Bochs and QEMU user mode, which is required for testing architectures non-natively and running any test suites. Apple macOS is currently required for producing Mach-O binaries, although this limitation may (hopefully) go away in the future.

Target platforms

Inbound should be able to facilitate building native machine code for the following architectures:

  • IA-16 (original 8086 & optionally 8087, i286, i287)
  • IA-32 (i386 & optionally i387, MMX, SSE2)
  • Intel 64 (Nocona/K6 & optionally AVX, AVX2, AVX512)
  • ARMv4T (ARM7TDMI with Thumb-1 interworking)
  • ARMv5TE (ARM946)
  • ARMv6K (ARM11 MPCore)
  • ARMv8.4-A (Apple M1)
  • SPARC V9 (UltraSPARC T1)

Although targeting of the relevant hardware systems is the ideal, a virtualisation (or emulation in the case of IA-16) approach is used. This is only intended to work on Linux hosts. IA-16 with the IBM-PC is supported using Bochs and all other architectures are supported with semi-hosted ELF binaries using QEMU user mode.

The following systems should be targetable on the architectures shown in this table using Inbound:

System Architecture Object code
MS-DOS 6.22 IA-16 none
Microsoft Windows 3.11 IA-16 with i286 PE
Microsoft Windows 4.0 IA-32 PE
Microsoft Windows NT 3.1 IA-32 PE
Microsoft Windows NT 5.2 Intel 64 PE
GNU/Linux with glibc-compat Intel 64 ELF
Nintendo Game Boy Advance ARMv4T ELF
Nintendo DS ARMv5TE + ARMv4T ELF
Nintendo 3DS ARMv6K + ARMv5TE ELF
Apple macOS 10.4 Intel 64 Mach-O
Apple macOS 11 ARMv8.4-A Mach-O

GNU/Linux is targeted with glibc but using musl with its glibc-compat interposer to ensure cross-libc compatibility.

While some systems are more flexible in supporting many architectures, a single architecture has been chosen for each system to keep complexity manageable.

Compiling and contributing

In lieu of proper COMPILING and CONTRIBUTING documents in the project repository’s root, here are some notes about the process:

  • Inbound does not—and should not—employ a build step
    • An emplacement technique is used to update Bitbound as embedded into the Makefile sources; see util/emplbb.py for details
  • A test suite of Hello, World! programs is being developed to ensure the efficacy of Inbound; it will only use Bochs and QEMU user mode
  • Inbound is licenced under the BSD-2-Clause; see the COPYING document for full terms