[gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
Brian Harring wrote: I don't recall having kde/gtk crap turned on by default when I first showed up. Maybe I'm missing something; regardless, the defaults (which should be minimal from my standpoint) are anything but. I think you recall wrong, then. The default USE flags have been set so that the majority of systems will work properly without modifications, not so that they're the minimal set. The purpose of being able to negate USE flags in lower cascaded profiles is pointless if each level is the minimum. I think it makes more sense to have each level be a reasonable default that most people would prefer, then have weird exceptions subtract it. Donnie -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
Note, sending to dev only, not cc'ing core; the inital -core post was to make sure those who aren't watching dev ml see the email (annoying, but it's an old habit I've yet to kick despite needing to). On Sat, Aug 27, 2005 at 04:48:26AM -0500, Donnie Berkholz wrote: Brian Harring wrote: I don't recall having kde/gtk crap turned on by default when I first showed up. Maybe I'm missing something; regardless, the defaults (which should be minimal from my standpoint) are anything but. I think you recall wrong, then. The default USE flags have been set so that the majority of systems will work properly without modifications, not so that they're the minimal set. Already stated that it's entirely possible my memory is whacked, that said my point still stands. The purpose of being able to negate USE flags in lower cascaded profiles is pointless if each level is the minimum. I think it makes more sense to have each level be a reasonable default that most people would prefer, then have weird exceptions subtract it. Note I'm not advocating every level of the profile be bare minimal, with the end nodes having tons jammed into it; I'm advocating exactly what you're stating. Chunk the sucker up, shifting stuff around just the same as you would if you were designing base classes to be inherited. The thing to note is that if you're relying on negation, it's going to bite you in the ass without efforts. A server subprofile pulling from a parent that holds desktop cruft will be forced to either A) reinvent the wheel (maintain their own USE list), as a sizable chunk of users do via -* usage B) or very carefully watch people screwing around with the parent, tagging in a new desktop USE var, and adding the matching negation. What I'm advocating is that the '05 profile (fex) tag in the defaults for that profile release, desktop/server agnostic, *system* defaults, eg toolchain, pam, nptl, etc. The subprofile the user chooses (the desktop or server target) building upon those base settngs. Multiple inherits for profiles is the main reason I'm not pushing on this; shifting desktop cruft out of the bases (my definition of base mind you) requires pulling from (fex) x86/2005.1 + desktop/2005.1 . My 2 cents at least. ~harring pgp3jPtVK3rmH.pgp Description: PGP signature
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On 27/8/2005 10:42:25, Brian Harring ([EMAIL PROTECTED]) wrote: Hola all. Straight to the point, I'm proposing that the following files- arch.list categories use.desc use.local.desc package.mask updates be moved out of the profiles directory in the tree Not sure about package.mask. I thought that was part of the profile, as different profiles might package.mask separately. I know I use it in /etc/profile to postpone updates. As far as the others are concerned I'd agree they're not profile data. Kev. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On Sat, Aug 27, 2005 at 01:17:50PM +0200, Kevin F. Quinn wrote: On 27/8/2005 10:42:25, Brian Harring ([EMAIL PROTECTED]) wrote: Hola all. Straight to the point, I'm proposing that the following files- arch.list categories use.desc use.local.desc package.mask updates be moved out of the profiles directory in the tree Not sure about package.mask. I thought that was part of the profile, as different profiles might package.mask separately. I know I use it in /etc/profile to postpone updates. Rough filtering stack- profiles/package.mask /etc/make.profile/package.mask (incremental through subprofiles) users package.mask, and users package.unmask Ordered it in that fashion to show that it's effectively repository filtering, profile filtering, user filtering; if you view it as seperate entities with filters stacked up (how the rewrite implements it), package.mask being repository metadata becomes clear. Basically, think of it this way; what files/data *must* stay with a repository? If I'm using (say) gentopia ebuilds, the p.mask they use is specific to _their_ repository; my official gentoo repository should not be p.mask'ing there stuff, it should only affect itself, and any repository that is slaved to it (overlays, which aren't stand alone). At least that's what I think :) ~harring pgpDVd29qJQ0C.pgp Description: PGP signature
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On Sat, Aug 27, 2005 at 01:32:33PM +0200, Fernando J. Pereda wrote: On Sat, Aug 27, 2005 at 01:17:50PM +0200, Kevin F. Quinn wrote: Not sure about package.mask. I thought that was part of the profile, as different profiles might package.mask separately. I know I use it in /etc/profile to postpone updates. In fact the arch teams use it to mask packages that won't work on a particular profile/arch. If package.mask is removed from the profiles directory does it mean we won't be able to do that anymore ? You're masking occurs within the profile itself, not globally. Global masking usually is for introduction of new ebuilds that need testing and shouldn't be hit by normal arch testers (portage early release candidates for example); if you're blocking valgrind on arm (fex), you *should* be blocking it in profiles/default-linux/arm, not profiles/package.mask ;) If it's profile specified files, relax, not targeted :). Strictly after getting the global data out of there, and into a directory reflecting that data's actual role within the repository, and makes sense in a more flexible, non single $PORTDIR+$PORTDIR_OVERlAY environment. Aside from that, see my other email re: the seperate levels of filtering :) ~harring pgpDGxBzbNfMb.pgp Description: PGP signature
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On Sat, Aug 27, 2005 at 06:38:36AM -0500, Brian Harring wrote: You're masking occurs within the profile itself, not globally. Global masking usually is for introduction of new ebuilds that need testing and shouldn't be hit by normal arch testers (portage early release candidates for example); if you're blocking valgrind on arm (fex), you *should* be blocking it in profiles/default-linux/arm, not profiles/package.mask ;) If it's profile specified files, relax, not targeted :). Strictly after getting the global data out of there, and into a directory reflecting that data's actual role within the repository, and makes sense in a more flexible, non single $PORTDIR+$PORTDIR_OVERlAY environment. Aside from that, see my other email re: the seperate levels of filtering :) ~harring That clarified it for me :) Thanks Ferdy -- \\|// . . . o o o o O O ( Born to be ) o o ( FREE ) +--ooO--O--Ooo---+ | Fernando José Pereda Garcimartín - http://www.ferdyx.org | | Gentoo Linux Developer - http://dev.gentoo.org/~ferdy | | [ ferdy AT ferdyx DOT org ] [ ferdy AT gentoo DOT org ] | | 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 | ++ pgphtFffPFpHO.pgp Description: PGP signature
[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] proposed shift of files in the tree of non profiles files into seperate dir
On 27/8/2005 13:34:15, Brian Harring ([EMAIL PROTECTED]) wrote: Rough filtering stack- profiles/package.mask /etc/make.profile/package.mask (incremental through subprofiles) users package.mask, and users package.unmask Ordered it in that fashion to show that it's effectively repository filtering, profile filtering, user filtering; if you view it as seperate entities with filters stacked up (how the rewrite implements it), package.mask being repository metadata becomes clear. Would it make sense to simply relocate the global package.mask and package.unmask to the base profile from which all profiles derive (haven't checked that they all do)? Users's data could be placed in the users profile at /etc/portage/profile instead of /etc/portage, and the concept of global package mask/unmask as repository metadata would go away. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] proposed shift of files in the tree of non profiles files into seperate dir
On Sat, Aug 27, 2005 at 03:29:32PM +0200, Kevin F. Quinn wrote: On 27/8/2005 13:34:15, Brian Harring ([EMAIL PROTECTED]) wrote: Rough filtering stack- profiles/package.mask /etc/make.profile/package.mask (incremental through subprofiles) users package.mask, and users package.unmask Ordered it in that fashion to show that it's effectively repository filtering, profile filtering, user filtering; if you view it as seperate entities with filters stacked up (how the rewrite implements it), package.mask being repository metadata becomes clear. Would it make sense to simply relocate the global package.mask and package.unmask to the base profile from which all profiles derive (haven't checked that they all do)? No global unmask; What you're proposing is actually exactly what I'm against; if I choose to use my own profile that's not bound to the tree's profile, I should still have my repository masked by the global profile.mask that's in it. Shifting it to base profile forces me to either copy the package.mask (or symlink it, which isn't possible in remote), or do without it (bad, able to hit packages with security holes and stuff that shouldn't be used). repository package.mask is a seperate filter from profile filter.mask, basically. Users's data could be placed in the users profile at /etc/portage/profile instead of /etc/portage, and the concept of global package mask/unmask as repository metadata would go away. global p.mask is a seperate thing from profile specific p.mask, which is the basis of me wanting it moved out of there :) ~harring pgpUK00XA3PyJ.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] why does gcc-3.4.x depend on gcc-3.3.x / libstdc++?
maillog: 27/08/2005-02:46:03(+0200): Bjarke Istrup Pedersen types I must say I have been wondering about this for a while too. A solution might be add some sort of flag to packages that are binary, and then let portage install libstdc++ the first time you install this kind of package. You mean, like have binary packages depend on virtual/libstdc++-SOMEVERSION and have virtual/libstdc++ provided by gcc or the split-out libstdc++ ebuild? Mike Frysinger skrev: On Fri, Aug 26, 2005 at 10:14:04AM +0100, Chris Bainbridge wrote: Subject says it all - is there any reason why 3.4.4 installs either gcc-3.3* or libstdc++-v3 built with gcc-3.3? because i got tired of people complaining about broken systems when they emerged gcc-3.4.4 and cleaned out all gcc-3.3.x versions from their system Is it possible to compile a native 3.4 system without the old gcc if I don't need binary compatibility? i just add libstdc++-v3 to my package.provided in /etc/portage/profile/ and call it a day i dont really see there being a clean solution until we have portage support to track ABI dependencies -mike -- gentoo-dev@gentoo.org mailing list -- \Georgi Georgiev \ Professor: This is gonna be one hell of a \ /[EMAIL PROTECTED] / bowel movement. Afterwards, he'll be lucky/ \ +81(90)2877-8845 \ if he has any bones left.\ pgpsPIa2KADCP.pgp Description: PGP signature
Re: [gentoo-dev] why does gcc-3.4.x depend on gcc-3.3.x / libstdc++?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bjarke Istrup Pedersen wrote: I must say I have been wondering about this for a while too. A solution might be add some sort of flag to packages that are binary, and then let portage install libstdc++ the first time you install this kind of package. This does not solve the following problem: 1. user upgrades to gcc-3.4.x 2. gcc-config to 3.4.x 3. emerge -P gcc Because libstdc++ has a different name (.6) in 3.4.x than the .5 in 3.3.X all the packages linked against the old one are borked and this includes python meaning that emerge does not work until you for example make a symlink from the .6 to .5. I recently run into this when reinstalling my desktop after a broken hard drive. Regards, Petteri Räty (Betelgeuse) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDEHpTcxLzpIGCsLQRAoOLAJwPpe3od7YvvqpQQkFE5zKbvEQgQQCdG7KG f07PYC8yAD+EJuBzyjT7cX8= =Trg6 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
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
[gentoo-dev] Conversion to linux-mod.eclass - deprecation of kernel-mod.eclass
Hi, the kernel team has announced this already some time ago, but there are still some ebuilds in the tree using kernel-mod.eclass in there latest version: sci-misc/comedi/comedi-0.7.68.ebuild: herd: no-herd dev: caleb media-video/mplayer/mplayer-1.0_pre7.ebuild: herd: video net-firewall/tuxfrw/tuxfrw-2.58-r1.ebuild: herd: netmon dev: angusyoung Please convert your ebuilds to linux-mod.eclass. You can find help at the top of the eclass and in the #gentoo-kernel irc channel. For the full list including older versions of pkges see: http://dev.gentoo.org/~genstef/files/remaining-kernel-mod-ebuilds If you maintain one of those please remove them from the tree and mark newer versions stable if applicable. Regards, Stefan pgp6ErY3MXb69.pgp Description: PGP signature
