Delphi Examples - Adding code directory to project screws up dpr

[peardox]

So I was just trying mesh_update and wanted to change the defaults to always use Shader and an 8192x8192 grid (grid takes a while with that many - notable that the framerate halved when I switched to WireFrame as well)

8192 was the only way to get FPS under 60...

Anyway the Delphi projects only include the standalone so the natural way to add in the code directrory contents is to drag then from explorer into the Project Group

Unfortunatly doing this screws up the dpr and you end up with this mess....

uses
  {$if defined(FPC) and (not defined(CASTLE_DISABLE_THREADS))}
    {$info Thread support enabled.}
    {$ifdef UNIX} CThreads, {$endif}
  {$endif}
  uses
  gameinitialize in 'code\gameinitialize.pas',
  gameviewmain in 'code\gameviewmain.pas';

CastleAutoGenerated, CastleWindow, GameInitialize;

Naturally you just need to remove trhe extra uses and it's clauses but it would be far nicer if the project when opened included the code directory so you could modify the code without having to mess around (as per the above IDE grab)

[peardox]

Oh yeah, as this is automated file generation anyway might be nice to also add in the data directory so you can easily edit stuff like animate_mesh.vs - IDE could maybe open GLBs in view3dscene (eventually?)

[michaliskambi]

Indeed, we had a talk about it some time ago on #delphi on Discord -- it seems that when program xxx in DPR is not commented out, then Delphi can handle modifications to DPR without breaking it, and we can also add all used units to DPR too automatically.

This task had to wait back then for other Delphi changes ( https://castle-engine.io/delphi_linux , https://castle-engine.io/delphi_packages ) but it's not blocked anymore, I should test and do it :)

[michaliskambi]

Done - DPR files have now program xxx; clause which seems to be enough to avoid Delphi IDE from breaking it when adding new units.

Note: We do not automatically add all Pascal files to the Delphi project (DPROJ or DPR), as of now. I considered adding them to DPROJ, but Delphi insists on synchronizing this information from DPROJ to DPR, and this means that all listed units would be actually compiled and linked to the project. And in CastleEngineManifest.xml we do not list all project units -- only units paths. So adding all units from paths (like code/) to DPROJ and DPR could result in unwanted behavior

• Any Pascal file, like myunusedunit.pas in code, would have to be compiled and linked to project. Users would be required to rename them like myunusedunit.pas.unused to really make them unused.

• Moreover, it would not correspond to library file, used when compiling for mobile.

  For this reason, in CGE, we recommend to add used units to sthg like GameInitialize, not to the program file. This way the information is equal for all platforms, using program (desktop) or library (mobile).

We add units to Lazarus LPI, but then they are not automatically compiled, only their timestamp is used to provoke recompilation.

[michaliskambi]

Note: We do not automatically add all Pascal files to the Delphi project (DPROJ or DPR), as of now.

I experimented with this more, but in short: I only confirmed above conclusion. We don't add units, like code/gameinitialize.pas , to the Delphi project automatically now. Though you are free to add them manually now to the project, after the above fix -- doing so will not break your DPR.

Details:

I've done one more experiment around this, adding units to DPROJ but not to DPR. It worked, but was pointless -- Delphi doesn't display units in the project panel based on the information in DPROJ, it seems. Only information in DPR matters.

So this is commented out now, with explanatory comment: 5e54686 .

( This is in contrast to Lazarus, where LPI specifies which files are part of the project, but DPR/LPR does not have to repeat them, and so not all listed units have to be linked through DPR/LPR. )