SFD

SFD is a Sun and Amiga program which takes as input a module_lib.sfd
file and emits a bunch of other files:
- .fd file
- prototype file
- pragma file
- BCPL header file
- .asm files and Makefiles to build amiga.lib and rom.lib stubs

SFD is used when make'ing V:lib.

The actual source is V:tools/src/sfd/sfd.l

sfd.l is a "lex" file.  Lex is a pre-processor that adds lexical
parsing features on top of a C base.  Nearly all of the modifications
I've ever had to do to sfd.l concerned the part in C, not lex.  To
make a lex change, get a lex expert, read up on lex, or just follow
the existing form.  The Sun Makefile generates sfd.c from sfd.l,
which is then compiled to make the sfd executable.

I always make sfd on a Sun 2, because compiling it on heartofgold
would mean that the executable won't run on a Sun 2.  This is an old
habit, and in fact Sun-sfd is only run on heartofgold.  So you could
ignore the warnings in the makefile about making sure this is running
on a Sun 2.

V:aug/src/sfd contains the makefile for the Amiga version of sfd.
Note that very deliberately, we don't store sfd.c here, since the
actual source code is sfd.l, and the C version is a derived file, not
to be edited by hand.  Typing "make" grabs the source code just long
enough to compile it.

Native and Sun sfd executables should be kept in sync.

On porting sfd:

One day, we may wish to port sfd fully over, which is to say retire
the Sun one altogether.  This would go hand-in-hand with porting the
V:lib make process native.  The two issues that matter are finding a
compatible Amiga-based lex tool (see the Fish disks), and modifying
sfd to produce Amiga-compatible makefiles for building amiga.lib and
rom.lib.  Remember that sfd actually emits assembler source code and
makefiles to build each module's stubs into amiga.lib and rom.lib, and
it builds ones suitable for the Unix cc compiler and Unix make.

On making .sfd files public:

The compiler vendors would like for us to make the .sfd files public.
From that they could automatically generate the prototypes they ship,
as well as the pragmas or other vendor-specific bindings.  Right now,
they have to do their pragma tagcall stuff by hand, and the prototypes
used to be by hand but now we publish those.  With a public sfd file,
they could write a new tool (sfd2pragma) that would generate
everything they need.

At issue is the fact that the .sfd files we have (and the pragma files
we generate for internal use) contain system-private LVOs.  The sfd
program could readily be extended to emit a public (sanitized) version
with the private stuff cleaned out.  Care should be taken to keep the
the function offsets in step.




See also the ReadMe in V:lib.
