About the compiler (not) finding the DFM files

[GabrielMoraru 32]

So, I have a program that uses the precompiled units of a library.

This:

1. Allows me to keep the Search Paths totally empty (as they should be)
2. Prevents the compiler from keep recompiling the files of the library unnecessarily, saving compilation time.

 

But if the library has DFM files, the compiler will throw that famous "where are my DFM files?" error message.

The "solution" (well, it is not a real solution, but rather a dirty trick) is to (manually or by script) copy the DFM files to the DCU folder of that library.

Four output DCU paths, four copies. What a nasty "solution"...

 

So, did anyone found a more elegant way to solve this?
I see in some old DProj files an entry called <DCC_ResourcePath>, but there is no page in "Project options" or in IDE's  "Tools -> Options" to set that path.

Edited Wednesday at 12:57 PM by GabrielMoraru

[PeterBelow 250]

1 hour ago, GabrielMoraru said:

So, I have a program that uses the precompiled units of a library.

This:

• Allows me to keep the Search Paths totally empty (as they should be)
• Prevents the compiler from keep recompiling the files of the library unnecessarily, saving compilation time.

 

But if the library has DFM files, the compiler will throw that famous "where are my DFM files?" error message.

The "solution" (well, it is not a real solution, but rather a dirty trick) is to (manually or by script) copy the DFM files to the DCU folder of that library.

Four output DCU paths, four copies. What a nasty "solution"...

 

So, did anyone found a more elegant way to solve this?
I see in some old DProj files an entry called <DCC_ResourcePath>, but there is no page in "Project options" or in IDE's  "Tools -> Options" to set that path.

I just add the "library" foms to the project that needs them, this way the required path is in the dpr file uses clause.

Btw.: I think this DCC_RessourcePath is for the resource compiler and you can set it under that node in the Options dialog. Never needed that myself, though.

[GabrielMoraru 32]

> "I just add the "library" forms to the project that needs them"
a) Won't this break the second rule: "2. Prevents the compiler from keep recompiling the files of the library unnecessarily, saving compilation time"?

b) Plus, this way you have to maintain the files twice. If you add/remove a form from your package, you need to manually add/remove it also from all DPR files that use that form.

 

If so, then copying the forms to the binary output (DCU) folder of the library via a post-build script it is still the best "hack".

 

> "I think this DCC_RessourcePath is for the resource compiler and you can set it under that node in the Options dialog. Never needed that myself, though"

I will try that! Thanks!

Edited Wednesday at 01:20 PM by GabrielMoraru

[dwrbudr 8]

Could you please share your PostBuild script and the entire sequence copying those files to the sub-folders.
I've done something similar, but on many libraries msbuild fails under 64-bit mode while compiling the .dproj files under command-line using a bat file.
In Delphi IDE all is OK, but msbuild fails building some 64-bit libraries.

build.bat:

call "C:\Program Files (x86)\Embarcadero\Studio\23.0\bin\rsvars.bat"
msbuild /t:rebuild /p:Config=Release /p:platform=Win32 MyPackage.dproj
msbuild /t:rebuild /p:Config=Debug /p:platform=Win32 MyPackage.dproj

64bit build.bat:

call "C:\Program Files (x86)\Embarcadero\Studio\23.0\bin64\rsvars64.bat"
msbuild /t:rebuild /p:Config=Release /p:platform=Win64 MyPackage.dproj
msbuild /t:rebuild /p:Config=Debug /p:platform=Win64 MyPackage.dproj

This is my postbuild event:

.\..\copyres.bat "$(PROJECTDIR)\..\" "$(PROJECTDIR)\$(Platform)\$(Config)"

 

copyres.bat:

@echo off
for /r %1 %%x in (*.res) do @copy "%%x" %2 /Y > NUL
for /r %1 %%x in (*.dfm) do @copy "%%x" %2 /Y > NUL
for /r %1 %%x in (*.dcr) do @copy "%%x" %2 /Y > NUL

The bigger problem I have is that I need to set some component packages Library path to point to their \Source\ folder (instead of to the precompiled Win32\ and Win64\ .dcu folders) if my program overrides some of the Delphi files like Vcl.Forms.pas/Vcl.Controls.pas, etc.

So my question is: Is there anyway to recompile a component package using custom Vcl.Forms, Vcl.Controls?

[Attila Kovacs 645]

3 hours ago, GabrielMoraru said:

Prevents the compiler from keep recompiling the files of the library unnecessarily, saving compilation time.

Why would it recompile if it hasn't changed? Do you mean when building the app? Why would you build the app so often?

