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

[Lei Zhang]

Hi,

I'm proposing to offer a new eselect module "compiler". Briefly
speaking, it manages /usr/bin/{cc,c++} as symlinks to C/C++ compilers
specified by the user.

This is related to my GSoC project: to use clang as the native
compiler in Gentoo. While putting "CC=clang" in make.defaults could
make portage use clang, symlinking cc/c++ to clang allows build tools
like GNU Make and CMake to also use clang as the default compiler,
making it feel more "native".

This module should be orthogonal to gcc-config. It just switches
between gcc, clang or whatever compiler, and doesn't care what version
of gcc is in use. Currently gcc, clang and icc are supported in my
implementation.

Another two programs that might be of interest are /usr/bin/{c89,c99}.
Currently they are just scripts that invoke gcc with proper "-std=..."
option. I'm not sure if any build tools use them instead of cc. In
that case, they probably should be handled by `eselect compiler` as
well.

A side note: actually there's a small issue with GNU make and I'm
trying to fix it. Please refer to
https://bugs.gentoo.org/show_bug.cgi?id=589894 and
https://github.com/gentoo/gentoo/pull/1982


Lei


compiler.eselect
Description: Binary data

[gentoo-dev] Packages up for grabs

[Michael Palimaka]

net-libs/qtweetlib - no revdeps, likely to be treecleaned at some point
if nobody wants it

dev-cpp/clucene - a couple of important revdeps but not much activity
upstream

Re: [gentoo-dev] [RFC] lua.eclass

[Michał Górny]

On Wed, 27 Jul 2016 14:54:15 +0700
"Vadim A. Misbakh-Soloviov"  wrote:

> Thanks a lot for your review work and critics.
> 
> Just 2 cents as comments about "why the hell is going on":
> 
> > It looks like a terrible masterpiece combination of base.eclass with   
> python.eclass
> 
> Actually, ruby-ng + python + some of that opera. And all of them was 
> (actually, still) huge monsters with tons of magic.
> 
> I mean, the eclass (in my point of view, not really counted LOC) is 70% 
> copied 
> from ruby-ng/python eclasses, 10% "unneded" magic crap and 20% is my own work.
> 
> And main target was to... Just to write less code in the ebuilds and let 
> eclass do all the magic, like ruby/perl/python/php eclsses does.

This is a non-goal. Crappy eclasses are not good examples, and you can
easily see a trend of improvement, with eclasses doing less completely
unrelated things.

It's better to have more code in ebuild than to have everyone else
waste precious time on figuring out why some ebuilds magically have X
and some others don't.

-- 
Best regards,
Michał Górny



pgpfxfulCNnkC.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] lua.eclass

[Vadim A. Misbakh-Soloviov]

Thanks a lot for your review work and critics.

Just 2 cents as comments about "why the hell is going on":

> It looks like a terrible masterpiece combination of base.eclass with 
python.eclass

Actually, ruby-ng + python + some of that opera. And all of them was 
(actually, still) huge monsters with tons of magic.

I mean, the eclass (in my point of view, not really counted LOC) is 70% copied 
from ruby-ng/python eclasses, 10% "unneded" magic crap and 20% is my own work.

And main target was to... Just to write less code in the ebuilds and let 
eclass do all the magic, like ruby/perl/python/php eclsses does.


> Kill it with fire. Start over. Focus on Lua. Stop reinventing
> everything else, and attempting to convert ebuilds into some terrible
> openrc-class semi-broken declarative crap which attempts to guess what
> the developer meant.

Ok, I'll try. Although, I guess, I then fail to reach the target of having 
less code in the ebuilds as a price of being done in a right way :)

And I want to mention just once more time, that actual target was to have as 
less code in ebuilds as possible, like it is for ruby-ng, perl and python 
packages. But it seems, I turned in wrong direction somewhere.

=== semiofftopic ===

By the way, some packages authors doing monster buildsystems which is non 
intended to work with distro's package managers, and says users must use 
language-specific package manager (gem,pip,luarocks,whatever), which is fully 
supported by them.

And if previously I was supporting the point that langname-modules should be 
installed system-wide through portage, then now (after having tons of sex with 
their buildsystems just to make it to obey gentoo's practice (say, like not 
doing network operations during src_prepare/configure/compile)) I'm in doubts.

=== / ===


-- 
wbr,
mva