add -conf=path compiler switch

[MartinNowak]

No description provided.

[MartinNowak]

See the references above for how people struggle with the current behavior.

[braddr]

A reasonable case can be made for just about any ordering. I don't think this change is categorically better than the current one. An argument could probably be made for ordering along with a policy/procedure for merging, but even that's fraught with fun.

Or, hrm.. never tried it, but can you do something like DFLAGS=$DFLAGS -Inewdir in dmd.conf right now?

For the sake of testing and guaranteed consistency of them, a command line parameter to point to the config file to use would probably be best. Assuming it also overrides any other search and internal defaults.

[WalterBright]

People tend to "fire and forget" their dmd.conf. Changing the search order will unexpectedly break things for them. It's like changing the way make works - what a disaster that is for people who cut&paste their makefiles with no understanding.

[yebblies]

This order makes more sense, because you want to configure different
compilers so the configuration should be attached to the compiler not
your current working dir.

On the other hand, sometimes you want to override sc.ini for a local project. I'm not sure what the best way is, but it's really annoying not being able to use a specific config file.

[MartinNowak]

A reasonable case can be made for just about any ordering.

No it can't, it's an installation time configuration for the compiler. That doesn't change when you cd into another directory. The current search order is nonsense because it favors using the same configuration for multiple compilers over using specific configurations per compiler.

On the other hand, sometimes you want to override sc.ini for a local project.

That's what you'd use a compiler switch for that specifies an alternative configuration.
Picking up the conf of the current directory means it will be used by any different compiler which leads to the know trouble.

People tend to "fire and forget" their dmd.conf. Changing the search order will unexpectedly break things for them.

Yeah, I'm also worried about that. Now I wonder who uses the current search order to override it's configuration. We could detect that and ask the people to move the config files.
And we should still add a switch to the compiler to select a specific config.

[yebblies]

That's what you'd use a compiler switch for that specifies an alternative configuration.

Sure, if we had one.

And we should still add a switch to the compiler to select a specific config.

Yes please.

[ghost]

And we should still add a switch to the compiler to select a specific config.

That would probably be the best solution.

[MartinNowak]

I'm search for both the new and the old order. If there is a mismatch an informational warning is printed, advising people to use the newly added -conf=path switch to select a non-standard configuration.

Once again the old order is culprit for many dmd.conf related issues, because it doesn't make sense that my installed compiler picks up a different config file depending on where I am.
Note that it's still possible to override the config of the system wide dmd by adding a dmd.conf in your HOME folder.
The current working directory will only be used as last resort, because you do not want to configure all compilers on a per project base.

[WalterBright]

because it doesn't make sense that my installed compiler picks up a different config file depending on where I am.

It seems obvious to me that when I am in my project directory, that it picks up the config file from that directory. I use it all the time.

Anyhow, a compiler flag sounds fine, but not a redo of the order and the attendant confusion and breakage that will cause.

If there is a mismatch an informational warning is printed

That just seems like layers of more complexity.

[andralex]

I disagree with the proposed order; local stuff should override global stuff. So things are good as they are. To override the global stuff just create a local conf file.

I'm okay with adding a flag though I see all this unnecessary churn and the illusion of progress because a simple and effective solution is available.

[MartinNowak]

I disagree with the proposed order; local stuff should override global stuff.

Yes, local to the compiler you're using.
Anyhow can't seem to convince anyone, so I'll just add the flag.

[MartinNowak]

Now it's only the -conf=path switch. I also left in the additions to error.c.

It seems obvious to me that when I am in my project directory, that it picks up the config file from that directory. I use it all the time.

It's obvious for things that you want to configure on a per-project base, like say which compiler version to use. But it doesn't make sense to use the same compiler configuration for every compiler.
And because @P is relative to the dmd.conf path, you'd have to hardcode phobos and druntime. How is that useful? It makes it impossible to compile the project with different dmd compilers.
And what is it that you're actually configuring? DFLAGS?

You're configuring the compiler not your project, therefor you need to lookup the config file from where the compiler is installed not from where your project lives.

[andralex]

what's "run" doing here?

[MartinNowak]

In dmd -run myprog.d -conf=dmd.conf the -conf=dmd.conf argument belongs to myprog.

[andralex]

If -conf= is passed without an argument, will that make dmd to use no conf file at all?

[yebblies]

Don't add these if they're not used.

[MartinNowak]

I already needed them earlier and it just makes the API consistent.

[MartinNowak]

If -conf= is passed without an argument, will that make dmd to use no conf file at all?

Good idea, added that.

[andralex]

unnecessary return at end of function

[andralex]

Auto-merge toggled on

[MartinNowak]

tl;dr, please reconsider changing the conf order or splitting the conf file

That dmd.conf is driving me crazy.

I need a dmd.conf in my dmd repo, so that I can use dmd-master. It wouldn't work without a config and putting dmd.conf anywhere but near dmd itself overrides my system dmd.conf.
That setup worked nicely for me although some of you guys seem to have a dmd.conf in your home dir (why?).

Now that we require a host D compiler to build dmd it no longer works, because the dmd.conf for my dmd-master overrides the system wide dmd.conf of my host dmd.
Why would my system dmd need a different configuration just because I am in a different folder?
It doesn't, it still uses the same phobos (the system wide) and still requires the same linker switches.

Setting HOST_DC is a workaround but is impractical, because it requires an awkward env HOST_DC='dmd -conf=/etc/dmd.conf' make -f posix.mak to work.
Requiring dmd -conf=/etc/dmd.conf in order to not pickup some random conf file is crazy. It's not portable either, because the config is somewhere else on each platform.

We learned the same from dlang.org dlang/dlang.org#758 (comment), adding the -conf= switch didn't solve the actual problem and created new ones.

It might seem intuitive, that a local configuration should override a global one, but it's a false friend here, because the configuration should be local from the perspective of the compiler, not from the perspective of the user.

In fact the config is so tied to the compiler that we could almost compile it into the compiler (like gcc does with it's spec). At best it's something package maintainers need to touch to accomodate platform differences, but it's not a user configuration file.

If people use it to configure DFLAGS and such project dependent stuff, then we need to split the configuration file, into one part that tells the compiler where to find druntime/phobos and how to link, and one part that can be used for per-project configuration of compiler arguments and env variables.
IMO the latter is better kept in makefiles/dub.json though.

conclusion

The lookup order for the config file should be changed to the following.

• next to dmd binary (highest precedence so that I can have multiple installations)
• per-user conf folder (HOME) (to override the system-wide config)
• system-wide conf folder (to allow package installations .deb/.rpm)

The current situation is unmaintainable.