jonesc at hep.phy.cam.ac.uk
Tue Apr 12 10:34:38 PDT 2016
> On 12 Apr 2016, at 4:59 pm, Daniel J. Luke <dluke at geeklair.net> wrote:
> On Apr 12, 2016, at 11:49 AM, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>> A lot of projects simply aren't built in a way that would allow that. The whole package (library, whatever) needs to be configured once with all the options, and built once. sub ports for the additional features simply aren't a option in main (most, I would bet) cases.
> Do they build the same output with different features?
> Port A with and without +foo builds lib-A.dylib
> And not, Port A without +foo builds lib-A.dylib and with +foo builds lib-A.dylib & lib-A-foo.dylib?
Both, and all points in-between. I wasn’t really thinking of specific cases, just in generality.
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.
> 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. For me, if upstream implements their build system with such an idea of additional ‘plugins’, that maps cleanly to sub-ports, then great. If not I am not of the opinion we should be trying to force things to work in ways upstream didn’t envisage.
> Daniel J. Luke
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1910 bytes
Desc: not available
More information about the macports-dev