3 hours ago, GabrielMoraru said:

So, did anyone found a more elegant way to solve this?

Yeah, compiling them into binary DFMs would be more elegant 😄

I don't know how many DFMs a library can have, but it's not typical.

 

[Uwe Raabe 2123]

3 hours ago, PeterBelow said:

I think this DCC_RessourcePath is for the resource compiler and you can set it under that node in the Options dialog.

Not quite, that setting is stored as BRCC_IncludePath.

 

DCC_ResourcePath is indeed the correct way to provide the paths to look for the DFM resources. Unfortunately there is no UI to edit that.

 

Manually editing the dproj file adding a node like

        <DCC_ResourcePath>..\lib\Source;$(DCC_ResourcePath)</DCC_ResourcePath>

under the appropriate PropertyGroup will make the DFM files located in ..\lib\source to be found without exposing the PAS files in that folder.

[Uwe Raabe 2123]

RSS-3125: Add Option to edit DCC_ResourcePath

[GabrielMoraru 32]

13 hours ago, Uwe Raabe said:

RSS-3125: Add Option to edit DCC_ResourcePath

1. Since the precompiled DCUs of the libraries should be located via "Library Path" (not via "Search Path") the option to edit DCC_ResourcePath should be a global option not a per-project option. I think your request does not make that clear. 🙂
2. Is there a way to vote for that feature request? In the past we had that possibility. Now it is gone.

 

Edited 18 hours ago by GabrielMoraru

[GabrielMoraru 32]

18 hours ago, dwrbudr said:

So my question is: Is there anyway to recompile a component package using custom Vcl.Forms, Vcl.Controls?

I have seen that done.
Believe me, it is not a good idea! Only nightmare will result from that.

 

If you really want to do it, recompile your changed VCL.Forms unit once to get its DCU the and replace the original Embarcadero DCU with the yours.

 

!!!!!!!!!!!!!!! Please open a separate topic about this !!!!!!!!!!!!!!!

Edited 18 hours ago by GabrielMoraru

[GabrielMoraru 32]

18 hours ago, dwrbudr said:

Could you please share your PostBuild script and the entire sequence copying those files to the sub-folders.

@echo on
xcopy "$(PROJECTDIR)\*.dfm" "$(ProductVersion)\$(Platform)\$(Config)" /Y
xcopy "$(PROJECTDIR)\*.res" "$(ProductVersion)\$(Platform)\$(Config)" /Y
xcopy "$(PROJECTDIR)\*.rc" "$(ProductVersion)\$(Platform)\$(Config)" /Y
echo Copy over

[Uwe Raabe 2123]

6 minutes ago, GabrielMoraru said:

Since the precompiled DCUs of the libraries should be located via "Library Path" (not via "Search Path") the option to edit DCC_ResourcePath should be a global option not a per-project option.

My request is targeting the per project option on purpose, while the global option would probably make sense, too - in addition. Please feel free to add your opinion on that in the comments, best with a concrete example where the current state may fail.

 

Perhaps this per project approach is driven by my personal favor of not contaminating the library path with the paths from the installed components, but add these on a per project basis restricted to the libraries actually used by the project. My projects follow a common folder pattern with a source and a lib folder at the project root and all libraries as sub folders of lib. This allows for similar relative paths in each project to find all the library files.

[GabrielMoraru 32]

Just now, Uwe Raabe said:

Perhaps this per project approach is driven by my personal favor

I did a search for *.dproj and we have here 198 of these files - this means 198 packages and projects.

If I change one of the 3rd party libraries then I have to adapt the rest of the 197 dproj files 😞
This is why I prefer the global Library Path. 🙂 
__________

 

Quote

of not contaminating the library path with the paths from the installed components

Is there something wrong with having multiple libraries into "Library path" ? Or is just a personal preference?

[Uwe Raabe 2123]

Just now, GabrielMoraru said:

I did a search for *.dproj and we have here 198 of these files - this means 198 packages and projects.

If I change one of the 3rd party libraries then I have to adapt the rest of the 197 dproj files 😞

Create an Option Set with the appropriate entries and add that to each project as reference. Then you really have only one place to change that even works when the project is opened in an IDE using another registry key, being another version or residing on a different system - all assuming that the paths actually exist.

 

Quote

Is there something wrong with having multiple libraries into "Library path" ? Or is just a personal preference?

Personal preference and the fact that I work for different customers with different sets of used libraries. I just don't want to clutter the search path with unneeded entries.

Edited 18 hours ago by Uwe Raabe