CydandClaude Fable 5
63312e07f9
- BORLAND/: Borland C++ 4.52 (chosen over 4.5 by byte-match: CODE/RP/CW32.LIB
is identical to 4.52's install lib). BCC32/TLINK32/TLIB/MAKE run natively on
Win11; CODE/BT/OPT.MAK is the shipped BTL4OPT.EXE's exact flag recipe
(extender = Borland PowerPack DPMI32, not Phar Lap TNT).
- restoration/source410/: the literal 1995-form reconstruction of the missing
BT game source (never mixed into CODE/). Round 1-3 state:
* 6 of 10 surviving original TUs COMPILE CLEAN under the period toolchain
(BTMSSN, BTCNSL, BTSCNRL, BTTEAM, BTL4MODE, BTL4ARND) - first builds
since 1996.
* BT_L4/BTL4APP.CPP pilot reconstruction: 12/12 functions, Fail() lands on
its binary-recorded line 400 exactly.
* BT/BTCNSL.HPP: console wire IDs recovered from the binary's ctors
(Killed=9, Damaged=10, ScoreUpdate=13, DeathWithoutHonor=15 [T1];
TeamScore=12 flagged [T4]).
* MUNGA/: 8 engine-header backfills back-dated from the BT412 WinTesla tree
(VDATA numbering decomp-verified; AUDREND's OpenAL-era virtual removed -
the period compiler is the drift detector).
* Tooling: backdate.py (WinTesla->1995 header transform), compile410.sh
(per-TU verification sweep under authentic OPT.MAK flags).
* README: corrected roadmap - MECH.HPP is the capstone grown with the mech
TU reconstructions; BTREG.CPP green = the header-family milestone.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
51 lines
2.4 KiB
Plaintext
51 lines
2.4 KiB
Plaintext
Instructions for the IDE example SRCPOOL.IDE.
|
|
//
|
|
// Instructions for SrcPool.IDE
|
|
// Copyright Borland International, 1994
|
|
//
|
|
|
|
This project demonstrates the use of a simple Source Pool by "reference
|
|
copying" a set of source nodes within a project.
|
|
|
|
Source Pools are abstract container objects that hold dependencies.
|
|
Although Source Pools are not buildable and runnable by themselves,
|
|
they can be moved or copied (usually by reference) to real targets. When
|
|
copied, they take on the options and target attributes of the context
|
|
in which they are copied. When the project make facility is checking
|
|
dependencies, or building a response table for linkers and librarians,
|
|
the Source Pool itself becomes invisible and the nodes referenced by
|
|
the Source Pool are seen as a direct dependency of the target.
|
|
|
|
Reference copying allows one node (and all of it's dependencies) to be
|
|
referenced in many different places within the Project Tree. In this
|
|
example we copy a Source Pool by reference to two different targets (a
|
|
16-bit target and a 32-bit target, both called WHELLO.EXE). When you copy
|
|
Source Pool by reference, all referenced copies are automatically updated
|
|
whenever you add, delete, or modify the original Source Pool nodes.
|
|
|
|
NOTE: The example here assumes that you've looked at the example in the
|
|
'MultiTrg' directory and are familiar with creating several targets in a
|
|
single project and setting local options on a target node.
|
|
|
|
To create a Source Pool in an existing project:
|
|
1) Select Project|New Target from the main menu
|
|
2) Type a Target Name
|
|
3) Select 'SourcePool' from the Target Type list
|
|
4) Press OK to confirm your settings and create a SourcePool node
|
|
5) Select that node in the Project window
|
|
6) Press the Insert key to access the Add Item dialog box
|
|
7) Select the files you want to add to the Source Pool
|
|
8) Press OK to confirm your selections and add the dependencies under
|
|
the SourcePool node
|
|
|
|
Once you've created your SourcePool node and dependencies, you can
|
|
copy the node by reference to anywhere in your project:
|
|
While holding down the Alt key, drag the SourcePool node to
|
|
the target node where the Source Pool is needed.
|
|
|
|
More advanced uses of Source Pools include nesting them, which allows
|
|
you to logically group source files without changing their location on
|
|
disk. All nested Source Pools are 'flattened' during target dependency
|
|
checking and creation time.
|
|
|