> On Oct 20, 2016, at 3:40 AM, René J.V. Bertin <rjvber...@gmail.com> wrote: > >> 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).
This is arguably a defect of python-1.0 that should be fixed in the portgroup. >>> 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? It is already possible to create options that enable/disable portgroup behavior after the portgroup is included. The python-1.0 and php-1.1 do this quite a bit. There is no need to muck up the inclusion syntax. vq _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
