blob: b6b96e0c708909e7ae1173d546b3b9fc14d59da8 [file] [log] [blame]
What a fucking nightmare it was to find this. Protobuf has the most horrendous include search path flag of all-fucking-time. So their build system, when set up for a cross-compile using --with-protoc, doesn't work in the testing phase because the -I didn't work correctly. Why? I have no fucking clue.
For the simulator build (host), it would cd into the src directory, then use -I., and set the paths to the .proto files as google/protobuf/blah.proto. This worked fine for the simulator build. This also follows the rule that the -I flag be a prefix of the .proto files, since -I pointed to the pwd (src), and google/protobuf is a subdirectory of that.
For the target build, the build kept failing. In the host build it cd'ed into the src directory out of convenience. The protoc executable resides there, along with the built libraries, and the test .proto files are subdirectories (google/protobuf/*.proto). Since in the target build case we passed in the protoc executable to use for running the test cases (--with-protoc), it wasn't nearly as convenient to cd into this directory, so they didn't. Instead, they try to get clever with their use of the -I flag and paths to the .proto files. Instead of being clever, though, it was an enormous bucket of shit. It exposed how awful their implementation of the -I flag was with the "must encompass blah blah blah" and "too dumb" bullshit. Fuck you protobuf. The way the makefile implemented things, as best I could tell, was indeed correct. The paths to the .proto files was indeed encompassed by -I$(srcdir), but it didn't fucking work. After much experimentation, a few stackoverflow articles, and nearly setting my hair on fire, I figured out that I needed to prefix the .proto files with the $(srcdir), which is non intuitive given the "encompass" crap given in the warning, and the description of how the half-assed -I flag works.