> On 12 Apr 2016, at 4:59 pm, Daniel J. Luke <dl...@geeklair.net> wrote: > > On Apr 12, 2016, at 11:49 AM, Chris Jones <jon...@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. Chris > > -- > Daniel J. Luke > > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
