Opened 3 years ago

Closed 2 years ago

#55807 closed defect (fixed)

boost @1.65.1_3 depends on itself

Reported by: mndavidoff (Monte Davidoff) Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.4.2
Keywords: Cc: ryandesign (Ryan Schmidt), michaelld (Michael Dickens), mamoll (Mark Moll), dbevans (David B. Evans), majoc-at-astro (majoc-at-astro), hapaguy (Brian Kurt Fujikawa)
Port: boost

Description (last modified by ryandesign (Ryan Schmidt))

Commit 83080c8 seems to have introduced a circular dependency on boost via py27-numpy.

$ port rdeps boost | grep boost
The following ports are dependencies of boost @1.65.1_3+no_single+no_static+python27:

boost -> py27-numpy -> gcc7 -> cctools -> llvm-5.0 -> cmake -> curl -> libpsl -> gtk-doc -> source-highlight -> boost

The full output of port rdeps boost is attached.

Attachments (3)

boost.rdeps.gz (656 bytes) - added by mndavidoff (Monte Davidoff) 3 years ago.
patch-Portfile (1.1 KB) - added by mamoll (Mark Moll) 3 years ago.
libpsl-docs.diff (1.6 KB) - added by michaelld (Michael Dickens) 3 years ago.

Download all attachments as: .zip

Change History (26)

Changed 3 years ago by mndavidoff (Monte Davidoff)

Attachment: boost.rdeps.gz added

comment:1 Changed 3 years ago by ryandesign (Ryan Schmidt)

Description: modified (diff)

comment:2 Changed 3 years ago by mamoll (Mark Moll)

I added that numpy dependency. We can of course easily undo this, but then what gets installed when someone installs boost with non-default variants will depend on whether someone has numpy installed. Boost will automatically compile the numpy library when it's detected at build time. That's not ideal either. I'd actually like to use this library in another project, so I lean in favor of enabling numpy support, but that leads to this circular dependency. If we want to disable it, we'll have to patch the Boost code to remove the numpy check.

comment:3 Changed 3 years ago by mndavidoff (Monte Davidoff)

Perhaps have two ports, boost and boost-numpy.

The boost port would install everything except the numpy library, even if it was built (e.g., in a Portfile post-destroot step, remove the numpy library if it was there). The boost port would not depend on pyXY-numpy.

The boost-numpy port would depend on boost and pyXY-numpy. It could rebuild boost but install only the numpy library. Rebuilding boost is admittedly inefficient, but it's better than not being able to install boost due to a circular dependency or not having the boost numpy library installed when it's needed. Perhaps at some later time boost could be patched to avoid rebuilding all of boost.

comment:4 Changed 3 years ago by michaelld (Michael Dickens)

A few thoughts here:

1) I am becoming more and more convinced that for openmaintainer ports with owner(s), someone wishing to make a potentially non-trivial change -- virtually anything except a rev-bump -- should either open a PR or an issue describing the problem and solution. The usual "24 hour timeout window before committing any such change" would apply. In this manner, we port maintainers are given a chance to test out any such changes and approve or not of them. We might not be able to catch every single issue, but at least we're given a chance to do so. I, for one, will do this MO from here on, even though I know it's not what the Committers' Guide says about openmaintainer ports.

2) We need to do -something- pretty quickly. Reverting isn't really a good option since Boost will use NumPy if found & we don't want that. Let's try to fix the issue.

3) I like Monte's idea, but not for Boost itself. Much easier would be to split off libpsl's docs to be their own subport, say libpsl-docs; who actually uses local docs anymore? Add a note to libpsl about how to get its docs. On my laptop, it takes 22 seconds to fetch and build libpsl; a pittance compared with boost.

Changed 3 years ago by mamoll (Mark Moll)

Attachment: patch-Portfile added

comment:5 Changed 3 years ago by mamoll (Mark Moll)

I have attached a patch. Testing it now.

comment:6 Changed 3 years ago by mamoll (Mark Moll)

@michaelld, in hindsight it definitely would have been better to have created a PR first. Sorry about that.

