12587 [Solved] autogen.sh and configure - The FreeBSD Forums
The FreeBSD Forums  

Go Back   The FreeBSD Forums > Ports & Packages > Porting New Software

Porting New Software Having trouble or general questions about porting software to FreeBSD? Ask here.

Reply
 
Thread Tools Display Modes
  #1  
Old May 8th, 2012, 15:30
ring_zero ring_zero is offline
Junior Member
 
Join Date: Mar 2011
Location: US
Posts: 67
Thanks: 13
Thanked 21 Times in 11 Posts
Default autogen.sh and configure

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?

Last edited by ring_zero; May 10th, 2012 at 01:17.
Reply With Quote
  #2  
Old May 8th, 2012, 15:36
SirDice's Avatar
SirDice SirDice is offline
Moderator
 
Join Date: Nov 2008
Location: Rotterdam, Netherlands
Posts: 13,712
Thanks: 47
Thanked 2,022 Times in 1,861 Posts
Default

Porter's Handbook: 6.4 Using GNU Autotools
__________________
Senior UNIX Engineer at Unix Support Nederland
Experience is something you don't get until just after you need it.
Reply With Quote
  #3  
Old May 8th, 2012, 16:28
ring_zero ring_zero is offline
Junior Member
 
Join Date: Mar 2011
Location: US
Posts: 67
Thanks: 13
Thanked 21 Times in 11 Posts
Default

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?
Reply With Quote
  #4  
Old May 8th, 2012, 16:39
SirDice's Avatar
SirDice SirDice is offline
Moderator
 
Join Date: Nov 2008
Location: Rotterdam, Netherlands
Posts: 13,712
Thanks: 47
Thanked 2,022 Times in 1,861 Posts
Default

Read the autogen.sh script. See what it does and translate that to the ports system.
__________________
Senior UNIX Engineer at Unix Support Nederland
Experience is something you don't get until just after you need it.
Reply With Quote
  #5  
Old May 8th, 2012, 16:47
ring_zero ring_zero is offline
Junior Member
 
Join Date: Mar 2011
Location: US
Posts: 67
Thanks: 13
Thanked 21 Times in 11 Posts
Default

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.
Reply With Quote
  #6  
Old May 9th, 2012, 07:20
SirDice's Avatar
SirDice SirDice is offline
Moderator
 
Join Date: Nov 2008
Location: Rotterdam, Netherlands
Posts: 13,712
Thanks: 47
Thanked 2,022 Times in 1,861 Posts
Default

Add USE_GMAKE to your Makefile. That'll make sure GNU make is used instead of the FreeBSD make.
__________________
Senior UNIX Engineer at Unix Support Nederland
Experience is something you don't get until just after you need it.
Reply With Quote
The Following User Says Thank You to SirDice For This Useful Post:
ring_zero (May 10th, 2012)
  #7  
Old May 10th, 2012, 01:15
ring_zero ring_zero is offline
Junior Member
 
Join Date: Mar 2011
Location: US
Posts: 67
Thanks: 13
Thanked 21 Times in 11 Posts
Default

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.

Last edited by DutchDaemon; May 10th, 2012 at 23:25.
Reply With Quote
  #8  
Old May 10th, 2012, 06:51
SirDice's Avatar
SirDice SirDice is offline
Moderator
 
Join Date: Nov 2008
Location: Rotterdam, Netherlands
Posts: 13,712
Thanks: 47
Thanked 2,022 Times in 1,861 Posts
Default

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.
__________________
Senior UNIX Engineer at Unix Support Nederland
Experience is something you don't get until just after you need it.
Reply With Quote
  #9  
Old May 11th, 2012, 01:25
ring_zero ring_zero is offline
Junior Member
 
Join Date: Mar 2011
Location: US
Posts: 67
Thanks: 13
Thanked 21 Times in 11 Posts
Default

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.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
How to configure ppp for u3g? iacobus Peripheral Hardware 18 August 24th, 2012 12:51
Anjuta - Autogen 5 not found akregator Installation and Maintenance of FreeBSD Ports or Packages 0 February 17th, 2012 19:24
[Solved] Help configure X please manblue X.Org 13 March 18th, 2011 15:26
Why would you want to configure inetd? johnblue Installing & Upgrading 2 December 15th, 2009 00:29
how to configure hal? jilingshu X.Org 0 November 21st, 2009 15:55


All times are GMT +1. The time now is 19:07.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2013, vBulletin Solutions, Inc.
The mark FreeBSD is a registered trademark of The FreeBSD Foundation and is used by The FreeBSD Project with the permission of The FreeBSD Foundation.
Web protection and acceleration provided by CloudFlare
0