Michał Górny 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, we don't ha
"C. Bergström" 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 introduced to ever
Hey Jan,
Jan Kundrát 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 of software
Michał Górny 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 gcc upgrades 4.
On Sun, Dec 15, 2013 at 3:34 PM, Matt Turner wrote:
> I'll make these changes in a few days.
Committed. Feel free to remove the local descriptions from your 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?
-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 packa
Dnia 2013-12-18, o godz. 22:58:07
hero...@gentoo.org napisał(a):
> Hey, Michał,
>
> Michał Górny 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
Dnia 2013-12-18, o godz. 15:20:10
"C. Bergström" 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 the long
> term meri
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
On 12/19/13 12:47 AM, Kent Fredric wrote:
On 19 December 2013 06:33, Jan Kundrát 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 man
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 Mon, 16 Dec 2013 18:07:42 -0500
"Rick \"Zero_Chaos\" Farina" 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 -mfpu=neon. Retard
On 19 December 2013 06:33, Jan Kundrát 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 fail to build
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 buil
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, ha
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] https://bugs.free
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 that
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,
Jan
-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
Hey, Michał,
Michał Górny 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 of elog conveying
On Wed, Dec 18, 2013 at 1:13 PM, "Paweł Hajdan, Jr."
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 in no applicable up
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 a
On Wed, Dec 18, 2013 at 11:11 AM, Fabio Erculiani 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 pkgs to slot
> 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:
http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-3
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 tha
On 12/18/13 02:54 PM, Michał Górny wrote:
Hello, folks.
Hi
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 would
27 matches
Mail list logo
