On Fri, Oct 8, 2021 at 7:54 PM Tomasz CEDRO <to...@cedro.info> wrote:
> On Fri, Oct 8, 2021 at 8:38 PM Gregory Nutt wrote: > > > > 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/ > > Hello and thank you Gregory :-) > > I will try to be as least invasive as possible. Personally I highly > oppose modern "enforcing changes" ideology, this is why the > "conservative" FreeBSD Unix is my ultimate choice. Changing too many > things too fast always results in a disaster, honestly I do not > understand how modern world even works (i.e. JavaScript + React-Native > is my last bad trip). > > The goal for now is just to run NuttX on FreeBSD as the development > environment, build firmware, get familiar with the RTOS, see what > works, what needs to be done. Then I will document it for the others. > > What I find important in business applications, as many years > corporate worker, now company owner, is a quick verification of the > required functionalities of the tool set under consideration: can I > use it in my current project, why it is better than the others, how > much time do I need to setup the environment, what is the maintenance > process of the tool set along with dependencies and how that impacts > maintenance of my own products. This is why I always check this in the > first place, before any decision or work is made. This is why I was > asking for the dependencies. > > Also having ability to quickly setup the environment and produce some > sort of demo is crucial in tool set selection. I would like that > process to be as smooth as in Zephyr RTOS (that I am using so far) - > setup takes 5 minutes, producing demo takes less than 5 minutes, build > time is around one minute, rebuild takes several seconds. There are > lots of sample demo applications in Zephyr that you can simply build > with `west build -b target_hardware_board`, then flash with `west > build -b target_hardware_board`. I would like to compare Zephyr and > NuttX in this area and make them both work well on FreeBSD :-) > > It seems that kconfig-frontends maintenance has been abandoned. > Luckily Espressif took over the project, and I think it can be good > idea to follow them as the current upstream. Espressif have really > nice dedicated team of specialists that can solve problems almost > instantly. I will use their repository as base for the FreeBSD port. > It would be nice if NuttX developers could verify if that version > works well with their current setup. It is also known to work with > Windows + MSYS, even though its modern python replacement kconfiglib > does not :-) > > CMake could be a nice solution. Zephyr uses it making project builds > really smooth and efficient. That could solve current GNU Make vs BSD > Make problem. But that seems too much burden of work and code base > change than it may be worth. Definitely a large breaking change that > could be only made by someone resourceful in time with perfect > understanding of the NuttX internals. It is worth mentioning that Matias started a PR to migrate the build system to CMake. I am not sure how much of the system was migrated, but it is here: https://github.com/apache/incubator-nuttx/pull/3704 At the time, the proposed change was controversial, and as you've said about stability and why you work with FreeBSD you can understand that this would have introduced a major change to how our build system works, but that caused work on this PR to stop and I think some feelings were hurt, which is a terrible tragedy, especially in a volunteer-driven project. Personally I do not have an opinion on what the build system should be, as long as it works, but just as a word of caution, if anyone would like to propose a big change, whether it's CMake, Python, Kconfig..., there should be a community discussion, possibly even followed by a vote, to decide the matter community-wide before anyone invests time implementing code that might not be merged. (Not saying you proposed to change anything!! Just saying...) Cheers, Nathan
