foo-snapshot / foo-diff convenience functions

[Lawrence Velázquez]

> On Oct 20, 2016, at 3:40 AM, René J.V. Bertin <rjvbertin at 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