On Fri, Oct 8, 2021 at 2:25 PM Tomasz CEDRO <to...@cedro.info> 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. > 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
