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.

Hans-Peter Diettrich wrote

Next I'll move ppudump into the compiler, according to Adem's suggestion, so that the dependency show stopper goes away.

The basic issue is that the functionality ppudump happens to depend on must not depend on the code generator. The current build system enforces this rather strictly. Removing the check from the build system so that you can break this separation of concerns is just wrong.

Jonas

Today I provided two new patches for old issues. One covers the preprocessor, which does not even compile in the trunk version (#16888). The other one addresses the initialization of the class type variables for node classes (#17516). Now I hope that these fundamental patches will be applied soon.

Next I'll move ppudump into the compiler, according to Adem's suggestion, so that the dependency show stopper goes away.

BTW I couldn't find "patches" and "features" lists, as exist for Lazarus. Any hints?

DoDi

Jonas Maebe wrote

The basic issue is that the functionality ppudump happens to depend on must not depend on the code generator. The current build system enforces this rather strictly. Removing the check from the build system so that you can break this separation of concerns is just wrong.

When I look at its description [
http://www.freepascal.org/tools/ppudump.var ] ("ppudump writes the contents of a Free Pascal unit file to standard output. It gives a listing of all definitions in the unit file. The format of the listing can be controlled by the options.") it's not clear to me why ppudump must be a strictly independent stand-alone executable.

Could you elaborate why you think it should be.

Cheers,
Adem

Adem wrote

it's not clear to me why ppudump must be a strictly independent stand-alone executable.

I did not say that it must be a stand-alone executable. I said that it must not depend on the code generator (whether it's inside or outside the compiler is irrelevant to that point). And the reason I said that is because Hans-Peter's wants to move it inside the compiler so that making ppudump depend on the code generator would no longer break the build.

The basic problem is that his rewrite made ppudump dependent on the code generator, not that ppudump's independence of the code generator is enforced by the build system.

Jonas

Could it not be the other way around?

That, it turned out that ppudump wasn't as independent as had been thought?

The compiler doesn't think, it just gives an error when a unit is not found.

Hans-Peter tried putting global variables from all over the compiler into a single unit, so it's logical that this makes everything dependent on everything (because that single globals unit has to import type definitions from all over the compiler).

Jonas

I don't see why bringing together all the globals together should make everything dependent on everything else; after all 'globals' are those variables/routines that are common to all.

Actually, if I were DoDi, I'd probably bring all those units (that do nothing but declare various types and constants) in the uses secions of globals.pas into globals.pas.

Such as version.pas, globtype.pas, systems.pas, cpuinfo.pas, and probably a few more.

These units either use no other units, or use no units that globals.pas doesn't.

In order for globals.pas to be a proper global unit, I'd bring copy paste those units into globals.pas.

And then remove/delete tose superfluous units.

I think there is a misunderstanding: 'global variables' 'globals'.

He meant variables that are not part of an object, but declared as a unit variable. If you put all such 'global' variables in 1 unit, you do drag in all the original units, if the variables are typed.

Michael.

True. 'Globals' include 'global variables', structures and routines.

He meant variables that are not part of an object, but declared as a unit variable. If you put all such 'global' variables in 1 unit, you do drag in all the original units, if the variables are typed.

I checked the following units used in globals.pas.

-- version.pas
Uses no external units. Comprises of a few type/constant declarations.

-- globtype.pas
Uses no external units. Comprises of a few type/constant declarations.

-- systems.pas
Uses some external units, all except one is already used in globals.pas. The only extra unit is {$ifdef FreeBSD},SysCtl,{$endif} which could easily be added to the uses section (or the body) of globals.pas.

-- cpuinfo.pas
Uses no external units. Comprises of a few type/constant declarations.

IOW, all these units could be combined into globals.pas

[ Curious: Why does every unit here has .pas extension but SysCtl ( .pp extension)? ]

Cheers,
Adem

You still don't understand.

take the unit export. It contains:

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

If you want to move the *global variables* (as in: unit scope) CExportLib,ExportLib to globals, you must add export to the globals unit.

Michael.

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?

Further, I think the NoGlobals brach is a very good starting point before moving on to multiple front-ends etc.

Cheers,
Adem

:)

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.

I hope you are joking ...

I have read the above sentence (of mine) a few times over; and I seriously cannot see why I should be expected to be joking.

Could someone tell me what advantage there can ever be in/of having global variables scattered all around the place.

2010/9/30 Adem :

Well, global variables are going to be all over the place and will be declared in the scope of the unit where they are established. It establishes their "belonging" in the unit/module in which they are/were declared :-)

I think that the assertion of taking variables (just because they are global) and placing them in one unit file is indeed funny.

Don't forget that part of the purpose of ppudump is also to get a second "opinion" on a PPU file.

It's hard to spot the real topics, that make ppudump so problematic. But it's easy to incorporate ppudump into the compiler, I just did it and will provide the according patch today.

During that work it turned out that precding hacks make ppudump hard to maintain. In detail some enumerated types are already out of sync, with different versions in ppudump and the original units (symconst...). I've limited the patch to remove only identical type declarations, constant arrays and procedures, that are no more required when the original units can be used in ppudump. Later the string arrays, describing the ordinals, can be moved into the units defining the enums. This will allow for better maintenance of these types, and for better error messages or other debug output, wherever required.

Like with the preprocessor, the ppudump functionality can be invoked with a dedicated commandline option (e.g. -P), that is handled in Compiler.Compile() as well.

During my work I also came across a recompilation problem. Sometimes the new ppudump unit is not recompiled after modifications, eventual syntax errors only turned out when pp was recompiled by the new compiler and -B. Does this ring a bell?

DoDi

So, from what you're saying, I am supposed to think that it is better to declare global variables in 460+ unit files in the compiler directory alone.

It establishes their "belonging" in the unit/module in which they are/were declared :-)

