On Fri, Oct 8, 2021 at 2:53 PM Nathan Hartman wrote: > On Thu, Oct 7, 2021 at 11:51 PM Tomasz CEDRO wrote: > (..) > > 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 ? > > > Kconfig-frontends is indeed a critical dependency. If you search the > mailing list archives you'll see that I've talked about this before: > > In the past, before we joined the Apache Incubator, all the NuttX repos > were together in one place and the Tools repo had Kconfig-frontends and > other tools (including customized cross compilers etc). > > When we moved to the Incubator (which is the entry point toward becoming an > Apache project), we were told that it's against policy to do a hostile fork > of other projects; the Tools repo contains what are essentially forks of > other projects, so it stayed at BitBucket while NuttX moved over to ASF. > > Now I contend that bringing in the Tools repo is not making a "hostile" > fork, it's ensuring that tools critical to this project remain available, > like Kconfig-frontends, which doesn't have to be "unmaintained" -- we can > maintain it. > > Or if someone can propose a better tool.
Hello Nathan and thank you for this quick summary! Fully agree with you :-) The goal is to make NuttX work "out of the box" on various platforms. FreeBSD port seems excellent ground for this task, and usually is the perfect ground for multiplatform verification chceck, this is why I stick to BSD because it cares about long term maintenance and compatibility :-) It seems that Linux users are using Espressif's packages already if not built by hand [1], so this may be current "upstream" of the project, also NuttX could use it as "upstream" not to multiply the forks and don't add maintenance workload burden: <quote> boris-kolpackov commented 4 hours ago > your repository seems the only last one well maintained and updated, that may > be the source origin for the FreeBSD's Port of kconfig-frontends. FWIW, we maintain a "port" of upstream (i.e., linux) kconfig code with patches (some backported from this project) to make it work on a wide variety of platforms (including Windows): https://github.com/build2-packaging/kconfig/tree/upstream-5.11-rc2 We also packaged the kconfig library (liblkc) and a number of configurators (conf and qconf) and they build fine on FreeBSD with byacc: https://queue.stage.build2.org/?builds=liblkc&cf=*freebsd* </quote> Alternatively NuttX can switch to `kconfiglib` but: 1. That probably would require some additional work and code base changes that I understand may not be welcome. Any revolution eventually eats up its own children. 2. Brings up hard dependency on Python that some people may not like (I heard). 3. Does not work on Windows + MSYS setup this is why Espressif maintains this project in the first place. Using Espressif's `kconfig-frontends` as "upstream" seems most reasonable and backward compatible way :-) Could anyone please verify if using mentioned "upstream" works well and does not break anything on existing Linux and Windows setups? ps/2: "Hostile Fork" is a bit bullshit statement, especially in a situation when no formal upstream exist. Look at Nordic and Zephyr - they maintain their own local fork of Zephyr for use with Nordic chips, there are some stuff available only in that fork, and they will not share it to the upstream [2] because they say that would be "hostile fork" quoting exactly "nRF Connect SDK / NCS is a downstream project and it would not be appropriate to include vendor downstream details anywhere in the zephyrproject-rtos GitHub organization", what if far from okay in my eyes because that just means someone does not want to share back with the upstream (it is the BLE UART implementation that would work on other chips as well and would be highly demanded). Depending on the situation people will understand "hostile fork" statement just to suit their benefit. [1] https://github.com/espressif/kconfig-frontends/issues/4 [2] https://github.com/zephyrproject-rtos/zephyr/issues/35075#issuecomment-840643074 -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
