Menu
Search

Forums

Forum Index

Thread overview
Call an external program from CTFE
Jun 23
realhet
Jun 24
realhet
Jun 23
monkyyy
Jun 24
realhet
Jun 26
anyaburke
June 23
Gravatar of realhetPosted by realhetReply
realhet
Gravatar of realhet


Reply

Hi,

Is there a way to call an external program from CTFE?

Use case:
Inside a module I want to put some GLSL code.
I also want to generate that GLSL code using CTFE.
And when it's done, it would be nice if I was able to save that GLSL code into a temp file and call the glsl compiler on it.
The goal is that the compiled version of the module would contain also the compiled version of that GLSL shader.
And the time of the GLSL compilation could be the exact same time of the EXE compilation.

This sounds a bit of hacking, but from viewing from a multi-target build perspective, it can make sense. Calling a compiler from another compiler... Why not? :D

The nearest thing I've found is the "include file contents" 'macro', that can be enabled with a command line parameter. (Maybe it's already deprecated, I'm not sure.)

My other way to do this would be an automation inside my IDE. But if something could be done on the language level it's always better than doing it by using external tools.

June 24
Gravatar of Richard (Rikki) Andrew CattermolePosted by Richard (Rikki) Andrew Cattermole
in reply to realhet		Reply
Richard (Rikki) Andrew Cattermole
Gravatar of Richard (Rikki) Andrew Cattermole
Posted in reply to realhet


Reply
On 24/06/2024 4:33 AM, realhet wrote:
> Hi,
> 
> Is there a way to call an external program from CTFE?

No. This is on purpose due to "security" and reproducibility concerns.

> The nearest thing I've found is the "include file contents" 'macro', that can be enabled with a command line parameter. (Maybe it's already deprecated, I'm not sure.)

See above why the string imports was designed that way.
June 23
Gravatar of monkyyyPosted by monkyyy
in reply to realhet		Reply
monkyyy
Gravatar of monkyyy
Posted in reply to realhet


Reply

On Sunday, 23 June 2024 at 16:33:54 UTC, realhet wrote:

>

Hi,

Is there a way to call an external program from CTFE?

Use case:
Inside a module I want to put some GLSL code.
I also want to generate that GLSL code using CTFE.
And when it's done, it would be nice if I was able to save that GLSL code into a temp file and call the glsl compiler on it.
The goal is that the compiled version of the module would contain also the compiled version of that GLSL shader.
And the time of the GLSL compilation could be the exact same time of the EXE compilation.

This sounds a bit of hacking, but from viewing from a multi-target build perspective, it can make sense. Calling a compiler from another compiler... Why not? :D

The nearest thing I've found is the "include file contents" 'macro', that can be enabled with a command line parameter. (Maybe it's already deprecated, I'm not sure.)

My other way to do this would be an automation inside my IDE. But if something could be done on the language level it's always better than doing it by using external tools.

ctfe is intentionally hobbled "for safety"; while theres bugs and edge cases I dont think anyone has a sane way to escape to full execution

realistically you should just write a build script with two stages

fun thought experiment time, if you found a programmable "FUSE"(file system api) database of some sort, mixed -J and -mixin, I think you may be able to call a compiler

June 24
Gravatar of realhetPosted by realhet
in reply to monkyyy		Reply
realhet
Gravatar of realhet
Posted in reply to monkyyy


Reply

On Sunday, 23 June 2024 at 16:46:05 UTC, monkyyy wrote:

>

On Sunday, 23 June 2024 at 16:33:54 UTC, realhet wrote:
realistically you should just write a build script with two stages

fun thought experiment time, if you found a programmable "FUSE"(file system api) database of some sort, mixed -J and -mixin, I think you may be able to call a compiler

Good idea, thx!

The two directions of this communication path could be:

  1. LDC2 -> External process:
    pragma(msg, x) produces specially formatted message to the stdErr, my buildsystem will watch it and will remember 'x'.

  2. External process -> LDC2
    -J, mixin file, using ProjFS on windows.

The ProjFS can block and wait for the external program to complete.

https://dlang.org/spec/expression.html#import_expressions
This is perfectly fits for this. The filename will be: glsl_hash. If there was a pragma(msg) with that hash, the Projected File System will provide it.

June 24
Gravatar of realhetPosted by realhet
in reply to Richard (Rikki) Andrew Cattermole		Reply
realhet
Gravatar of realhet
Posted in reply to Richard (Rikki) Andrew Cattermole


Reply
On Sunday, 23 June 2024 at 16:42:43 UTC, Richard (Rikki) Andrew Cattermole wrote:
> See above why the string imports was designed that way.

I totally forgot the name "string imports". Now I remember, thanks.  That's one data direction of the 2.
June 26
Gravatar of anyaburkePosted by anyaburke
in reply to realhet		Reply
anyaburke
Gravatar of anyaburke
Posted in reply to realhet


Reply

On Monday, 24 June 2024 at 09:52:48 UTC, realhet wrote:

>

On Sunday, 23 June 2024 at 16:46:05 UTC, monkyyy wrote:

>

[...]

Good idea, thx!

The two directions of this communication path could be:

  1. LDC2 -> External process:
    pragma(msg, x) produces specially formatted message to the stdErr, my buildsystem will watch it and will remember 'x'.

  2. External process -> LDC2
    -J, mixin file, using ProjFS on windows.

The ProjFS can block and wait for the external program to complete.

https://dlang.org/spec/expression [url=https://ageofwargame.io]age of war[/url]
This is perfectly fits for this. The filename will be: glsl_hash. If there was a pragma(msg) with that hash, the Projected File System will provide it.

"pragma(msg, x)" is a D language pragma that produces a specially formatted message to the standard error stream (stdErr). This message will be watched by the user's build system.