On Sat, Feb 01, 2020 at 03:29:25AM -0500, Raymond E. Pasco wrote: > - I used a modified distfile provided by abieber with a vendor directory, > which is necessary due to the large number of go package dependencies.
IMHO, bundling things defeats the purpose of ports/package system. What do you do if a dependency got a security update? Grep all distfiles if bundled somewhere and re-roll and depend on abieber (no offense!) to handle that? How about adding the dependencies as own ports instead? We do the same for python, perl, etc. I know, this is a lot of work, may be portgen can be tricked into handling go first... > - The custom version of go-libvterm used by aerc upstream includes an > (unmodified) bundled copy of libvterm itself, which causes issues with > the build. I instead link against devel/libvterm. What issues? However, using the existing port makes sense, but why have you still bundled it? > - One filter script shipped with aerc (to display HTML email) depends on > socksify (provided by security/dante) and www/w3m. I did not include these > as RUN_DEPENDS because this is an optional script disabled by default, > but I'm not sure whether this approach is correct. I suggest to add a note to package readme. > - cgo in go 1.13 (but not go 1.14) considers ~ an invalid path character, > but the top-level package name here (and therefore WRKSRC) contains an ~. > I remedied this by moving the vendor directory contents up to the level > of the MODGO_WORKSPACE. This workaround shouldn't be necessary when go > 1.14 is released. Weird. > - aerc can be built with notmuch support, but notmuch isn't in ports (yet?), > so I didn't bother with this. There were some submissions for notmuch in the past, but afaik never imported. Other than that, I tested your port and it works for me. Would be nice to have this imported. Thanks, Regards, Joerg
