[2020-03-26 17:47:35+] Samuel Bernardo:
> I send this email to ask you for your help for the better approach to
> translate the following autoreconf command to an ebuild:
>
> > |autoreconf -i -f ./configure \ --prefix=/usr \
> > --libexecdir=/usr/lib/snapd \
> > --with-snap-mount-dir=/var/lib/
Dear all,
I send this email to ask you for your help for the better approach to
translate the following autoreconf command to an ebuild:
> |autoreconf -i -f ./configure \ --prefix=/usr \
> --libexecdir=/usr/lib/snapd \
> --with-snap-mount-dir=/var/lib/snapd/snap \ --enable-apparmor \
> --enable-n
Currently, each of the mentioned eclasses has its own *_BUILD_DIR.
Therefore, if someone needs to provide a custom BUILD_DIR, he needs to
set it explicitly for the eclass. This is fine for ebuilds but not
really neat for eclasses.
The idea is simple: use a common BUILD_DIR instead. For compatibili
On Friday 12 January 2007 13:37, Alon Bar-Lev wrote:
> After you commit this
Diego already did
-mike
--
gentoo-dev@gentoo.org mailing list
On Friday 12 January 2007 13:14, Mike Frysinger wrote:
> if/when an issue comes up where someone is
> inheriting autotools but they're using it conditionally, we'll revisit this
seems Diego is two steps ahead ... set the vars to "none" :)
-mike
pgpt5VjQENLt7.pgp
Description: PGP signature
On 1/12/07, Mike Frysinger <[EMAIL PROTECTED]> wrote:
On Sunday 07 January 2007 11:27, Alon Bar-Lev wrote:
> 1. Add default.
we've gone this route ... if/when an issue comes up where someone is
inheriting autotools but they're using it conditionally, we'll revisit this
autotools.eclass:
[[ -z $
On Sunday 07 January 2007 11:27, Alon Bar-Lev wrote:
> 1. Add default.
we've gone this route ... if/when an issue comes up where someone is
inheriting autotools but they're using it conditionally, we'll revisit this
autotools.eclass:
[[ -z ${WANT_AUTOCONF} ]] && WANT_AUTOCONF="latest"
[[ -z ${WA
On 1/7/07, Mike Frysinger <[EMAIL PROTECTED]> wrote:
On Saturday 06 January 2007 13:32, Diego 'Flameeyes' Pettenò wrote:
> On Saturday 06 January 2007 19:23, Mike Frysinger wrote:
> > why not just get rid of the idea of "latest" ? is there a scenario where
> > autotools would be inherited but not
On Saturday 06 January 2007 13:32, Diego 'Flameeyes' Pettenò wrote:
> On Saturday 06 January 2007 19:23, Mike Frysinger wrote:
> > why not just get rid of the idea of "latest" ? is there a scenario where
> > autotools would be inherited but not actually used/added to DEPEND ? i
> > guess that's w
On Saturday 06 January 2007 19:23, Mike Frysinger wrote:
> why not just get rid of the idea of "latest" ? is there a scenario where
> autotools would be inherited but not actually used/added to DEPEND ? i
> guess that's what this all comes down to really ...
If autotools were to be inherited by a
On Saturday 06 January 2007 13:00, Diego 'Flameeyes' Pettenò wrote:
> On Saturday 06 January 2007 18:25, Mike Frysinger wrote:
> > the reason was so in the *eclass* you could translate latest to "1.10
> > 1.9" and drop the need of executing that helper function in local scope
>
> Right, but I thoug
On Saturday 06 January 2007 18:25, Mike Frysinger wrote:
> the reason was so in the *eclass* you could translate latest to "1.10 1.9"
> and drop the need of executing that helper function in local scope
Right, but I thought the other one, too..
Well, I suppose it would do little harm at this point
On Saturday 06 January 2007 11:05, Diego 'Flameeyes' Pettenò wrote:
> On Saturday 06 January 2007 16:42, Mike Frysinger wrote:
> > what does it matter if all of the ebuilds declare latest or the eclass
> > declares latest ?
>
> Weren't we going to allow declaring "1.10 1.9" soon, so that we could s
On Saturday 06 January 2007 16:42, Mike Frysinger wrote:
> what does it matter if all of the ebuilds declare latest or the eclass
> declares latest ?
Weren't we going to allow declaring "1.10 1.9" soon, so that we could stop
using "latest" ?
--
Diego "Flameeyes" Pettenò - http://farragut.flameey
On Saturday 06 January 2007 10:22, Diego 'Flameeyes' Pettenò wrote:
> On Saturday 06 January 2007 11:10, Alon Bar-Lev wrote:
> > Is there any reason why not setting "latest" as default for WANT_AUTO*
> > variables?
>
> Because then stuff will "magically" work in stable, and break in ~arch, and
> yo
On Saturday 06 January 2007 09:47, Kevin F. Quinn wrote:
> Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > On Saturday 06 January 2007 05:10, Alon Bar-Lev wrote:
> > > Is there any reason why not setting "latest" as default for
> > > WANT_AUTO* variables?
> > >
> > > I believe that an ebuild should s
On Saturday 06 January 2007 11:10, Alon Bar-Lev wrote:
> Is there any reason why not setting "latest" as default for WANT_AUTO*
> variables?
Because then stuff will "magically" work in stable, and break in ~arch, and
you won't know why it's happening.
Instead if you follow the procedure (set the
On 1/6/07, Kevin F. Quinn <[EMAIL PROTECTED]> wrote:
Not sure. Would we run the risk that working ebuilds would start to
fail when newer autotools versions arrive?
So what do you suggest of putting? Current revision?
And we can drop the "latest" support... right?
But then we should handle old
On Sat, 6 Jan 2007 05:21:48 -0500
Mike Frysinger <[EMAIL PROTECTED]> wrote:
> On Saturday 06 January 2007 05:10, Alon Bar-Lev wrote:
> > Is there any reason why not setting "latest" as default for
> > WANT_AUTO* variables?
> >
> > I believe that an ebuild should set these variables only if there i
On Saturday 06 January 2007 05:10, Alon Bar-Lev wrote:
> Is there any reason why not setting "latest" as default for WANT_AUTO*
> variables?
>
> I believe that an ebuild should set these variables only if there is
> some exception.
that seems like a not-too-shabby idea actually
-mike
pgp7qE8JnVb
Hello,
Is there any reason why not setting "latest" as default for WANT_AUTO*
variables?
I believe that an ebuild should set these variables only if there is
some exception.
Best Regards,
Alon Bar-Lev.
--
gentoo-dev@gentoo.org mailing list
On Wednesday 05 July 2006 22:05, Marcus Furlong wrote:
> Running 'configure' goes fine, but running 'make' just keeps running
> configure over and over.
It's commonly caused when the timestamp of configure and the sources for
configure are messed up. Make sure no file has modification time in the
Hi,
I am trying to create an ebuild for the icecream monitor available at
ftp://ftp.suse.com/pub/projects/icecream/icemon-kde3.tar.bz2
Running 'configure' goes fine, but running 'make' just keeps running
configure over and over. If there's any autotools gurus who can have a
quick look, it'd be
23 matches
Mail list logo
