Jump to content
Dave Novo

compiling DCU without creating EXE

Recommended Posts

Hello,

Recently we had to switch to using Project Groups because the delphi compiler ran out of memory, particularly on 64 bit.

We created one project that is a console project, that is basically used to create dcus.

The a second project that uses those dcus, and compiles other dcus as well. This second project makes the actual EXE.

 

Even though the first project is essentially a "dcu generator" and it is an empty console application  (the dpr has a whole bunch of units in the Uses clause, and the following main code)

 

begin
  try
    { TODO -oUser -cConsole Main : Insert code here }
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

It still generates an EXE in excess of 100MB. In addition, the time it takes to link and create the EXE is about 2/3 of the time to generate the dcus. However, we dont even need the EXE from the first project.  Is there a way to just generate the DCUs but not create an actual EXE?

  • Like 1

Share this post


Link to post
8 hours ago, Dave Novo said:

In addition, the time it takes to link and create the EXE is about 2/3 of the time to generate the dcus.

This is also one of the things that bugs me most. There must be a way to speed this up. You just change one line of code and then have to stare at your screen for 15 seconds because everything must be linked again.

Share this post


Link to post
9 minutes ago, Der schöne Günther said:

You just change one line of code and then have to stare at your screen for 15 seconds because everything must be linked again.

Probably, if you move the code to one or more run time packages, it will be faster. You can use run time package just for development. Then if you like, you can disable it for your release to keep one single executable file.

Share this post


Link to post
28 minutes ago, TigerLilly said:

If the DPR had a syntax error in the last line, wouldn´t do this the trick?

@TigerLilly - that was a very clever suggestion! It works to a degree, in that it creates the dcus. But if you select Compile all for the project group, it stops at that syntax error and does not compile the other projects. So I would have to manually trigger the compile for the other project as well. Maybe I could automate that somehow.

Share this post


Link to post

Some googling came up with a few times this question has been asked

https://stackoverflow.com/questions/33936269/how-to-build-a-delphi-project-without-generating-exe

https://community.embarcadero.com/ru/component/easydiscuss/how-can-i-compile-a-project-dproj-file-bypassing-the-linker-without-generate-the-exe-file

 

with no good answer yet.

We started off creating a BPL, but it still takes time to link and create the BPL that we do not need.

 

Share this post


Link to post

It is even possible to compile just pas files with dcc<xxx>. So create a unit that uses all of your units and compile that one.

  • Like 1

Share this post


Link to post
9 hours ago, Dave Novo said:

Recently we had to switch to using Project Groups because the delphi compiler ran out of memory, particularly on 64 bit.

Very interesting. How large your project is?

 

Regarding the subject, you could also split your bucket of units into several projects and build them one after all. Anyway, if it's possible, I'd recommend considering extracting some units into separate subprojects that will be built independently; main project would use their DCU's without rebuilding.

Share this post


Link to post

As @Uwe Raabe already suggested: The commandline compiler dcc can compile single pas files to a dcu.

So you could use a batch file that only compiles the pas files and creates dcus using the command line compiler. You only need to figure out the parameters once and generate that batch file using e.g. the map file of your project(s).

 

No idea whether that would actually speed up the process though.

Share this post


Link to post

Thanks for the tips. The command line compiler could work. The only issue I forsee is how to get all the hints/warnings etc.  if it is done as part of a pre-build batch action

 

Share this post


Link to post

@Fr0sT.Brutal - our project is 2.5M LOC approx. The 32 bit compiler gets up to 3GB but does usually complete without running out of memory. But the 64 bit compiler consistently ran out of memory. What you have described is exactly what we have done. to make it work. But we do not need all the EXE from the subprojects.

Share this post


Link to post
1 minute ago, Dave Novo said:

@Fr0sT.Brutal - our project is 2.5M LOC approx. The 32 bit compiler gets up to 3GB but does usually complete without running out of memory. But the 64 bit compiler consistently ran out of memory. What you have described is exactly what we have done. to make it work. But we do not need all the EXE from the subprojects.

That's weird BTW - IDE seems to run compiler as standalone EXE so it should not eat memory itself. And compiler is 64-bit so it must be able to allocate as much memory as possible including swap.

3 minutes ago, Dave Novo said:

But we do not need all the EXE from the subprojects.

Just don't use them if you don't need

Share this post


Link to post

@Fr0sT.Brutal The compiler is not 64 bit. The compiler is a 32 bit application that generates 64 bit code. In my initial post I described the problem with the EXE.

Share this post


Link to post

IDEFixPack adds a command line option "-x--compileonly" to the compiler. It skips the linker phase, so no EXE, BPL, DLL, MAP and TDS files are created.

But IDEFixPack doesn't exist for Delphi 10.4. So this is no option if you are using the newest Delphi version.

Share this post


Link to post

@jbg - thanks for the tip. We are using Seattle for now, but in the process of upgrading to Delphi 10.4. So this will be useful for a bit. Is there somewhere in the project options you can specify extra command line parameters?

Share this post


Link to post
1 hour ago, Dave Novo said:

per this post, it seems that many of the optimizations from IDEFixPack were ported to Delphi 10.4.2, but not the compileOnly (which is perfect for us BTW).

https://blogs.embarcadero.com/delphi-10-4-2-compiler-speed-improvements/

I wouldn't say "many". I would say "a hand full". But marketing is something else. None of the additional features was added. Actually only the patches that give the most performance boosts in usual cases were applied. (But reading the IDEFixPack source code isn't easy as it is a lot of assembler code)

Share this post


Link to post
17 hours ago, Dave Novo said:

@Fr0sT.Brutal The compiler is not 64 bit. The compiler is a 32 bit application that generates 64 bit code. In my initial post I described the problem with the EXE.

Thanks, I didn't know that.

15 hours ago, jbg said:

But IDEFixPack doesn't exist for Delphi 10.4. So this is no option if you are using the newest Delphi version.

It was opensourced so anyone could try to build it for newest versions

Share this post


Link to post
6 minutes ago, Fr0sT.Brutal said:

It was opensourced so anyone could try to build it for newest versions

DDevExtensions is open sourced, IDEFixPack is not.

  • Thanks 1

Share this post


Link to post

Not sure when it was added, but this compiler option appears to just compile (i.e. omits the linking phase):

-Jc

I discovered this after probing ChatGPT for an answer. The reason why I'm using this option is because I want my CI to just do a compile check in case there's been any boneheaded mistakes in the code, without having it linking to SDKs or other binaries (which can take ages)

Jc = "Just compile"? 😉
 

  • Sad 1

Share this post


Link to post
22 minutes ago, Dave Nottage said:

I discovered this after probing ChatGPT for an answer.

Congratulations.

 

-J* makes the compiler output .obj files instead of dcu files. -JHurrah!NoDCUs works "just as well".

 

-h will tell you all the command line switches. No need to have an AI invent new ones.

  • Like 1
  • Haha 2

Share this post


Link to post

...and was necessary an AI to show (to him) this

how much resources invested for so little return... maybe GPT 4.0 will be more useful.

 😂

Edited by programmerdelphi2k

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×