Couple of questions:
1) Can it handle non-gcc compilers? If so, how?
It is possible, but I'm not sure if icc is installed in a way that
makes it convenient. All the binaries will need to be lumped in a
directory by themselves (like we do with gcc). You'll have to create
your own
Well, incidentally I was working on toolchainasing gnat (a gcc
based Ada
compiler, basically just another frontend) and pestered toolchain
people on
irc regarding similar matters. Basically it came down to:
toolchain.eclass
and eselect-compiler are not for stuff not in gcc, so I had to
On Jun 2, 2006, at 21:33 , Donnie Berkholz wrote:
Couple of questions:
1) Can it handle non-gcc compilers? If so, how?
It is possible, but I'm not sure if icc is installed in a way that
makes it convenient. All the binaries will need to be lumped in a
directory by themselves (like we do
On Sat, Jun 03, 2006 at 09:11:38PM -0600, Ryan Hill wrote:
LIRC_DEVICE? most of the USE_EXPAND stuff seems to be named for the device
rather than the driver. eg. ALSA_CARDS, VIDEO_CARDS, INPUT_DEVICES.
The ones you just mentioned all refer to driver names.
Regards,
Brix
--
Henrik Brix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Henrik Brix Andersen wrote:
On Sat, Jun 03, 2006 at 09:11:38PM -0600, Ryan Hill wrote:
LIRC_DEVICE? most of the USE_EXPAND stuff seems to be named for the device
rather than the driver. eg. ALSA_CARDS, VIDEO_CARDS, INPUT_DEVICES.
The ones you
On Thursday 01 June 2006 14:30, Josh Saddler wrote:
Jan Kundrát wrote:
Wiktor Wandachowicz wrote:
Summing up:
* UTF-8 manuals: good or bad?
The Only Way To Go (tm), IMHO. Let's let the legacy encodings die in
piece.
Agreed. I'd like to see much more extensive use of Unicode throughout
On Thursday 01 June 2006 19:37, Matteo Azzali wrote:
XMLTV_OPTS isn't accessible anymore through the ebuild (tomorrow it
was).
So I'll need a TV_GRAB expanded variable to avoid having 200 local flags.
how about a better variable name ? TV_GRAB is kind of awful
-mike
pgp8cjmq5iMBe.pgp
Well, TV_GRAB is synthetical , but explains what this variable
is,however, how about TV_GRABBER or
TV_LOCALE or TV_GRABBER_LOC ?
Any suggestion is listened
-mattepiu
Mike Frysinger wrote:
On Thursday 01 June 2006 19:37, Matteo Azzali wrote:
XMLTV_OPTS isn't accessible anymore through
On Sunday 04 June 2006 06:03, Matteo Azzali wrote:
Well, TV_GRAB is synthetical , but explains what this variable
is,however, how about TV_GRABBER or
TV_LOCALE or TV_GRABBER_LOC ?
all same quality
what about TV_CAPTURE_CARDS
-mike
pgpJguhwqrXMM.pgp
Description: PGP signature
On Sunday 04 June 2006 14:56, Mike Frysinger wrote:
what about TV_CAPTURE_CARDS
You got it quite wrong, it's not about the TV cards :)
It's about TV guide grabbers.
--
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM,
Diego 'Flameeyes' Pettenò wrote:
On Sunday 04 June 2006 14:56, Mike Frysinger wrote:
what about TV_CAPTURE_CARDS
You got it quite wrong, it's not about the TV cards :)
It's about TV guide grabbers.
TV_GUIDE_GRABBERS
see that was easy ;)
--
gentoo-dev@gentoo.org mailing list
On Sunday 04 June 2006 08:59, Diego 'Flameeyes' Pettenò wrote:
On Sunday 04 June 2006 14:56, Mike Frysinger wrote:
what about TV_CAPTURE_CARDS
You got it quite wrong, it's not about the TV cards :)
It's about TV guide grabbers.
then i guess Matteo's assumption that 'TV_GRAB' was
On Monday 29 May 2006 20:13, Jakub Moc wrote:
Otherwise, some review used to be done, but there's been a negative
opinion about closing bugs w/ sucky broken ebuilds as WONTFIX/CANTFIX
expressed by some of the devs
probably because neither of those resolutions are generally correct
sucky
Repoman considers lots of local variables as an error, I was pointed
to expanded vars as a solution.
If no developers has something against I'll be happy to use 28 local
flags
mattepiu
Mike Frysinger wrote:
On Sunday 04 June 2006 08:59, Diego 'Flameeyes' Pettenò wrote:
On Sunday 04
Matteo Azzali wrote:
Repoman considers lots of local variables as an error, I was pointed
to expanded vars as a solution.
If no developers has something against I'll be happy to use 28 local
flags
mattepiu
Well uh, no please Don't create 28 local use flags for one ebuild,
Slipping this in before 2.1 goes stable, it's a small check.
Basically if your ebuild inherits a VCS eclass ( currently darcs,
subversion, cvs ) AND your ebuild has stable keywords on any arches
repoman will report an error.
One thing to note here:
Are there any cases when one inherits a
On Sunday 04 June 2006 05:11, Ryan Hill wrote:
Matthias Schwarzott wrote:
The --with-driver part will be moved to LIRC_DRIVERS. The name need not
to be LIRC_DRIVERS, tell me if you have a better name for it
(LIRC_RECEIVERS is another possibility).
LIRC_DEVICE? most of the USE_EXPAND
I need to add a desktop entry that call an executable with arguments.
Actually the entry Exec (that could contain the executable with
parameters) and the entry TryExec (used to test if the executable is
installed) are set to the same value.
I wonder if I can fix that with the following patch to
Jakub Moc wrote:
Matteo Azzali wrote:
Repoman considers lots of local variables as an error, I was pointed
to expanded vars as a solution.
If no developers has something against I'll be happy to use 28 local
flags
mattepiu
Well uh, no please Don't create 28 local use flags for
Matthias Schwarzott wrote:
On Sunday 04 June 2006 05:11, Ryan Hill wrote:
Matthias Schwarzott wrote:
The --with-driver part will be moved to LIRC_DRIVERS. The name need not
to be LIRC_DRIVERS, tell me if you have a better name for it
(LIRC_RECEIVERS is another possibility).
LIRC_DEVICE?
On Sunday 04 June 2006 15:43, Jakub Moc wrote:
Matteo Azzali wrote:
Repoman considers lots of local variables as an error, I was pointed
to expanded vars as a solution.
you did something wrong then ... there is no such error lots of local
variables ... and if there is such an errro, then
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 15551 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in
On Sun, Jun 04, 2006 at 08:36:57PM -0400, Doug Goldstein wrote:
Jakub Moc wrote:
Matteo Azzali wrote:
Repoman considers lots of local variables as an error, I was pointed
to expanded vars as a solution.
If no developers has something against I'll be happy to use 28 local
flags
23 matches
Mail list logo