boost: use system layout instead of tagged layout

[mjpost@…]

The boost Portfile specifies '--layout=tagged' in its build.args. This allows multiple boost variants to be installed, I suppose, but also makes it hard to link against boost libraries which assume the Unix standard boost layout, which is '--layout=system' (which doesn't decorate libraries with config options like "-mt". It seems to me it would be preferable to use the default layout, on the assumption that people who really require different variants will have the technical know-how to install them from source to nonstandard locations.

[ryandesign (Ryan Carsten Schmidt)]

I'm reclassifying this as an enhancement, because boost works fine as it is.

I assume changing the layout would mean revbumping and possibly changing configure arguments for every port that uses boost? That might be a lot of work.

[mjpost@…]

Replying to ryandesign@…:

I'm reclassifying this as an enhancement, because boost works fine as it is.

I assume changing the layout would mean revbumping and possibly changing configure arguments for every port that uses boost? That might be a lot of work.

I don't know enough about the intricacies of Macports dependencies to answer confidently, but I'm not sure that it would. For example, I can get the "system" layout by specifying the following install options:

sudo port install boost -no_single

This produces libraries like /opt/local/lib/libboost_program_options.dylib, although under Macports, that file is single-threaded, whereas under the "system" layout there is no knowing without looking more deeply into the boost installation.

Basically, the system layout means that the path to the headers and libraries is always the same, and files names no longer contain information about build options.

[ryandesign (Ryan Carsten Schmidt)]

Ah. Well, we have in many ports had to explicitly use the "-mt" suffix. Admittedly it was inconvenient to have to do that, and it would have been simpler not to have to do that. On the other hand, it's already done now, so if we were to change this now, we would have to undo that in all those places.

Also, the port currently always installs the multi-threaded libraries, and offers users the option of also installing the single-threaded libraries. With your proposed change, I'm assuming we would no longer be able to offer users that choice, and would only install the multi-threaded libraries using the filenames that were previously used by the single-threaded libraries. I don't know whether continuing to offer the choice to install the single-threaded libraries is important or not.

[mjpost@…]

Replying to ryandesign@…:

Ah. Well, we have in many ports had to explicitly use the "-mt" suffix. Admittedly it was inconvenient to have to do that, and it would have been simpler not to have to do that. On the other hand, it's already done now, so if we were to change this now, we would have to undo that in all those places.

Also, the port currently always installs the multi-threaded libraries, and offers users the option of also installing the single-threaded libraries. With your proposed change, I'm assuming we would no longer be able to offer users that choice, and would only install the multi-threaded libraries using the filenames that were previously used by the single-threaded libraries. I don't know whether continuing to offer the choice to install the single-threaded libraries is important or not.

I see. Yes, with my change, you'd only be able to have a single version of the libraries installed at a time (at least, under /opt/local/{lib,include}). If you already have downstream dependencies presuming the *-mt name, I suppose that would engender a host of changes if you accepted this request. I suppose you have to balance between using standard installation practices and allowing users to have multiple versions installed. I think it's worth noting that the system layout is the default for a reason (and wonder what other package management systems use?), but on the other hand, I am mostly thinking just of myself here.

[ryandesign (Ryan Carsten Schmidt)]

Replying to mjpost@…:

Yes, with my change, you'd only be able to have a single version of the libraries installed at a time (at least, under /opt/local/{lib,include}).

More than that: we would not be able to give the user the option to change their boost installation in any way. If we were to implement your proposed change where e.g. libboost_program_options.dylib is the multi-threaded library, then we would not be able to give the user an option that would cause libboost_program_options.dylib to be the single-threaded library, because that would break any other ports in MacPorts that link with that library, because those other ports could have been built on our automated build server which would have boost installed in its default configuration (i.e. per your proposal libboost_program_options.dylib would default to being multi-threaded).

Again, if nobody would ever want to use the single-threaded libraries, then we could make this change. And that's a possiblity: as you mentioned, the only way currently to get MacPorts to build the single-threaded libraries is to deactivate the no_single variant which is on by default. Since our build server only builds default variants, and since the MacPorts dependency engine does not have the ability to declare dependencies on variants of a port, there is probably no port in MacPorts today that requires the single-threaded boost libraries. But it's possible some user has software built outside of MacPorts that uses MacPorts boost's single-threaded libraries.

It would probably be a lot of work to make this change, for a small gain in convenience and a small gain in simplifying the port. But the way the boost port currently works predates me taking over as its maintainer so I'm not totally informed on the reasons for it working the way it currently does and am therefore reluctant to make major changes.

[ryandesign (Ryan Carsten Schmidt)]

I no longer maintain the boost port and it's been five years since this suggestion was made and there hasn't been any further discussion on why the change should be made, so I'm closing the ticket.