On Fri, Oct 8, 2021 at 7:49 AM Takashi Yamamoto wrote: > > On Fri, Oct 8, 2021 at 2:25 PM Tomasz CEDRO wrote: > > > > On Fri, Oct 8, 2021 at 6:45 AM Takashi Yamamoto wrote: > > > > > > On Fri, Oct 8, 2021 at 12:51 PM Tomasz CEDRO wrote: > > > > > > > > On Fri, Oct 8, 2021 at 5:15 AM Tomasz CEDRO wrote: > > > > > On Fri, Oct 8, 2021 at 4:47 AM Nathan Hartman wrote: > > > > > > There is a NuttX Tools repo at > > > > > > https://bitbucket.org/nuttx/tools/downloads/ > > > > > > > > > > > > I think I built the kconfig-frontends from there a long time ago. > > > > > > > > > > Thank you for this hint I will try to build that on my FreeBSD. I > > > > > could not find kconfig sources :-) > > > > > > > > `kconfig-frontends-4.11.0.1` does not build on FreeBSD: > > > > > > > > CC libs/parser/libs_parser_libkconfig_parser_la-yconf.lo > > > > In file included from libs/parser/yconf.c:252: > > > > libs/parser/hconf.gperf:153:1: error: conflicting types for > > > > 'kconf_id_lookup' > > > > kconf_id_lookup (register const char *str, register unsigned int len) > > > > ^ > > > > libs/parser/hconf.gperf:12:31: note: previous declaration is here > > > > static const struct kconf_id *kconf_id_lookup(register const char > > > > *str, register GPERF_LEN_TYPE len); > > > > ^ > > > > libs/parser/hconf.gperf:40:44: warning: static variable > > > > 'kconf_id_strings_contents' is used in an inline function with > > > > external linkage [-Wstatic-in-inline] > > > > register const char *s = o + kconf_id_strings; > > > > ^ > > > > libs/parser/hconf.gperf:145:43: note: expanded from macro > > > > 'kconf_id_strings' > > > > #define kconf_id_strings ((const char *) &kconf_id_strings_contents) > > > > ^ > > > > libs/parser/hconf.gperf:147:1: note: use 'static' to give inline > > > > function 'kconf_id_lookup' internal linkage > > > > > > > > There is `gperf-3.1` package installed. > > > > > > > > > > > > Can anyone point me to the official `kconfig-frontends` website and > > > > source code repository? > > > > > > > > I can find 28 repositories on GitHub all seems to be outdated forks: > > > > https://github.com/search?q=kconfig-frontends > > > > > > > > > > > > One of them is > > > > https://github.com/NuttX/tools/tree/master/kconfig-frontends, > > > > where I find: > > > > > > > > This is a snapshot of the kconfig-frontends version 4.11.0.1 tarball > > > > taken > > > > from http://ymorin.is-a-geek.org/projects/kconfig-frontends. > > > > > > > > But that server does not respond. > > > > > > > > > > > > Another finding is https://github.com/espressif/kconfig-frontends but > > > > that is explicitly a modified version so its a different tool with the > > > > same name. > > > > > > > > > > > > I hope NuttX does not have a critical dependency on abandoned > > > > unmaintained tool ? > > > > > > i guess "we are maintaining the fork by ourselves" is a better > > > description of the current situation. > > > as it can be built for macOS. i guess it isn't too difficult to port > > > it to FreeBSD. > > > > Porting to FreeBSD was my first intention, no problem with that, but > > then where do I even send patches if "maintenance" is just keeping old > > bz2 package somewhere out there. Sorry, this is not the serious way to > > go, this tool seems abandoned and you should consider abandoning it > > too. > > > > "Works for me after I patched 38 packages that took me 18 days and > > works only on my local machine"^TM makes me think "do not touch that > > project"^TM :-) > > > > > > > i think kconfiglib is a better tool in general. at least it's > > > definitely easier for someone new to nuttx to start with. > > > but it seems for some people python dependency is not acceptable. > > > maybe we can support the both? how others think? > > > > Anything that has live community, source code repository, and is > > proven effective in other projects will be better :-) > > > > There are some `*.py` files in `nuttx/tools/` already so why Python > > could be a blocker? > > because kconfig is a more critical tool than these .py files? > > i don't remember who told me python was not acceptable. > hopefully he will read this and explain us.
Yup, sounds like kconfig is a critical dependency. In perfect scenario some well maintained multiplatform solution that does not require a lot of changes in current NuttX code base would be the best one. I put some FreeBSD related notes on GitHub issue: https://github.com/apache/incubator-nuttx/issues/4648 I saw Espressif have their own modified fork of kconfig-frontend that is updated to work with CMake (that fixes GNU Make vs BSD Make problem as well): https://github.com/espressif/kconfig-frontends On the other hand ESP-IDF and Xtensa Toolchain also have problems with maintaining self-compatibility as reported by FreeBSD port maintainers already: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251659 Personally I am using Linux Xtensa Toolchain on FreeBSD (FreeBSD can natively emulate Linux binaries). It works but I am not really happy with that solution. The bootstrap and update is automated by Zephyr's west though so I am sure I am working with the one that builds working firmware. The good news is FreeBSD already has working ports for embedded RISC-V 32/64 GCC, Binutils and QEmu, so we are not tied to binary builds for Linux here. FreeBSD itself works on RISC-V boards already :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
