Don't merge this as is - it breaks the build when included from external workspaces, since -I$(GENDIR)/glog_internal is not the correct path.

Hm, it was always intended to be hidden from dependent projects (see for example this change). I guess it is unclear which directories Bazel automatically adds to a dependent projects include path though these are not specified by the project as part of the public interface. At least I don't agree that Bazel should add $(GENDIR) to the include path of other projects by itself...

Looking back at this previous PR that intended to fix the same, I am wondering if because of gflags_h and other rules that are specified as (public) hdrs of the library, Bazel adds the GENDIR of these rules which is identical to the GENDIR of config.h? Hence, the previous "fix" to move public headers to an include subdirectory was probably incorrect. Instead, the private headers needed to be moved. However, even that I think seems like a flaw in Bazel... there should be completely separate directory trees for public and private headers generated by a rule, not just an "internal" subdirectory.

Are you more familiar how Bazel manages include paths and separation of public and private header files? Or know where it is documented?

(... just got the don't merge yet message...)

Are strip_include_prefix and/or include_prefix be of any use, see here?

I've added a messy fix, but let's ask bazel-discuss@ if there's a better way.

The understanding that I have comes from Header inclusion checking, where it says:

Technically, the compilation of a .cc file may transitively include any header file in the hdrs or srcs in any cc_library in the transitive deps closure.

and

Unfortunately Bazel currently cannot distinguish between direct and transitive inclusions, so it cannot detect error cases where a file illegally includes a header directly that is only allowed to be included transitively. [...] Currently, no error is produced in that case, but such error checking may be added in the future.

So I think Bazel can't easily detect this - it has to add the problematic -I flag to handle the case where you have:

cc_library(
    name = "lib",
    srcs=["internal.h", "lib.cc"],
    hdrs=["lib.h"],
)
internal.h is in genfiles
lib.h #includes internal.h (which is allowed)

Have you had a look at include_prefix? The effect of it?

I posted on bazel-discuss.

I haven't tried using include_prefix for this, but I've been using it elsewhere and I don't think it would help. It makes the headers accessible under a different path by creating a tree of symlinks and pointing to them from there, but I don't think it stops them being accessed by their previous repository-relative path.

Just tried adding:

diff --git a/bazel/gflags.bzl b/bazel/gflags.bzl
index cd0edad..acf1749 100644
--- a/bazel/gflags.bzl
+++ b/bazel/gflags.bzl
@@ -85,7 +85,8 @@ def gflags_library(hdrs=[], srcs=[], threads=1):
         name       = name,
         hdrs       = hdrs,
         srcs       = srcs,
-        includes   = ["include/"],
+        strip_include_prefix = "include/gflags",
+        include_prefix = "gflags",
         copts      = copts,
         linkopts   = linkopts,
         visibility = ["//visibility:public"]

to see if it would make config.h inaccessible, but no luck - it results in:

-iquote .
-iquote bazel-out/local-fastbuild/genfiles
-iquote external/com_github_gflags_gflags
-iquote bazel-out/local-fastbuild/genfiles/external/com_github_gflags_gflags
-iquote external/bazel_tools
-iquote bazel-out/local-fastbuild/genfiles/external/bazel_tools
-Ibazel-out/local-fastbuild/bin/external/com_github_gflags_gflags/_virtual_includes/gflags

_virtual_includes is added by *include_prefix, but it doesn't remove genfiles/external/com_github_gflags_gflags. As far as I'm aware, copts is the only way to have a different include path for .cc files in this rule than for .cc files in rules that depend on this.

I feel Bazel's automatic addition of unwanted paths to the include path of an external project and the inability to mark outputs of a genrule as private (at least not documented), and considering that the rule for "configuring" config.h isn't really needed, it appears easier to just get rid of the rule in the first place? See #235.

I haven't tried using include_prefix for this, but I've been using it elsewhere and I don't think it would help. It makes the headers accessible under a different path by creating a tree of symlinks and pointing to them from there, but I don't think it stops them being accessed by their previous repository-relative path.

Yes, I've played with it myself now to see what it does. Interestingly, even though the -iquote path to the generated files without the prefix is still passed to the compiler (wrapper), I couldn't include gflags.h without the gflags/ prefix, though, just as intended. But this only worked for the public hdrs of the library. As you noted, it doesn't prevent config.h from being included.

@drigz Thanks for bringing up the issue and providing a solution. I've merged the PR that instead avoids a genrule for a private header file.