"Pass" parameters to Delphi compiler, from code

[david berneda 52]

Before submitting a jira request ticket, do you think is this a good/useful idea:

 

file: project1.dpr

 

{$PASS -$R+ -DFOO}

program Project1;

...

 

dcc32.exe project1.dpr

 

the compiler starts looking at project1, finds the PASS option and then this is like:

 

dcc32.exe project1.dpr -$R+ -DFOO

 

project wide, to force compiler options that work like if these were in project options.

 

I had an issue with a test project that lost the options, this would never happened if something like PASS existed.

 

 

 

 

[Anders Melander 2096]

24 minutes ago, david berneda said:

do you think is this a good/useful idea

No.

 

Use the existing mechanisms instead (e.g. include files). It adds complexity and I'd prefer they use their limited resources on solving problems that we can't solve ourselves.

[david berneda 52]

But if I have 100 units I need to include the inc in the all 100 of them.

This avoids that.

[david berneda 52]

And maybe the project uses units from different projects, folders, that do not share a common place where I can have my single unique inc file, thus needing multiple duplicate identical inc files, a nightmare to maintain.

[Uwe Raabe 2185]

What about units that change the passed directive values?

[david berneda 52]

The PASS should only be allowed before reserved words program and library.

Its just like if you were passing the params at the command line, before parsing anything.

 

Several compiler params cannot be used inside an inc file. PASS allows everything.

 

Units will still work right they do now, no changes.

 

Edited Sunday at 07:46 PM by david berneda

[Anders Melander 2096]

The main question here should be: What problem does this solve?

 

If the answer is "I once lost the options" then there is no problem - because the solution to that problem is "Don't lose the options".

 

I'm afraid I can't see the use case.

[Lars Fosdal 1904]

@david berneda You could have your "PASS defines" in "dcc_define" in Enviroment variables, but those are global and not per project, AFAIK.
It would have been nice to be able to set those per project.

dcc_define = Eurekalog;FOO;someotherdefine

 

and use ifdef blocks in each unit for that which cannot be set in an .inc file.

[Dave Novo 59]

@david berneda - this is where AI shines. Just fire up claude code and ask it to insert the include directive in a specific spot (i.e. "insert this include statement xxxxx right after the unit specifier at the top of units that start with the letter q in this folder" and it will just do it. 

[david berneda 52]

Yep ! But this is exactly what I was trying to avoid, an inc file that would need to be copied and duplicated because not all units belong to the same projects or products, there is no shared path where to put that inc.

[Uwe Raabe 2185]

On 9/7/2025 at 8:34 PM, david berneda said:

I had an issue with a test project that lost the options, this would never happened if something like PASS existed.

This sounds as if you want a fallback for the case when parts of the dproj file get lost.

 

At the end, implementing your proposal will override the settings in the dproj file and make it (at least partly) obsolete. Especially the different Build Configurations and platform settings are almost meaningless when such options are placed inside the sources.

 

I cant' help, but to me it looks like you want to solve a completely different problem. If I get it right, it is already solved by using version control.

[Anders Melander 2096]

1 hour ago, Uwe Raabe said:

it is already solved by using version control

Exactly