[gentoo-dev] Split ebuilds for GCC

[gentoo-dev] Split ebuilds for GCC

[Dirk Heinrichs]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

Hi,

there has been a lengthy discussion on bugzilla ([1]), about the best 
packaging method for the gnat Ada compiler. The outcome seems to be that 
gnat will still have its own ebuild in the future and not be part of the 
GCC ebuild. It also has a mention that gcj will eventually be split out 
from the GCC ebuild in the future.

So my question is: Would it be a good idea to generally turn GCC into split 
ebuilds (like KDE/X.org)? Pros/Cons?

Bye...

	Dirk

[1]: http://bugs.gentoo.org/show_bug.cgi?id=111340
-- 
Dirk Heinrichs          | Tel:  +49 (0)162 234 3408
Configuration Manager   | Fax:  +49 (0)211 47068 111
Capgemini Deutschland   | Mail: dirk.heinrichs@capgemini.com
Hambornerstraße 55      | Web:  http://www.capgemini.com
D-40472 Düsseldorf      | ICQ#: 110037733
GPG Public Key C2E467BB | Keyserver: www.keyserver.net

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] Split ebuilds for GCC

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

On Wed, 4 Jan 2006 08:47:00 +0100 Dirk Heinrichs
<ext-dirk.heinrichs@nokia.com> wrote:
| So my question is: Would it be a good idea to generally turn GCC into
| split ebuilds (like KDE/X.org)? Pros/Cons?

Sure, that'd be nice. It's also impossible, but don't let that stop you
from trying.

-- 
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Split ebuilds for GCC

[Dirk Heinrichs]

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

Am Mittwoch, 4. Januar 2006 09:16 schrieb ext Ciaran McCreesh:

> <ext-dirk.heinrichs@nokia.com> wrote:
> | So my question is: Would it be a good idea to generally turn GCC into
> | split ebuilds (like KDE/X.org)? Pros/Cons?
>
> Sure, that'd be nice. It's also impossible, but don't let that stop you
> from trying.

Could you explain why it is impossible?

However, my point is not trying to force GCC into split ebuilds, but rather 
having the GCC suite installed in a consistant manner. I don't like the 
idea of having a couple of languages in one ebuild, while other languages 
are installed via their own ebuild.

IMHO it would be easier for the end user (like me) to either install GCC 
with one ebuild, enabling the languages I want via USE flags, or have one 
ebuild for each language, but not one ebuild for a handful of languages and 
separated ebuilds for each of the others.

Bye...

	Dirk 
-- 
Dirk Heinrichs          | Tel:  +49 (0)162 234 3408
Configuration Manager   | Fax:  +49 (0)211 47068 111
Capgemini Deutschland   | Mail: dirk.heinrichs@capgemini.com
Hambornerstraße 55      | Web:  http://www.capgemini.com
D-40472 Düsseldorf      | ICQ#: 110037733
GPG Public Key C2E467BB | Keyserver: www.keyserver.net

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] Split ebuilds for GCC

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

On Wed, 4 Jan 2006 09:32:44 +0100 Dirk Heinrichs
<ext-dirk.heinrichs@nokia.com> wrote:
| Am Mittwoch, 4. Januar 2006 09:16 schrieb ext Ciaran McCreesh:
| > <ext-dirk.heinrichs@nokia.com> wrote:
| > | So my question is: Would it be a good idea to generally turn GCC
| > | into split ebuilds (like KDE/X.org)? Pros/Cons?
| >
| > Sure, that'd be nice. It's also impossible, but don't let that stop
| > you from trying.
| 
| Could you explain why it is impossible?

GCC does not have a nice clean build system, nor does it have a nice
clean modular setup that allows you to pick and choose language
frontends (or arch backends) at anything other than compile time. It's
just not designed to let you provide gcc-frontend-c, gcc-frontend-c++,
gcc-backend-x86-linux etc packages.

-- 
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Split ebuilds for GCC

[Dirk Heinrichs]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

