Re: [gentoo-dev] Empty project: LXDE

2016-08-09 Thread Raymond Jennings
Hey, just a heads up as a user.  I'm currently using LXDE.

On Sun, Aug 7, 2016 at 1:22 AM, Pacho Ramos  wrote:

> Now https://wiki.gentoo.org/wiki/Project:LXDE is empty
>
> Feel free to join, anyway, if I don't misremember, LXDE is dead for a
> long time in favor of LXQT... in that case treecleaning the packages
> would also be an option
>
> Thanks
>
>


Re: [gentoo-dev] [RFC] new eselect module: compiler

2016-08-09 Thread M. J. Everitt
On 10/08/16 06:08, Michał Górny wrote:
> On Wed, 10 Aug 2016 01:52:29 +0100
> "M. J. Everitt"  wrote:
>
>> On 10/08/16 01:39, Lei Zhang wrote:
>>> 2016-08-09 13:58 GMT+08:00 Fabian Groffen :
 As a question to Lei, I'm wondering why you chose eselect compiler, and
 not gcc-config to manage the links.  In a way, gcc-config is tailored
 towards gcc, but it does a lot of things also for the environment.  With
 clang, from my experience, you just want it as drop-in replacement for
 gcc as it doesn't give you too much issues (on Darwin at least).
>>> In its current form, gcc-config specializes in handling different
>>> versions of gcc. If we extend it to cover other compilers (and rename
>>> it to cc-config as James suggested), should it handle different
>>> versions of clang? What about different versions of icc?
>>>
>>> I'm just afraid gcc-config would become too complex that way, so I
>>> prefer a simpler approach: let eselect-compiler be version-agnostic.
>>> Then we can have clang-config to handle the versioning of clang,
>>> icc-config to handle icc, etc.
>>>
>>>
>>> Lei
>>>
>> Extending the ideas presented in this thread .. you could introduce
>> cc-config, and which utility script it runs would then be governed by
>> eselect compiler .. eg. gcc would have gcc-config, clang would run
>> clang-config ..
> .. to switch between the one version of clang that can be installed?
>
Tis early days Mr Gorny .. who knows what the future holds .. and Gentoo
is all about choice, right?!



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] new eselect module: compiler

2016-08-09 Thread Michał Górny
On Wed, 10 Aug 2016 01:52:29 +0100
"M. J. Everitt"  wrote:

> On 10/08/16 01:39, Lei Zhang wrote:
> > 2016-08-09 13:58 GMT+08:00 Fabian Groffen :
> >> As a question to Lei, I'm wondering why you chose eselect compiler, and
> >> not gcc-config to manage the links.  In a way, gcc-config is tailored
> >> towards gcc, but it does a lot of things also for the environment.  With
> >> clang, from my experience, you just want it as drop-in replacement for
> >> gcc as it doesn't give you too much issues (on Darwin at least).
> > In its current form, gcc-config specializes in handling different
> > versions of gcc. If we extend it to cover other compilers (and rename
> > it to cc-config as James suggested), should it handle different
> > versions of clang? What about different versions of icc?
> >
> > I'm just afraid gcc-config would become too complex that way, so I
> > prefer a simpler approach: let eselect-compiler be version-agnostic.
> > Then we can have clang-config to handle the versioning of clang,
> > icc-config to handle icc, etc.
> >
> >
> > Lei
> >
> Extending the ideas presented in this thread .. you could introduce
> cc-config, and which utility script it runs would then be governed by
> eselect compiler .. eg. gcc would have gcc-config, clang would run
> clang-config ..

.. to switch between the one version of clang that can be installed?

-- 
Best regards,
Michał Górny



pgpkxSSO5MOFn.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] new eselect module: compiler

2016-08-09 Thread Benda Xu
Lei Zhang  writes:

> I'm just afraid gcc-config would become too complex that way, so I
> prefer a simpler approach: let eselect-compiler be version-agnostic.
> Then we can have clang-config to handle the versioning of clang,
> icc-config to handle icc, etc.

If we model after eselect python here, `eselect python` governs versions
of python as well as pypy.

Benda



Re: [gentoo-dev] [RFC] new eselect module: compiler

2016-08-09 Thread Lei Zhang
2016-08-10 0:16 GMT+08:00 Zac Medico :
> I'm guessing you Darwin folks don't compile many Linux kernels? The last
> I heard, clang is not yet a drop-in replacement for gcc when building
> the Linux kernel:
>
> http://llvm.linuxfoundation.org/index.php/Main_Page

Yes, Linux kernel has to be built by gcc at the moment. Last time I
checked it, the kernel source is hardcoded to use gcc, so changing cc
won't affect it.

