Getting source code updates and rebuilding FreeBASIC
 

This page describes the normal rebuild path after updating a source checkout.

To download updates made available in the fbc Git repository, use your preferred Git tool, or run:

git pull --ff-only

To inspect incoming changes before applying them:

# Update remote branches
git fetch

# Review the remote history with your preferred Git viewer.
gitk --all

# Merge the remote branch when you are ready.
git merge origin/master

Which rebuild path should I use?

There are now two common rebuild paths:
  • Use make directly for normal developer builds from an already prepared checkout.
  • Use a script from build_scripts/ for platform packaging, release builds, cross-builds, VM builds, emulator-based checks, or installer tests.
The direct make path is still valid, but it is no longer the whole build story. The top-level GNUmakefile is now a small entrypoint that loads the modular build system under mk/. The scripts in build_scripts/ sit above that make system and drive the platform-specific workflows.

Normal native rebuild

For a native development build on a system that already has a usable compiler or bootstrap state:

make print-config
make prereqs-fbc
make -j$(nproc)

Some systems use gmake instead of make. The package and VM scripts choose the right command for the platform where practical.

make print-config is the first thing to check when a rebuild does something surprising. It shows the resolved target identity, compiler tools, feature policy, and layout decisions. make prereqs-fbc checks whether the build has a usable compiler or bootstrap path before the real build starts.

If you use build options on the command line, pass them again on later rebuilds unless they are stored in config.mk:

make -j$(nproc) ENABLE_STANDALONE=1

When to clean first

A simple rebuild is usually enough after ordinary source edits. Clean first when switching targets, changing toolchains, changing major feature policy, updating generated bootstrap sources, or after source files have been renamed or removed:

make clean
make -j$(nproc)

The old DOS/DJGPP warning still matters, but it is no longer the only reason to clean. DOS is especially sensitive to stale objects because command-line length limits force parts of that build to rely on object wildcards. A clean rebuild is the safe choice after source graph changes.

Build scripts

Use build_scripts/ when the job is more than a simple local rebuild. The scripts are the supported entrypoints for the release and platform workflows.

Examples:

./build_scripts/debianubuntu-build-freebasic.sh --help
./build_scripts/msys2-build-freebasic.sh --help
./build_scripts/macos-build-freebasic.sh --help
./build_scripts/freebsd-vm-build-freebasic.sh --help

The folder also contains matrix builders, cross-build helpers, VM builders for the BSD and Solaris-like targets, Windows/MSYS2 installer builders, Android/JavaScript/Xbox/Wii builders, package-test runners, and smoke-test wrappers. Prefer those scripts for producing redistributable packages because they know the staging layout, bootstrap archive names, dependency setup, and per-target test flow.

Modular make system

The make system is intentionally split by responsibility. In broad terms:
  • mk/platform.mk resolves the target OS, CPU, runtime key, and package naming.
  • mk/platform-features.mk and mk/feature-policy.mk decide which features are enabled.
  • mk/compiler-config.mk, mk/toolchain-flags.mk, mk/host-tools.mk, and mk/os-flags.mk choose tools and flags.
  • mk/layout.mk and mk/build-layout.mk define install-tree and in-tree paths.
  • mk/source-graph.mk and mk/archives.mk decide what gets built.
  • mk/build/*.mk contains the actual compile, archive, dependency, target, and clean rules.
  • mk/bootstrap/*.mk owns compiler recovery and bootstrap source emission.
  • mk/tests*.mk and mk/tests/**/*.mk own build-system verification targets.
  • mk/inst_uninst.mk owns install, uninstall, and simple package payload layout.
For a more detailed map, read mk/README.md and mk/File-Map.md in the source tree.

Bootstrap notes

A rebuild needs either a runnable fbc or suitable bootstrap sources. The build now checks that state early instead of failing later with a malformed compiler command.

Useful bootstrap commands:

make prereqs-fbc
make bootstrap-minimal
make bootstrap-seed-peer

Use bootstrap-minimal when current-target bootstrap sources already exist. bootstrap-seed-peer is a manual recovery tool for bring-up work when an appropriate peer bootstrap is available; it is not part of the normal default build.

Most platform build scripts handle the bootstrap setup for their package workflow. If you are building a release package, start with the appropriate script before falling back to manual bootstrap commands.

Useful test targets

After a rebuild, useful high-level checks include:

make sanity
make quick-test
make compiler-smoke
make bootstrap-emit-test

Platform scripts may run stronger or more specific checks than these make targets, especially for installers, cross-build packages, VM targets, browsers, emulators, graphics, and sound.