1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

autogen.sh and configure

Discussion in 'Porting New Software' started by ring_zero, May 8, 2012.

  1. ring_zero

    ring_zero New Member

    Messages:
    67
    Likes Received:
    0
    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?
     
  2. SirDice

    SirDice Moderator Staff Member Moderator

    Messages:
    17,392
    Likes Received:
    7
  3. ring_zero

    ring_zero New Member

    Messages:
    67
    Likes Received:
    0
    I tried using
    Code:
    USE_AUTOTOOLS=   aclocal automake
    and compilation failed with the error code:
    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?
     
  4. SirDice

    SirDice Moderator Staff Member Moderator

    Messages:
    17,392
    Likes Received:
    7
    Read the autogen.sh script. See what it does and translate that to the ports system.
     
  5. ring_zero

    ring_zero New Member

    Messages:
    67
    Likes Received:
    0
    Already there. Now I am getting the error:
    Code:
    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.
     
  6. SirDice

    SirDice Moderator Staff Member Moderator

    Messages:
    17,392
    Likes Received:
    7
    Add USE_GMAKE to your Makefile. That'll make sure GNU make is used instead of the FreeBSD make.
     
  7. ring_zero

    ring_zero New Member

    Messages:
    67
    Likes Received:
    0
    SirDice, Thank You for taking the time to help me out with this.
    Code:
    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
    Code:
    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.
     
  8. SirDice

    SirDice Moderator Staff Member Moderator

    Messages:
    17,392
    Likes Received:
    7
    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.
     
  9. ring_zero

    ring_zero New Member

    Messages:
    67
    Likes Received:
    0
    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.