www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - D alternative for C/C++ -Dfoo=42

reply "Cherry" <cherry dream.land> writes:
Hello

I want to define an enum int, but I want to make it possible to 
set its value when I run dmd from the command line. Is it 
possible in D?

Regards
Cherry
Feb 25 2014
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tuesday, 25 February 2014 at 12:45:06 UTC, Cherry wrote:

 Hello

 I want to define an enum int, but I want to make it possible to 
 set its value when I run dmd from the command line. Is it 
 possible in D?


No, D does not allow passing values via the compiler command 
line. You can use the -debug=xxx or -version=xxx to enable 
debug(xxx) or version(xxx) blocks.

For arbitrary values, you will need intermediary files. You can 
use the import(filename) construct to read a file from disk 
during compilation, like so:

echo 42 > foo.txt

cat > test.d
import std.conv, std.string;
enum foo = to!int(import("foo.txt").strip());
^D

dmd -J. test.d
Feb 25 2014
prev sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Tuesday, 25 February 2014 at 12:45:06 UTC, Cherry wrote:

 Hello

 I want to define an enum int, but I want to make it possible to 
 set its value when I run dmd from the command line. Is it 
 possible in D?

 Regards
 Cherry


D offers version blocks: http://dlang.org/version.html#version

It would be great if D compiler had a way to substitute enums 
with given values. (This is a nice candidate for a DIP)

Imagine you have a code like this:

module myproggy;
import std.stdio;
enum foo = 5;
enum bar = "walter";

int main() {
   writeln(bar);
   return foo;
}

... and you call compiler like:
   dmd myproggy.d -Dfoo=42 -Dbar=hello

smart, new D compiler would replace enums (iff they exist in the 
source code) with the given arguments, so when you run myproggy, 
you get "walter" as output, and the exit code is 42.
Feb 25 2014
next sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Tuesday, 25 February 2014 at 12:57:51 UTC, Dejan Lekic wrote:

 On Tuesday, 25 February 2014 at 12:45:06 UTC, Cherry wrote:

 Hello

 I want to define an enum int, but I want to make it possible 
 to set its value when I run dmd from the command line. Is it 
 possible in D?

 Regards
 Cherry


 D offers version blocks: http://dlang.org/version.html#version

 It would be great if D compiler had a way to substitute enums 
 with given values. (This is a nice candidate for a DIP)

 Imagine you have a code like this:

 module myproggy;
 import std.stdio;
 enum foo = 5;
 enum bar = "walter";

 int main() {
   writeln(bar);
   return foo;
 }

 ... and you call compiler like:
   dmd myproggy.d -Dfoo=42 -Dbar=hello

 smart, new D compiler would replace enums (iff they exist in 
 the source code) with the given arguments, so when you run 
 myproggy, you get "walter" as output, and the exit code is 42.


And yes, if someone builds multiple modules, he/she would have to 
use fully-qualified name. Example: dmd foo.d bar.d -Dfoo.var1=5 
-Dbar.var4=walter
Feb 25 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Dejan Lekic:


 And yes, if someone builds multiple modules, he/she would have 
 to use fully-qualified name. Example: dmd foo.d bar.d 
 -Dfoo.var1=5 -Dbar.var4=walter


If you are interested in such things I suggest you to take a look 
at how the Fortress language does them.

Bye,
bearophile
Feb 25 2014
parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Tuesday, 25 February 2014 at 13:21:38 UTC, bearophile wrote:

 Dejan Lekic:


 And yes, if someone builds multiple modules, he/she would have 
 to use fully-qualified name. Example: dmd foo.d bar.d 
 -Dfoo.var1=5 -Dbar.var4=walter


 If you are interested in such things I suggest you to take a 
 look at how the Fortress language does them.

 Bye,
 bearophile


No, I am not interested, but thanks. I am interested how D does 
them, or better say how it may do them...
Feb 25 2014
prev sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
 module myproggy;
 import std.stdio;
 enum foo = 5;
 enum bar = "walter";

 int main() {
   writeln(bar);
   return foo;
 }

 ... and you call compiler like:
   dmd myproggy.d -Dfoo=42 -Dbar=hello

 smart, new D compiler would replace enums (iff they exist in 
 the source code) with the given arguments, so when you run 
 myproggy, you get "walter" as output, and the exit code is 42.


I don't like it. I would prefer a CTFE-able counter part to 
boost::program_options that generates thouse enums from a config 
file.
Feb 25 2014
next sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
 I don't like it. I would prefer a CTFE-able counter part to 
 boost::program_options that generates thouse enums from a 
 config file.


If you want a config file, you do not need -D args. You simply 
import() it. Right?
Feb 25 2014
next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
On Tuesday, 25 February 2014 at 13:26:20 UTC, Dejan Lekic wrote:

 I don't like it. I would prefer a CTFE-able counter part to 
 boost::program_options that generates thouse enums from a 
 config file.


 If you want a config file, you do not need -D args. You simply 
 import() it. Right?


