On Sat, Apr 15, 2023 at 01:47:36PM +0100, Stuart Henderson wrote:
> 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 <[email protected]> 
> > > 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-*

Yes stupid me. Drop the FLAVOR*


-- 
Antoine

Reply via email to