Am Mittwoch, 4. Januar 2006 09:44 schrieb ext Ciaran McCreesh:

> GCC does not have a nice clean build system, nor does it have a nice
> clean modular setup that allows you to pick and choose language
> frontends (or arch backends) at anything other than compile time. It's
> just not designed to let you provide gcc-frontend-c, gcc-frontend-c++,
> gcc-backend-x86-linux etc packages.

That makes things more clear to me, thanks a lot.

Bye...

	Dirk
-- 
Dirk Heinrichs          | Tel:  +49 (0)162 234 3408
Configuration Manager   | Fax:  +49 (0)211 47068 111
Capgemini Deutschland   | Mail: dirk.heinrichs@capgemini.com
Hambornerstraße 55      | Web:  http://www.capgemini.com
D-40472 Düsseldorf      | ICQ#: 110037733
GPG Public Key C2E467BB | Keyserver: www.keyserver.net

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] Split ebuilds for GCC

[George Shapovalov]

Wow, thanks Dirk for bringing this up, but no thatnks for rushing - I haven't 
got my prototype ebuilds and eclass workign yet :). Well, I did somewhat, but 
not to the point where it would really, um, work..

Anyway, since this was brought up, I think I would do that -dev posting, to 
announce proposed changes and clarify the issue.

See, not only gcc is a mess, the situation with gnat, while technically 
somewhat more "stable", is messier "organizationally". In short, there are 
two communities now that develop ada (gcc-related) and three relevant 
compilers.

First (organization) is Ada Core - they do the development and most new 
features, they are involved with the Ada standard (Ada 200x - the standard, 
is almost out BTW and most of the new features are already "done") and also 
they do commercial support. They are a commercial company, a lot tike 
Trolltech, with a slightly different licensing model from what I can tell.
They issue two compilers:
gnatpro - a commercial "alternative" which you can use to sell software or do 
non-OS/academia development 
and
gnatgpl - essentially the same, but all GPL and released with some delay. And 
no support, except by public forums/lists of course..

Now, these two are supposed to share 99% of the code, so, theoretically, one 
package could deal with both. Unfortunately looks like that 1% difference is 
in legal land and not just some license bundled with the rest of it. The 
license clause is in the code and in pretty much every distributed spec file 
(analog of headers for C[++] distributed with compiler, for the rts system, 
etc.). So I am not sure we can simply use one ebuild with LICENSE="blah | 
blah". Although gnatgpl-2005 is not out yet, so we'll have to see it for 
real, when it is released.

Now, nice folks at gcc have picked it up recently as well (and they seem to be 
consistently active nowadays). They are mostly making it play nicely with the 
mainstream gcc (Ada Core's stuff is built vs fixed gcc version, quite far 
behind normally) and porting to other arches. This one is different enough 
technically to warrant separate ebuild, plus trying to stick all three 
together would make versioning insane (it is almost that now with a single 
gnat package (and gnatpro-3.15, gnatgcc-3.4x in..) and I don't want to think 
how we would agg the Ada Core's 2005 stuff in).

Keep in mind, I am not closely involved in either of these communities, so if 
somebody has any clarifications to these clarifications, just shoot them :).

So, the idea was to split gnat into three packages (gnatpro although would 
have to wait untill we sort it all out, make gnatgpl work and contact Ada 
Core..) plus an eclass "tu rule them all". In addition to following the logic 
of upstream this will give you the ability to install them in parallel, plus 
they will be SLOTted, to allow verrsions based on different backends to 
coexist..
Looks like that will have to be done via an extra eclass - gnatbuild, in 
addition to the gnat.eclass we have now. The gnatbuild will keep common 
functionality for building all the gnats and gnat.eclass is necessary for 
building ada packages (there is some shared code for them, mostly filtering 
flags and setting env). Plus the eselect module, to set the active compiler. 

