Handle the case where neither public-files nor private-files are present

[storypku]

Hi @martis42
I found some cases w/ neither public-files nor private-files. Please help review whether or not it's OK.

[martis42]

@storypku
Thanks for identifying and fixing this bug!
However, please reduce the examples in test/aspect/shared_library/BUILD. Using alwayslink or dlopen is not related to DWYU or the identified bug. Essentially only //test/aspect/shared_library:libfoobar.so seems relevant, which you correctly use as integration test.

[storypku]

@storypku Thanks for identifying and fixing this bug! However, please reduce the examples in test/aspect/shared_library/BUILD. Using alwayslink or dlopen is not related to DWYU or the identified bug. Essentially only //test/aspect/shared_library:libfoobar.so seems relevant, which you correctly use as integration test.

Done. Is it better to keep the alwayslink attribute? Otherwise, users may wonder why libfoo.so doesn't export any useful symbol...

What's your opinion?

[martis42]

@storypku
I don't think it is important that the example correctly exports symbols. In the end this is only showing that the tool can handle cc_binary targets without srcs attribute.

I just discovered something which I overlooked in my first review. Please remove package(default_visibility = ["//visibility:public"]). There is no reason to make these targets available outside the example.

[storypku]

Done. It think you are right. alwayslink=True is only a non-essential point here.

Thanks also for pointing my carelessness in the visibility settings. According to Bazel Visibility Best Practices:

Avoid setting default_visibility to public. It may be convenient for prototyping or in small codebases, but the risk of inadvertently creating public targets increases as the codebase grows. It's better to be explicit about which targets are part of a package's public interface.