On 2023/05/06 16:01, Joel Knight wrote: > Stu/Antoine, thoughts on how I've handled using the correct toolchain?
So here's a quick review of what's going on in the cmake module with this... Ports using cmake normally use the module so the toolchain bits are all handled automatically in those cases. Before we had those extra CONFIGURE_ARGS in cmake.port.mk, we ran into problems with certain ports with junking when ports-llvm was installed at configure time and junked during build. This was mostly ports that do link-time optimization, but I think there were some others too. So the paths were forced via CONFIGURE_ARGS to tell cmake to use the llvm toolchain binaries from base despite the fact that they're installed under non-standard names (llvm-ar renamed to ar, etc). Of the ports which don't use the module, lang/rust lang/zig depend on ports-llvm anyway so those CONFIGURE_ARGS don't matter very much. There are a few other ports which use cmake without the module, maybe we just got lucky that we haven't run into build problems yet, or maybe they don't pull in the bits of cmake which are affected. devel/py-lief,python3 geo/py-osmium,python3 lang/mono math/py-osqp,python3 net/bro textproc/hotdoc I've attached an updated py-awscrt tar with what I think is slightly better handling of this. It's still a bit ugly but I think not as bad and it will pick up new things from cmake.port.mk. With that I'm OK with py-awscrt. Now onto awscliv2 (which I thought was going to be the easy part...) See https://github.com/aws/aws-cli/issues/4947#issuecomment-586046886 #3: they don't want to support a wide range of dependency versions #4: they want to use their own python build with a specific openssl version #5: they want to be able to include other binaries written in various languages Backing this up, upstream's supported installation method is a zip with a bundled copy of Python 3.11, static-linked to their own copy of an OpenSSL 1.1.1 release, bundled libbz2 libffi libsqlite3 etc plus various Python modules. As things stand, ignoring awscrt (where keeping in sync with awscliv2 is no problem), this would add tight version restrictions on the following ports: devel/py-colorama devel/py-dateutil devel/py-flit_core devel/py-jmespath devel/py-prompt_toolkit security/py-cryptography sysutils/py-distro textproc/py-docutils textproc/py-ruamel.yaml textproc/py-ruamel.yaml.clib www/py-urllib3 This already breaks the port (the current versions of several of those deps are not accepted, even in upstream git head). And tight specs for those ports, many of which are very common, make it difficult to work on general Python ecosystem ports. This seems a total nightmare and I don't really see how we can support it in ports until at least the source bundle suggested in https://github.com/aws/aws-cli/issues/4947#issuecomment-793192340 is available (and, even then, depending on how that source bundle works, that may well cause trouble for ports too). So I'm afraid -1 from me for awscliv2.
