[fpc-pascal] optionally uses a unit

Mark Morgan Lloyd markMLl.fpc-pascal at telemetry.co.uk
Mon Nov 18 11:18:06 CET 2013

Tomas Hajny wrote:
> On Mon, November 18, 2013 07:38, Xiangrong Fang wrote:
> Hi,
>> Is it possible to optionally use a unit? e.g.
>> unit myunit;
>> uses {$ifexists persist.pas}persist,{$endif} Classes;
>> type
>>   TMyClass = class
>>   public
>>     {$ifexists persist.pas}
>>     procedure SaveToStream(s: TStream);
>>     {$endif}
>>   end;
> Isn't {$IFDEF PERSIST}... combined with calling the compiler with/without
> -dPERSIST depending on availability of the source sufficient (and more
> general)? Obviously, you can test availability of the source file in a
> makefile/shell script/batch file/... and have the -dPERSIST added to
> compiler options accordingly.
> BTW, your example (and partly the whole concept) might give
> unexpected/unwanted results - what if a precompiled version (.ppu/.o) of
> that unit is available but not the source file? Which directories should
> be checked when searching the file (note that the compiler couldn't know
> if the filename mentioned should belong to a unit source file, specific
> include file, compiled object, library or even a completely independent
> file, and that different search paths are used for searching files of
> different types)?

There are definitely hazards, but I think that an exists() predicate of 
some form would definitely be useful. For example, inside an {$ifdef 
persist} it would give the developers the ability to have a tailored 
error message advising the maintainer that if persists.pas didn't exist 
he should also get such-and-such a project from local svn, and set up 
appropriate symlinks.

The major issue would be directories and search paths.

Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

More information about the fpc-pascal mailing list