On Thu, Dec 18, 2014 at 08:09:01PM -0500, Anthony G. Basile wrote:
> Hi fellow hardened devs:
>
> I'm sorry for missing the meeting but things came up and the day got
> hectic. It is an important meeting because we were to discuss:
>
> 1) what we want with toolchain.eclass - There is a move to get rid of
> the eclas because it is "messy". This is probably a bad thing in
> general and especially for hardened so we should discuss the pros and
> cons and what we want.
I quite dislike the eclass, it breaks stable systems whenever there is
any change to it. A recent one that broke things for me was when the
sanitize useflag was added to stable ebuilds which broke all my crossdev
toolchains. (it was defaulted to enabled and im not sure there was much
testing and sanitizing makes no sense on AVR or other bare metal
microcontrollers.)
Another thing is the differences between gcc versions. with most
packages its pretty simple to see changes with diff -u but that doesn't
work obviously. I find using diff a lot easier than stuff like this:
if tc_version_is_at_least 4.6 ; then
LICENSE="GPL-3+ LGPL-3+ || ( GPL-3+ libgcc libstdc++
gcc-runtime-library-exception-3.1 ) FDL-1.3+"
elif tc_version_is_at_least 4.4 ; then
LICENSE="GPL-3+ LGPL-3+ || ( GPL-3+ libgcc libstdc++
gcc-runtime-library-exception-3.1 ) FDL-1.2+"
elif tc_version_is_at_least 4.3 ; then
LICENSE="GPL-3+ LGPL-3+ || ( GPL-3+ libgcc libstdc++ ) FDL-1.2+"
elif tc_version_is_at_least 4.2 ; then
LICENSE="GPL-3+ LGPL-2.1+ || ( GPL-3+ libgcc libstdc++ ) FDL-1.2+"
elif tc_version_is_at_least 3.3 ; then
LICENSE="GPL-2+ LGPL-2.1+ FDL-1.2+"
else
LICENSE="GPL-2+ LGPL-2.1+ FDL-1.1+"
fi
I understand why people like the eclass and I think some of the reasons
are good but I think there is far too much stuff in the eclass and a lot
of it should be moved into the ebuilds. Especially if there is a feature
in a new version of gcc, why take the risk that older stable versions
will break when things are added to the eclass?
Perhaps a cleaner approach would be to split things into eblits like
glibc or perl does? Then there can be one per 4.x version of gcc instead
of having a single eclass that has to support all the way from gcc-2.95
up to gcc-4.9 and all the associated craziness.
-- Jason
