Hacker News Reader

Comment by rfoo | Hacker News Reader

> they make no effort what so ever to distinguish between public header files and their source code

They did, in a different way. The world is used to distinguish by convention, putting them in different directory hierarchy (src/, include/). google3 depends on the build system to do so, "which header file is public" is documented in BUILD files. You are then required to use their build system to grasp the difference :(

> And their public headers tend to do idiotic stuff like `#include "base/pc.h"`, where that `"base/pc.h"` path is not relative to the file doing the include.

I have to disagree on this one. Relying on relative include paths suck. Just having one `-I/project/root` is the way to go.

View on HN

> I have to disagree on this one. Relying on relative include paths suck. Just having one `-I/project/root` is the way to go.

Oh to be clear, I'm not saying that they should've used relative includes. I'm complaining that they don't put their includes in their own namespace. If public headers were in a folder called `include/webrtc` as is the typical convention, and they all contained `#include <webrtc/base/pc.h>` or `#include "webrtc/base/pc.h"` I would've had no problem. But as it is, WebRTC's headers are in include paths which it's really difficult to avoid colliding with. You'll cause collisions if your project has a source directory called `api`, or `pc`, or `net`, or `media`, or a whole host of other common names.

Thanks for the clarification. Yeah, that's pretty frustrating.

Now I'm curious why grpc, webrtc and some other Chromium repos were set up like this. Google projects which started in google3 and later exported as an open source project don't have this defect, for example tensorflow, abseil etc. They all had a top-level directory containing all their codes so it becomes `#include "tensorflow/...`.

Feels like a weird collision of coding style and starting a project outside of their monorepo

>> `#include "base/pc.h"`, where that `"base/pc.h"` path is not relative to the file doing the include.

> I have to disagree on this one.

The double-quotes literally mean "this dependency is relative to the current file". If you want to depend on a -I, then signal that by using angle brackets.

Eh, no. The quotes mean "this is not a dependency on a system library". Quotes can include relative to the files, or they can include things relative to directories specified with -I. The only thing they can't is include things relative to directories specified with -isystem and system include directories.

I would be surprised if I read some project's code where angle brackets are used to include headers from within the same project. I'm not surprised when quotes are used to include code from within the project but relative to the project's root.

The only difference between "" and <> is that the former adds the current file's directory to the beginning of the search path.

So the only reason to use "" instead of <> is when you need that behaviour, because the dependency is relative to the current file.

If you use "" in any other situation, then you are introducing a potential error, because now someone can change the meaning of your code simply by creating a file with a name and location that happens to match your dependency.

(Yes, some compilers have -isystem and -iquote which modify that behaviour, but those options are not standard, and can't be relied upon. I'd strongly advise against their use.)

Reply on news.ycombinator.com