On Thursday May 19 2016 12:13:03 Mojca Miklavec wrote: > OK, Debian also goes some steps further and then splits packages into > smaller packages "beyond any common sense" (no pun intended) :) :) :)
That's often the doing of individual package maintainers, but one thing is clear: it's easy to get into a combinatorial dependency nightmare when you start indulging in this kind of thing (probably even if you don't add versioning to the dependency criteria). ... > - Could/should we then start splitting binary part of the package from > the "architecture independent" part (docs, plain text files, ...)? Is > that also true for libc++ and libstdc++? > - etc. One could, the real question is, should we? I think a main MacPorts guideline has always been to keep dependencies as simple as possible by not splitting up ports even if they can. Qt has always allowed (and advised) building each component separately, but it's only since recently that port:qt5 has actually implemented that. I don't think that's a big advantage except for users who install only a very limited set of Qt5-dependent ports, and IIRC someone (Ryan?) lodged a formal-looking request not to do this on trac. > (I don't know if and in what ways this would simplify the three stage > compiling of GCC though ... I still need to finish and polish the > mingw cross-compiler one day.) I doubt that, in fact I'm pretty sure it doesn't. If GCC's build system were capable of using an installed libgcc_s, libstdc++ etc. rather than building it from scratch it would already allow that (as well as building only those libraries). It should be possible, at least in stage 3. It does however address the build cost, evidently. R _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
