SYSCONFDIR.imp isn't documented anywhere

[WalterBright]

@dkorpel writes:

Sysconfdir.imp is a file with the location where dmd should look for its 
configuration file, sc.ini/dmd.conf. Some dmd packages wanted to have a 
different location than the default /etc folder, so a string import 
import("SYSCONFDIR.imp") was used so a build script can overwrite that file 
before building dmd. You can't pass string constants on the command line, since 
you're against C's option to make arbitrary preprocessor defines on the command 
line which allows an 'open set' of versions as opposed to a closed set. This 
SYSCONFDIR mechanism works around that limitation.

It's because of this that you need the -J../.. flag by the way, because there is 
no allowed location for string imports enabled by default, which I really 
dislike. I've proposed too loosen this restriction, but ai got some opposition. 
Only OpenD implemented something that allows string imports to read files in 
places where you can already import regular source files, if I recall correctly.

It is incorrectly documented in the compiler source file here:

https://github.com/dlang/dmd/blob/master/compiler/src/dmd/dinifile.d#L61

It should be documented on this page:

https://dlang.org/dmd-linux.html#dmd-conf

[adamdruppe]

Only OpenD implemented something that allows string imports to read files in
places where you can already import regular source files

OpenD's rule for string imports is it defaults to searching for them in the same directory as the source file that imports it. It doesn't search all source directories, it looks specifically in the same one as the module doing the importing. So consider the following:

main.d

import a.thing;
import b.file;

static assert(import("mything") == "main\n");

void main() {

}

mything

main

a/thing.d

module a.thing;
static assert(import("mything") == "a\n");

a/mything

a

b/file.d

module b.file;
static assert(import("mything") == "b\n");

b/mything

b

Three different mything files, but no conflict - each source file sees the import next to it. This was deliberately done so multiple libraries, independently developed, would not be at risk of accidentally hijacking each other's import files. Basically, it treats a string import as an extension of the source file.

[rikkimax]

Two days ago I was discussing on Discord, how having the CWD in the default import paths causes build problems.

I suspect part of the solution would be to do what javac does, if you provide a path, it'll override whatever the compiler defaults to.

Between that and what Adam just suggested, it sounds like a good solution for string imports.

[adamdruppe]

Note that opend does not search source paths. Delete any one of those mything files and you'll get an error:

me@arsd:~/test/strimp$ rm a/mything
me@arsd:~/test/strimp$ opend main.d
a/thing.d(2): Error: need `-J` switch to import text file `mything`
a/thing.d(2):        while evaluating: `static assert(import("mything") == "a\n")`

directing you to use -J if the file lives somewhere else (same as upstream). But I wouldn't recommend this in general; only real use here is if you need to feed data into the library from outside it, and there's better ways to do that (e.g. passing the string as a normal function or template parameter).

But since it never searches, the -I paths, including the CWD or not, are irrelevant.

[ibuclaw]

Two days ago I was discussing on Discord, how having the CWD in the default import paths causes build problems.

Not anymore - cwd is the last place searched, rather than first since

dlang/dmd#21686

[rikkimax]

Two days ago I was discussing on Discord, how having the CWD in the default import paths causes build problems.

Not anymore - cwd is the last place searched, rather than first since

dlang/dmd#21686

I'm aware of the PR, that changes the order, not the fact that it is still a default behaviour that you cannot turn off.

It's the same for string import paths, any path that is provided by the compiler can have side effects that may not be desirable.

[ibuclaw]

I'm aware of the PR, that changes the order, not the fact that it is still a default behaviour that you cannot turn off.

It's the same for string import paths, any path that is provided by the compiler can have side effects that may not be desirable.

I'll likely add a global flag soon, as it's isolated to just two lines now. Will leave it to someone else to add a CLI option for it.