On Wednesday October 19 2016 21:44:04 Ryan Schmidt wrote: >No, that situation should not be common, nor indeed present at all.
I'm not sure I agree. PortGroups are intended to take care of setting up things for the ports that use them (like declaring a dependency in such a way ports work with the main as well as the -devel port), and even an official one like the github PG adds dependency info. Ditto for the Python PG: you cannot (to my knowledge) include it just to obtain the variables that provide the python paths without also redefining the configure mechanism. You could claim that it should be uncommon that ports want only part of the info a PG provides, but even that might not be relevant as I think there are quite a few ports providing Python extensions but that don't use Python's own configure/build/install mechanism (PyQt and PyKDE come to mind). >> For instance, a port providing translation files for a KDE port would >> probably need to include a KDE PortGroup but doesn't need to depend on Qt. > >I haven't looked at the kde portgroup specifically. Maybe the portgroup needs >additional options to handle different types of ports (e.g. libraries vs. >translation files), or maybe there need to be separate portgroup. Well, that's indeed what I've ended up doing with KF5, but there it's justified because of the sheer number of dependency variables (over 30 frameworks). The Qt PGs on the other hand define a considerable number of relevant variables but also add a single dependency to depends_lib. I don't think it's really justified to put just that in a separate PG. For that I'd rather add a switch to the PG, a variable to define before including it in order to deactivate something. Maybe it would be possible to make that latter approach a bit more elegant, somehow merging those variable declarations into the PortGroup syntax? R. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
