4 ms·

Because config.h, for whatever reason (possibly to make more easily human-editable), is created in the top-level directory.

CaliforniaKarl 7y ago
It's where autoconf, when told to write out a config.h, typically puts the file. See https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Configuration-Headers.html#Configuration-Headers https://www.gnu.org/software/autoconf/manual/autoconf-2.69/h... for more info.
- ncmncm 7y ago
  So, fix autoconf, if you can't retire it. It is actionably hazardous to require that a directory that contains random files be in the include path. But I'll bet it doesn't; it is probably just the lazy choice. That said, there is no requirement at all that "#include <version>" must pick up a file called "version" (of any case). The compiler could prefer a file called "version.standard-header", if it exists, or "std/version"; or, things in <> brackets could be looked up on a different list, such as one designated by "--isystem" (which does already exist). There doesn't need to be such a file at all -- the standard just says what names must be found to be defined after that point in the code. The compiler can Just Know. Or, it can recognize just Standard header names, and get them somewhere special. Which is why we don't bother about this in committee. Doing the dumb thing is dumb, no matter what we say. Do the smart thing, and trouble evaporates. I always thought it was mad that compilers shipped with standard header files that had exactly the name as appears in the standard, and that preprocessors shipped that favor or require such. If you need for the files to have exactly those names, define a cpp option naming a file with a list of them, and exactly where each is.
  - emn13 7y ago
    Standards evolve. There's value in keeping things simple and consistent to allow that. So it'd be a cost to have specifically version treated exceptionally here, and it'd be a cost to have system headers treated very differently from other headers (because it makes it harder to extend the system). So while it makes sense that system headers needn't be files - in principle - it sounds like a pretty big change too with some downsides as well. All that just for "version"?
    - ncmncm 7y ago
      Not for <version>, or just for <version>. Rather, for being able to designate header names without worry about what files have been shoveled into random directories. It really is on the compiler implementers for not providing a better accommodation to this very predictable problem. That said, fixing the autoconf scripts may be the most immediate route to sanity for the "config.h" / <version> case, eliminating the problem at its source.
      - a1369209993 7y ago
        > for being able to designate header names In other words, there's no reason why '#include <foo>' should ever be looking in the translation unit's directory; that's what '#include "foo"' is for.
        ncmncm 7y ago
        I bet autoconf actually says "-I $top_level" or some such. What's mad is that -I controls where <> names are searched.
        kazinator 7y ago
        I concur. -I is a traditional option from Unix compilers with a very silly behavior; but for years now we have had something called -iquote in gcc (and clang). Before -iquote, there was -I- which is deprecated.
    - kazinator 7y ago
      There is value in not telling your compiler to look for all headers in your project root. There is no telling what clash that will create. Documented, public <> headers include other headers that are not documented. There is no telling what their names are.
      - emn13 7y ago
        sure, no question - but that's out of the standards body control. And even if you don't include your own top-level dir, using a common file name might clash in other dirs too. Hoping that compilers would not resolve headers via user-specifiable directories sounds absurd to me - every single compiler I know of allows that, not just on unix, so if you want to retire that, that's going to be huge, multi-year effort. No point in considering that hypothetical reality when it comes to meaningful header names unless there is a reasonable likelihood of that happening. Not objecting to such a push; it just sounds wildly out of scope when picking a header file name.

CaliforniaKarl 7y ago

It's where autoconf, when told to write out a config.h, typically puts the file. See https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Configuration-Headers.html#Configuration-Headers https://www.gnu.org/software/autoconf/manual/autoconf-2.69/h... for more info.

ncmncm 7y ago
So, fix autoconf, if you can't retire it. It is actionably hazardous to require that a directory that contains random files be in the include path. But I'll bet it doesn't; it is probably just the lazy choice. That said, there is no requirement at all that "#include <version>" must pick up a file called "version" (of any case). The compiler could prefer a file called "version.standard-header", if it exists, or "std/version"; or, things in <> brackets could be looked up on a different list, such as one designated by "--isystem" (which does already exist). There doesn't need to be such a file at all -- the standard just says what names must be found to be defined after that point in the code. The compiler can Just Know. Or, it can recognize just Standard header names, and get them somewhere special. Which is why we don't bother about this in committee. Doing the dumb thing is dumb, no matter what we say. Do the smart thing, and trouble evaporates. I always thought it was mad that compilers shipped with standard header files that had exactly the name as appears in the standard, and that preprocessors shipped that favor or require such. If you need for the files to have exactly those names, define a cpp option naming a file with a list of them, and exactly where each is.
- emn13 7y ago
  Standards evolve. There's value in keeping things simple and consistent to allow that. So it'd be a cost to have specifically version treated exceptionally here, and it'd be a cost to have system headers treated very differently from other headers (because it makes it harder to extend the system). So while it makes sense that system headers needn't be files - in principle - it sounds like a pretty big change too with some downsides as well. All that just for "version"?
  - ncmncm 7y ago
    Not for <version>, or just for <version>. Rather, for being able to designate header names without worry about what files have been shoveled into random directories. It really is on the compiler implementers for not providing a better accommodation to this very predictable problem. That said, fixing the autoconf scripts may be the most immediate route to sanity for the "config.h" / <version> case, eliminating the problem at its source.
    - a1369209993 7y ago
      > for being able to designate header names In other words, there's no reason why '#include <foo>' should ever be looking in the translation unit's directory; that's what '#include "foo"' is for.
      - ncmncm 7y ago
        I bet autoconf actually says "-I $top_level" or some such. What's mad is that -I controls where <> names are searched.
        kazinator 7y ago
        I concur. -I is a traditional option from Unix compilers with a very silly behavior; but for years now we have had something called -iquote in gcc (and clang). Before -iquote, there was -I- which is deprecated.
  - kazinator 7y ago
    There is value in not telling your compiler to look for all headers in your project root. There is no telling what clash that will create. Documented, public <> headers include other headers that are not documented. There is no telling what their names are.
    - emn13 7y ago
      sure, no question - but that's out of the standards body control. And even if you don't include your own top-level dir, using a common file name might clash in other dirs too. Hoping that compilers would not resolve headers via user-specifiable directories sounds absurd to me - every single compiler I know of allows that, not just on unix, so if you want to retire that, that's going to be huge, multi-year effort. No point in considering that hypothetical reality when it comes to meaningful header names unless there is a reasonable likelihood of that happening. Not objecting to such a push; it just sounds wildly out of scope when picking a header file name.