Avoid automatic file saving when starting program

[440bx]

I think it would be very nice to have a service that compiles.

That way, the compiler doesn't need to be loaded for every compile.  The compiler could be "shoehorned" into being suitable as a service but, it would be much nicer if the compiler's code allowed for it to be installed as a service.

That way, at least in theory, it would be possible to do multiple compilations in parallel.  For instance, if the project has multiple release modes, then "Run->Compile many modes" could conceivably use one service per mode.  One way to put those cores to good use.

[Thaddy]

I wonder if it is also possible to "integrate" the compiler into Lazarus, as a package?

Theoretically: yes, based on the same information I provided.

About Delphi: the 32 bit compiler comes as a dll for the ide and dccXXX for the commandline. Both use the same dll (has not always been the case, though). All other platforms work through cross-compilers, just like Lazarus does now, and suffer therefor from the same limitations. The Delphi IDE itself is still firmly win32 windows although there is "being worked on".

If you accept the same limitations Delphi has but minus the win32 tie(after all FPC does not suffer from that), there is otherwise no reason why it can't be done. It can be done and fp is proof.

[RayoGlauco]

it would be much nicer if the compiler's code allowed for it to be installed as a service.

I think it could be an option. I wouldn't want to be forced to install the debugger as a service. In my case, I use Lazarus on computers where I can't install software, and I need Lazarus to remain portable.

[Thaddy]

I think that is a bad idea because services/daemons need controllers for all input/output and that would possibly be quite heavy. And defeats the purpose of a service/daemon. Possibly only feasable for win32 and older windows versions that do not rely on code signing for services or manual rights management.
(What you already can do is run ppc as a cgi on a local or remote webserver)

I think it is a good idea to split-up the thread.

[440bx]

I think that is a bad idea because services/daemons need controllers for all input/output and that would possibly be quite heavy.

Not if it's implemented correctly.  It would be extremely efficient, much, much faster than creating a new process for every compilation.  The communication with the services can be done using memory mapped files... everything in memory = very, very fast.

[Thaddy]

The communication with the services can be done using memory mapped files... everything in memory = very, very fast.

Linux won't allow that and win64 won't allow that too afaik.
Sometimes you are too win32 centric, although you have a huge bag of knowledge.
The case is ownership of memory and execution ring. In modern OS's the mapped memory is isolated and you can not use it for communication.

[440bx]

I have no idea what can and cannot be done in Linux, therefore I'm staying away from that one.

In Windows, there is no problem at all using memory mapped file in services.  No problem using them for communication with other processes.

[Thaddy]

Unless I am mistaken, your development is still firmly rooted in Win32, not Win64 nor e.g. Linux?
And that is a niche, nowadays. (And rather permissive)
My point is that memory mapping can't be shared without explicit permissions in modern OS's of which 32 bit windows is not one. There is a reason for that: isolation.

[440bx]

I've left Delphi 2 behind.   I develop everything on Win64 but, whenever possible, I still make sure the code runs in 32 bit if needed.

[Thaddy]

Fair enough. Then share code for a win64 service that shares memory with a user space app and does not need any raised permissions? Because that is what you are implying.
If you can, I stand corrected, but you likely can't.
And if you can't most others can't either....I will give you that..

Ah, I see, if the service defines that the user group can access defined shared memory, then the user can access that memory without elevation. (But the service needs to adapt SID and DACL for that so the memory doesn't have SYSTEM only.)
BUT I would use pipes or sockets instead.

So it is possible, but you may introduce a security violation.
Although I found a C++ example, I won't use such code.
That said: according to MS it does not violate its best practice.

[JuhaManninen]

That way, at least in theory, it would be possible to do multiple compilations in parallel.  For instance, if the project has multiple release modes, then "Run->Compile many modes" could conceivably use one service per mode.  One way to put those cores to good use.

I think that starting parallel processes is more realistic. Actually it would be very realistic without this FPC feature/bug.
  https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40986

Without the bug the "Compile many Modes ..." menu item in Lazarus could take care of it, instead of starting many LazBuild instances.

[Thaddy]

Let's split the discussion in two:
1. avoiding saves
2. compiler integration like fp (the textmode ide) has into Lazarus.
They are frankly only remotely related.

[JuhaManninen]

Let's split the discussion in two:
1. avoiding saves
2. compiler integration like fp (the textmode ide) has into Lazarus.

... and 3. parallel compilation.

[Thaddy]

fpc packages can already be compiled over multiple threads.
Just in case you forgot...

[PascalDragon]

- The FreePascal textmode IDE has an integrated compiler, so it is not completely unlikely this can be done for Lazarus.

How is it done? The compiler must then be in a form of a library with an API and linked to the IDE.

The text mode IDE directly uses the units of the compiler. And there isn't much API besides "compile file xyz" and some hooks for feedback.