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

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

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.

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

> 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.

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

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...

>
> 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?

>
> 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

> 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