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