Better configurability for portability and robustness

[JCash]

What language does this apply to? This is regarding the C/C++ part of the code.

Describe the problem you are trying to solve. When building the lib for various platforms, one often finds that different compilers move their (non standard) include folders. One such example is the sys/endian.h, when the compiler has suddenly moved it to machine/endian.h.

Currently, I am using a fork with modified code, simply to make sure the correct endian.h is used.

Describe the solution you'd like I'd like a more robust way to configure the builds. Since my problem refers to an actual include path, simple defines may not be the best idea.

I suggest having support for a custom config header. E.g. like so:

// coded_stream.h

#if defined(PROTOBUF_USE_CONFIG_H)
   #include "config.h"
#else
   // the current plethora of if statements to select an endian.h
#endif

(or something similar)

Describe alternatives you've considered

• Maintaining a fork - bad for keeping updated

Additional context Add any other context or screenshots about the feature request here.

[googleberg]

@JCash Protobuf C++ only supports compilers and platforms as described here: https://opensource.google/documentation/policies/cplusplus-support

If you are using a compiler on that list, please tell us which one and we will look into it. If you are using a compiler that is not on that list, we accept PRs to increase compatibility on a best effort basis. That is, we will accept those PRs but since we do not test against that target compiler or environment, the compatibility might be broken by subsequent changes to protobuf or that compiler.

[JCash]

Thanks for the info!

While the compiler is clang it is also unfortunately custom built (common with console developers) so it's not easy to fix unless you have access.

Since it seems my suggestion wasn't rejected, I can move ahead and create a PR that would cater for vanilla and custom setups.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please reopen it.

This issue was closed and archived because there has been no new activity in the 14 days since the inactive label was added.