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