[fpc-devel] Patches

[Adem]

  On 2010-09-30 06:59, Florian Klämpfl wrote:
> Am 30.09.2010 19:12, schrieb Adem:
>>   On 2010-09-30 19:39, Michael Van Canneyt wrote:
>>> If you want to move the *global variables* (as in: unit scope)
>>> CExportLib,ExportLib to globals, you must add export to the globals unit.
>> Not only do I think they should be moved to globals.pas, I also think
>> they should be fields/properties/methods of, say, TFCPGlobalSettings class.
>>
>> Which, in turn, should be used in the compiler object as a field/property.
>>
>> Doing that does not increase complexity.
>>
>> Just the opposite: the code becomes more decipherable and hence more
>> robust.
>>
>> BTW, removing all these
>>
>> var
>>    CExportLib : array[tsystem] of TExportLibClass;
>>    ExportLib  : TExportLib;
>>
>> procedure RegisterExport(t: tsystem; c: TExportLibClass);
>> procedure InitExport;
>> procedure DoneExport;
>>
>> from export.pas, also enables us to remove 'globals' from the 'uses' of
>> export.pas --which means less convolution to me.
>>
>> What I would like to know is why seem to think this is a bad idea?
> Because it requires that TExportLib with all methods goes into
> globals.pas so we can completely kick export.pas. In the end, we end up
> with one compiler.pas file of 200k lines.
:)

No. I don't think there's that risk.

But, if we're talking specifically about export.pas, there's no reason 
that all of it should go into globals.pas.

But, IMO, there's no reason why these should be in there

   procedure exportprocsym(sym: tsym; const s : string; index: longint; 
options: word);
   procedure exportvarsym(sym: tsym; const s : string; index: longint; 
options: word);
   procedure exportname(const s : string; options: word);
   procedure exportallprocdefnames(sym: tprocsym; pd: tprocdef; options: 
word);
   procedure exportallprocsymnames(ps: tprocsym; options: word);

var
   CExportLib: array[tsystem] of TExportLibClass;
   ExportLib: TExportLib;

procedure RegisterExport(t:tsystem;c:TExportLibClass);
procedure InitExport;
procedure DoneExport;

It is only more logical/sensible to bring together all these 
one-instance global objects into a one-instance global object, instead 
of having them scattered all around the place.