Build architecture

Architecture documentation section of TMC Suite. How the package build is organized: the "shared sources / separate builds" principle, property sheets, the four phases, the two platforms (win32/win64).

The build is a self-contained part of the package architecture. It is built around one rule: shared sources, separate outputs.

1. The "shared sources, separate builds" principle

A single set of source code lives in src/. The two platforms differ only in the output folder:

Libraries — a separate folder for each platform. You must not mix win32 and win64 .lib in one folder: the names coincide, the files would overwrite each other, and linking would break. All win32 → dist/win32/lib, all win64 → dist/win64/lib.

Source code is never duplicated per platform.

2. Property sheets — centralized configuration

Common build settings are extracted into property sheets (build/) rather than written into each project separately. This keeps paths and parameters in one place.

There are no hard-coded paths like D:\work\... in the code or projects — only relative ones through the property sheets. This is part of the architectural portability rule.

3. Project directory structure

TMC_Suite/
├── src/
│   ├── Include/      — shared headers (.h)
│   ├── libs/         — sources of the 6 libraries
│   ├── viewers/      — sources of the 3 viewers
│   ├── kernels/      — sources of the 2 compute kernels
│   └── fieldview/    — FieldView source
├── build/            — property sheets (Common/LibOutput/ExeOutput.props)
├── dist/
│   ├── win32/{lib,bin}
│   └── win64/{lib,bin}
├── samples/SAMPLE_R/ — test data
└── docs/             — documentation (api, build-guide, user-manual, architecture)

4. Build order — four phases

The build is strictly phased. Each phase is performed for both platforms.

PHASE 1 — ALL 6 libraries
   sfile95, complex, exprint, TMCLibError, prepr, TMCIndan
PHASE 2 — 3 viewers
   TMCROS, TMCGROUT, TMC_DN
PHASE 3 — 2 compute kernels
   tmc_rth (H), tmc_rtx (X — requires 6 macros)
PHASE 4 — FieldView (requires OpenGL)

Programs are not built until ALL 6 libraries are ready. The order among the libraries themselves does not matter — each .lib compiles independently (see Dependencies).

The link dependencies that determine the phasing:

• Viewers ← sfile95, complex, exprint
• Compute kernels ← sfile95, prepr, exprint, TMCIndan, TMCLibError
• FieldView ← the same as the kernels, + opengl32, glu32

5. X-mode: configuration through project macros

PlanarRT_X is built from the same sources as PlanarRT_H, but with 6 preprocessor macros set in the project properties (C/C++ → Preprocessor → Preprocessor Definitions):

ELECTRON_Q___
ELECTRON_M___
CTMCRTH_INDANBLCK_FILEY
CTMCRTH_INDANBLCK_RECTSTATY
CTMCRTH_INDANBLCK_CIRCSTATY
CTMCRTH_INDANBLCK_POLYGSTTY

The macros are not added to the shared headers (Typerth.h, Tmcgrviw.h) — otherwise the H-mode and the viewers would break. This is an example of the general principle: build variability is expressed through project settings, not by editing shared code.

6. Two platforms: win32 and win64

Historically the package was built for win16 and win32. The win64 build is a new task that required width fixes in the code:

• pointers do not fit into int → correct integer types;
• LONG → LONG_PTR in MFC signatures;
• no inline assembly (incompatible with x64);
• removal of win16-type remnants.

Porting strategy:

1. First fully build win32 (closer to the original code, simpler).
2. Then switch to win64 and fix 64-bit errors one by one.

Each 64-bit change is recorded in the porting log (docs/build-guide/.../08-porting-changes) with a justification. The computation math is not touched in the process.

7. Build commands

# win32
msbuild <Solution>.sln /p:Platform=Win32 /p:Configuration=Release

# win64
msbuild <Solution>.sln /p:Platform=x64 /p:Configuration=Release

A detailed step-by-step guide is in docs/build-guide/.