On Mon, 30 Nov 2015 14:59:45 +0100 Thomas Monjalon <thomas.monjalon at 6wind.com> wrote:
> 2015-11-30 14:27, Jan Viktorin: > > I believe (and have already expressed this idea) that this is not a > > problem of architecture ports but it is a problem of the build system. > > Love me or hate me, in my opinion the build system is broken :). The > > build system should be able to solve this. > > > > I've created privately an integration of kconfig into DPDK, however, it > > is far from being usable and I did not have time to make at least an > > RFC patch. If there is an attitude in the community to include such > > thing in the future versions, I'd like to make some more effort in this > > area. > > If we were integrating kconfig, we should consider kconfig-frontends > (http://ymorin.is-a-geek.org/projects/kconfig-frontends). True, this seems to be the easiest way. I've already used it successfully. > But I'm not sure it is the way to go. You are welcome to open the debate > in a dedicated thread by explaining the benefits compared to a configuration > script. OK. I will consider this. Probably, after the community call... (Or before?) > I think most of the options could be automatically guessed given the target > CPU, kernel, libc and compiler. It looks like a scripting task, not a > manual configuration (as kconfig provides). But maybe we can mix kconfig > and some automatic defaults. > Well, scripting... If you have issues like "feature X" does not work on "platform A" then you need to express this. If you try to script such dependency, I am afraid you always end up with a system of the same or equivalent complexity as the kconfig already has :). We'll see... Regards Jan -- Jan Viktorin E-mail: Viktorin at RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic