The package will not build without the offending lines in '
Makefile.am'. I am considering contacting the author of the software for more information/help with this. I have actually finished the ports using the repackaged distfiles, and submitted a PR, the idea being if anything changes based off of the possible response from the application's author, I can always submit another PR with a diff reflecting the changes. The port that I have written is dependent on E17. The ports-maintainer for E17 has recently upgraded E17 to the current official version. The changes should be committed sometime soon, hopefully. Unfortunately, the current version of the software that I have ported is written against the latest E17-svn code, which is significantly different than the current official release of E17. This means that I am having to use an older version of the software that I have ported. The source, however, is only distributed via git repository. I have yet to figure out how to download source for a previous commit into the ports tree. I have an address that points to a tar archive.
Code:
https://github.com/jeffdameth/ecomorph/tarball/76e0131b9f197585b0781f532c9a2c22432b7a60
The issue here is when I define the variables as follows:
Code:
MASTER_SITES=https://github.com/jeffdameth/ecomorph/tarball/
PORTVERSION=76e0131b9f197585b0781f532c9a2c22432b7a60
The ports system keeps wanting to add ".tar.gz" to the end of the commit hash defined in
PORTVERSION, there is also the obvious fact that a commit hash is not really the best version number. I thought of defining the
DISTFILES variable with the commit hash, but the file pointed to by the commit hash is named something entirely different. I went through the Porter's Handbook, and I could just be dim here, but I did not see any information dealing with git repositories. Another thing I did not see in the GNU autotools section of the Porter's Handbook, or in
bsd.port.mk for that matter, was a way to use
autopoint. The
autogen.sh script uses this as well.
Code:
#!/bin/sh
rm -rf autom4te.cache
rm -f aclocal.m4 ltmain.sh
touch README
echo "Running autopoint..." ; autopoint -f || :
echo "Running aclocal..." ; aclocal -I m4 $ACLOCAL_FLAGS || exit 1
echo "Running autoheader..." ; autoheader || exit 1
echo "Running autoconf..." ; autoconf || exit 1
echo "Running libtoolize..." ; (libtoolize --copy --automake || glibtoolize --automake) || exit 1
echo "Running automake..." ; automake --add-missing --copy --gnu || exit 1
if [ -z "$NOCONFIGURE" ]; then
./configure "$@"
fi
Something that is a little ambiguous is whether or not the order of tools defined for the
AUTOTOOLS variable is also the order in which the tools are run. I am at a loss here, and assuming I cannot find a way to handle git, I will have to repackage the distfile. In the event I can handle git, there is still the issue with
autogen.sh. I will note that running
autogen.sh to generate the necessary
configure,
Makefile.in, etc, worked. I have tested the port on 9.0-STABLE amd64, 9.0-RELEASE amd64, 9.0-RELEASE i386, and 8.3-RELEASE i386, with no build or runtime errors. While I do realize that repackaging the distfile, is not the preferred way to go, it did greatly simplify the issues outlined above.