Re: [gentoo-dev] [RFC] autotools support eclass
On Saturday 27 August 2005 03:38 pm, Martin Schlemmer wrote: On Sat, 2005-08-27 at 15:11 -0400, Mike Frysinger wrote: On Saturday 27 August 2005 02:58 pm, Martin Schlemmer wrote: Which reminds me .. anybody going to scream if I update elibtoolize() to be able to check if it was already run, and then bug the portage guys to also add it to econf() ? do what now ? Make econf handle elibtoolize the same way it does gnuconfig ... why ? this would help us embedded peeps with uclibctoolize, but other than that ... maybe i just havent really sat down to figure out what elibtoolize does ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] autotools support eclass
On Sun, 2005-08-28 at 01:59 -0400, Mike Frysinger wrote: On Saturday 27 August 2005 03:38 pm, Martin Schlemmer wrote: On Sat, 2005-08-27 at 15:11 -0400, Mike Frysinger wrote: On Saturday 27 August 2005 02:58 pm, Martin Schlemmer wrote: Which reminds me .. anybody going to scream if I update elibtoolize() to be able to check if it was already run, and then bug the portage guys to also add it to econf() ? do what now ? Make econf handle elibtoolize the same way it does gnuconfig ... why ? this would help us embedded peeps with uclibctoolize, but other than that ... maybe i just havent really sat down to figure out what elibtoolize does ... Because it applies the portage/relink/whatever patches to ltmain.sh without the need for real libtoolize and the pains that comes with it and a autoreconf (due to missing macro's, broken build system, etc). Note ... I really don`t think uclibctoolize and the other stuff that was added is really appropriate in libtool.eclass, as they touch config.guess, etc .. maybe it would have been better to update gnuconfig to try and apply the patch if in uclibc profile? -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] autotools support eclass
On Sunday 28 August 2005 07:28 am, Martin Schlemmer wrote: On Sun, 2005-08-28 at 01:59 -0400, Mike Frysinger wrote: On Saturday 27 August 2005 03:38 pm, Martin Schlemmer wrote: On Sat, 2005-08-27 at 15:11 -0400, Mike Frysinger wrote: On Saturday 27 August 2005 02:58 pm, Martin Schlemmer wrote: Which reminds me .. anybody going to scream if I update elibtoolize() to be able to check if it was already run, and then bug the portage guys to also add it to econf() ? do what now ? Make econf handle elibtoolize the same way it does gnuconfig ... why ? this would help us embedded peeps with uclibctoolize, but other than that ... maybe i just havent really sat down to figure out what elibtoolize does ... Because it applies the portage/relink/whatever patches to ltmain.sh without the need for real libtoolize and the pains that comes with it and a autoreconf (due to missing macro's, broken build system, etc). i guess if we can clean up the output to not complain when none of the patches are needed ... Note ... I really don`t think uclibctoolize and the other stuff that was added is really appropriate in libtool.eclass, as they touch config.guess, etc .. maybe it would have been better to update gnuconfig to try and apply the patch if in uclibc profile? uhh, uclibctoolize doesnt touch config.guess ... it only touches ltconfig/configure because libtool does not know about uClibc and thus will often disable shared library support when trying to build on a uClibc host -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] autotools support eclass
On Sun, 2005-08-28 at 12:50 -0400, Mike Frysinger wrote: On Sunday 28 August 2005 07:28 am, Martin Schlemmer wrote: On Sun, 2005-08-28 at 01:59 -0400, Mike Frysinger wrote: On Saturday 27 August 2005 03:38 pm, Martin Schlemmer wrote: On Sat, 2005-08-27 at 15:11 -0400, Mike Frysinger wrote: On Saturday 27 August 2005 02:58 pm, Martin Schlemmer wrote: Which reminds me .. anybody going to scream if I update elibtoolize() to be able to check if it was already run, and then bug the portage guys to also add it to econf() ? do what now ? Make econf handle elibtoolize the same way it does gnuconfig ... why ? this would help us embedded peeps with uclibctoolize, but other than that ... maybe i just havent really sat down to figure out what elibtoolize does ... Because it applies the portage/relink/whatever patches to ltmain.sh without the need for real libtoolize and the pains that comes with it and a autoreconf (due to missing macro's, broken build system, etc). i guess if we can clean up the output to not complain when none of the patches are needed ... Yeah, that is the plan. Note ... I really don`t think uclibctoolize and the other stuff that was added is really appropriate in libtool.eclass, as they touch config.guess, etc .. maybe it would have been better to update gnuconfig to try and apply the patch if in uclibc profile? uhh, uclibctoolize doesnt touch config.guess ... it only touches ltconfig/configure because libtool does not know about uClibc and thus will often disable shared library support when trying to build on a uClibc host Urk, my fault .. maybe its the macosx stuff then. Either way, how about integrating them rather with the default way elibtoolize() work? If you guys are game, I can do it so that the old still will work, and we can then drop the call to it and elibtoolize once its integrated into econf(). -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] autotools support eclass
On Sunday 28 August 2005 01:43 pm, Martin Schlemmer wrote: On Sun, 2005-08-28 at 12:50 -0400, Mike Frysinger wrote: On Sunday 28 August 2005 07:28 am, Martin Schlemmer wrote: On Sun, 2005-08-28 at 01:59 -0400, Mike Frysinger wrote: On Saturday 27 August 2005 03:38 pm, Martin Schlemmer wrote: On Sat, 2005-08-27 at 15:11 -0400, Mike Frysinger wrote: On Saturday 27 August 2005 02:58 pm, Martin Schlemmer wrote: Which reminds me .. anybody going to scream if I update elibtoolize() to be able to check if it was already run, and then bug the portage guys to also add it to econf() ? do what now ? Make econf handle elibtoolize the same way it does gnuconfig ... why ? this would help us embedded peeps with uclibctoolize, but other than that ... maybe i just havent really sat down to figure out what elibtoolize does ... Note ... I really don`t think uclibctoolize and the other stuff that was added is really appropriate in libtool.eclass, as they touch config.guess, etc .. maybe it would have been better to update gnuconfig to try and apply the patch if in uclibc profile? uhh, uclibctoolize doesnt touch config.guess ... it only touches ltconfig/configure because libtool does not know about uClibc and thus will often disable shared library support when trying to build on a uClibc host Urk, my fault .. maybe its the macosx stuff then. i make no claims as to the sanity of the OS X libtoolize as i had nothing to do with it :) Either way, how about integrating them rather with the default way elibtoolize() work? If you guys are game, I can do it so that the old still will work, and we can then drop the call to it and elibtoolize once its integrated into econf(). if you mean dropping uclibctoolize and integrating all of that stuff into the elibtoolize logic, then sure, feel free ... as long as we keep the patches sep though ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] autotools support eclass
On Sun, 2005-08-28 at 13:54 -0400, Mike Frysinger wrote: On Sunday 28 August 2005 01:43 pm, Martin Schlemmer wrote: On Sun, 2005-08-28 at 12:50 -0400, Mike Frysinger wrote: On Sunday 28 August 2005 07:28 am, Martin Schlemmer wrote: On Sun, 2005-08-28 at 01:59 -0400, Mike Frysinger wrote: On Saturday 27 August 2005 03:38 pm, Martin Schlemmer wrote: On Sat, 2005-08-27 at 15:11 -0400, Mike Frysinger wrote: On Saturday 27 August 2005 02:58 pm, Martin Schlemmer wrote: Which reminds me .. anybody going to scream if I update elibtoolize() to be able to check if it was already run, and then bug the portage guys to also add it to econf() ? do what now ? Make econf handle elibtoolize the same way it does gnuconfig ... why ? this would help us embedded peeps with uclibctoolize, but other than that ... maybe i just havent really sat down to figure out what elibtoolize does ... Note ... I really don`t think uclibctoolize and the other stuff that was added is really appropriate in libtool.eclass, as they touch config.guess, etc .. maybe it would have been better to update gnuconfig to try and apply the patch if in uclibc profile? uhh, uclibctoolize doesnt touch config.guess ... it only touches ltconfig/configure because libtool does not know about uClibc and thus will often disable shared library support when trying to build on a uClibc host Urk, my fault .. maybe its the macosx stuff then. i make no claims as to the sanity of the OS X libtoolize as i had nothing to do with it :) Either way, how about integrating them rather with the default way elibtoolize() work? If you guys are game, I can do it so that the old still will work, and we can then drop the call to it and elibtoolize once its integrated into econf(). if you mean dropping uclibctoolize and integrating all of that stuff into the elibtoolize logic, then sure, feel free ... as long as we keep the patches sep though ... Was thinking about creating uclibc-ltconfig and uclibc-configure patch sets and add that to $elt_patches ... -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
[gentoo-dev] [RFC] autotools support eclass
I was wondering last night with az about the handling of autotools.
They not always require to be re-run by scratch, but when you have to run
aclocal you usually have to run everything after that.
Every ebuild handles them in a different way, some ebuilds run them in a
list and then || die, others runs them one-by-one.
Some force updating of support files and some don't.
Some adds code to let them print the status to the screen, some hides the
actual output and some don't.
Attached there's an autotools eclass, it's basically a way to give more
information to the user while providing an epatch-like die message.
the eauto* calls are directly calls to the original command, without black
magic, with the only exception of automake that is called with -afc options
to let it update the support files.
eautoreconf instead is way different from autoreconf as it simply calls the
tools one after the other, adding the -I options to eaclocal when requested.
The sequence is aclocal, autoconf, autoheader, automake, gnuconfig_update and
libtoolize --copy --force (this seems to be needed quite everytime you run
aclocal.
Comments?
--
Diego Flameeyes Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v 1.194 2005/08/09
22:40:39 vapier Exp $
#
# Author: Diego Pettenò [EMAIL PROTECTED]
#
# This eclass is for handling autotooled software packages that
# needs to regenerate their build scripts.
#
# NB: If you add anything, please comment it!
inherit eutils gnuconfig
DELEND=sys-devel/automake
sys-devel/autoconf
sys-devel/libtool
# Internal function to run an autotools' tool
autotools_run_tool() {
local STDERR_TARGET=${T}/$$.out
local PATCH_TARGET=${T}/$$.patch
local ris
echo * $1 * ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/}
echo ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/}
ebegin Running $1
$@ ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/} 21
ris=$?
eend $ris
if [[ $ris != 0 ]]; then
echo
eerror Failed Running $1 !
eerror
eerror Include in your bugreport the contents of:
eerror
eerror ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/}
echo
die Failed Running $1 !
fi
}
# These functions runs the autotools using autotools_run_tool with the
# specified parametes. The name of the tool run is the same of the function
# without e prefix.
# They also force installing the support files for safety.
eaclocal() {
autotools_run_tool aclocal $@
}
eautoheader() {
autotools_run_tool autoheader $@
}
eautoconf() {
autotools_run_tool autoconf $@
}
eautomake() {
autotools_run_tool automake --add-missing --force-missing --copy $@
}
# This function mimes the behavior of autoreconf, but uses the different
# eauto* functions to run the tools. It doesn't accept parameters, but
# the directory with include files can be specified with M4DIR variable.
#
# Note: doesn't run autopoint right now, but runs gnuconfig_update.
eautoreconf() {
local aclocal_opts
[[ -n ${M4DIR} ]] aclocal_opts=-I ${M4DIR}
eaclocal $aclocal_opts
eautoconf
eautoheader
eautomake
gnuconfig_update
autotools_run_tool libtoolize --copy --force
}
pgpeFZeCcvU6r.pgp
Description: PGP signature
Re: [gentoo-dev] [RFC] autotools support eclass
On Sat, 2005-08-27 at 14:00 +0200, Diego 'Flameeyes' Pettenò wrote:
I was wondering last night with az about the handling of autotools.
They not always require to be re-run by scratch, but when you have to run
aclocal you usually have to run everything after that.
Every ebuild handles them in a different way, some ebuilds run them in a
list and then || die, others runs them one-by-one.
Some force updating of support files and some don't.
Some adds code to let them print the status to the screen, some hides the
actual output and some don't.
I still think a autoreconf is usually enough, except for cases where
that do not work, and then something like this will not work anyhow.
Anyhow, if you insist, then rather something like attached.
PS: elibtoolize is a problem as it might collide with the one from
libtool.eclass
--
Martin Schlemmer
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v 1.194 2005/08/09
22:40:39 vapier Exp $
#
# Author: Diego Pettenò [EMAIL PROTECTED]
# Enhancements: Martin Schlemmer [EMAIL PROTECTED]
#
# This eclass is for handling autotooled software packages that
# needs to regenerate their build scripts.
#
# NB: If you add anything, please comment it!
inherit eutils gnuconfig
DEPEND=sys-devel/automake
sys-devel/autoconf
sys-devel/libtool
# Internal function to run an autotools' tool
autotools_run_tool() {
local STDERR_TARGET=${T}/$$.out
local PATCH_TARGET=${T}/$$.patch
local ris
echo * $1 * ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/}
echo ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/}
ebegin Running $1
$@ ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/} 21
ris=$?
eend ${ris}
if [[ ${ris} != 0 ]]; then
echo
eerror Failed Running $1 !
eerror
eerror Include in your bugreport the contents of:
eerror
eerror ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/}
echo
die Failed Running $1 !
fi
}
# Internal function to check for support
autotools_check_macro() {
[[ -f configure.ac || -f configure.in ]] \
autoconf --trace=$1 2/dev/null
return 0
}
# Internal function to get additional subdirs to configure
autotools_get_subdirs() {
local subdirs_scan_out
subdirs_scan_out=$(autotools_check_macro AC_CONFIG_SUBDIRS)
[[ -n ${subdirs_scan_out} ]] || return 0
# Add --posix to below awk to make sure it will run on macosx, etc
echo ${subdirs_scan_out} | awk \
'($0 !~ /^[[:space:]]*(#|dnl)/) {
# The following is replaced by below, as we cannot use match()
# with a third argument with non-gawk (posix) versions of awk:
#
#if (match($0, AC_CONFIG_SUBDIRS\\(\\[?([^\])]*), res)) {
# split(substr($0, sindex), DIRS, /[\])]/)
# print DIRS[1]
#}
#
sindex = match($0, /AC_CONFIG_SUBDIRS\(\[?([^\])]*)/)
if (sindex 0) {
sindex += length(AC_CONFIG_SUBDIRS()
while (substr($0, sindex, 1) == [)
sindex++
split(substr($0, sindex), DIRS, /[\])]/)
print DIRS[1]
}
}' | uniq
return 0
}
# These functions runs the autotools using autotools_run_tool with the
# specified parametes. The name of the tool run is the same of the function
# without e prefix.
# They also force installing the support files for safety.
eaclocal() {
local aclocal_opts
[[ -n ${M4DIR} ]] aclocal_opts=-I \${M4DIR}\
[[ -f aclocal.m4 -n $(grep -e 'generated.*by aclocal' aclocal.m4) ]]
\
autotools_run_tool aclocal $@ ${aclocal_opts}
}
_elibtoolize() {
# Check if we should run libtoolize
[[ -n $(autotools_check_macro AC_PROG_LIBTOOL) ]] || return 0
autotools_run_tool libtoolize $@
# Need to rerun aclocal
eaclocal
}
eautoheader() {
# Check if we should run autoheader
[[ -n $(autotools_check_macro AC_CONFIG_HEADERS) ]] || return 0
autotools_run_tool autoheader $@
}
eautoconf() {
if [[ ! -f configure.ac ! -f configure.in ]] ; then
echo
eerror No configure.{ac,in} present in '$(pwd | sed -e
's:.*/::')'!
echo
die No configure.{ac,in} present!
fi
autotools_run_tool autoconf $@
}
eautomake() {
[[ -f Makefile.am ]] || return 0
autotools_run_tool automake --add-missing --force-missing --copy $@
}
# This function mimes the behavior of autoreconf, but
Re: [gentoo-dev] [RFC] autotools support eclass
On Sat, 2005-08-27 at 16:24 +0200, Martin Schlemmer wrote:
On Sat, 2005-08-27 at 14:00 +0200, Diego 'Flameeyes' Pettenò wrote:
I was wondering last night with az about the handling of autotools.
They not always require to be re-run by scratch, but when you have to run
aclocal you usually have to run everything after that.
Every ebuild handles them in a different way, some ebuilds run them in a
list and then || die, others runs them one-by-one.
Some force updating of support files and some don't.
Some adds code to let them print the status to the screen, some hides the
actual output and some don't.
I still think a autoreconf is usually enough, except for cases where
that do not work, and then something like this will not work anyhow.
Anyhow, if you insist, then rather something like attached.
PS: elibtoolize is a problem as it might collide with the one from
libtool.eclass
Apparently I can now use gawk on all the bsd's. I am touchy about
adding gawk/whatever to the DEPEND, as it sometimes causes issues during
'emerge system' if its in a very base package ...
--
Martin Schlemmer
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v 1.194 2005/08/09
22:40:39 vapier Exp $
#
# Author: Diego Pettenò [EMAIL PROTECTED]
# Enhancements: Martin Schlemmer [EMAIL PROTECTED]
#
# This eclass is for handling autotooled software packages that
# needs to regenerate their build scripts.
#
# NB: If you add anything, please comment it!
inherit eutils gnuconfig
DEPEND=sys-devel/automake
sys-devel/autoconf
sys-devel/libtool
# Internal function to run an autotools' tool
autotools_run_tool() {
local STDERR_TARGET=${T}/$$.out
local PATCH_TARGET=${T}/$$.patch
local ris
echo * $1 * ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/}
echo ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/}
ebegin Running $1
$@ ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/} 21
ris=$?
eend ${ris}
if [[ ${ris} != 0 ]]; then
echo
eerror Failed Running $1 !
eerror
eerror Include in your bugreport the contents of:
eerror
eerror ${STDERR_TARGET%/*}/$1-${STDERR_TARGET##*/}
echo
die Failed Running $1 !
fi
}
# Internal function to check for support
autotools_check_macro() {
[[ -f configure.ac || -f configure.in ]] \
autoconf --trace=$1 2/dev/null
return 0
}
# Internal function to get additional subdirs to configure
autotools_get_subdirs() {
local subdirs_scan_out
subdirs_scan_out=$(autotools_check_macro AC_CONFIG_SUBDIRS)
[[ -n ${subdirs_scan_out} ]] || return 0
echo ${subdirs_scan_out} | gawk \
'($0 !~ /^[[:space:]]*(#|dnl)/) {
if (match($0, AC_CONFIG_SUBDIRS\\(\\[?([^\\])]*), res)) {
split(res[1], DIRS, /[\])]/)
print DIRS[1]
}
}' | uniq
return 0
}
# These functions runs the autotools using autotools_run_tool with the
# specified parametes. The name of the tool run is the same of the function
# without e prefix.
# They also force installing the support files for safety.
eaclocal() {
local aclocal_opts
[[ -n ${M4DIR} ]] aclocal_opts=-I \${M4DIR}\
[[ -f aclocal.m4 -n $(grep -e 'generated.*by aclocal' aclocal.m4) ]]
\
autotools_run_tool aclocal $@ ${aclocal_opts}
}
_elibtoolize() {
# Check if we should run libtoolize
[[ -n $(autotools_check_macro AC_PROG_LIBTOOL) ]] || return 0
autotools_run_tool libtoolize $@
# Need to rerun aclocal
eaclocal
}
eautoheader() {
# Check if we should run autoheader
[[ -n $(autotools_check_macro AC_CONFIG_HEADERS) ]] || return 0
autotools_run_tool autoheader $@
}
eautoconf() {
if [[ ! -f configure.ac ! -f configure.in ]] ; then
echo
eerror No configure.{ac,in} present in '$(pwd | sed -e
's:.*/::')'!
echo
die No configure.{ac,in} present!
fi
autotools_run_tool autoconf $@
}
eautomake() {
[[ -f Makefile.am ]] || return 0
autotools_run_tool automake --add-missing --force-missing --copy $@
}
# This function mimes the behavior of autoreconf, but uses the different
# eauto* functions to run the tools. It doesn't accept parameters, but
# the directory with include files can be specified with M4DIR variable.
#
# Note: doesn't run autopoint right now, but runs gnuconfig_update.
eautoreconf() {
local pwd=$(pwd) x
# Take care of subdirs
for x in $(autotools_get_subdirs); do
if [[ -d ${x} ]] ; then
Re: [gentoo-dev] [RFC] autotools support eclass
On Sat, Aug 27, 2005 at 04:24:40PM +0200, Martin Schlemmer wrote: I still think a autoreconf is usually enough, except for cases where that do not work, And what is not work in this case? - fails with an error so it's impossible to miss as a dev, or - fails to do things properly, causing subtle bugs that users will run into -- Maurice van der Pot Gentoo Linux Developer [EMAIL PROTECTED] http://www.gentoo.org Creator of BiteMe! [EMAIL PROTECTED] http://www.kfk4ever.com pgpW5R7V5dLo5.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] autotools support eclass
On Sat, 27 Aug 2005 14:00:06 +0200 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | Attached there's an autotools eclass, it's basically a way to give | more information to the user while providing an epatch-like die | message. the eauto* calls are directly calls to the original command, | without black magic, with the only exception of automake that is | called with -afc options to let it update the support files. I don't like it. It removes the ability to DEPEND (which you spelt wrong, btw) upon the correct auto* version. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpOX2XlqTZuN.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] autotools support eclass
On Saturday 27 August 2005 17:53, Ciaran McCreesh wrote: I don't like it. It removes the ability to DEPEND (which you spelt wrong, btw) upon the correct auto* version. Yeah I know I typoed. About the version.. well you just can't depend upon a specified version anyway. When you depend on whatever autoconf it depends on autoconf-wrapper, that depends on both the version of autoconf we have. The same goes for automake. So the version stuff just don't make sense anymore right now... -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpgLx00HnSmc.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] autotools support eclass
On Sat, 27 Aug 2005 18:05:19 +0200 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | On Saturday 27 August 2005 17:53, Ciaran McCreesh wrote: | I don't like it. It removes the ability to DEPEND (which you spelt | wrong, btw) upon the correct auto* version. | Yeah I know I typoed. | About the version.. well you just can't depend upon a specified | version anyway. | When you depend on whatever autoconf it depends on autoconf-wrapper, | that depends on both the version of autoconf we have. | The same goes for automake. The circular autothing - wrapper dependency will be phased out at some point in the future once all auto* deps properly specify versions. The aim is to remove the need to install certain obscure auto* slots that are becoming rarer and rarer. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpzick6U8xjO.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] autotools support eclass
On Saturday 27 August 2005 18:11, Ciaran McCreesh wrote: The circular autothing - wrapper dependency will be phased out at some point in the future once all auto* deps properly specify versions. The aim is to remove the need to install certain obscure auto* slots that are becoming rarer and rarer. Well then it can be tweaked to include just the wrapper dependencies, leaving to the ebuild to specify the dependency on the right autotool, so that if the right autotool will be missing we have a meaningful message? -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgphRvfAymUXA.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] autotools support eclass
On Sat, 2005-08-27 at 17:51 +0200, Maurice van der Pot wrote:
On Sat, Aug 27, 2005 at 04:24:40PM +0200, Martin Schlemmer wrote:
I still think a autoreconf is usually enough, except for cases where
that do not work,
And what is not work in this case?
- fails with an error so it's impossible to miss as a dev, or
- fails to do things properly, causing subtle bugs that users will run into
Some guy doing a half ass job on writing configure.{ac,in}, Makefile.am
and whatever other helper scripts causing either autoreconf to fail, or
errors during building.
Don't ask for an example .. I cannot recall now, but I have run into a
few packages in the past.
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] autotools support eclass
On Saturday 27 August 2005 08:00 am, Diego 'Flameeyes' Pettenò wrote:
eautoreconf() {
local aclocal_opts
[[ -n ${M4DIR} ]] aclocal_opts=-I ${M4DIR}
eaclocal $aclocal_opts
eautoconf
eautoheader
eautomake
gnuconfig_update
autotools_run_tool libtoolize --copy --force
}
the gnuconfig isnt really needed ... econf handles all of that for you
-mike
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] autotools support eclass
On Sat, 2005-08-27 at 14:37 -0400, Mike Frysinger wrote:
On Saturday 27 August 2005 08:00 am, Diego 'Flameeyes' Pettenò wrote:
eautoreconf() {
local aclocal_opts
[[ -n ${M4DIR} ]] aclocal_opts=-I ${M4DIR}
eaclocal $aclocal_opts
eautoconf
eautoheader
eautomake
gnuconfig_update
autotools_run_tool libtoolize --copy --force
}
the gnuconfig isnt really needed ... econf handles all of that for you
Which reminds me .. anybody going to scream if I update elibtoolize() to
be able to check if it was already run, and then bug the portage guys to
also add it to econf() ?
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] autotools support eclass
On Saturday 27 August 2005 02:58 pm, Martin Schlemmer wrote:
On Sat, 2005-08-27 at 14:37 -0400, Mike Frysinger wrote:
On Saturday 27 August 2005 08:00 am, Diego 'Flameeyes' Pettenò wrote:
eautoreconf() {
local aclocal_opts
[[ -n ${M4DIR} ]] aclocal_opts=-I ${M4DIR}
eaclocal $aclocal_opts
eautoconf
eautoheader
eautomake
gnuconfig_update
autotools_run_tool libtoolize --copy --force
}
the gnuconfig isnt really needed ... econf handles all of that for you
Which reminds me .. anybody going to scream if I update elibtoolize() to
be able to check if it was already run, and then bug the portage guys to
also add it to econf() ?
do what now ?
-mike
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] autotools support eclass
On Sat, 2005-08-27 at 15:11 -0400, Mike Frysinger wrote:
On Saturday 27 August 2005 02:58 pm, Martin Schlemmer wrote:
On Sat, 2005-08-27 at 14:37 -0400, Mike Frysinger wrote:
On Saturday 27 August 2005 08:00 am, Diego 'Flameeyes' Pettenò wrote:
eautoreconf() {
local aclocal_opts
[[ -n ${M4DIR} ]] aclocal_opts=-I ${M4DIR}
eaclocal $aclocal_opts
eautoconf
eautoheader
eautomake
gnuconfig_update
autotools_run_tool libtoolize --copy --force
}
the gnuconfig isnt really needed ... econf handles all of that for you
Which reminds me .. anybody going to scream if I update elibtoolize() to
be able to check if it was already run, and then bug the portage guys to
also add it to econf() ?
do what now ?
Make econf handle elibtoolize the same way it does gnuconfig ...
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
