phrocker commented on a change in pull request #610: MINIFICPP-814 - Fixed
ListenHTTP and HTTPClient bugs, created tests f…
URL: https://github.com/apache/nifi-minifi-cpp/pull/610#discussion_r304557156
##########
File path: bootstrap.sh
##########
@@ -468,13 +468,6 @@ build_cmake_command(){
add_os_flags
- curl -V | grep OpenSSL &> /dev/null
Review comment:
I think the approach in the script is quite dated and began in a time in
which we had to support multiple scenarios primarily one in which we were "boot
strapping" the system on which we are building -- but boostrapping has been
overloaded into the build process for other machines. With that history in mind
I don't agree with some of your interpretations.
I see risk of change as lack of testing. This has been a concern for some
time ( and frankly I'm glad you are addressing it! ) so it's one in which we
were hoping to alleviate by better controlling the chain. It's always good to
"know what your problems are" and I see a lot of "possibilities here." So if we
can simplify this to always building a libcurl and libressl and control those
artifacts much more, would that minimize changes?
We will always have consumers who want dynamic linking -- but with
justification we can change that as it's not really outward facing. As a result
we can make changes. I'm not tied to configure_ssl_context, but I am tied to
avoiding change in a release -- so while there still would be no benefit would
the risks be mitigated? I would completely approve of a case where we did not
allow linking against libcurl on the system. It would increase build times, but
it would alleviate this and concerns others have had.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
