1 Mar
2017
1 Mar
'17
6:57 p.m.
Hi everyone,
That means for building of our toolchain we'll need to have separately stored
"defconfigs" in some form. Let's see what Anton says on that :)
And regardless of what mr Anton says having off-the-tree defconfigs is not
the best idea because with time options will go in and out and occasionally
we'll have outdated defconfigs.
[AK] Not specifying architecture via uClibc config file is good for me - I
wanted this long ago, since I never understood why current approach was used in
the first place.
Out-of-tree defconfigs are not good, because it is not clear who would update
them in time. In addition that would create an additional coupling between
toolchain build scripts and uClibc - they now should be always synchronized,
which is a bad design. Defconfigs should be part of uClibc, toolchain build
scripts (and other uClibc builders) would just select one by its name - less
coupling, easier maintenance.
IMHO it should be OK to increase capabilities of prebuilt toolchain, that
Synopsys provides, to it would do more out of the box, at the expense of extra
bloat - it is not possible to please everyone, anyway. Those users, who are not
happy with "bloated" tools, can build tools themselves with configuration they
need. That said, I think there should be some common sense in what are the
features being enabled. I'd suggest that "full" feature configuration
should
enable those features which are required by at least one package in Buildroot
or there is some another clearly defined user of it. If we don't know where
feature is used - why enable it?
Anton
building.
Those changes I made to make sure our prebuilt toolchain is useful for
building more packages. I.e. to be in one camp with Mentor's (AKA
CodeSourcery) prebuilt tools that are really capable.
>
That's more of a question for Waldemar: does it really makes sense
> to have defconfigs for each architecture? I mean how do they differ
> between each other?
>
> For example, the ARC arcv2_defconfig and defconfig only differ by
> the option CONFIG_ARC_CPU_HS, whose only purpose is to pass -
mcpu=archs.
Shouldn't be the solution used on ARM (removing all options to
select the compiler flags, and leave it to the user to pass the
appropriate
options) be used as well ?
Yeah that would work fine I guess !
So, are they really useful? Shouldn't uclibc-ng instead come with
just one or two defconfigs, like a "minimal" one and "full-featured"
one?
totally agree and I've historically been pushing back on patches from
Alexey et all where we wanted to enable toggles to get buildroot packages
That was
a fair requirement on their part but it kept bloating uClibc for our
typical embedded use. But this idea of minimal vs. full featured is exactly
what we need.
@Alexey / @vlad can we take this up please !
Probably Waldemar's opinion might be useful here.
@Waldemar are there any plans for busting arch-specific defconfigs in favor
to generic defconfigs like those "minimal" and "full" mentioned
above?
-Alexey