for generated pb.cc files, avoid __FILE__ in VERIFY_VERSION macro call

[packetzero]

Currently, whether generated .pb.cc files are built in release or debug mode, the source filenames are included as strings in the resulting binary.

This is because protoc-cpp adds a call to the GOOGLE_PROTOBUF_VERIFY_VERSION macro in the InitDefaultsImpl function of every generated C++ protobuf message file. That macro contains the FILE macro. Therefore, if you have a source file named MySpecialMessage.pb.cc, runnings strings on the resulting .o or .a or executable will reveal all the source file names. If you are using CMAKE for your build, it will include the absolute path of all .pb.cc files (e.g. "/Users/bob/dev/blah/generated/MySpecialMessage.pb.cc").

This change follows the behavior of the assert macro, which will omit FILE when NDEBUG is defined.

[bazel-io]

Can one of the admins verify this patch?

[grpc-kokoro]

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

[grpc-kokoro]

Thanks for your pull request. The automated tests will run as soon as one of the admins verifies this change is ok for us to run on our infrastructure.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If your company signed a CLA, they designated a Point of Contact who decides which employees are authorized to participate. You may need to contact the Point of Contact for your company and ask to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the project maintainer to go/cla#troubleshoot.
• In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again.

[packetzero]

cla: I signed it!

[googlebot]

CLAs look good, thanks!

[xfxyjwf]

Unfortunately we cannot use NDEBUG in header files due to the reasons stated in: #3322

Can you think of a solution that doesn't require the use of NDEBUG macro?

[packetzero]

So the latest revision uses a relative path to proto file without ".proto" extension as the name ("google/proto/descriptor") and for most users simply "MyProtoMessage". Personally, I would prefer DEBUG or NDEBUG to enable/disable FILE usage. The issues in #3322 that are a concern are only for changes that alter the behavior or message hash. Etiher way, this pull request is ready for review.

[xfxyjwf]

Sorry for the late response. If you only need to hide the prefix of the build path, maybe you can build it in a place where the prefix doesn't matter? For example, /home/build/.... The alternative is for protobuf code base to support a GOOGLE_PROTOBUF_NO_FILE_MACRO macro that you can define to switch off the use of FILE in our code base.

If you are still interested in getting it in, feel free to reopen.