comment:7 Changed 3 years ago by mndavidoff (Monte Davidoff)

Michael, I like your idea of creating a libpsl-docs port. (BTW, I use local docs when I need to refer to them frequently.)

comment:8 Changed 3 years ago by michaelld (Michael Dickens)

@mamoll: Thanks. I'm sure you've experienced this too (and, not the first time for me), that I'm not alone in my wondering whether (1) would be a better MO for these situations.

comment:9 Changed 3 years ago by michaelld (Michael Dickens)

I've attached a patch for libpsl, that splits off docs. It's pretty simple & works nicely for me & fixes this issue. Please test & verify on your setups. I'm adding on the owner of the libpsl port, too.

comment:10 Changed 3 years ago by michaelld (Michael Dickens)

Cc: dbevans added

comment:11 Changed 3 years ago by michaelld (Michael Dickens)

@dbevans: I'm proposing splitting off docs from libpsl, and have attached a patch that does this.

comment:12 Changed 3 years ago by mamoll (Mark Moll)

@michaelld, I created a PR here: It solves the circular dependency problem. An argument could also be made that having numpy support enabled by default would pull in too many other dependencies.

comment:13 Changed 3 years ago by michaelld (Michael Dickens)

@mamoll: Cool thx I'll check it out. I do agree that adding in NumPy adds more dependencies that desired. Maybe we do both solutions to make it that much more robust? Worth considering.

comment:14 Changed 3 years ago by mamoll (Mark Moll)

I am not sure what you mean by do both. Instead of a numpy variant, we could add a boost-bumpy subport that enables numpy support and in the post-destroot phase removes everything but ${prefix}/lib/libboost_numpy-mt.dylib / ${prefix}/lib/libboost_numpy3-mt.dylib (depending on which python variant was selected). We'd need to make sure that boost_numpy uses the same python variant as boost in that case.

comment:15 Changed 3 years ago by michaelld (Michael Dickens)

"both" meaning your boost-numpy and my libpsl-docs ports. That way there are 2 ports that split off the cycle, not just 1.

It's easy to add in variant same-same checking to make sure the same Python is used for both boost and boost-numpy. I'll work on this shortly.

Changed 3 years ago by michaelld (Michael Dickens)

Attachment: libpsl-docs.diff added

comment:16 Changed 3 years ago by michaelld (Michael Dickens)

The patch is '-p1', by the way. I just updated it with the correct description for the subport.

comment:17 Changed 3 years ago by majoc-at-astro (majoc-at-astro)

Cc: majoc-at-astro added

comment:18 Changed 3 years ago by mndavidoff (Monte Davidoff)

@michaelld: I tested the libpsl patch. It worked well. I reinstalled libpsl and installed libpsl-docs without any dependency cycles.

comment:19 Changed 3 years ago by michaelld (Michael Dickens)

@mndavidoff: great! thanks for the feedback. not sure which way we'll go, but we'll decide soonish.

comment:20 Changed 3 years ago by michaelld (Michael Dickens)

In 4f291a71ee38b58407f0ad141ad88c9591de51f7/macports-ports:

libpsl: split off docs to subport libpsl-docs .

  • Maintainer timeout of > 24 hours to review and comment.
  • breaks a port dependency cycle: #55807

comment:21 Changed 3 years ago by michaelld (Michael Dickens)

I went ahead and committed the libpsl split, since it does fix this issue.

That said, given the number of dependencies added by py*-numpy, I'd like for @mamoll to keep pushing that split too. The challenge will be how to deal with the variants: do -all- variants have to be the same for boost-numpy as for boost itself: the same +clang (if selected), +*mpi* (if selected) (etc)? I don't know, but the safest way to go is to make sure the variants are identical between these ports ... which seems like a lot of work. Maybe someone else has some wisdom here?

comment:22 Changed 3 years ago by hapaguy (Brian Kurt Fujikawa)

Cc: hapaguy added

comment:23 Changed 2 years ago by michaelld (Michael Dickens)

Resolution: fixed
Status: newclosed

This issue was fixed in 2 different ways. Closing this ticket.

Note: See TracTickets for help on using tickets.