https://issues.dlang.org/show_bug.cgi?id=7044
--- Comment #51 from Martin Nowak <c...@dawg.eu> --- I think requiring a `-confsection` switch limits the usefulness a lot. One reason for the extended ini format is that we can make the linking configurable for certain targets, e.g. m32coff or msvc14 (see [here](https://github.com/D-Programming-Language/druntime/pull/1341#issuecomment-129163526)) without hardcoding those rules in the compiler. This gives packagers the necessary control to adapt dmd to every platform and provide some extras, such as a debug phobos library. Currently it's not possible to select a debug phobos lib solely by `-debug`. We have similar requirements for `m32coff` and VS2015. The other reason is similar but focused on letting the user select different configurations. This is already solved by the `-conf=` switch, but having the compiler match sections would reduce the necessary number of dmd.conf files. We already have a proved implementation to select configurations based on compiler flags and targets. http://code.dlang.org/package-format?lang=json#build-settings Matching "version" identifiers is a generic solution that's both simple and flexible, e.g. it readily allows to match `[Environment-D_HardFloat-ARM_Thumb]` or `[Environment-linux-D_NoBoundsChecks-D_InlineAsm_X86_64]`. Maybe we don't need that much flexibility but `Environment32/Environment64/Environment32mscoff` already don't scale with a adding a second orthogonal switch for [MSVC14](https://github.com/D-Programming-Language/druntime/pull/1341#issuecomment-129168177). > I agree, but I'd like to try this out first to see what the common usage > patterns will be, and then adding those later. If we add them now, we may > wind up with a bunch of useless clutter that we cannot remove because we > don't want to break legacy makefiles. That's a noble effort, but it's already clear that user selected config sections aren't the right solution to ship a debug/profile/msvc14 phobos variant. Also trying to find out usage patterns by providing an inferior feature is flawed, because you don't necessarily get feedback and it might get less or different acceptance as the real feature. In this case the requirements are already know, so if you want to know the usage patterns just ask the packagers that need to deal with dmd.conf limitations. --