variants

[Daniel J. Luke]

On Apr 12, 2016, at 1:34 PM, Christopher Jones <jonesc at hep.phy.cam.ac.uk> wrote:
> Take if you want, as a real world case, ROOT6, which I know well. It has a large number of variants, because upstream’s build system offers all these as optional extras. Many of them have dependencies I do not wish to force on all users, if they don’t require that feature. 
> 
> Some of them create additional libraries for the new features, some just add the functionality to existing ones. Most will also extend the introspection system as part of root. None can be built as afterthoughts. You have to configure ROOT from the start with the features you want. So for this port there is no chance in hell I am going to implement them as sub-ports. 

It would be nice if upstream could be convinced to 'fix' this.

(As an end user, it's much easier to understand application + optional plugins than application configured in one of many possible states).

ROOT6 may well be a 'special case' where we can't easily work-around our lack of variant dependency info - but how do other packaging systems that don't have variants deal with it?

>> IIRC the subversion-bindings ports didn't initially have nice 'install' targets, so we manually cleaned up post-destroot so that they would just have the additional libs that were necessary. The actual 'build' ends up duplicating some build products that don't get installed for the bindings ports (because they're already installed by the main port) - but it's worth it to have everything "just work" for our end-users.
> 
> That sounds just like the hackery needed in the portfiles to implement this that I think we should avoid.

I suppose it looks like hackery to you - but it does provide a consistent and functional end product for the user.

hacking on how default variants work only fixes one case (and doesn't fix the problem in general).

-- 
Daniel J. Luke