# autogen.sh and configure



## ring_zero (May 8, 2012)

The software that I am trying to port only has an autogen shell script.  The configure script is not created until autogen.sh is run. So I have two questions here.  Is there a way to get the ports system to use the autogen.sh script? Or can I safely run this on my machine, and then repackage the software with the resulting configure script?


----------



## SirDice (May 8, 2012)

Porter's Handbook: 6.4 Using GNU Autotools


----------



## ring_zero (May 8, 2012)

I tried using 
	
	



```
USE_AUTOTOOLS=   aclocal automake
```
 and compilation failed with the error code: 
	
	



```
Makefile.am:19: `%'-style pattern rules are a GNU make extension
configure.ac:14: required file `config.h.in' not found
*** Error code 1
```
 I am really unsure of what is happening here, this is the first port that I have tried to write.  I did look at the section of the Porter's Handbook that you referred me to, but it was not obvious to me at the time that this was what I needed to deal with the autogen.sh issue.  I wonder, is it frowned upon to repackage source for the ports tree?


----------



## SirDice (May 8, 2012)

Read the autogen.sh script. See what it does and translate that to the ports system.


----------



## ring_zero (May 8, 2012)

Already there.  Now I am getting the error: 
	
	



```
Makefile.am:19: `%'-style pattern rules are a GNU make extension
*** Error code 1
```
 which is puzzling to me, as I passed the --gnu flag to automake.


----------



## SirDice (May 9, 2012)

Add USE_GMAKE to your Makefile. That'll make sure GNU make is used instead of the FreeBSD make.


----------



## ring_zero (May 10, 2012)

SirDice, Thank You for taking the time to help me out with this.

```
USE_GMAKE=yes
```
 has been set from the start, I knew that I would have to use GNU make to build this.  I think that some aspects of Makefile.am are malformed, as the line pointed to by the previously listed error contains '%' signs which it should not.  I also compiled the source from scratch outside of the ports tree to see what was going on, and ran 
	
	



```
gmake distclean
```
 afterwards, and found that many of the headers and source files needed to build the application were deleted, necessitating a new download of the original source.  Because of this and several other issues that were not easily solved (the way that the source is distributed for one), I have opted to repackage them, and host them for download.  It will mean a little more work for me in the long run as new distributions are released, but it was the most effective way to solve all of the problems that I was encountering.


----------



## SirDice (May 10, 2012)

Can you make a simple patch to patch the 'broken' Makefile.am? The ports system can automatically apply that patch before starting the actual build. That may solve the issue.


----------



## ring_zero (May 11, 2012)

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. 
	
	



```
https://github.com/jeffdameth/ecomorph/tarball/76e0131b9f197585b0781f532c9a2c22432b7a60
```
 The issue here is when I define the variables as follows: 
	
	



```
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. 
	
	



```
#!/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.


----------

