Hi,

> I think the cmake.mk-link approach would be a good idea and given 
> previous discussions the plan is afaik to pull in Ninja first and 
> once that's confirmed working via CMake add support for Meson.

fine with me.

> Having a look at https://www.python.org/dev/peps/pep-0537/#lifespan 
> it seems like a good idea to stick with 3.7?

No opinion.

> As for OpenWrt, there are already files with hard dependency of 
> python3 dating back to 2015 doing a quick grep of the source tree.
> 
> https://github.com/openwrt/openwrt/blob/master/scripts/dl_cleanup.py
> https://github.com/openwrt/openwrt/blob/master/scripts/flashing/eva_ramboot.py

Both files are supplemental scripts not used as part of the actual build
process.

> There are also upstream projects like wireless-db that doesn't 
> compile/build cleanly with vanilla 2.7 
> https://github.com/openwrt/openwrt/pull/1521

On the other end of the spectrum there is SCons (include/scons.mk) which
apparently explicitly does not support Python 3 [1].

Having to depend on two Python versions is not ideal. Maybe it is worth
sacrificing scons support for meson, depending on the number of users.

~ Jo

1:
https://bitbucket.org/scons/scons/wiki/FrequentlyAskedQuestions#markdown-header-am-i-restricted-to-using-python-24-code-in-my-sconscript-files

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to