On Tue, May 30, 2023 at 02:06:30PM +0100, Stuart Henderson wrote:
> 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

Well, we could patch the version requirements.


-- 
Antoine

Reply via email to