boost: Remove this wrapper port; it keeps breaking different dependents of Boost

[barracuda156]

The wrapper port serves no good purpose, its only function is breaking various consumers of Boost libs.

Just another example: ​https://github.com/NickvisionApps/libnick/issues/50 And one more: ​https://github.com/macports/macports-ports/pull/25855 And we got yet more in ports tree.

These errors never show up on CI or buildbots, for obvious reasons, but the current set-up is wrong. It wastes time on debugging and then forces to add per-port hacks via conflicts_build.

[ryandesign (Ryan Carsten Schmidt)]

Duplicate of, or at least dependent upon, #63136.

[mascguy (Christopher Nielsen)]

Replying to ryandesign:

Duplicate of, or at least dependent upon, #63136.

Yes definitely, there are still a number of ports that depend on boost:

./editors/sigil-qt4/Portfile:depends_lib-append      port:boost \
./editors/textmate2/Portfile:                        port:boost \
./games/glob2/Portfile:depends_lib         port:boost \
./games/PlasmaClient/Portfile:                            port:boost \
./games/wesnoth/Portfile:depends_lib-append      port:boost \
./graphics/agave/Portfile:                port:boost
./graphics/alembic/Portfile:    depends_lib-append      port:boost
./graphics/exempi/Portfile:     depends_lib-append port:boost
./graphics/vtk/Portfile:    depends_lib-append port:boost \
./net/et/Portfile:    depends_lib-append port:boost
./python/py-pynds/Portfile:                        port:boost \
./science/aircraft_oap/Portfile:depends_lib-append  port:boost \
./science/lscsoft-deps/Portfile:        port:boost
./science/openbabel/Portfile:depends_lib-append  port:boost \
./science/plumed/Portfile:    depends_lib-append port:boost
./sysutils/QLColorCode/Portfile:depends_build       port:boost
./textproc/freeling/Portfile:                    port:boost
./www/FileZilla/Portfile:                    port:boost

[reneeotten (Renee Otten)]

the issue with the “papillo” port in the PR you reference is that you didn’t supply the correct location to look for boost as configure arguments. I am not saying we can’t go without the “boost” wrapper port but often it’s pretty straightforward to resolve things without resorting to “conflicts_builds”.

[barracuda156]

Replying to mascguy:

Replying to ryandesign:

Duplicate of, or at least dependent upon, #63136.

Yes definitely, there are still a number of ports that depend on boost:

Yes, I am aware of that. I used this in one of my ports earlier too. But they all should just use boost176 directly or, if possible, boost181.

[barracuda156]

Replying to reneeotten:

the issue with the “papillo” port in the PR you reference is that you didn’t supply the correct location to look for boost as configure arguments. I am not saying we can’t go without the “boost” wrapper port but often it’s pretty straightforward to resolve things without resorting to “conflicts_builds”.

Boost portgroup should take care of finding the right boost. If it fails with papilo, then it is a PG issue.

[reneeotten (Renee Otten)]

Replying to barracuda156:

Boost portgroup should take care of finding the right boost. If it fails with papilo, then it is a PG issue.

No, it is not. Upstream can pick whatever random variable/configure argument they decide on so it’s impossible for any PortGroup to make that work all the time. It’s the port maintainers/person doing the update to take care of it.

[reneeotten (Renee Otten)]

having said that, I am fine with removing the shim port and have only the versioned ones. Feel free to do the requiired work and submit a PR.