Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
Michel Alexandre Salim wrote: LLVM is becoming an increasingly integral part of our distribution (with mesa now using it to build the LLVMpipe renderer, for example) that I don't really feel comfortable maintaining it mostly by myself. I'm not sure how much help I'd be with maintaining the native LLVM package, though I'm willing to try. However, because I have an application that uses the LLVM libraries and needs to build for both Linux and Windows, I've taken a shot at packaging a mingw-llvm package. The package review bug is: https://bugzilla.redhat.com/show_bug.cgi?id=819670 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On Mon, May 14, 2012 at 12:48:42AM -0400, Jon Masters wrote: On 05/13/2012 02:02 AM, Matthew Garrett wrote: snip From a purely practical perspective, the popularity of OS X as a development platform means that we're likely to see a gradual increase in the amount of code written to assume LLVM-specific functionality. People are just going to have to cope. I do not like this as a strategy. I feel it is necessary in the case of a core toolchain component to set some expectations early on. Those might be Fedora welcomes everyone using LLVM for everything once Red Hat hires some folks to maintain LLVM on the same level as gcc or whatever the wording needs to be. But we're not going to just cope. What's going to happen is we're going to get bitten nastily. Again, how is this different to any other niche toolchain component? I'm not in favour of people using LLVM purely because it's there, but where applications require its functionality the choice is either to use LLVM or not to ship that application. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On Sun, 2012-05-13 at 12:21 +0700, Michel Alexandre Salim wrote: Apart from the worrying test suite results on secondary archs, actually it's the libstdc++ issue that's causing the most headache. How much effort does it take to maintain a compatibility version of libstdc++? It'd make clang much more useful if we're not caught between upstream (that abandons released versions) and the Fedora GCC team's fast update cycles. Apologies, I'm not familiar with this part of the eternal waking nightmare called C++. Can you give more details? - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On Sun, May 13, 2012 at 01:33:46AM -0400, Jon Masters wrote: We could. Right now, for ARM (as an example), there is really about as much representation as x86 from what I can see in terms of core arch support. I'm sure upstream bits will be pulled in, and David and ajax will do a great job - but unless I'm mistaken they're not offering to take on the task of being a architectural maintainer for core x86 code. On x86, we have Jeff's tools group within Red Hat that does an excellent job of providing all of the kinds of behind-the-scenes support that an architecture really needs. It's not just fixing build issues, or whether stuff builds on ARM - it's known how and why specific instructions are emitted and how that relates to the design. IOW it's a full time job to support something like clang at the same level that we support gcc today and I don't see that level available. Which bit of this doesn't apply to *any* package requiring a niche toolchain component? It would be problematic for packages to gratuitously migrate to llvm, but packages that actually depend on its functionality are as welcome in the distribution as anything written in ADA, go, falcon, R, AGI, Pure, Q, any of the lisps or any other compiler or interpreter we ship. Some of our toolchain components are much better supported than others, and obviously relying on one of the less supported ones is risky - unless anyone's willing to do the support work, it'll go away and so will all the packages that depend on it. Any maintainer is expected to understand that risk and make an appropriate and rational choice. From a purely practical perspective, the popularity of OS X as a development platform means that we're likely to see a gradual increase in the amount of code written to assume LLVM-specific functionality. People are just going to have to cope. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On 05/13/2012 02:02 AM, Matthew Garrett wrote: snip From a purely practical perspective, the popularity of OS X as a development platform means that we're likely to see a gradual increase in the amount of code written to assume LLVM-specific functionality. People are just going to have to cope. I do not like this as a strategy. I feel it is necessary in the case of a core toolchain component to set some expectations early on. Those might be Fedora welcomes everyone using LLVM for everything once Red Hat hires some folks to maintain LLVM on the same level as gcc or whatever the wording needs to be. But we're not going to just cope. What's going to happen is we're going to get bitten nastily. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/11/2012 02:16 AM, Jon Masters wrote: On 05/10/2012 04:56 AM, David Airlie wrote: Don't confuse llvm and clang, llvm has no equivalent in gcc world, clang is a C compiler like gcc that uses llvm tech. Right so I wasn't confusing these :) However, we package both together and for ease of discussion many folks are going to think of it as a gcc alternative (aside from the specific gfx situations you and ajax have). My main concern was potential for growing use beyond that. I made an analogy about glibc to which I accept ajax's response that they're trying to reconcile with eglibc, but it's more the general concept I was getting at. Let me avoid a specific example because someone will find a way to find a hole in it :) Instead, my stance is we want to be very careful about unsupportable use of LLVM. I've filed a ticket with FESCo so hopefully there can be some debate as to acceptable use :) It probably makes sense that one of myself, ajax or glisse help out packaging llvm, but we aren't the most reliable people in terms of spare time to commit. Right. You guys have various incentives to care about specific use of LLVM itself so I'm sure it will always be supported to some level, but for the other piece - clang+LLVM, etc. - to grow further use in the distro (in displacement of gcc) I feel we'd need to have actual RH staff to support it that I don't think we have any plans to have. So I want to cut this off at the pass before we blink and we have a problem. Maybe we should draw more of a distinction between LLVM and clang, and use ExclusiveArch: on the latter to whitelist only architectures we feel comfortable supporting? I'm at the moment not really comfortable switching LLVM to be built with Clang as the default -- given that on Linux it has a brittle dependency on specific versions of libstdc++. But we could certainly make it a switchable build-time option. Apart from the worrying test suite results on secondary archs, actually it's the libstdc++ issue that's causing the most headache. How much effort does it take to maintain a compatibility version of libstdc++? It'd make clang much more useful if we're not caught between upstream (that abandons released versions) and the Fedora GCC team's fast update cycles. Thanks, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPr0TxAAoJEEr1VKujapN6uZsIAIGhhi29Z81Ko9ayvsYqijfR b7lpEwHihJBETbsFrP5zxqAIwdr5lIvE+Ox6thK9RIHdpICIurwO9rWQ0pparBqf JLcsLeYfm96P7uoTWkjdwJTs9KHvntLtXJLek40vGq74vX43ysnNuI8vs2DqN0zB 8W10OIQfj1G7dw9tDtQjDKXZLc3mIki3lAAUesv78oSZNdFjkv28Go8K+Fku27uU XQAmK3SzIApvSPAvjuemDruwU9M2TwXmVsUDlNLtI/LYRZfm1NikX+BfP/bNCelj 51aP1livuXdhqndrEMj5/6sL2V0ku1IAJtQgdutS9bgQIJzhm2E31Mr3uE3uSlM= =iiGx -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
Maybe we should draw more of a distinction between LLVM and clang, and use ExclusiveArch: on the latter to whitelist only architectures we feel comfortable supporting? That would only make it worse, for surely x86-32 and x86-64 would be whitelisted, so most developers would just use clang anyway and not realize the problems they're causing. The issues are how to stop developers and/or packagers from arbitrarily bringing in new dependencies that (1) aren't supportable, and (2) aren't desirable, and how to decide what dependencies fit those categories. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On 05/13/2012 01:21 AM, Michel Alexandre Salim wrote: snip Maybe we should draw more of a distinction between LLVM and clang, and use ExclusiveArch: on the latter to whitelist only architectures we feel comfortable supporting? We could. Right now, for ARM (as an example), there is really about as much representation as x86 from what I can see in terms of core arch support. I'm sure upstream bits will be pulled in, and David and ajax will do a great job - but unless I'm mistaken they're not offering to take on the task of being a architectural maintainer for core x86 code. On x86, we have Jeff's tools group within Red Hat that does an excellent job of providing all of the kinds of behind-the-scenes support that an architecture really needs. It's not just fixing build issues, or whether stuff builds on ARM - it's known how and why specific instructions are emitted and how that relates to the design. IOW it's a full time job to support something like clang at the same level that we support gcc today and I don't see that level available. Therefore, if ExclusiveArch is a solution, it ought to be ExclusiveArch: none. Instead, while I think some arches do need to be considered for exclusion - for example, if you compare the build flags for gcc and llvm+clang today for non-ARM and non-x86 you'll see various stuff on ppc/s390x that (to me) raises some concerns just in terms of the build itself - I think more this should be ExclusivePackage. I believe one should have to make a case for growing a dependence like this within the distribution. So we need it for soft rendering? Great. That's a wonderful exception to a general rule of not requiring it. I don't mean to sound anal, but we need to stop any growing in dependence on this until we're in a position to broadly support on any arches. (it's rather like how we have core packages depending on nonsense like ruby or python in the SPEC file just to do something that a shell escape could trivially have done ten years ago - if we don't make rules to stop this growth there, we're making it much harder to bootstrap - therefore rules do matter and we need them in this case before we start growing a dependence on something as core as a new toolchain) I'm at the moment not really comfortable switching LLVM to be built with Clang as the default -- given that on Linux it has a brittle dependency on specific versions of libstdc++. But we could certainly make it a switchable build-time option. Apart from the worrying test suite results on secondary archs, actually it's the libstdc++ issue that's causing the most headache. How much effort does it take to maintain a compatibility version of libstdc++? It'd make clang much more useful if we're not caught between upstream (that abandons released versions) and the Fedora GCC team's fast update cycles. I think upstream also not providing support is another red flag to be honest. On the secondary arch front btw, I believe we have two problems on ARM: one is some tests are failing (not unique to ARM), and two I believe I am onto a heretofore not-well-isolated general futex bug that isn't related to LLVM/clang as a package. Anyway, I don't feel in a good position to comment on the libstdc++ resolution other than to again repeat my concerns about having any growth in dependency. Obviously don't take this personally! You do a great job Michel :) But it's become clear to me that supporting a toolchain in Fedora requires a team of folks to back it up that we don't seem to have here. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On Thu, May 10, 2012 at 4:17 AM, DJ Delorie d...@redhat.com wrote: Is LLVMpipe needed on, say, ARM? (Does anyone have a screenshot of GNOME Shell running on such a system?). Is this close enough? http://www.delorie.com/arm/f15-gnome-on-olpc.jpg And currently OLPC uses gnome-panel although there is plans to move to gnome-shell. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
- Original Message - From: Jon Masters j...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: Michel Alexandre Salim sali...@fedoraproject.org Sent: Wednesday, 9 May, 2012 10:57:30 PM Subject: Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers On 05/06/2012 02:29 AM, Michel Alexandre Salim wrote: LLVM is becoming an increasingly integral part of our distribution (with mesa now using it to build the LLVMpipe renderer, for example) that I don't really feel comfortable maintaining it mostly by myself. Thanks for the private email about ARM stuff. I've just kicked off another scratch build for ARM LLVM that might fix our outstanding problems. I'm ok - vaguely - in being a co-maintainer on ARM if there is nobody else on our end who can represent ARM (as it seems). I started going through some of its design over the weekend, in my copious non-existent spare time to try to understand the ARM bits. More broadly though, I feel that GCC is well represented in terms of engineering knowledge but I'm *concerned* that we run the risk of growing a dependence on LLVM that is more critical than the LLVMpipe stuff. Before we can blink, we might need LLVM for building lots of other fundamental stuff. I am wondering if as a distribution we ought to have an official FESCo-debated position on LLVM use? I do not think Fedora has the resources to maintain two critical toolchain pieces. I do think LLVM is useful, etc. BUT its growing use is concerning. Don't confuse llvm and clang, llvm has no equivalent in gcc world, clang is a C compiler like gcc that uses llvm tech. Apart from llvmpipe, we use llvm to execute vertex shaders on earlier AMD chipsets, newer AMD GPUs are also going to use llvm as the shader compiler backend for GLSL shaders. AMD also have open source OpenCL work in progress, that uses the GPU driver and LLVM. It probably makes sense that one of myself, ajax or glisse help out packaging llvm, but we aren't the most reliable people in terms of spare time to commit. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On Wed, 2012-05-09 at 18:00 -0400, Jon Masters wrote: Putting that another way, if we carried eglibc in Fedora, there would be cries and shouts if a large number of packages started requiring it because we have folks that maintain GLIBC. I don't believe this is entirely accurate, since glibc appears to be making moves to get eglibc merged. I feel LLVM is a similar piece of critical technology that we should not need for critpath. Honestly the biggest question I have about llvm maintenance is whether we should allow it to self-host under clang or whether we must build it with gcc. Upstream llvm typically self-hosts, and there are known bugs where clang-built-llvm works but gcc-built-llvm is crashy. We should at least make it easy to build llvm either way for comparison. I'm happy to keep patching up llvm as I hit issues in it, of course. It's something I'm stuck with for RHEL in the future anyway. I'm not likely to have the resources to investigate issues that don't affect Mesa, but as long as everybody who needs llvm can commit to that level of self-interest we should be fine. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
Is this close enough? http://www.delorie.com/arm/f15-gnome-on-olpc.jpg That's GDM, and so useless unto the purpose. It's not accelerated. I could log in and got the fallback shell, but it all worked sufficiently well. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On Thu, 2012-05-10 at 13:40 -0400, DJ Delorie wrote: Is this close enough? http://www.delorie.com/arm/f15-gnome-on-olpc.jpg That's GDM, and so useless unto the purpose. It's not accelerated. I could log in and got the fallback shell, but it all worked sufficiently well. Yes, but fallback mode doesn't hit the llvm renderer path. So since the question was does anyone have llvmpipe working on arm, the answer is no. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On 05/10/2012 04:56 AM, David Airlie wrote: - Original Message - From: Jon Masters j...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: Michel Alexandre Salim sali...@fedoraproject.org Sent: Wednesday, 9 May, 2012 10:57:30 PM Subject: Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers On 05/06/2012 02:29 AM, Michel Alexandre Salim wrote: LLVM is becoming an increasingly integral part of our distribution (with mesa now using it to build the LLVMpipe renderer, for example) that I don't really feel comfortable maintaining it mostly by myself. Thanks for the private email about ARM stuff. I've just kicked off another scratch build for ARM LLVM that might fix our outstanding problems. I'm ok - vaguely - in being a co-maintainer on ARM if there is nobody else on our end who can represent ARM (as it seems). I started going through some of its design over the weekend, in my copious non-existent spare time to try to understand the ARM bits. More broadly though, I feel that GCC is well represented in terms of engineering knowledge but I'm *concerned* that we run the risk of growing a dependence on LLVM that is more critical than the LLVMpipe stuff. Before we can blink, we might need LLVM for building lots of other fundamental stuff. I am wondering if as a distribution we ought to have an official FESCo-debated position on LLVM use? I do not think Fedora has the resources to maintain two critical toolchain pieces. I do think LLVM is useful, etc. BUT its growing use is concerning. Don't confuse llvm and clang, llvm has no equivalent in gcc world, clang is a C compiler like gcc that uses llvm tech. Right so I wasn't confusing these :) However, we package both together and for ease of discussion many folks are going to think of it as a gcc alternative (aside from the specific gfx situations you and ajax have). My main concern was potential for growing use beyond that. I made an analogy about glibc to which I accept ajax's response that they're trying to reconcile with eglibc, but it's more the general concept I was getting at. Let me avoid a specific example because someone will find a way to find a hole in it :) Instead, my stance is we want to be very careful about unsupportable use of LLVM. I've filed a ticket with FESCo so hopefully there can be some debate as to acceptable use :) It probably makes sense that one of myself, ajax or glisse help out packaging llvm, but we aren't the most reliable people in terms of spare time to commit. Right. You guys have various incentives to care about specific use of LLVM itself so I'm sure it will always be supported to some level, but for the other piece - clang+LLVM, etc. - to grow further use in the distro (in displacement of gcc) I feel we'd need to have actual RH staff to support it that I don't think we have any plans to have. So I want to cut this off at the pass before we blink and we have a problem. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On Thu, 2012-05-10 at 13:40 -0400, DJ Delorie wrote: Is this close enough? http://www.delorie.com/arm/f15-gnome-on-olpc.jpg That's GDM, and so useless unto the purpose. It's not accelerated. I could log in and got the fallback shell, but it all worked sufficiently well. Yes. But the context of the initial question was to find out if we actually have accelerated drivers on ARM. If anyone had seen ARM running the Shell, that would be an excellent indication that we do. Seeing ARM running fallback mode, though, indicates absolutely nothing except that it's capable of rendering graphics. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On 05/06/2012 02:29 AM, Michel Alexandre Salim wrote: LLVM is becoming an increasingly integral part of our distribution (with mesa now using it to build the LLVMpipe renderer, for example) that I don't really feel comfortable maintaining it mostly by myself. Thanks for the private email about ARM stuff. I've just kicked off another scratch build for ARM LLVM that might fix our outstanding problems. I'm ok - vaguely - in being a co-maintainer on ARM if there is nobody else on our end who can represent ARM (as it seems). I started going through some of its design over the weekend, in my copious non-existent spare time to try to understand the ARM bits. More broadly though, I feel that GCC is well represented in terms of engineering knowledge but I'm *concerned* that we run the risk of growing a dependence on LLVM that is more critical than the LLVMpipe stuff. Before we can blink, we might need LLVM for building lots of other fundamental stuff. I am wondering if as a distribution we ought to have an official FESCo-debated position on LLVM use? I do not think Fedora has the resources to maintain two critical toolchain pieces. I do think LLVM is useful, etc. BUT its growing use is concerning. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On 05/09/2012 05:57 PM, Jon Masters wrote: More broadly though, I feel that GCC is well represented in terms of engineering knowledge but I'm *concerned* that we run the risk of growing a dependence on LLVM that is more critical than the LLVMpipe stuff. Before we can blink, we might need LLVM for building lots of other fundamental stuff. I am wondering if as a distribution we ought to have an official FESCo-debated position on LLVM use? I do not think Fedora has the resources to maintain two critical toolchain pieces. I do think LLVM is useful, etc. BUT its growing use is concerning. Putting that another way, if we carried eglibc in Fedora, there would be cries and shouts if a large number of packages started requiring it because we have folks that maintain GLIBC. I feel LLVM is a similar piece of critical technology that we should not need for critpath. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/10/2012 05:00 AM, Jon Masters wrote: On 05/09/2012 05:57 PM, Jon Masters wrote: More broadly though, I feel that GCC is well represented in terms of engineering knowledge but I'm *concerned* that we run the risk of growing a dependence on LLVM that is more critical than the LLVMpipe stuff. Before we can blink, we might need LLVM for building lots of other fundamental stuff. I am wondering if as a distribution we ought to have an official FESCo-debated position on LLVM use? I do not think Fedora has the resources to maintain two critical toolchain pieces. I do think LLVM is useful, etc. BUT its growing use is concerning. Putting that another way, if we carried eglibc in Fedora, there would be cries and shouts if a large number of packages started requiring it because we have folks that maintain GLIBC. I feel LLVM is a similar piece of critical technology that we should not need for critpath. Jon. I agree -- besides the resource problem, there's also the Debian-esque problem of putting secondary architectures (and less-used primary ones) at a disadvantage. Is LLVMpipe needed on, say, ARM? (Does anyone have a screenshot of GNOME Shell running on such a system?). Perhaps we need an official decision on which platforms we feel comfortable depending on LLVM for (e.g. ix86/x86_64, to get GNOME Shell running without 3D acceleration), and we should require that LLVM-dependent features be made optional on other architectures (e.g using the %bcond_with and %bcond_without directives, as used in the LLVM packaging) - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPqzJuAAoJEEr1VKujapN6nDIH/2sn0WpLcUWDW4ribRXIKe03 4Q9xqU+28Lv07IVUUaIM21Rv3uFv+QJckekdNdWBkveMaQ+3syZ1ohhgM/1CRAG0 vjwn3Sh4F3JwUHXDiNm0oxgbD5JAXyc5uV7zyGWLybSZza25UJDHCco3KUGyA/+0 mXYQTwsXdNnk8y31koQgjtQv1Zihkn334e+ohUizQ5RsgR6+127FwwvxrqQK/6W7 xrUMhctWgdB1KLHE9PhhMffmUuLAA8XqnVeGDngvdR/sRsqVqLevFhaHA+TUwE6N Qqkk+nFv0jynzlDlo5NiP85nCZyPwXfV9J3PWXGHfeJVRjiU6wtCQl7sNcWrrDE= =nyR4 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
Is LLVMpipe needed on, say, ARM? (Does anyone have a screenshot of GNOME Shell running on such a system?). Is this close enough? http://www.delorie.com/arm/f15-gnome-on-olpc.jpg -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On Wed, 2012-05-09 at 23:17 -0400, DJ Delorie wrote: Is LLVMpipe needed on, say, ARM? (Does anyone have a screenshot of GNOME Shell running on such a system?). Is this close enough? http://www.delorie.com/arm/f15-gnome-on-olpc.jpg That's GDM, and so useless unto the purpose. It's not accelerated. To answer MAS: we don't have working drivers capable of rendering Shell for any ARM system, to the best of my knowledge. But to slice it another way, I don't think any current ARM CPU is likely to be powerful enough to software render Shell at an acceptable speed. ajax would probably know better than me, though, I may just be blowing smoke. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, LLVM is becoming an increasingly integral part of our distribution (with mesa now using it to build the LLVMpipe renderer, for example) that I don't really feel comfortable maintaining it mostly by myself. I'd love to have some extra help here -- especially those with deep C++ expertise; until we get LLVM's own libcxx packaged (it currently only supports OS X), LLVM's clang C/C++/Obj-C/Objc-C++ compiler tends to play catch-up with g++/libstdc++ in its C++11 support, and since upstream does not support older branches post-release, it's normally up to us to try and backport patches whenever GCC in a stable release gets updated. Also, LLVM's packaging is currently not optimal -- https://bugzilla.redhat.com/show_bug.cgi?id=787187 -- even if you're not interested in C++ support, you're more than welcome to help fix other issues! TIA, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPpho4AAoJEEr1VKujapN6BOAH/1N5+DiagAfV7Z8AsVaqI0Wq cgxWKC2LFtK3T9Ja4dPPOGQV81xC/gsKBahjdjcnQWNkEx4smwx6a9M5Am1uZ63r fstWhYLIZQ9Oc8iNvhHbcEiycO+KmrCQne5tcB7upvl235dUyH1eHLyFpWjztUbf ihHsUrf8hvaTAWFdU52gRdLgc2h6w8v2TfaccECgGhmY5YefQbiYlbDXSg819Q0J +kvP8/WNs/O6Y0RPhskq/D8rXZzd23K6TqmloOFUZY23DhiA3QRWfe28EVtINdyX Cb8xsnZYsaWVwebOwazlHiPp3MzfGQ9ZPF94KCQHb35De8RjAEkj/bL44d/xl74= =eLRR -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
2012/5/6 Michel Alexandre Salim sali...@fedoraproject.org: Hi all, LLVM is becoming an increasingly integral part of our distribution (with mesa now using it to build the LLVMpipe renderer, for example) that I don't really feel comfortable maintaining it mostly by myself. I'd love to have some extra help here -- especially those with deep C++ expertise; until we get LLVM's own libcxx packaged (it currently only supports OS X), LLVM's clang C/C++/Obj-C/Objc-C++ compiler tends to play catch-up with g++/libstdc++ in its C++11 support, and since upstream does not support older branches post-release, it's normally up to us to try and backport patches whenever GCC in a stable release gets updated. Also, LLVM's packaging is currently not optimal -- https://bugzilla.redhat.com/show_bug.cgi?id=787187 -- even if you're not interested in C++ support, you're more than welcome to help fix other issues! About packaging I can at least give some ideas. I completely redesigned the llvm package in Mandriva some months ago. See http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/llvm/current/SPECS/llvm.spec?view=markup selling point is using the Mandriva library policy, so it is possible, for example, to have installed at the same time libllvm3.0 and a possible libllvm3.1 in the near future. But the choice to give it major/minor 3.0 is not official... http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/llvm/current/SOURCES/llvm-3.0-soversion.patch?view=markup Also, libraries are installed in libdir, %_not %_libdir/llvm The advantage of building it with cmake is that llvm and clang packages are shared and a release build by default, and require like 6+ MB, while if built with %configure it will use like 250MB+ in a debug/static build to include everything. TIA, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Paulo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
