[gentoo-dev] [RFC] autotools support eclass

[gentoo-dev] [RFC] autotools support eclass

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1.1: Type: text/plain, Size: 1310 bytes --]

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)

[-- Attachment #1.2: autotools.eclass --]
[-- Type: text/plain, Size: 2164 bytes --]

# 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ò <flameeyes@gentoo.org>
#
# 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##*/} 2>&1
	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
}

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] autotools support eclass

[Martin Schlemmer]

[-- Attachment #1.1: Type: text/plain, Size: 902 bytes --]

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


[-- Attachment #1.2: autotools.eclass --]
[-- Type: text/plain, Size: 4094 bytes --]

# 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ò <flameeyes@gentoo.org>
# Enhancements: Martin Schlemmer <azarah@gentoo.org>
#
# 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##*/} 2>&1
	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 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
			cd "${x}"
			eautoreconf
			cd "${pwd}"
		fi
	done

	eaclocal
	_elibtoolize --copy --force
	eautoconf
	eautoheader
	eautomake
	gnuconfig_update
}

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] autotools support eclass

[Martin Schlemmer]

[-- Attachment #1.1: Type: text/plain, Size: 1197 bytes --]

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


[-- Attachment #1.2: autotools.eclass --]
[-- Type: text/plain, Size: 3623 bytes --]

# 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ò <flameeyes@gentoo.org>
# Enhancements: Martin Schlemmer <azarah@gentoo.org>
#
# 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##*/} 2>&1
	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
			cd "${x}"
			eautoreconf
			cd "${pwd}"
		fi
	done

	eaclocal
	_elibtoolize --copy --force
	eautoconf
	eautoheader
	eautomake
	gnuconfig_update
}

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] autotools support eclass

[Maurice van der Pot]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

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   griffon26@gentoo.org     http://www.gentoo.org
Creator of BiteMe!       griffon26@kfk4ever.com   http://www.kfk4ever.com


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] autotools support eclass

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

On Sat, 27 Aug 2005 14:00:06 +0200 "Diego 'Flameeyes' Pettenò"
<flameeyes@gentoo.org> 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


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] autotools support eclass

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

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)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] autotools support eclass

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 968 bytes --]

On Sat, 27 Aug 2005 18:05:19 +0200 "Diego 'Flameeyes' Pettenò"
<flameeyes@gentoo.org> 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


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] autotools support eclass

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

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)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] autotools support eclass

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] autotools support eclass

[Mike Frysinger]

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

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] autotools support eclass

[Mike Frysinger]

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

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] autotools support eclass

[Mike Frysinger]

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

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] autotools support eclass

[Mike Frysinger]

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

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] autotools support eclass

[Mike Frysinger]

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

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 2404 bytes --]

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


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]