It seems, that if I make any change in a unit file, even if it is just a comment, then the change triggers a recompile of all dependent units. In theory, only a relevant change of the interface ABI of a unit would need to trigger a recompile of dependent units. Has this ever been considered (or even implemented) ?

Regards,

Adriaan van Os

I'm currently looking into it.

Mattias

Adriaan van Os via fpc-devel schrieb am
Di., 3. Feb. 2026, 11:28:

That is how it's already supposed to work. Due to reworking in the related parts of the compiler that doesn't work correctly anymore and needs to be fixed.

Regards,
Sven

That's great !

Another question. Has anybody considered running the external assembly (e.g. on macOS) in a separate process ? That would greatly reduce build times of large projects.

Regards,

Adriaan van Os

Adriaan van Os via fpc-devel schrieb am
Di., 3. Feb. 2026, 20:07:

Ehm... The external assembly *is* run in a separate process, that's the point of it being *external*.

Regards,
Sven

You are right, of course. What I mean is — is the compiler waiting for that process to finiish ? It would have to wait before starting the linking phase, but not before starting compiling other units.

Regards,

Adriaan van Os

It would make the logic quite complex.
Not all platforms can handle this, sometimes the internal assembler is used, you have to make sure not to launch 200 assembler processes at once etc. The current approach has the advantage of simplicity.

Traditionally, make is used to parallelize (and fpmake supports it).

Michael.

Adriaan van Os schrieb am Mi., 4. Feb. 2026, 13:46:

The compiler needs to wait for the assembler to exit, it does not have a concept for asynchronously started processes.

Regards,
Sven

Yes, I have been thinking in that direction, create a rule where .o depends on and is created from .s. But then, you need a hardcoded list of units in the Makeffile ?

Regards,

Adriaan van Os

On Feb 3, 2026 at 8:05:08 PM, Sven Barth via fpc-devel <

I'm stuck on a compiler version from 2023 because of this. There were changes recently that caused a regression in performance but are they going to be fixed? Last time I tried to use a new version from 12 months ago already.

I tried to make a reproducible example but failed and gave up. Waiting 5 seconds when changing anything was too much.

We are still working on it. If you follow what happens on gitlab you'll see that extra tests are being added for just this work.

It's not easy, as it means reworking a 25 year old, very fragile, architecture.

Michael.

You could construct that based on the list of .ppu files. The compiler will always write the .ppu files, and they should match the assembler files (unless there are units that have no code, but that can be catered for)

Michael.

Maybe I am simplifying this too much, and likely overlooking something....

But, the assembler generates the .o files => and they should only be needed for linking?

So... if you compile units only (which means no linking), or otherwise stop/defer the linking:
Could you not just wrap the assembler into a small program, that would start it into the background and return to the compiler pretending to be done?

But you can already do this with the -s option.
The compiler generates all needed files, and at the end produces a script that does the assembling and linking.

But in the end, if you want to test, you need to wait anyway till everything is assembled and linked...

Michael.

Yes, that's exactly what I am thinking about.

Regards,

Adriaan van Os