www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Call an external program from CTFE

reply realhet <real_het hotmail.com> writes:
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.
Jun 23
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
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.
Jun 23
parent realhet <real_het hotmail.com> writes:
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.
Jun 24
prev sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
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
Jun 23
parent reply realhet <real_het hotmail.com> writes:
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.
Jun 24
parent anyaburke <anyaburke63 gmail.com> writes:
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.
Jun 25