Hydra time out

Hydra time out

[Andreas Enge]

gcc-objc++-4.8.2.mips64el-linux fails to be built because of:

building of `/gnu/store/avdn8phqm44v33p6k42pipybcgjs92mb-gcc-objc++-4.8.2.drv' timed out after 72000 seconds
@ build-failed /gnu/store/avdn8phqm44v33p6k42pipybcgjs92mb-gcc-objc++-4.8.2.drv - timeout

I think it simply takes more than 12 hours...

Do you think there might be a way of compiling all gcc languages in one go
instead of in several packages? Maybe enable all languages in gcc? Or would
this create too big a gcc package? Also, maybe we could drop one of the three
gcc versions.

And finally, why are there two gcc-4.8.2 packages, and where are they actually?
$ guix package -A gcc
gcc     4.7.3   out     gnu/packages/gcc.scm:95:4
gcc     4.8.2   out     gnu/packages/gcc.scm:95:4
gcc     4.9.0   out     gnu/packages/gcc.scm:95:4
gcc     4.8.2   out     gnu/packages/gcc.scm:95:4

Is there a way of printing not the line 95 in which the base gcc package is
defined from which all others inherit, but the line where the actual package
is defined?

Andreas

GCC language front-ends

[Ludovic Courtès]

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

Andreas Enge <andreas@enge.fr> skribis:

> gcc-objc++-4.8.2.mips64el-linux fails to be built because of:
>
> building of `/gnu/store/avdn8phqm44v33p6k42pipybcgjs92mb-gcc-objc++-4.8.2.drv' timed out after 72000 seconds
> @ build-failed /gnu/store/avdn8phqm44v33p6k42pipybcgjs92mb-gcc-objc++-4.8.2.drv - timeout
>
> I think it simply takes more than 12 hours...

Ahah.  :-)

> Do you think there might be a way of compiling all gcc languages in one go
> instead of in several packages? Maybe enable all languages in gcc? Or would
> this create too big a gcc package?

That would be too big.  Plus, when you say “all”, do you really mean Ada
and Java for instance?  These make things definitely bigger.

> Also, maybe we could drop one of the three gcc versions.

The default package does C and C++.  We could imagine another one that
would in addition to Objective-C and FORTRAN, yes.  That would save
build time, at the expense of being somewhat confusing to the user IMO.

> And finally, why are there two gcc-4.8.2 packages, and where are they actually?
> $ guix package -A gcc
> gcc     4.7.3   out     gnu/packages/gcc.scm:95:4
> gcc     4.8.2   out     gnu/packages/gcc.scm:95:4
> gcc     4.9.0   out     gnu/packages/gcc.scm:95:4
> gcc     4.8.2   out     gnu/packages/gcc.scm:95:4

One of the GCC 4.8.2 is ‘gcc-final’ in base.scm.

> Is there a way of printing not the line 95 in which the base gcc package is
> defined from which all others inherit, but the line where the actual package
> is defined?

Yes, good idea.

I’ve just committed this patch:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 366 bytes --]