?

I think that the assertion of taking variables (just because they are global) and placing them in one unit file is indeed funny.

I'll remember this joke when I am writing the next Pascal code and declare my variables not at the top of each class/routine but right where they are needed and all over the place ;)

The basic problem is that his rewrite made ppudump dependent on the code generator, not that ppudump's independence of the code generator is enforced by the build system.

Then *ppudump* must be hacked further, since the currently present workarounds (not using symconst, globtype, systems and other compiler units) turned out to be insufficient.

Perhaps e.g. the Globals unit has to be split into one general part, with no possible code generator dependencies, and one part with variables that may introduce such dependencies. But this IMO is fruitless work, when ppudump can be incorporated with almost no negative impact into the compiler itself.

DoDi

Consequently the compiler can not know about the reasons of such dependencies, and can not be used to judge what's the cause and what's only symptoms of the disease.

Hans-Peter tried putting global variables from all over the compiler into a single unit, so it's logical that this makes everything dependent on everything (because that single globals unit has to import type definitions from all over the compiler).

You know that this is *not* true :-(

My last attempt, to move all *remaining* global variables into dedicated units (with/out cg dependences), only was an intermediate solution, in order to just figure out these dependencies. Once all evitable global variables have been elimited, there remains nothing that could introduce unwanted dependencies.

DoDi

Correct me if I'm wrong, but isn't this exactly the opposite of what you were doing, i.e. putting all such variables in globals.pas ?

Michael.

Then what about moving those variables to the units where they belong? That might be a starting point of which the solution might be easier applied to trunk (not only in the sense of merging, but also in the sense of "discussion with core developers about usage"). ^^

Regards,
Sven

He meant variables that are not part of an object, but declared as a unit variable. If you put all such 'global' variables in 1 unit, you do drag in all the original units, if the variables are typed.

Every external tool has to drag in all the units, that initialize the used global variables, regardless of their placement in globals.pas or other units. Consequently all global variables should reside in those units, that contain their initialization code. Doing so may increase the number of units, that have to be used in *all* other units, be internal or external, but it would provide the supposed consistency of the unit dependencies - automagically, with no need for further considerations or discussions.

When ppudump has to use globals.pas, this is a general misdesign. I wonder why e.g. pendingstate resides there, when used exclusively by the scanner, or init_settings and current_settings, which are meaningful only to the compiler and have to be initialized by code somewhere else. That's not a problem inside the compiler, which uses all related units, but then all global variables for external use should reside in an different unit, not in the compiler specific globals unit.

DoDi

Then what about moving those variables to the units where they belong?

Huh? Wasn't this exactly what I did in the NoGlobals branch?

That might be a starting point of which the solution might be easier applied to trunk (not only in the sense of merging, but also in the sense of "discussion with core developers about usage"). ^^

Right. Perhaps we should restart the discussion in an new thread, to reduce the current confusion?

DoDi

I feel an urgent need to clarify what we are talking about :-(

When you (everybody, please) inspect the NoGlobals branch, in detail the *release candidate* (around r15858, see README.txt), then I only had moved global variables *out* of globals.pas. This was my initial approach, that should be discussed. Later revisions stem from various attempts to identify and cure the ppudump problem.

DoDi

I'm sorry... I didn't take a look at your branch, so I based my mail on the knowledge I gained from the mailing list, which seems to have been wrong.

Might be a good idea.

Regards,
Sven