On 2023/04/15 13:45, Antoine Jacoutot wrote:
> On Fri, Apr 07, 2023 at 07:44:40AM -0600, Joel Knight wrote:
> > Hi ports@,
> >
> > On Tue, Mar 28, 2023 at 10:03 PM Joel Knight <knight.j...@gmail.com> wrote:
> > >
> > > Hi.
> > >
> > > Linked below are two new (and tightly coupled) ports: the AWS CLIv2
> > > and the Python bindings for the AWS Common Runtime.
> > >
> > > Given that AWS releases v1 and v2 of their CLI as independent
> > > products, I've elected to create CLIv2 as a new port; the CLIv2 port
> > > does not replace sysutils/awscli, the v1 port.
> > >
> > > Unlike the CLIv1, CLIv2 depends on the AWS CRT. I don't know if the
> > > CRT will build on non-amd64 arches. I already know it doesn't build on
> > > arm64. For now, I've set ONLY_FOR_ARCHS to amd64 in both ports.
> > >
> > > I've (presumptively) set myself as MAINTAINER as I'm volunteering to
> > > maintain these ports.
> >
> > Still looking for feedback on these two ports. Even if you aren't able
> > to test the port, it would be helpful to have feedback on the contents
> > of the tarball.
> >
> > Attaching the tarball in case that's preferable to downloading it from a
> > link.
>
> Hi.
>
> A few things:
>
> - I think we also need a @conflict marker in sysutils/awscli
that, or set the PKGNAME base to awscli (i.e. awscli-1.xx and
awscli-2.xx) which I think will automatically conflict and would
be a bit more 'discoverable' for users (though with that, it
does want "@option is-branch")
Re: "Don't know what other arches this will build on", that's not a
reason to restrict archs. Remove ONLY_FOR_ARCHS and we can add it
if builds fail.
Nitpicking but we can get rid of $V -
------
V = 2.11.6
DISTNAME = awscliv2-${V}
GH_ACCOUNT = aws
GH_PROJECT = aws-cli
GH_TAGNAME = $V
MODPY_EGG_VERSION = $V
------
MODPY_EGG_VERSION = 2.11.6
DISTNAME = awscliv2-${MODPY_EGG_VERSION}
GH_ACCOUNT = aws
GH_PROJECT = aws-cli
GH_TAGNAME = ${MODPY_EGG_VERSION}
------
(or just set PKGNAME instead of overriding DISTNAME; personally
I prefer to keep the default distfile name as long as it's sane)
> - add a comment to explain the reason for setting USE_NOEXECONLY
yep
> - if llvm is installed, the wrong ar is used by py-awscrt
> -- CMAKE_AR found: /usr/local/bin/llvm-ar
This is because it's not using standard ports build arguments for
cmake as would be used by the cmake module (there are a bunch of
CONFIGURE_ARGS lines to override various detected paths and other
settings).
The cc command lines are hidden in the output but I bet they are not
using proper CFLAGS etc too.
Not sure the best way to deal with this, but ideally it would use
things from cmake.port.mk directly somehow rather than having to
replicate and sync when things change..
> I also think these diffs are needed:
>
>
> diff -ruN /tmp/devel/py-awscrt/Makefile devel/py-awscrt/Makefile
> --- /tmp/devel/py-awscrt/Makefile Tue Mar 28 21:36:29 2023
> +++ devel/py-awscrt/Makefile Sat Apr 15 13:21:28 2023
> @@ -19,7 +19,10 @@
> MODULES = lang/python
>
> MODPY_PI = Yes
> -MODPY_SETUPTOOLS = Yes
> +MODPY_PYBUILD = setuptools
> +
> +FLAVORS = python3
> +FLAVOR = python3
>
> BUILD_DEPENDS += devel/cmake
>
> diff -ruN /tmp/devel/py-awscrt/pkg/PLIST devel/py-awscrt/pkg/PLIST
[..]
+1 for this
> diff -ruN /tmp/sysutils/awscliv2/Makefile sysutils/awscliv2/Makefile
> --- /tmp/sysutils/awscliv2/Makefile Wed Mar 29 05:29:52 2023
> +++ sysutils/awscliv2/Makefile Sat Apr 15 13:35:37 2023
> @@ -24,13 +24,16 @@
>
> MODPY_PYBUILD = flit_core
>
> -RUN_DEPENDS += devel/py-awscrt>=0.16.11
> +FLAVORS = python3
> +FLAVOR = python3
I think not this one, it's a standalone thing rather than a py-*
