Build failure due to C++ version mismatch

[Flamefire]

🐛 Describe the bug

I'm building with GCC 12.2 and "system"/preinstalled protobuf.

The build fails on caffe2.pb.cc which includes protobuf which includes abseil which tries to use std::string_view.

Abseil was build without specific C++-standard flags so it uses the compilers default, which is C++17. However PyTorchs C++ standard (used to) be C++14:

pytorch/CMakeLists.txt

Line 40 in dff70a5

set(CMAKE_CXX_STANDARD 14 CACHE STRING "The C++ standard whose features are requested to build this target.")

Both Abseil and Protobuf correctly export (via INTERFACE properties) their required C++ standard but PyTorchs doesn't consistently use the CMake target protobuf::libprotobuf

The 2 affected locations are:

• pytorch/caffe2/proto/CMakeLists.txt

  Line 9 in dffa4e1

  add_library(Caffe2_PROTO OBJECT ${Caffe2_PROTO_HEADERS} ${Caffe2_PROTO_SRCS})

  which adds an (object-)library containing (generated) protobuf C++ files but that doesn't link against protobuf::libprotobuf and hence doesn't know about it's C++ standard

• pytorch/cmake/ProtoBuf.cmake

  Lines 120 to 122 in dffa4e1

  	get_target_property(__tmp protobuf::libprotobuf INTERFACE_INCLUDE_DIRECTORIES)
  	message(STATUS "Caffe2 protobuf include directory: " ${__tmp})
  	include_directories(BEFORE SYSTEM ${__tmp})

  which hides the issue by adding the protobuf include path (read from the target) globally (which is discouraged CMake practice)

I was able to resolve this by adding target_link_libraries(Caffe2_PROTO PUBLIC protobuf::libprotobuf) and removing

pytorch/cmake/ProtoBuf.cmake

Lines 120 to 122 in dffa4e1

	get_target_property(__tmp protobuf::libprotobuf INTERFACE_INCLUDE_DIRECTORIES)
	message(STATUS "Caffe2 protobuf include directory: " ${__tmp})
	include_directories(BEFORE SYSTEM ${__tmp})

However I'm wondering why the object-library is necessary at all (the objects are used once to create caffe2_protos)

Although this (currently) might not be an issue anymore after 36ac095 raised the standard to C++17 I still think it is wrong to just ignore the C++ standard of (in this case) libprotobuf and any other INTERFACE options it might have set and which may be required to successfully compile it on all systems.

Versions

1.13.1 - master

cc @malfet @seemethere