Now, back to the topic at hand. 
gnatgcc (the proposed name for the compiler that's in gcc, maintained by FSF) 
*may be* joined with the rest of gcc, starting with gcc-4.0 or gcc-4.1 for 
example. It also *may be* kept separate. I would really like here to hear 
some opinions, as I heard users requesting it both ways.. Does anybody know 
if there is there is some "generic" Ada users hangout as well? I think it 
would be usefull to post something similar there, when I make it all work..

For more details please refer to #111340 and #64373.

Last, but not least: we need a long-term maintainer of ada stuff to help me 
and David Holm. I am really sidetracking now from the rest of Scientific 
Gentoo and Ezotheric Gentoo stuff that I do, so I would like to hand this 
over to somebody when I finish with this reorganization and make it work.. 
So, if there is anybody motivated enough to look over Ada in Gentoo, please 
follow the normal routine:
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=2
email recruiters, CC me or ada herd.. 
(Above that was apparently a call to users, if there is an interesetd in Ada 
dev, so much the better :)).

George

середа, 4. січень 2006 08:47, Dirk Heinrichs Ви написали:
> Hi,
>
> there has been a lengthy discussion on bugzilla ([1]), about the best
> packaging method for the gnat Ada compiler. The outcome seems to be that
> gnat will still have its own ebuild in the future and not be part of the
> GCC ebuild. It also has a mention that gcj will eventually be split out
> from the GCC ebuild in the future.
>
> So my question is: Would it be a good idea to generally turn GCC into split
> ebuilds (like KDE/X.org)? Pros/Cons?
>
> Bye...

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Split ebuilds for GCC

[Duncan]

Ciaran McCreesh posted <20060104084418.37ff6b02@snowdrop.home>, excerpted
below,  on Wed, 04 Jan 2006 08:44:18 +0000:

> On Wed, 4 Jan 2006 09:32:44 +0100 Dirk Heinrichs
> <ext-dirk.heinrichs@nokia.com> wrote:
> | Am Mittwoch, 4. Januar 2006 09:16 schrieb ext Ciaran McCreesh:
> | > <ext-dirk.heinrichs@nokia.com> wrote:
> | > | So my question is: Would it be a good idea to generally turn GCC
> | > | into split ebuilds (like KDE/X.org)? Pros/Cons?
> | >
> | > Sure, that'd be nice. It's also impossible, but don't let that stop
> | > you from trying.
> | 
> | Could you explain why it is impossible?
> 
> GCC does not have a nice clean build system, nor does it have a nice
> clean modular setup that allows you to pick and choose language
> frontends (or arch backends) at anything other than compile time. It's
> just not designed to let you provide gcc-frontend-c, gcc-frontend-c++,
> gcc-backend-x86-linux etc packages.

That begs the question... how is it then possible for gcj/java, gnat/ada
and the like? Are some languages treated differently upstream?  (Curious
users want to know! <g>)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Split ebuilds for GCC

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

On Wed, 04 Jan 2006 05:26:44 -0700 Duncan <1i5t5.duncan@cox.net> wrote:
| That begs the question...

No it doesn't.

http://www.wsu.edu/~brians/errors/begs.html

| Curious users want to know!

Perhaps said curious users should go and take a look, then.

-- 
Ciaran McCreesh : Gentoo Developer (King of all Londinium)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Split ebuilds for GCC

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]

Duncan wrote:
> Ciaran McCreesh posted <20060104084418.37ff6b02@snowdrop.home>, excerpted
> below,  on Wed, 04 Jan 2006 08:44:18 +0000:
> 
> 
>>On Wed, 4 Jan 2006 09:32:44 +0100 Dirk Heinrichs
>><ext-dirk.heinrichs@nokia.com> wrote:
>>| Am Mittwoch, 4. Januar 2006 09:16 schrieb ext Ciaran McCreesh:
>>| > <ext-dirk.heinrichs@nokia.com> wrote:
>>| > | So my question is: Would it be a good idea to generally turn GCC
>>| > | into split ebuilds (like KDE/X.org)? Pros/Cons?
>>| >
>>| > Sure, that'd be nice. It's also impossible, but don't let that stop
>>| > you from trying.
>>| 
>>| Could you explain why it is impossible?
>>
>>GCC does not have a nice clean build system, nor does it have a nice
>>clean modular setup that allows you to pick and choose language
>>frontends (or arch backends) at anything other than compile time. It's
>>just not designed to let you provide gcc-frontend-c, gcc-frontend-c++,
>>gcc-backend-x86-linux etc packages.
> 
> 
> That begs the question... how is it then possible for gcj/java, gnat/ada
> and the like? Are some languages treated differently upstream?  (Curious
> users want to know! <g>)
> 

