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? From my experience Python is the best way to provide platform independent tools in most cases. This is my "first contact" with NuttX. That could provide a valuable feedback for you guys. I played before with FreeRTOS, ARM MBED, and Zephyr RTOS, all of them provide Fire-and-Forget experience that is crucial for business. There is no point in using solution that requires +10x more time to setup than work on the target project. Sure I can invest some time in developing the tools but first I need to get at least one working product to prove that tool is worth the time and effort :-) I don't want to sound rude, but on Zephyr I just got from scratch working example for ESP32-C3 under 5 minutes, that proves I can implement my project using that tool set even though it may require some additional work. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
