On 12/18/13 02:54 PM, Michał Górny wrote:
Hello, folks.
Hi
snip
Basically, I've hit this with sys-devel/llvm. A user has requested lldb
support to be enabled in the ebuild [2]. Sadly, lldb requires C++11 to
be used, and this means that whole LLVM needs to become C++11 enabled.
And then, it
Hi,
6 days ago gienah committed a bunch of slotmoves for the haskell
glib/gtk stuff [1], basically moving the pkgs to slot 0 (from slot 2).
This was done in file 4Q-2013.
It turns out that the same gienah moved those pkgs to slot 2 (from
slot 0) in 2Q-2013 [2].
I have never seen something like
On Wed, 18 Dec 2013, Fabio Erculiani wrote:
I have never seen something like that and this generated an
interesting bug in entropy (well, I fixed it...). What I am asking
is quite simple though. Is this allowed?
The PMS does not allow it:
On Wed, Dec 18, 2013 at 11:11 AM, Fabio Erculiani lx...@gentoo.org wrote:
Hi,
6 days ago gienah committed a bunch of slotmoves for the haskell
glib/gtk stuff [1], basically moving the pkgs to slot 0 (from slot 2).
This was done in file 4Q-2013.
It turns out that the same gienah moved those
On 12/18/13, 10:19 AM, Ulrich Mueller wrote:
On Wed, 18 Dec 2013, Fabio Erculiani wrote:
I have never seen something like that and this generated an
interesting bug in entropy (well, I fixed it...). What I am asking
is quite simple though. Is this allowed?
The PMS does not allow it:
On Wed, Dec 18, 2013 at 1:13 PM, Paweł Hajdan, Jr.
phajdan...@gentoo.org wrote:
[ snip ]
Finally, do we have a good way now to automate checks against this?
The current PMS spec, as you quoted, allows one way moves only.
For this reason, I guess that simulating the updates twice should
result
Hey, Michał,
Michał Górny mgo...@gentoo.org writes:
a) adding USE=c++11 and USE-deps to all the packages in question,
I think it is better achieved by a (simple and stupid) global
CXXFLAGS. Adding an extra USE flag feels a little over-engineering.
Any anyway, if it is only for lldb, a piece
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18/12/13 02:54 AM, Michał Górny wrote:
Hello, folks.
As some of you are already aware, the C++11 standard brought a few
changes to the C++ standard library. As a result, the standard
library used in C++11 mode has a different ABI than the
On Wednesday, 18 December 2013 14:58:07 CEST, hero...@gentoo.org wrote:
I think it is better achieved by a (simple and stupid) global
CXXFLAGS. Adding an extra USE flag feels a little over-engineering.
What compiler flag do you propose to use? Note that --std=c++11 will not
work.
Cheers,
On 12/18/13 11:29 PM, Jan Kundrát wrote:
On Wednesday, 18 December 2013 14:58:07 CEST, hero...@gentoo.org wrote:
I think it is better achieved by a (simple and stupid) global
CXXFLAGS. Adding an extra USE flag feels a little over-engineering.
What compiler flag do you propose to use? Note
On Wednesday, 18 December 2013 17:37:56 CEST, C. Bergström wrote:
From the perspective of a compiler vendor - I must ask why not?
There is code out there which builds fine under C++98, but fails to build
when C++11 is enabled (as but one exmaple, have a look at [1]).
[1]
On 12/18/13 11:50 PM, Jan Kundrát wrote:
On Wednesday, 18 December 2013 17:37:56 CEST, C. Bergström wrote:
From the perspective of a compiler vendor - I must ask why not?
There is code out there which builds fine under C++98, but fails to
build when C++11 is enabled (as but one exmaple,
On Wednesday, 18 December 2013 18:05:46 CEST, C. Bergström wrote:
If moving to C++11 - Isn't that considered just part of the
work along the path? There's some clang tools to help with the
migration, but I don't think anyone expects it to be zero work.
The flag is just a way to a) enable
On 19 December 2013 06:33, Jan Kundrát j...@gentoo.org wrote:
I'm worried by the cost of such a policy, though, because we would suddenly
have to patch some unknown amount of software
Given the nature that changing that CXX Flag globally for all users
could cause many packages to spontaneously
On Mon, 16 Dec 2013 18:07:42 -0500
Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote:
3.) Broken build systems. Forgive me for the term, but packages like
libpng seem to require arcane configure flags like
--enable-arm-neon=$(usex neon on off) to enable my neon fpu despite
passing
On 12/19/13 12:33 AM, Jan Kundrát wrote:
On Wednesday, 18 December 2013 18:05:46 CEST, C. Bergström wrote:
If moving to C++11 - Isn't that considered just part of the work
along the path? There's some clang tools to help with the migration,
but I don't think anyone expects it to be zero work.
On 12/19/13 12:47 AM, Kent Fredric wrote:
On 19 December 2013 06:33, Jan Kundrát j...@gentoo.org wrote:
I'm worried by the cost of such a policy, though, because we would suddenly
have to patch some unknown amount of software
Given the nature that changing that CXX Flag globally for all users
On 12/18/2013 02:54 AM, Michał Górny wrote:
The problem with this solution is that as soon as user upgrades, shklee
is forced to use C++11. On the other hand, we get rid of pre-C++11
packages quite transparently, without extra work.
What are your thoughts?
I assume with variant a you will be
Dnia 2013-12-18, o godz. 15:20:10
C. Bergström cbergst...@pathscale.com napisał(a):
If the only driving motivation is lldb then I think this isn't worth the
effort and I wonder what may be incompatible as a result. Long term it
certainly should happen - I can't/won't argue or disagree with
Dnia 2013-12-18, o godz. 22:58:07
hero...@gentoo.org napisał(a):
Hey, Michał,
Michał Górny mgo...@gentoo.org writes:
a) adding USE=c++11 and USE-deps to all the packages in question,
I think it is better achieved by a (simple and stupid) global
CXXFLAGS. Adding an extra USE flag feels
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18/12/13 01:10 PM, Anthony G. Basile wrote:
On 12/18/2013 02:54 AM, Michał Górny wrote:
The problem with this solution is that as soon as user upgrades,
shklee is forced to use C++11. On the other hand, we get rid of
pre-C++11 packages
Either way, it is reasonable to assume that some users would like to build
their own software and link it with system libraries. It is not reasonable
to force these users to build in the C++11 mode, IMHO.
As far as I understand now you're just forcing users to build in C++03
mode, don't you?
On Sun, Dec 15, 2013 at 3:34 PM, Matt Turner matts...@gentoo.org wrote:
I'll make these changes in a few days.
Committed. Feel free to remove the local descriptions from your packages.
Michał Górny mgo...@gentoo.org wrote:
Then, many developers just won't bother. Users will be the ones to hit
the incompatible package build failures first.
Is Diego's tinderbox still available?
My feeling is that the non-downward compatbility (API-wise)
of C++11 is much smaller than e.g. the
Hey Jan,
Jan Kundrát j...@gentoo.org writes:
This perspective is interesting (and I admit that I tend to like it) --
considering packages which won't build with C++11 to be buggy.
I'm worried by the cost of such a policy, though, because we would
suddenly have to patch some unknown amount
C. Bergström cbergst...@pathscale.com writes:
Best case both build and you end up with a linker problem (can be
worked around with compiler patches)
/usr/lib64/libboost.so
/usr/lib64-c++11/libboost.so
This is the right way to do, but as scary as our multilib where a
couple of USE flags are
Michał Górny mgo...@gentoo.org writes:
This is nowhere near a good solution IMO.
First of all, it doesn't give us a way of ensuring ABI compatibility.
Users switch the flags and have to rebuild all C++ packages to regain
the ABI compatibility. The system ends up borked quite easily.
Then,
On Tue, Dec 17, 2013 at 3:28 PM, Mike Frysinger vap...@gentoo.org wrote:
URL: https://bugs.gentoo.org/487478
Perhaps, with this bug resolved, this matter falls under the more
trouble than its worth to fix category -- but...
My hunch is that the decision to put the config.{sub,guess}
replacement
On Wednesday 18 December 2013 17:20:32 Greg Turner wrote:
My hunch is that the decision to put the config.{sub,guess}
replacement code in econf was intended as a quick-and-dirty way to
avoid doing the replacements, in cases where no configure script runs
in an ebuild.
it was intended as the
29 matches
Mail list logo
