Stuart Henderson <s...@spacehopper.org> wrote:
> Please only use GH_* if using github's autogenerated tarball. If you are
> setting MASTER_SITES anyway then it's not wanted/needed - for this it should
> just have DISTNAME/MASTER_SITES/HOMEPAGE.

Fixed. There are some other packages that define both GH_* and
MASTER_SITES and could be fixed. If there is interest, I can send a 
different email addressing that.

Maybe it should be added to bsd.port.mk(5)?

> This is because of the post-patch target using a sed -i on configure.ac,
> causing it to have a newer timestamp than the generated files. This
> can be fixed by removing that post-patch target (it doesn't make sense
> anyway), the AUTO* lines, and change to CONFIGURE_STYLE=gnu.

Thanks for pointing this. As you said, removing that target and setting
CONFIGURE_STYLE=gnu builds, passes the tests and runs fine. Also we can
drop BUILD_DEPENDS+=${MODGNU_AUTO*} because of it.

That line was changed from /usr/local to ${TRUEPREFIX} in r1.4, and I
think it tries to address a hardcoded /usr/local in the project's
configure.ac, line 190:

      [test "x$PLATFORM" = xopenbsd],
      [AC_CHECK_FILE([/usr/local/include/ereadline],
          [LIBS="-lereadline $LIBS"
              AM_CPPFLAGS="-I/usr/local/include/ereadline $AM_CPPFLAGS"
              AM_LDFLAGS="-L/usr/local/lib $AM_LDFLAGS"
              AC_SUBST(AM_LDFLAGS)])],

I think that using ${TRUEPREFIX} in that line is a mistake, but I'm not
sure (out of ignorance) if such replacement doesn't make sense. Maybe
the correct approach is to try to upstream a fix for it, relying on
pkg_info -qe devel/readline.

> >  WANTLIB += assuan c crypto curl curses ereadline expat ffi gcrypt
> >  WANTLIB += gio-2.0 glib-2.0 gmodule-2.0 gobject-2.0 gpg-error
> >  WANTLIB += gpgme iconv intl m mesode nghttp2 otr pcre pthread
> > -WANTLIB += ${MODPY_WANTLIB} ssl util z
> > +WANTLIB += ${MODPY_WANTLIB} signal-protocol-c ssl util z
> 
> "make port-lib-depends-check" says this:
> 
> profanity-0.7.0(net/profanity):
> Extra:  python3.7m.0 util.13
> 
> This isn't new but from what I see it's not building any of the python
> parts. rsadowski, any idea what's going on there?

Dunno if it helps, but configure shows

checking for python-config... no
configure: Python development package not found, Python plugin support disabled.

This happens on line 83 of configure.ac, which just check for
python-config instead of python[23]-config. I went back to autoconf
configure and added

        sed -i s,python-config,python${MODPY_VERSION}-config, \
            ${WRKSRC}/configure.ac

to post-configure. It correctly detects python support and builds fine,
passes the tests, runs and can load and use python plugins, thing that
didn't happen before.

Now, I don't know if patching configure.ac in post-configure target is
the right thing(TM). Is it correct to override pre-configure instead?
Should I use patch target and write a proper patch for configure.ac?

After we have consensus about all this I'll send an updated patch.

Thanks for all the input!

-Lucas

Reply via email to