USE_GCC politic -- why so many ports has it as runtime dependency?

[Lev Serebryakov]

Hello, Dimitry.
You wrote 8 февраля 2014 г., 3:24:34:

>> And it seems, that most of USE_GCC-equipped ports pull all this development
>> toolkit for nothing!
DA> Well, some ports can be more or less difficult to get building with
DA> clang.  So depending on whether the maintainer(s) wish to choose the way
DA> of least resistance, they will sometimes decide to set USE_GCC.
  I'm not speaking about BUILD. I'm speaking about RUN. Why do I need compiler,
assembler, linker & Ko to run pre-build software?

DA> Since a lot (maybe even most?) of modern software requires something way
DA> newer than our old gcc in base, and 10.0 and later ship without gcc by
DA> default, it is logical to use lang/gcc in such cases too.
  Yep. It is not logical to have gcc + binutils + libraries as RUNTIME
dependency. Especially -- one with java (!) support. Does ANYBODY need
crippled gcc-based Java support at all?! And pull it for KERNEL MODULES?!
0.5G doesn't looks a lot by current standards, I understand :(

>> Maybe, it is time to make USE_GCC work as if ":build" is specified by
>> default? And, yes, add additional port with gcc RUNTIME?
DA> As far as I know, this is a feature still in the works for pkgng.  E.g.
DA> using one port work directory for multiple packages, for example -libs,
DA> -devel and so on.  Although some people tend to hate such modularization
DA> with great passion.  Paint for more bikesheds... :-)
  I have mixed feeling about such modularization in general myself, but not
in case of USE_GCC, as libgcc.so + libstdc++.so is a tiiiiiiny fraction of full
binutils + gcc package, and on non-developers system there is no need to
have 0.5G of toolchain only because some software were build by this
tooclahin on our build cluster!

 And I have feeling, that right now many cases of USE_GCC=any could be
replaced with USE_GCC=any:build and some "magic" to link with
libgcc/libstdc++ statically. Without any modularization of packages and
pkgng support.

-- 
// Black Lion AKA Lev Serebryakov <lev at FreeBSD.org>