I don't think that there is any particular reason to "forbid" Python in the build. The current build does not depend on Python and, hence, adding the requirement for Python would probably affect many people in the community. Historically, the project has avoided adding new build tool requirements and so perhaps Python was "fobidden" for that reason only.
There is a similar argument for using CMake, for example. I think that because the impacts are widespread and could have unintended side effects, we should check with the community to assure any new tool is the way to go. It is worth disrupting everyone's build environment? Is if fully compatible? Is it fully tested? Is it available on all platforms? Will it lead to support issues? Is it maintainable? We should be objective and always try to do the right thing for the community, rather than just advocating our favorite tools. kconfig-frontends builds under Windows MSYS2 and Cygwin with no issues (at least last time I build them). I use them frequently. For Windows native, this has been recommended: http://reclonelabs.com/more-kconfig-awesomeness-for-windows/ And this is also available: https://distortos.org/downloads/tools/kconfig-frontends-windows/ On Fri, Oct 8, 2021 at 10:59 AM Tomasz CEDRO <to...@cedro.info> wrote: > On Fri, Oct 8, 2021 at 3:14 PM Alan Carvalho de Assis wrote: > > > > Hi Tomasz, > > > > On 10/8/21, Tomasz CEDRO wrote: > > > On Fri, Oct 8, 2021 at 6:45 AM Takashi Yamamoto wrote: > > sic > > >> 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. > > > > > > > NuttX works out-of-the-box on many tested host OS as you can see here: > > > > https://nuttx.apache.org/docs/latest/quickstart/install.html > > > > Users of Ubuntu 19.04+ for example doesn't need to compile the > > kconfig-frontend because it is a package available to be installed > > using "apt(-get) install". > > > > Unfortunately we have only Bernd Walter, and now you, using FreeBSD. > > So it is easy to understand why it is not working yet and why you are > > facing issues. > > > > If you analyze the errors you will see they are just Warnings promoted > > to Errors. > > Hello Alan and thank you for directing me towards NuttX! You are the > one to blame I am here hahah :-) :-) :-) > > The goal is to make NuttX work and build out of the box on FreeBSD and > other BSD family OS as well (OpenBSD, NetBSD, NomadBSD, MidgnightBSD, > etc :-) > > I have ported multiple software utilities to FreeBSD (for instance > OpenOCD [1]), I can create low-level embedded stuff from scratch in > ViM+ZSH [2] when necessary, so that does not scare me, its just a > process that requires work and time, but I am sure we will make it :-) > > It may be also good opportunity to review some stuff with a fresh look > of a newcomer, like this `kconfig` stuff, like quick setup and > functionalities evaluation + demo for the business project available > to achieve in one work day time slot, etc :-) > > I can see that team is small so there may no corporate mumbo jumbo > here :-) Direct contact with code authors is also very important! > > Zephyr attracted me because of architecture independence - I did build > my firmware for ARM Cortex-M and ESP32 / Xtensa at instant. Now I need > to work with ESP32-C3 / RISC-V architecture. NuttX attracts me even > more with scalability from 8-bit upards and more raw minimalistic Unix > approach. One day I would love my 8-bit Atari running NuttX :-) > > [1] https://www.freshports.org/devel/openocd/ > [2] https://github.com/CeDeROM/LibSWD > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
