Prof A Olowofoyeku (The African Chief) wrote:
On 3 Mar 2003 at 23:14, Frank Heckenbach wrote:
[...]
No, it shouldn't. But it should mean "generate a DLL (Windows) or a .so (Unix), as opposed to a .o".
Uhm, well, that's not exactly what I meant with "should *not*". Whether a static or a shared library is built should not affect the source code.
I think we are on very different wave lengths here. But I won't press the issue.
In fact, under Unix it's common for libraries to build both static and shared versions (and I think the same can be done under Windows), and of course, there should be no change required in the source code (just some different options used etc.).
"library foo;" under BP/Delphi always means a DLL. But I am getting confused now about what we are really talking about ;(
And this confusion is probably caused by Borland because they don't properly separate the language definition and implementation details. (I had a look in my BP manuals about units the other day, and noticed the same ...)
AFAIK, under "plain" Windows (i.e. without Cygin/Mingw or similar) there are no static libs (.a), so DLLs are the only kind of libraries (correct me if I'm wrong), and a BP/Delphi library naturally creates a DLL.
But that's an implementation detail and should not be considered part of the language definition.
For an example about units -- the BP manuals state something like the compiled unit is placed in a file whose name consists of the first 8 letters of the unit name (maybe they even said, converted to upper case) plus the extension `.TPU' (in real mode). Surely, everyone who is familiar with the issues would see that the former is a property of the FAT file system, and would not expect a BP compatible compiler to truncate unit file names after 8 characters on systems that allow longer file names. (And even the extension `.TPU' is certainly implementation-specific; GPC and FPC (and probably also other more or less BP compatible compilers) use different names.)
Same here -- we do have two ways of building libraries (*), so we should support them, of course.
(*) On most systems. I'm not completely sure, but I think, e.g., DJGPP doesn't support shared libs (yet). That, of course, means that Pascal libraries can only create static libs (or a set of object files) there ...
So I was talking more about the syntactical and semantical aspects of `library' in BP/Delphi, not the implementation details (which includes how to link them).
Ok.
So what are they like?
I presume you are talking about the BP/Delphi syntax for "libraries". Here is an example:
library foobar; uses bar, baz;
function bar1 : integer; stdcall; begin { blah, blah } end;
function foo : integer; stdcall; begin { blah, blah } end;
exports bar1 index 1 name 'myBar'; {IIRC, "index n" and "name x" are optional} foo index 2 name 'foo';
begin { optional } [...] { optional } end.
Do you have to list all exports explicitly? I.e., they don't re-export everything from the units used automatically? Well then, it actually doesn't seem to have much to do with unit inheritance as I thought ...
Frank