# is not supported in srcs (duplicate of #374)

[wsxiaoys]

Hey, I'm trying to add bazel support for gambit-scheme, while it have a convention that using "#" in its scheme header files:
https://github.com/gambit/gambit/tree/master/lib

As these header files will be dependencies at gambit scheme's compile time, there's no easy workaround by simple renaming them.

It looks that a fix can be achieved by adding '#' into following variable.

bazel/src/main/java/com/google/devtools/build/lib/cmdline/LabelValidator.java

Line 32 in c484f19

private static final CharMatcher PUNCTUATION_REQUIRING_QUOTING = CharMatcher.anyOf("+,=~");

Any suggestions? I can send such a fix if that's an acceptable solution.

Thanks
Meng

[laszlocsomor]

Interesting idea. I added # to that set and ran our tests and everything passes, so from a technical point-of-view I think this would be fine. However given how old Bazel is (inside Google) I'm sure this came up earlier and there's probably a reason why # is not supported in target names.

Adding some people who can hopefully provide insight: @ulfjack, @laurentlb, @lberki

[damienmg]

This the general problem of extending the label syntax to accept arbitrary characters in it. I would say dupe of #374

[laszlocsomor]

Agreed, closing as duplicate.

[wsxiaoys]

Thanks for referencing #374

It seems the problem is identified and the only blocking issue is that the current bazel base might "assume the label is trival" thus a escaping scheme is required.

While in case of "#", @laszlocsomor pointed out all test cases passed without other modificiation. So is it ok to add "#" as a short-term solution?

[damienmg]

The ultimate problem is that Bazel cannot address a file that has a # in its name, barely fixing the query pattern won't be enough.

[laszlocsomor]

@damienmg , why not? What prevents us from extending the label syntax to accept # in the target name?

[lberki]

I am personally worried about all the Google-internal stuff that assumes that labels are of a specific syntax. I think we should nevertheless change it, but not piecemeal (add #, then add !, then...), but in one go so that these things only need to be updated once.

[wsxiaoys]

@lberki Current implementation already allow characters like +-@ and bash-like environment treat '#' no different than them.

So if we add '#' here:

1. Un-aware checking code still disallow '#': stuff won't break until someone want to use this feature. An "update" would mostly like redirect its checking functionality to LabelValidator.
2. Un-aware checking code doesn't check for '#': work as is.

In either case seems we don't require more-than-one updates to internal stuff.

[wsxiaoys]

Kindly ping on question raised by @laszlocsomor

[wsxiaoys]

Ping

[damienmg]

Changing

bazel/src/main/java/com/google/devtools/build/lib/cmdline/LabelValidator.java

Line 127 in c484f19

public static String validateTargetName(String targetName) {

is needed. And we need to add test for the new character, that will break a lot of service depending on the label name.

I definitely wants to prioritize doing that work, but let's do it 50 times.

[wsxiaoys]

As discussed in OP and verified by @laszlocsomor, modification to validateTargetName only involve adding '#' to PUNCTUATION_REQUIRING_QUOTING.

Could you name a few example services would be broken after adding the test? (I assume you're referring some integrating test as unit test is pretty easy to added.)

If it's google internal service, wouldn't it be better to simply leave it as is, given it would simply fall into cases described in #2006 (comment)?

[damienmg]

If such a simple change work for you, we can always try to run it with the internal tests, if everything pass then it should be pretty safe.