Other than the kernel, non-gcc compilers should work just fine in
userland. FWIW, I've tried rebuilding @world with clang on my host;
only two packages failed and they are very easy to fix [1].


[1] 
https://blogs.gentoo.org/gsoc2016-native-clang/2016/07/24/a-new-gentoo-stage4-musl-clang/

Lei



Re: [gentoo-dev] [RFC] new eselect module: compiler

2016-08-09 Thread M. J. Everitt
On 10/08/16 01:39, Lei Zhang wrote:
> 2016-08-09 13:58 GMT+08:00 Fabian Groffen :
>> As a question to Lei, I'm wondering why you chose eselect compiler, and
>> not gcc-config to manage the links.  In a way, gcc-config is tailored
>> towards gcc, but it does a lot of things also for the environment.  With
>> clang, from my experience, you just want it as drop-in replacement for
>> gcc as it doesn't give you too much issues (on Darwin at least).
> In its current form, gcc-config specializes in handling different
> versions of gcc. If we extend it to cover other compilers (and rename
> it to cc-config as James suggested), should it handle different
> versions of clang? What about different versions of icc?
>
> I'm just afraid gcc-config would become too complex that way, so I
> prefer a simpler approach: let eselect-compiler be version-agnostic.
> Then we can have clang-config to handle the versioning of clang,
> icc-config to handle icc, etc.
>
>
> Lei
>
Extending the ideas presented in this thread .. you could introduce
cc-config, and which utility script it runs would then be governed by
eselect compiler .. eg. gcc would have gcc-config, clang would run
clang-config ..



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] new eselect module: compiler

2016-08-09 Thread Zac Medico
On 08/08/2016 10:58 PM, Fabian Groffen wrote:
> On 08-08-2016 13:45:07 -0500, R0b0t1 wrote:
>> On Mon, Aug 8, 2016 at 11:23 AM, Lei Zhang  wrote:
>>> "cc" is the standard C compiler name defined in POSIX, so ideally any
>>> gcc-agnostic programs should use "cc" instead of "gcc". Practically,
>>> build tools like GNU Make and CMake would be affected as they use "cc"
>>> implicitly.
>>
>> It is not just programs which rely on GNU extensions, but poorly
>> created scripts that rely on a compiler directly or otherwise break
>> portability.
> 
> I'd agree and say "gcc" is hardcoded in many places, that's why I
> believe Apple includes a gcc which is clang on their systems, same for
> cc.
> 
> As a question to Lei, I'm wondering why you chose eselect compiler, and
> not gcc-config to manage the links.  In a way, gcc-config is tailored
> towards gcc, but it does a lot of things also for the environment.  With
> clang, from my experience, you just want it as drop-in replacement for
> gcc as it doesn't give you too much issues (on Darwin at least).
> 
> Fabian
> 
> 

I'm guessing you Darwin folks don't compile many Linux kernels? The last
I heard, clang is not yet a drop-in replacement for gcc when building
the Linux kernel:

http://llvm.linuxfoundation.org/index.php/Main_Page
-- 
Thanks,
Zac



Re: [gentoo-dev] [RFC] new eselect module: compiler

2016-08-09 Thread james

On 08/09/2016 12:58 AM, Fabian Groffen wrote:

On 08-08-2016 13:45:07 -0500, R0b0t1 wrote:

On Mon, Aug 8, 2016 at 11:23 AM, Lei Zhang  wrote:

"cc" is the standard C compiler name defined in POSIX, so ideally any
gcc-agnostic programs should use "cc" instead of "gcc". Practically,
build tools like GNU Make and CMake would be affected as they use "cc"
implicitly.


It is not just programs which rely on GNU extensions, but poorly
created scripts that rely on a compiler directly or otherwise break
portability.


I'd agree and say "gcc" is hardcoded in many places, that's why I
believe Apple includes a gcc which is clang on their systems, same for
cc.

As a question to Lei, I'm wondering why you chose eselect compiler, and
not gcc-config to manage the links.  In a way, gcc-config is tailored
towards gcc, but it does a lot of things also for the environment.  With
clang, from my experience, you just want it as drop-in replacement for
gcc as it doesn't give you too much issues (on Darwin at least).

Fabian




There are many things afoot with compilers, particularly related to 
distributed and tightly coupled parallel systems. Perhaps a name change

from gcc-config to cc-config would be more accurate or better if that
aspect of choice is to accurately reflect the choices going forward?

Also, when you get down to smaller microprocessor levels there are often 
numerous choices for compilers. Granted, today, most of those are still 
commercial, but, pressure over time could very likely see many of those 
compilers going the open source route, confounding the choice issue for 
a more open naming convention for gcc-config?



hth,
James