public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Diego 'Flameeyes' Pettenò" <flameeyes@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Dirt: To shove under the rug or not shove under the rug? (aka another round of USE_EXPAND)
Date: Tue, 27 Sep 2005 12:41:50 +0200	[thread overview]
Message-ID: <200509271242.05438@enterprise.flameeyes.is-a-geek.org> (raw)
In-Reply-To: <200509271912.22758.jstubbs@gentoo.org>

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

On Tuesday 27 September 2005 12:12, Jason Stubbs wrote:
> Which leads me to the one thing I didn't say but feel strongest about..
> What is the real point of USE_EXPAND? What can/does it do that USE flags do
> not?
They are forced by the profile, as we don't want users to go away WITHOUT them 
when they are needed. That's the main part of it.
Then there's the fact that I can test for a generic BSD libc using [[ ${ELIBC} 
== *BSD ]], too.

> This doesn't quite apply to cross compiling and such, but in general yeah.
Cross-compiling with different libc can be possible (glibc->uclibc) but I'm 
not sure on what extent. Currently trying to have cross-compiling between 
different kernels is a no-go.

The proposal of domains or whatever they are called that Brian talked about 
some time ago when he proposed BDEPEND would probably fix this issue, tho.

> Similar to "build" and "bootstrap"? Note, these aren't hidden either but if
> the ELIBC and friends should be hidden those should be hidden too.
But they have sort of meaning to users, for example with newuse, and does not 
screw your system around, or at least not completely (one can build a few 
packages with build useflag active and still have a working system, at the 
end).
Changing the ELIBC/KERNEL/USERLAND is like using a sparc profile on an x86 ...

Also, most ebuilds does not use the above variables in a complete way, they 
usually check for a certain content (GNU userland, FBSD libc, Linux Kernel).
Saying for example that kdelibs uses kernel_linux can make people think that 
kdelibs works ONLY for Linux kernel, while that's not true at all.
They are special features or workarounds that does not concern users at all.

> And we're back to USE flags again... ;)
As they are the only way to change the dependencies, yeah, always USE is what 
we need. For the most of the uses, variables are fine, but for dependency we 
use them use-expanded.

-- 
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 --]

  reply	other threads:[~2005-09-27 10:44 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-27  9:23 [gentoo-dev] Dirt: To shove under the rug or not shove under the rug? (aka another round of USE_EXPAND) Jason Stubbs
2005-09-27  9:38 ` Diego 'Flameeyes' Pettenò
2005-09-27 10:12   ` Jason Stubbs
2005-09-27 10:41     ` Diego 'Flameeyes' Pettenò [this message]
2005-09-27 12:51       ` Jason Stubbs
2005-09-27 13:44         ` Diego 'Flameeyes' Pettenò
2005-09-27 14:07           ` Kito
2005-09-27 16:27             ` Stephen Bennett
2005-09-27 16:48             ` Brian Harring
2005-09-27 14:25           ` Jason Stubbs
2005-09-27 15:40       ` [gentoo-dev] " Duncan
2005-09-27 12:38     ` [gentoo-dev] " Chris Gianelloni
2005-09-27 15:36       ` Donnie Berkholz
2005-09-27 10:54 ` Thomas de Grenier de Latour
2005-09-27 12:31   ` Jason Stubbs
2005-09-27 12:35 ` Chris Gianelloni
2005-09-27 13:07   ` Thomas de Grenier de Latour
2005-09-27 13:50     ` Chris Gianelloni
2005-09-27 14:20   ` Jason Stubbs
2005-09-27 15:35 ` Donnie Berkholz
2005-09-28  1:23   ` Jason Stubbs
2005-09-28  3:13     ` Jason Stubbs
2005-09-28  3:58   ` Jason Stubbs
2005-09-28  4:19     ` Donnie Berkholz
2005-09-28  4:45       ` Jason Stubbs
2005-09-28  6:23         ` Donnie Berkholz
2005-09-28  8:03           ` Jason Stubbs
2005-09-28  4:21     ` Jason Stubbs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200509271242.05438@enterprise.flameeyes.is-a-geek.org \
    --to=flameeyes@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox