This is by design and it has to change. A sensible default config.h is included in the rpclib source for people who just blindly copy the library include dir. But version.h and config.h are actually configured by cmake and might have different contents than the default one. It might make sense to add it to gitignore though.

yes, adding to gitignore would be great. Right now its bit annoying since we always see that red "modified" line in git status whenever you do build even if nothing is changed.

Any chance we can add this sooner? This is confusing quite a few people in our user base... I hope this is just .gitignore change in last release?

Hmm, I just realized an issue with ignoring the file. I will want to a) keep it in the repo and b) occasionally modify it. I don't know if git allows this easily (any suggestions?)

I would suggest downloading a tarball/zip from github instead of using a submodule (which is usually preferable anyway because consumers won't need the full history). The link for downloading a commit is https://github.com/rpclib/rpclib/archive/sha1-or-ref.tar.gz

Yes, using source archive seems to be better solution. Thanks, I'll switch our build to do just that. However I would still maintain that build should not modify the source files in repo. If its doing that then there is a problem with design...

I disagree, but I'm open to suggestions if you think this is a design issue. The way I see it, the alternative is to not have config.h, only config.h.in in the repo. People would complain that they can't simply copy the include directory and only use make install.

We can have config.h but build shouldn't modify it. If build wants to override something, one way is to use preprocessor macros. The .h file can reference those macros with default values. Then build can set those macros to whatever value it wants.

Having a config.h file is not something exotic that rpclib made up and certainly not a design problem. Libraries are unlike standalone applications in that they need to adapt to vastly different environments. One of the most compelling reasons to use a library to do anything is to have an implementation that works in many environments. But I digress. It's a very common practice with lots of support from build systems.

If build wants to override something, one way is to use preprocessor macros. The .h file can reference those macros with default values. Then build can set those macros to whatever value it wants.

The issue with your proposal is that rpclib consists of headers and sources. If the macros are not set in a file, then consumers can potentially break their builds in fantastic ways if they fail to pass the exact same flags (i.e. if you built rpclib with one set of macros and your application uses another one). It's not a sane default and annoying to collect and set flags to use with an already built library.

Again, from my naive/personal experience, I don't think this config.h should be modified during the build.
What's modified :

1)
static RPCLIB_CONSTEXPR std::size_t DEFAULT_BUFFER_SIZE = 1024 << 10;
static RPCLIB_CONSTEXPR std::uint16_t DEFAULT_PORT = 8080;
2)
#ifndef RPCLIB_CXX_STANDARD
#define RPCLIB_CXX_STANDARD 11

1. If you don't like the default values, you can always add one line in your implementation to change those.
2. With #147, the build flags are exported in the rpclib::rpc library flags, using either cmake or pkg-config.

I would keep the default values, but remove the flags. A warning on the documentation/website explanning how to include rpclib (copying the sources, using cmake, using pkg-config, using Qt .pro files) would be enough I guess. What do you think @sztomi ?

Again, from my naive/personal experience, I don't think this config.h should be modified during the build.

I only have anecdotal evidence as well to counter that, so let's remove this argument, it's not important who's right on this being common or not. There is a user pain which needs helping :)

The problem, it seems, is that rpclib is used as a submodule and will show up as modified for the end users.

Now, another possible fix for that is to not have config.h in the repo at all and .gitignoring it. config.h.in stays and cmake can safely generate config.h without annoying submodule users.

I think that breaking assumptions is not a good idea if it can be avoided. In my experience, users expect that they can:

1. build the library
2. copy the .a or .lib file
3. copy the contents of the include directory
4. build their application by adding the static library and include path

Now, requiring macros on the command line breaks the 4th assumption because the build will need extra defines and users don't read the documentation until they have to (i.e. this is friction).

The second option breaks the assumption of copying the include directory because the generated file is located in the build directory and users tend to not use the install target.

Maybe the solution is to gitignore it and generate the file in the include dir, instead of the build dir. I think I'd be happy with that, and this would allow proper submodule usage, while also shipping sane defaults. @ahoarau, @sytelus ?

Now, requiring macros on the command line breaks the 4th assumption because the build will need extra defines and users don't read the documentation until they have to (i.e. this is friction).

What about adding something like :

#if !defined(RPCLIB_CXX_STANDARD)
#error "You have to build rpclib with the compile flag RPCLIB_CXX_STANDARD=14"
#endif

So it won't build unless you specify the build flag.

That's still friction, it still needs those defines. It still lets you build with incorrect flags, too (there is no way to verify at compile time that the library was built with what you are providing for you application). The point is to ship something that works without hoops for the majority. Is there an issue with my gitignore proposal besides config.h being modified (or in this case, generated from scratch)?

That seems like a good compromise 👍