[uclibc-ng-devel] [PATCH] ARC: Enable getpt() support in ARC defconfigs

[Anton Kolesov]

Hi everyone,

> > > 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 !
> 
> 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

> 
> > >
> > > 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
> 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 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