On 2/8/2014 10:24, Lev Serebryakov wrote: > Hello, John. > You wrote 8 февраля 2014 г., 12:32:23: > >>> JM> dynamically linked libraries. >>> JM> libcstd++ >>> JM> libgfortran >>> JM> libquadmath >>> JM> libssp >>> JM> libgcc_s >>> JM> etc,etc >>> 90% of USE_GCC-ports don't use libgrotran & libquadmath. Many of them >>> doesn;t use libstdc++. virtualbox-ose-additions DOESN'T USAE ANY OF THESE >>> LIBRARIES! And I think, it is not unique in this regard! >>> >>> And, of course, 99.9% of them doesn't use Java! > > JM> It doesn't matter, you get everything that is built by default. And you > JM> need everything by default because sometimes gcc is needed for c++, > JM> sometimes it's needed for fortran, sometimes it's needed for Ada > JM> (gcc-aux), often the package has object files produced by different > JM> languages but needs the same compiler to build them all. > (sigh). I now how it is done now. Again, I try to say, that it should > be changed. For example, gcc port could be split into > gcc/g++/gfrotran/gcc-aux/gcj/runtime ports. 90% of software need gcc and/or > g++. I never used gfortran or gnu ADA and I never-ever hear about projects, > which need specifically gcj, especially when we have native OpenJDK7!
Your "solution" causes multiple issues for others, and for what benefit? The libraries are not packaged individually. You would need to split up every GCC package into at least two packages, and then change the infrastructure to add the compiler as the build dependency and the libraries as a run dependency. I do not see the library dependencies getting whittled down to 5 - 15 separate packages though. That is way too much of a maintenance headache. But the fact that you don't use use specific libraries is irrelevant. The needs of the entire tree is what is being considered, as well as the amount of work the maintainers are willing to do. GCC x 5 is a set of monster packages that I don't see a bunch of people clamoring to take over. > JM> Like I said above, if you don't fix *ALL* of them, there's no point to > JM> working on any of them. Any port with USE_GCC=yes will pull in > JM> everything anyway, so you'd have to kill them all. > It is perfectionism. May be, if we cover 50% of ports, but 50% which is > used by 95% of non-developing users (and other 50% is rarely used) it is > success. No, it's all or nothing. And you are asking people to do a tremendous amount of work to address a personal philosophy. While I can see value in splitting out the gcc libraries into separate packages (especially when subpackages come where one can package libraries separately for free), I see zero value in reworking vendor makefiles. I'd never agree to it myself, nor would I want a non-maintainer making an invasive change like that. John _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