It is not possible for gcj/java. The best thing you can do is to make on
ebuild for gcj that just disables as much as it can in the gcc build
process. This does not avoid duplication but helps somewhat. Work on
this has already been done by one of our users. If you are interested in
this take a look at:

http://research.operationaldynamics.com/linux/gentoo/dev-java/gcj-jdk/

I have talked with the upstream gcj maintainer in the past and they are
planning to separate gcj in such a way from the core that they would be
able to make separate releases. He just said that the binary interface
between the two is just not stable enough yet.

Regards,
Petteri

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

[gentoo-dev] Re: Re: Split ebuilds for GCC

[Duncan]

Ciaran McCreesh posted <20060104123442.1768e676@snowdrop.home>, excerpted
below,  on Wed, 04 Jan 2006 12:34:42 +0000:

> On Wed, 04 Jan 2006 05:26:44 -0700 Duncan <1i5t5.duncan@cox.net> wrote:
> | That begs the question...
> 
> No it doesn't.
> 
> http://www.wsu.edu/~brians/errors/begs.html

Forget formal logic, it still "begs the question", in that it "begs that
the question be asked".  IOW, a narrowly constructed answer was /too/
narrow -- it didn't answer a follow-on question that logically follows
from the answer as given.  Thus, it "begs" that the follow-on question be
asked.

You (and the above link) are using "beg" in the sense of [1913 Webster]
definition 4: "To take for granted; to assume without proof."  If that
definition fails to make sense (as it does) in context, look to the other
definitions.  "Beg" in the sense of [1913 Webster] definition 3 makes
perfect sense in context: "To make petition to; to entreat; as, to beg a
person to grant a favor", or definition 1:  "To ask earnestly for; to
entreat or supplicate for; to beseech."

It also mentions that it may imply deference or respect, rather than
earnestness.  I should also mention that it has a specfic sub-entry for
"To beg the question", which does indeed invoke the definition four usage
as you and the above link did.  However, that's not the only meaning of
beg, tho it may have been the common meaning in the context of "begging
the question" at that time.

Therefore, while "to beg the question" as used here doesn't work in the
"assume that which was to be proved" sense, it works quite well in the
"causes a follow-up question to be asked with earnestness and/or respect"
sense.

Wordnet has a more modern definition that leaves out the "proof" concept
entirely.  Beg:  1: "Call upon in supplication; entreat [...] [syn:
implore, pray]."  2: "Make a solicitation or entreaty for something;
request urgently or persistently [...] [syn: solicit, tap]."  (The third
definition is "ask to obtain free; "beg money and food", but that doesn't
really apply to either usage under discussion.  There is no fourth
definition, so no "proof" concept in the modern Wordnet definition at all.)

So... tho your definition fit with the usage in 1913, it doesn't appear to
fit with modern usage nearly a century later.  Even in 1913, however, one
couldn't properly say my usage was entirely incorrect, given the other
definitions for the word "beg".

The definitions above courtesy of kdict, KDE's desktop dictionary
protocol applet, with its default source of dict.org.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Split ebuilds for GCC

[Stephen P. Becker]

Duncan wrote:
> Ciaran McCreesh posted <20060104123442.1768e676@snowdrop.home>, excerpted
> below,  on Wed, 04 Jan 2006 12:34:42 +0000:
> 
> 
>>On Wed, 04 Jan 2006 05:26:44 -0700 Duncan <1i5t5.duncan@cox.net> wrote:
>>| That begs the question...
>>
>>No it doesn't.
>>
>>http://www.wsu.edu/~brians/errors/begs.html
> 
> 
> Forget formal logic, it still "begs the question", in that it "begs that
> the question be asked".

