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

[Waldemar Brodkorb]

Hi,
Vineet Gupta wrote,

> On 03/01/2017 10:57 AM, Anton Kolesov wrote:
> >> 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 :)
> 
> But why is that - as long as buildroot (or other build systems) pass the right cpu
> flags - why do you need a seperate config ?
> 
> >> 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.
> 
> The whole out-of-tree defconfig approach is nonsense - lets not discuss it !
> 
> > [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.
 
I am not really sure I understand the discussion completely.
I think we discuss two points here.

Point 1.:

Rules.mak and some default CFLAGS/LDFLAGS passed to the compile and
linking of code. I favour removing any specific -march/-mcpu/-mtune
stuff, as we have done in the past for ARM/MIPS.
So if ARC people like to remove this:
ifeq ($(TARGET_ARCH),arc)
        CPU_CFLAGS-$(CONFIG_ARC_CPU_700) += -mA7
        CPU_CFLAGS-$(CONFIG_ARC_CPU_HS) += -mcpu=archs
        CPU_LDFLAGS-y += $(CPU_CFLAGS) -marclinux
endif

I would say, yes, good thing. The toolchain defaults should be
correctly set, no need to overwrite it inside uClibc-ng buildsystem.

Point 2.:

The files in extra/Configs/defconfigs/ and its use-cases.
I haven't touched or used any files here, because most of them just
contain TARGET_<arch>=y

I would rather vote either to completely remove this directory or
use it in the same way for all architectures.

At the moment only ARC, OR1K and NDS32 use full defconfigs:
wc -l uClibc-ng-git/extra/Configs/defconfigs/*/*
    1 uClibc-ng-git/extra/Configs/defconfigs/alpha/defconfig
   39 uClibc-ng-git/extra/Configs/defconfigs/arc/arcv2_defconfig
   38 uClibc-ng-git/extra/Configs/defconfigs/arc/defconfig
   38 uClibc-ng-git/extra/Configs/defconfigs/arc/tb10x_defconfig
    1 uClibc-ng-git/extra/Configs/defconfigs/arm/defconfig
    1 uClibc-ng-git/extra/Configs/defconfigs/avr32/defconfig
    1 uClibc-ng-git/extra/Configs/defconfigs/bfin/defconfig
    1 uClibc-ng-git/extra/Configs/defconfigs/cris/defconfig
    1 uClibc-ng-git/extra/Configs/defconfigs/frv/defconfig
    1 uClibc-ng-git/extra/Configs/defconfigs/h8300/defconfig
    1 uClibc-ng-git/extra/Configs/defconfigs/hppa/defconfig
    1 uClibc-ng-git/extra/Configs/defconfigs/i386/defconfig
    1 uClibc-ng-git/extra/Configs/defconfigs/ia64/defconfig
    1 uClibc-ng-git/extra/Configs/defconfigs/m68k/defconfig
    1 uClibc-ng-git/extra/Configs/defconfigs/metag/defconfig
    1 uClibc-ng-git/extra/Configs/defconfigs/microblaze/defconfig
    1 uClibc-ng-git/extra/Configs/defconfigs/mips/defconfig
  167 uClibc-ng-git/extra/Configs/defconfigs/nds32/defconfig
    1 uClibc-ng-git/extra/Configs/defconfigs/nios2/defconfig
  236 uClibc-ng-git/extra/Configs/defconfigs/or1k/defconfig
    1 uClibc-ng-git/extra/Configs/defconfigs/powerpc/defconfig
    1 uClibc-ng-git/extra/Configs/defconfigs/sh/defconfig
    1 uClibc-ng-git/extra/Configs/defconfigs/sparc/defconfig
    1 uClibc-ng-git/extra/Configs/defconfigs/x86_64/defconfig
  537 total

I think only the ARC defconfigs are really used anywhere.

All projects I know of, using uClibc-ng as a C library to create a
cross-toolchain are using some kind of own defconfigs and generated
fragments.

In OpenADK I have some target/<arch>/uclibc-ng.config for every
architecture with sane defaults to regular run and test uClibc-ng
based systems in emulators or on real hardware. 
This is used in embedded-test to do regression testing.

Buildroot has some minimal defconfig and a developer can enable or
disable some features (RPC, WCHAR, Locales, ..).
I think a developer can also supply his own uClibc-ng config
fragment.

OpenWrt/LEDE use some own defconfigs.

To have a good compatibility for a lot of applications the ARC
Synopsis toolchains might use the existing Buildroot defaults, which
allows to build a lot of software packages. We have seen before the
last release, a lot of packages fail to compile, because the
internal buildroot toolchain uses more features than the external
Synopsis toolchain. (UCLIBC_HAS_GETPT, ..)

If the default creates to big systems, Synopsis can use minimal
configs and fix any autobuild issues ;)

I think any external toolchain builders should create their own
config and the uClibc-ng project should not provide any defconfigs
anymore. Indeed when someone just use Kconfig defaults he/she should always
end with a known to work toolchain.

I still think we have too much different config possibilities and if
we find some, which can be removed, I always vote for it.

Best regards
 Waldemar