Cross-unit compiler directive

[Eugene Loza]

Hi all!

I have a main unit and a library unit. (Actually, the stuff is very complex, but let's abstract to easy)
Library unit loads a *.dll library by filename defined in the constant.
I want the possibility to change this constant in the main unit by

Code: [Select]

{$DEFINE filename:='library.dll'}But the documentation says:

The directive {$DEFINE name} defines the symbol name. This symbol remains defined until the end of the current module (i.e. unit or program)
...
Macros defined in the interface part of a unit are not available outside that unit! They can just be used as a notational convenience, or in conditional compiles.

So, the question is: how can I pass a constant to the library unit from the main unit before the program starts? Seems like $DEFINE (and maybe $MACRO ON) is perfect, I just need to share it between units. I need something like "Define global"...

[marcov]

Preprocessor does not carry over units.

This is logical, since the mainprogram is not compiled before every unit to gather these values.

There are two solutions:
1. put the macro in an include file, and include it in every file.
2. define it on the commandline -dmacroname:=xxx;

Unfortunately, there is a bug report out for specifying macros on the cmdline (http://bugs.freepascal.org/view.php?id=27529 ), and I don't know if this will be mergable to 3.x yet.

So the only sure cross version solution would be to define use the include file

[Eugene Loza]

So the only sure cross version solution would be to define use the include file

hmm... doesn't look good.
Maybe there is another way to pass a variable to a library unit before it starts loading external dlls?
I think, that TForm.oncreate will come too late, and the dll will be already 'preloaded' when 'USES' syntax is found.
Maybe somewhere before 'Application.Run;'?

I.e. I want the library unit to be static. No user changes. So that 'include' is a bad option.
But user is able to pass a folder (i.e. different than default) to the dll file (i.e. the folder is user-customizable).

[marcov]

In the case of loadlibrary(), yes.  (see. the "dyn" versions of various database client libraries)

In the case of static linking to the dll, as in

Code: [Select]

procedure xx; stdcall; external 'bla.dll';

Then the "bla.dll" part must be completely defined compiletime. So then you have to rewrite it using the loadlibrary/getprocaddress way. (see again those e.g. postgres3dyn unit in pacakges/postgres/src)

[Eugene Loza]

Thanks! I'll try it as soon as I'll be on windows