[MacPorts] #51516: MacPorts should use a bundled copy of a newer libcurl and SSL library rather than the OS X version

[MacPorts]

#51516: MacPorts should use a bundled copy of a newer libcurl and SSL library
rather than the OS X version
--------------------------+--------------------------------
  Reporter:  ryandesign   |      Owner:  macports-tickets@…
      Type:  enhancement  |     Status:  new
  Priority:  Normal       |  Milestone:  MacPorts Future
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+--------------------------------

Comment (by RJVB):

 Replying to [comment:121 kencu]:
 > The advantage of linking against libcurl.a statically is that it would
 hopefully be robust to breaking changes

 That's true of course, it's equivalent to installing a shared libcurl in a
 dedicated location in that aspect. However, you'd still want a libcurl.a
 from an appropriate build variant, which is tricky to ensure and
 cumbersome for the enduser IMHO. Plus, you'll need to link all the
 indirect dependencies yourself, the ones that would normally be linked to
 the shared libcurl.
 And purely on grounds of principle I dislike installing AND using a static
 library, because it's formally a waste of space.

 Yes, port:pextlib doesn't exist yet, but neither does the port that will
 provide the dedicated libcurl...

 Replying to [comment:122 kencu]:
 > But if you know how to make the build more elegant by building only the
 needed part, then by all means, that would be better.

 My git-fu isn't so good that I can tell you how best to split the pextlib
 subdir into its own repo (maintaining the commit history and all) and then
 make it a submodule, but I'm sure you can google that.
 Once that's done (and figured out how to create release tarballs that
 include the corresponding pextlib sources) I'd write a simple CMake file
 to build Pextlib as a standalone project. Partly that's because I'm lazy
 too and not interested in learning how to write a configure.ac file,
 partly because we won't have to touch the Makefile.in and partly because
 that means the MacPorts "base" configure script cannot possibly get
 confused by the presence of an autoconf "sub buildsystem".

 From there it'd be like building any other port that installs to a custom
 location (if the CMake file doesn't simply specify it).

 For the libcurl subport I'd indeed build all of curl if there is no
 existing build option to generate only the shared library, and of course
 using a hardcoded version of the appropriate build variants from
 port:curl. Use a `destroot` that copies the generated libcurl into place,
 or a `post-destroot` that prunes everything not needed if the curl install
 procedure involves relinking.

 I'd keep the curl version 1 step behind current, or at least avoid .0
 versions.

 And of course, with port:pextlib and port:pextcurl (hey, I like the name!)
 in a single Portfile it will be easiest to clamp the version of either one
 as required by the target OS or architecture, should that turn out to be
 required. I suppose our resident barracuda may have some experience in
 that domain :)

-- 
Ticket URL: <https://trac.macports.org/ticket/51516#comment:124>
MacPorts <https://www.macports.org/>
Ports system for macOS