Wrong.

-Steve

P.S. Maybe some people might actually read your emails if you didn't 
feel the need to write a 100 page dissertation 5 times a day...
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Split ebuilds for GCC

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

Duncan wrote:	[Wed Jan 04 2006, 02:49:39PM EST]
> Forget formal logic, it still "begs the question", in that it "begs
> that the question be asked".

No, the reason you used the expression "begs the question" is because
it sounds familiar to you.  Otherwise you would have said something
like "brings up the question."  The fact is that "begs the question"
is an expression with a particular meaning, and it shouldn't be
confused with the sum of its parts.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Re: Split ebuilds for GCC

[Tomasz Mloduchowski]

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

Aron Griffis wrote:
> Duncan wrote:	[Wed Jan 04 2006, 02:49:39PM EST]
> 
>>Forget formal logic, it still "begs the question", in that it "begs
>>that the question be asked".
> 
> 
> No, the reason you used the expression "begs the question" is because
> it sounds familiar to you.  Otherwise you would have said something
> like "brings up the question."  The fact is that "begs the question"
> is an expression with a particular meaning, and it shouldn't be
> confused with the sum of its parts.
Altough, the primary function of the language is as a means of
communication. While I must agree that 'official' meaning of 'begs the
question' is not 'brings up the question', I believe the number of
English users who understands this statement in 'brings up' meaning
exceeds the number of formalists.

English is not a standard, until somebody RFC'd it. It's evolving, we
saw the career of podcasting, I believe we will see in 20 years:

begs the question:
	brings up the question. (archaic: ...)

So, why not make this linguistic debate EOT for now... and resume it
with Gentoo 2020.0 ?

Best wishes,
Tomasz Mloduchowski
- Gentoo User


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Split definitions for an idiom

[Drake Wyrm]

Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> On Wed, 04 Jan 2006 05:26:44 -0700 Duncan <1i5t5.duncan@cox.net> wrote:
> | That begs the question...
> 
> No it doesn't.
> 
> http://www.wsu.edu/~brians/errors/begs.html
> 
> | Curious users want to know!
> 
> Perhaps said curious users should go and take a look, then.

Or as illustrated in an amazingly apropos edition of a webcomic:

http://qwantz.com/index.pl?comic=693

-- 
Human beings, who are almost unique in having the ability
to learn from the experience of others, are also
remarkable for their apparent disinclination to do so.
  -- Douglas Adams
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Split definitions for an idiom

[Duncan]

Drake Wyrm posted <20060107095923.GA11945@phaenix.haell.com>, excerpted
below,  on Sat, 07 Jan 2006 01:59:23 -0800:

> http://qwantz.com/index.pl?comic=693

Apropos indeed.  Thanks!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Split ebuilds for GCC

[Kumba]

Dirk Heinrichs wrote:
> Hi,
> 
> there has been a lengthy discussion on bugzilla ([1]), about the best 
> packaging method for the gnat Ada compiler. The outcome seems to be that 
> gnat will still have its own ebuild in the future and not be part of the 
> GCC ebuild. It also has a mention that gcj will eventually be split out 
> from the GCC ebuild in the future.
> 
> So my question is: Would it be a good idea to generally turn GCC into split 
> ebuilds (like KDE/X.org)? Pros/Cons?

The only case where we actually split anything is for the few C-only kernel 
compiler packages, gcc-mips64, gcc-sparc64, gcc-powerpc64, etc..  These disable 
everything else but C, as this compiler is explicitly only for kernel building.

Anything else...good luck.  Aim for manipulating USE flags properly, though, to 
disable features of gcc you don't want or need.  This works better than 
splitting everything.


--Kumba

-- 
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond
-- 
gentoo-dev@gentoo.org mailing list