Yep, that would be a cleaner solution since it would avoid some 
pitfalls with the current flags proposal: Should those enums be 
fully qualified? What if I put all the source files into a single 
command line (which leads to faster compilation with dmd)? May 
that override enums by accident? Should every enum be 
overwriteable or only those that have a specific UDA etc. etc. ?

And in the end you are using a build tool anyway and you'll put 
your config flags into a makefile or something that then becomes 
an ugly config file.
Feb 25 2014
prev sibling parent "Kagamin" <spam here.lot> writes:
On Tuesday, 25 February 2014 at 13:26:20 UTC, Dejan Lekic wrote:

 I don't like it. I would prefer a CTFE-able counter part to 
 boost::program_options that generates thouse enums from a 
 config file.


 If you want a config file, you do not need -D args. You simply 
 import() it. Right?


or import myconfig; and specify -I path to myconfig.d instead of 
-J path.
Feb 25 2014
prev sibling parent reply "Cherry" <cherry dream.land> writes:
 I don't like it. I would prefer a CTFE-able counter part to 
 boost::program_options that generates thouse enums from a 
 config file.


That would be good.

I would have taken that approach for my current needs, but I do 
not see any way to have a fallback if the config file does not 
exist. I mean mixin import would just fail to compile if the 
configuration file is not present. I need an option to live with 
default values if the configuration file is not there. Something 
like "static if(fileExists!"config.d") mixin(import("config.d")) 
else ...".

Thoughts?

Regards
- Cherry
Feb 25 2014
next sibling parent reply "Cherry" <cherry dream.land> writes:
 I would have taken that approach for my current needs, but I do 
 not see any way to have a fallback if the config file does not 
 exist. I mean mixin import would just fail to compile if the 
 configuration file is not present. I need an option to live 
 with default values if the configuration file is not there. 
 Something like "static if(fileExists!"config.d") 
 mixin(import("config.d")) else ...".



For now maybe I could keep an empty/default config.d somewhere in 
the library source path. And I could use that with multiple -J 
options. This way dmd configuration from the default path unless 
it finds the config file in the user path.

That should be good enough for me. But I believe this could be 
made more friendly.

Regards
- Cherry
Feb 25 2014
parent "Cherry" <cherry dream.land> writes:
Just a few clarifications ....



 For now maybe I could keep an empty/default config.d somewhere 
 in the library source path.


I am creating a DSL (Domain Specific Language) library. I am 
talking about the library src path of my DSL library.


 And I could use that with multiple -J options. This way dmd 
 configuration from the default path unless it finds the config 
 file in the user path.


I figured that DMD will pick import file from the left-most -J 
path it finds the file in. So all I need is a wrapper over 
rdmd/dmd that adds a -J. and -J<default path> (in that order) to 
the user compile command.

Regards
- Cherry
Feb 25 2014
prev sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
 Something like "static if(fileExists!"config.d") 
 mixin(import("config.d")) else ...".

 Thoughts?

 Regards
 - Cherry


--
static if(__traits(compiles, import("config.d")))
{
// import/parse/mixin
}
else
{
// default here
}
--

May be wrapped into a template for more convenience.
Feb 25 2014
parent reply "Francesco Cattoglio" <francesco.cattoglio gmail.com> writes:
On Tuesday, 25 February 2014 at 14:26:13 UTC, Tobias Pankrath 
wrote:

 Something like "static if(fileExists!"config.d") 
 mixin(import("config.d")) else ...".

 Thoughts?

 Regards
 - Cherry


 --
 static if(__traits(compiles, import("config.d")))
 {
 // import/parse/mixin
 }
 else
 {
 // default here
 }
 --

 May be wrapped into a template for more convenience.


I thought that too... And then, when I tried, SURPRISE, it 
doesn't work :S
Feb 25 2014
parent "Francesco Cattoglio" <francesco.cattoglio gmail.com> writes:
On Tuesday, 25 February 2014 at 14:30:23 UTC, Francesco Cattoglio 
wrote:

 On Tuesday, 25 February 2014 at 14:26:13 UTC, Tobias Pankrath 
 wrote:

 Something like "static if(fileExists!"config.d") 
 mixin(import("config.d")) else ...".

 Thoughts?

 Regards
 - Cherry


 --
 static if(__traits(compiles, import("config.d")))
 {
 // import/parse/mixin
 }
 else
 {
 // default here
 }
 --

 May be wrapped into a template for more convenience.


 I thought that too... And then, when I tried, SURPRISE, it 
 doesn't work :S


Ok, MY BAD! It works, but I gave him a folder instead of a file. 
When you give it a folder instead of a file, it still works but 
also outputs an error:
read error, errno = 21
However the "else" branch is still taken. Well, this went better 
than expected!
Feb 25 2014