On Thursday, June 20, 2024 7:55 PM, Junio C Hamano wrote: ><rsbecker@xxxxxxxxxxxxx> writes: > >> I have another patch almost ready for zlib and libcurl, but it is >> based on the OpenSSL change. Would you like a re-roll or should I wait for the >merge? >> I do not have the PCRE - not available on my system, so someone else >> should do that one. > >A two-patch series for zlib and libcURL that builds on top of 8b731b8d (version: -- >build-options reports OpenSSL version information, 2024-06-19), which has >already hit 'next', would be OK, but most likely, these three are independent "for X >in (cURL, zlib, OpenSSL), append X if X is there", and when the three changes are >merged together, it would result in > > #if defined CURL_something > strbuf_add*(...libcurl thing...); > #endif > #if defined OPENSSL_something > strbuf_add*(...openssl thing...); > #endif > #if defined libz_something > strbuf_add*(...zlib thing...); > #endif > >with possible permutation of different ordering of them. And in such a case, three >parallel topics that build on the same base (i.e. some recent tip of 'master') would >be just fine, even though they _surely_ will introduce trivial textual conflicts. > >If you introduced a helper function or CPP macro to make it easy to add the >OpenSSL version string in your OpenSSL patch, and the other two patches took >advantage of the helper or CPP macro while adding the zlib or libcURL version >string, then it would be a different story. A two-patch series for zlib and libcURL that >builds on top of the OpenSSL patch would become the best (and the only practical) >approach in such a case, but there is nothing in the OpenSSL patch we have >reviewed that these other two would want to depend on, so... I think I would rather let each one stand. Embedding an #if defined inside a macro makes me nervous, considering it is compiler version dependent. Would putting each one in its own commit work for you? --Randall
