Bug 14681 – Add a way to specify a file import's contents on the command line

Status
NEW
Severity
enhancement
Priority
P4
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2015-06-11T04:40:43Z
Last change time
2024-12-13T18:43:21Z
Assigned to
No Owner
Creator
yebblies
Moved to GitHub: dmd#19003 →

Comments

Comment #0 by yebblies — 2015-06-11T04:40:43Z
C/C++ compilers generally have the ability to set preprocessor symbols from the command line. While dmd's -version=ident covers most use cases, it is sometimes useful to set the symbol to a specific value and access this inside the program. eg -DVERSION=3 With DMD this can be done by creating a file and using -J/import(), but there is no way to set the value directly on the command line. My proposed syntax to extend -J/import() to allow setting a value: dmd -J:key=value main.d Then in the program the import() syntax is used to retrieve the value: static assert(import(":key") == "value"); The ':' prefix allows the compiler to tell apart import paths and key/value pairs.
Comment #1 by yebblies — 2015-06-11T05:02:24Z
Comment #2 by k.hara.pg — 2015-06-11T14:02:56Z
> The ':' prefix allows the compiler to tell apart import paths and key/value pairs. I think it's not good. Indeed in most platform `:` cannot be in file name, but it actually depends on the external file system. Is there more better syntax for the "named import string"?
Comment #3 by yebblies — 2015-06-12T09:50:45Z
(In reply to Kenji Hara from comment #2) > > The ':' prefix allows the compiler to tell apart import paths and key/value pairs. > > I think it's not good. Indeed in most platform `:` cannot be in file name, > but it actually depends on the external file system. > > Is there more better syntax for the "named import string"? I thought ':' would be fairly safe as linux uses it for the path separator, and windows uses it as the drive letter separator. Is there really any risk of someone wanting to allow importing files from a directory whose name starts with ':'?
Comment #4 by bugzilla — 2015-06-12T12:49:38Z
The version feature is deliberately restrictive. Setting variables from the command line is most often a failure to design the code properly. I don't think it is a good idea. Do you have a compelling use case for it?
Comment #5 by yebblies — 2015-06-26T05:59:12Z
(In reply to Walter Bright from comment #4) > The version feature is deliberately restrictive. Setting variables from the > command line is most often a failure to design the code properly. I don't > think it is a good idea. > > Do you have a compelling use case for it? Passing strings in from the command line is sometimes quite useful. Some examples from DMD would be: -J:SYSCONFDIR=/etc/dmd.conf -J:VERSION=2.068 Another would be to easily embed a build id in the binary. The next-best solution is to write these values to a file first, but that brings with it several complications. Sometimes all you need is a short string, and this provides an convenient and safe version of the C preprocessor solution. I certainly don't think this should be used to replace version(), but I think the syntax is enough of a disincentive to avoid that. eg static if (import(":mode") == "something") {}
Comment #6 by robert.schadek — 2024-12-13T18:43:21Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/19003 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB