On Tue, 30 Jan 2007 08:41:56 +0100 Luca Barbato <[EMAIL PROTECTED]>
wrote:
| Ciaran McCreesh wrote:
| > On Tue, 30 Jan 2007 08:30:40 +0100 Luca Barbato <[EMAIL PROTECTED]>
| > wrote:
| > | Ciaran McCreesh wrote:
| > | > What is the best way to handle packages that require parts of
| > | > tr1? The
Ciaran McCreesh wrote:
>
> bringing it up to 3.3MBytes of code, about 3.2MBytes of which is
> compiler bug workarounds and boost-review-process-induced mutual
> masturbation.
So the safest route is either bundle boost (that is heavy as you shown
in detail) and/or just depend on it at least for no
On 30.01.2007, at 09:36, Ciaran McCreesh wrote:
| * have the application bundle a static implementation and switch to
| system on at configure time as done for other libs?
At something like five megs of code per application?
If you make that decidable by a USE-flag like minimal?
Philipp
--
On Tue, 30 Jan 2007 11:36:35 +0200 Philipp Riegger
<[EMAIL PROTECTED]> wrote:
| On 30.01.2007, at 09:36, Ciaran McCreesh wrote:
|
| > | * have the application bundle a static implementation and switch
| > | to system on at configure time as done for other libs?
| >
| > At something like five megs
On Tue, 2007-01-30 at 06:27 +, Ciaran McCreesh wrote:
> [ Background: tr1 is a set of extensions to the C++ Standard Library
> giving various useful things like hash tables and smart pointers. There
> are partial implementations included in g++-4.1 and boost and full
> implementations available
On Tue, 30 Jan 2007 14:49:48 +0100
Matthias Langer <[EMAIL PROTECTED]> wrote:
> isn't it possible to check the version of gcc that is in _use_ in an
> ebuild, like i can do in a configure script? if so, one could provide a
> "old-gcc" use flag that must be enabled when trying to build with
> whe
On 30.01.2007, at 11:40, Ciaran McCreesh wrote:
| > | * have the application bundle a static implementation and switch
| > | to system on at configure time as done for other libs?
| >
| > At something like five megs of code per application?
|
| If you make that decidable by a USE-flag like mini
> * Hard dep upon boost. This sucks for g++-4.1 users.
>
> * Hard dep upon g++-4.1, which isn't available for all archs. This
> doesn't even work because there's no guarantee that >=4.1 is being used
> even if it's installed.
I don't think these are necessarily compatible. tr1 is implemented in t
Marius Mauch <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], excerpted below, on Tue, 30
Jan 2007 16:49:51 +0100:
> On Tue, 30 Jan 2007 14:49:48 +0100
> Matthias Langer <[EMAIL PROTECTED]> wrote:
>
>> isn't it possible to check the version of gcc that is in _use_ in an
>> ebuild, like i can do in
Ciaran McCreesh wrote: [Tue Jan 30 2007, 12:27:49AM CST]
> * Hard dep upon boost. This sucks for g++-4.1 users.
Agreed. Worse, it's a stop-gap measure, since presumably the long term
solution is for tr1 to be supported directly by the compiler on all
archs. So, any work done with this approach w
I have a few suggestions for the make_desktop_entry function in
eutils.eclass:
1 - Allow me to pass in a full application path. If you pass in the
full path to an executable as the first argument, it comes up with a
crazy filename like this:
/var/tmp/portage/rox-base/mime-editor-0.5/temp//usr
On Tuesday 30 January 2007 16:10, Jim Ramsay wrote:
> In other words, I propose that this function should probably do
> 'basename' on $exec before using it for the .desktop filename.
no ... the point of using $exec is to make sure the .desktop file is unique
i'll change it to sanitize the filenam
12 matches
Mail list logo
