Specifying and build output separately?

Specifying and build output separately?

[Hartmut Goebel]

Hi,

we have several cyclic dependencies due to e.g. packages depending on
each other only for building the documentation. Examples are numpy and
matpltlib.

So I wonder it it would be possible to to something like this:

(define-public numpy:doc
  (inherit numpy)
  (name "numpy:doc")
  (outputs "doc")
  (inputs … matplotlib …)
  (… modify-phases …))


This would at least help breaking cycles where only specific the
documentation is effected. It will still not solve more complex
situation we have for python--tk--libxck--python, i assume. But maybe
this could be generalized.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Specifying and build output separately?

[Ludovic Courtès]

Hello,

Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:

> we have several cyclic dependencies due to e.g. packages depending on
> each other only for building the documentation. Examples are numpy and
> matpltlib.
>
> So I wonder it it would be possible to to something like this:
>
> (define-public numpy:doc
>   (inherit numpy)
>   (name "numpy:doc")
>   (outputs "doc")
>   (inputs … matplotlib …)
>   (… modify-phases …))

Making the documentation a separate package, instead of a separate
output, is of course doable and it could help address the circular
reference issue.

Currently the approach used for numpy is a different one: there’s a
“bootstrap” package lacking documentation that is used as input to the
final package, which has an extra “doc” output.

I prefer this approach over what you propose because it’s more
consistent with what we usually do, which is to have doc in a “doc”
output rather than in a separate package.

Thanks,
Ludo’.

Re: Specifying and build output separately?

[Hartmut Goebel]

Am 17.10.2016 um 10:55 schrieb Ludovic Courtès:
> I prefer this approach over what you propose because it’s more
> consistent with what we usually do, which is to have doc in a “doc”
> output rather than in a separate package.

Yes, but it has the major drawback of building numpy twice - which is
quite time-consuming.

If we could "augment" the existing bootstrap package, for the normal
one, this would save the second build.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Specifying and build output separately?

[Ludovic Courtès]

Hartmut Goebel <h.goebel@crazy-compilers.com> skribis:

> Am 17.10.2016 um 10:55 schrieb Ludovic Courtès:
>> I prefer this approach over what you propose because it’s more
>> consistent with what we usually do, which is to have doc in a “doc”
>> output rather than in a separate package.
>
> Yes, but it has the major drawback of building numpy twice - which is
> quite time-consuming.
>
> If we could "augment" the existing bootstrap package, for the normal
> one, this would save the second build.

You’re right.  However, the approach so far has been to favor usability
or convenience over build time.  The rationale is that most users do not
build everything locally.

Does that make sense?

Ludo’.