--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -971,6 +971,7 @@ exec ~a/bin/~a-~a -B~a/lib -Wl,-dynamic-linker -Wl,~a/~a \"$@\"~%"
   ;; The final GCC.
   (package (inherit gcc-boot0)
     (name "gcc")
+    (location (source-properties->location (current-source-location)))
     (arguments
      `(#:guile ,%bootstrap-guile
        #:implicit-inputs? #f

[-- Attachment #3: Type: text/plain, Size: 21 bytes --]


Thanks,
Ludo’.

Re: GCC language front-ends

[Andreas Enge]

On Wed, Jun 04, 2014 at 11:34:33PM +0200, Ludovic Courtès wrote:
> That would be too big.  Plus, when you say “all”, do you really mean Ada
> and Java for instance?  These make things definitely bigger.

Okay.

> > Also, maybe we could drop one of the three gcc versions.
> The default package does C and C++.  We could imagine another one that
> would in addition to Objective-C and FORTRAN, yes.  That would save
> build time, at the expense of being somewhat confusing to the user IMO.

Sorry, here I meant the version numbers 4.7.3, 4.8.2 and 4.9.0. Maybe we could
drop 4.7.0?

> One of the GCC 4.8.2 is ‘gcc-final’ in base.scm.

So this is the one that is used for compiling all our packages? Could we
then not drop the gcc-4.8.2 from gcc.scm and let the user install gcc-final?
Or otherwise, give it a different NAME?

> > Is there a way of printing not the line 95 in which the base gcc package is
> > defined from which all others inherit, but the line where the actual package
> > is defined?
> Yes, good idea.
> I’ve just committed this patch:

Hm, I meant in all generality for all packages that are inherited. Would
this be easily possible?

Andreas

Re: GCC language front-ends

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Wed, Jun 04, 2014 at 11:34:33PM +0200, Ludovic Courtès wrote:

[...]

>> > Also, maybe we could drop one of the three gcc versions.
>> The default package does C and C++.  We could imagine another one that
>> would in addition to Objective-C and FORTRAN, yes.  That would save
>> build time, at the expense of being somewhat confusing to the user IMO.
>
> Sorry, here I meant the version numbers 4.7.3, 4.8.2 and 4.9.0. Maybe we could
> drop 4.7.0?

Eventually yes, but for now I think it may still be useful to have 4.7
around (for instance, as a developer it’s sometimes useful to test with
older compilers.)

>> One of the GCC 4.8.2 is ‘gcc-final’ in base.scm.
>
> So this is the one that is used for compiling all our packages?

Yes.

> Could we then not drop the gcc-4.8.2 from gcc.scm and let the user
> install gcc-final?  Or otherwise, give it a different NAME?

It’s been discussed several times, but there’s no satisfactory solution
so far.  Changing the name seems like a bad idea, because it’s really
gcc.  Making either gcc-final or gcc-4.8 private isn’t an option because
they’re referred from elsewhere.

Maybe package objects should have an extra property that says whether
they should be hidden?

>> > Is there a way of printing not the line 95 in which the base gcc package is
>> > defined from which all others inherit, but the line where the actual package
>> > is defined?
>> Yes, good idea.
>> I’ve just committed this patch:
>
> Hm, I meant in all generality for all packages that are inherited. Would
> this be easily possible?

Hmm, define-record-type* could be augmented with an inheritable? flag,
and the ‘location’ field would be marked as non-inheritable, something
like that.

Ludo’.

Re: GCC language front-ends

[Andreas Enge]

On Thu, Jun 05, 2014 at 03:00:57PM +0200, Ludovic Courtès wrote:
> It’s been discussed several times, but there’s no satisfactory solution
> so far.  Changing the name seems like a bad idea, because it’s really
> gcc.  Making either gcc-final or gcc-4.8 private isn’t an option because
> they’re referred from elsewhere.

Sorry for my forgetfulness. So the references to gcc-4.8 could not be replaced
by references to gcc-final? Notice, for instance, that gcc-toolchain-4.8 does
not use gcc-4.8, but gcc-final already.

Andreas

Re: GCC language front-ends

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Thu, Jun 05, 2014 at 03:00:57PM +0200, Ludovic Courtès wrote:
>> It’s been discussed several times, but there’s no satisfactory solution
>> so far.  Changing the name seems like a bad idea, because it’s really
>> gcc.  Making either gcc-final or gcc-4.8 private isn’t an option because
>> they’re referred from elsewhere.
>
> Sorry for my forgetfulness. So the references to gcc-4.8 could not be replaced
> by references to gcc-final?

No.  It’s a bit tricky but the idea is: gcc-4.8 is the “abstract” recipe
for GCC, whereas gcc-final is a specialized recipe for use in the
bootstrap process.

The abstract recipe has useful properties:

  • it is a “normal”, self-contained package recipe, and thus easier to
    grasp;

  • it can be cross-compiled (whereas gcc-final cannot, because it is
    anchored in the bootstrap dependency DAG);

  • it can easily be derived (for gfortran, etc.);

  • it remains valid even when the default GCC version changes.

So we need that abstract gcc-4.8.

At the same time, for native compilation, we only ever want to use
gcc-final, because gcc-4.8 is just the same compiler built once more
with itself.

So ideally, ‘guix package’ would magically ignore the abstract gcc-4.8
(and coreutils, grep, etc.) and favor their -final variant.

I hope I’m being clear, but I’m not sure.  ;-)

Ludo’.