Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

New eclass: oasis.eclass for oasis-based ocaml packages.

 

 

Gentoo dev RSS feed   Index | Next | Previous | View Threaded


aballier at gentoo

Mar 23, 2012, 1:15 AM

Post #1 of 24 (460 views)
Permalink
New eclass: oasis.eclass for oasis-based ocaml packages.

Hi,

Oasis [1] is becoming the de factor standard for ocaml packages. I've
been bored of copy/pasting always the same code from ebuilds to ebuilds
and thus decided to write an eclass simplifying everything.

Attached: said eclass, a diff of a random dev-ml package I've
converted to illustrate and said random ebuild now.

Comments welcome,

Alexis.

[1] http://oasis.forge.ocamlcore.org/
Attachments: oasis.eclass (2.66 KB)
  fieldslib.diff (1.25 KB)
  fieldslib-0.1.2.ebuild (0.52 KB)


floppym at gentoo

Mar 23, 2012, 8:58 AM

Post #2 of 24 (452 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

On Fri, Mar 23, 2012 at 4:15 AM, Alexis Ballier <aballier [at] gentoo> wrote:

> DEPEND=">=dev-lang/ocaml-3.12[ocamlopt?]"
> DEPEND="${RDEPEND}"

That looks like a typo.

> oasis_src_compile() {
> oasis_src_compile_no_doc
> if has doc ${IUSE} && use doc; then
> ocaml setup.ml -doc || die
> fi
> }

This should probably call use_if_iuse from eutils.eclass, which
handles IUSE="[+-]doc".


ciaran.mccreesh at googlemail

Mar 23, 2012, 9:02 AM

Post #3 of 24 (453 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

On Fri, 23 Mar 2012 11:58:47 -0400
Mike Gilbert <floppym [at] gentoo> wrote:
> > oasis_src_compile() {
> > oasis_src_compile_no_doc
> > if has doc ${IUSE} && use doc; then
> > ocaml setup.ml -doc || die
> > fi
> > }
>
> This should probably call use_if_iuse from eutils.eclass, which
> handles IUSE="[+-]doc".

Actually, neither way works. The spec says:

Global variables must only contain invariant values
(see~\ref{sec:metadata-invariance}). If a global variable's value is
invariant, it may have the value that would be generated at any
given point in the build sequence.

So you can't rely upon IUSE having the "merged" value in an eclass.

--
Ciaran McCreesh
Attachments: signature.asc (0.19 KB)


axs at gentoo

Mar 23, 2012, 9:14 AM

Post #4 of 24 (452 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 23/03/12 12:02 PM, Ciaran McCreesh wrote:
> On Fri, 23 Mar 2012 11:58:47 -0400 Mike Gilbert
> <floppym [at] gentoo> wrote:
>>> oasis_src_compile() { oasis_src_compile_no_doc if has doc
>>> ${IUSE} && use doc; then ocaml setup.ml -doc || die fi }
>>
>> This should probably call use_if_iuse from eutils.eclass, which
>> handles IUSE="[+-]doc".
>
> Actually, neither way works. The spec says:
>
> Global variables must only contain invariant values
> (see~\ref{sec:metadata-invariance}). If a global variable's value
> is invariant, it may have the value that would be generated at any
> given point in the build sequence.
>
> So you can't rely upon IUSE having the "merged" value in an
> eclass.
>

I don't know if I follow this one or not. When inheriting an eclass,
all entities within the eclass get merged into the ebuild. As long as
there aren't any special conditional tricks being used to assign to
global variables like IUSE, it would still be invariant wouldn't it?

I think 'any point in the build sequence' is still
post-eclass-inheritance isn't it?



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9soW8ACgkQAJxUfCtlWe1UJQEAuTQriXmsu6YKcpeADGusTNdZ
k8Vr99LdEFwyXicZHMsBAN2bo95GvLvdrpVEj8h1THQ4HMZDvPRx0o/yrWzjxGNZ
=+e3P
-----END PGP SIGNATURE-----


ciaran.mccreesh at googlemail

Mar 23, 2012, 9:19 AM

Post #5 of 24 (453 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 23 Mar 2012 12:14:39 -0400
Ian Stakenvicius <axs [at] gentoo> wrote:
> I don't know if I follow this one or not. When inheriting an eclass,
> all entities within the eclass get merged into the ebuild. As long as
> there aren't any special conditional tricks being used to assign to
> global variables like IUSE, it would still be invariant wouldn't it?

The point is that the merging might be done inside the package manager
(not in bash code) on the IUSE metadata variable, and the changes don't
have to be reflected in the IUSE environment variable inside the ebuild.

> I think 'any point in the build sequence' is still
> post-eclass-inheritance isn't it?

Nope. It's also at any point during the sourcing of any of the files.

- --
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk9sonsACgkQ96zL6DUtXhEtFgCgyT/pUwKQIaLE8e28U8P0uS3x
HF8An1frYjZvoNYSC2/Qs1eNzqdlgVzT
=Kj+k
-----END PGP SIGNATURE-----


axs at gentoo

Mar 23, 2012, 9:32 AM

Post #6 of 24 (453 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 23/03/12 12:19 PM, Ciaran McCreesh wrote:
> On Fri, 23 Mar 2012 12:14:39 -0400 Ian Stakenvicius
> <axs [at] gentoo> wrote:
>> I don't know if I follow this one or not. When inheriting an
>> eclass, all entities within the eclass get merged into the
>> ebuild. As long as there aren't any special conditional tricks
>> being used to assign to global variables like IUSE, it would
>> still be invariant wouldn't it?
>
> The point is that the merging might be done inside the package
> manager (not in bash code) on the IUSE metadata variable, and the
> changes don't have to be reflected in the IUSE environment variable
> inside the ebuild.

If that was the case, then eclasses could no longer append deps to
(R)DEPEND, either .....?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9spYUACgkQAJxUfCtlWe1g+QEA1NAl+nl3zCEOmTIjCN1271r7
pCJNO7aCW/iNrXniCQUA/3j1xktcStPmQL8rXPRLSjMy+vqBsclWQwFHa4eytu6B
=g3Dz
-----END PGP SIGNATURE-----


axs at gentoo

Mar 23, 2012, 9:36 AM

Post #7 of 24 (454 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 23/03/12 12:32 PM, Ian Stakenvicius wrote:
> On 23/03/12 12:19 PM, Ciaran McCreesh wrote:
>> On Fri, 23 Mar 2012 12:14:39 -0400 Ian Stakenvicius
>> <axs [at] gentoo> wrote:
>>> I don't know if I follow this one or not. When inheriting an
>>> eclass, all entities within the eclass get merged into the
>>> ebuild. As long as there aren't any special conditional
>>> tricks being used to assign to global variables like IUSE, it
>>> would still be invariant wouldn't it?
>
>> The point is that the merging might be done inside the package
>> manager (not in bash code) on the IUSE metadata variable, and
>> the changes don't have to be reflected in the IUSE environment
>> variable inside the ebuild.
>
> If that was the case, then eclasses could no longer append deps to
> (R)DEPEND, either .....?

Err, nvm.. i think i'm following the difference now. functions like
has_version and so forth don't actually work on the value(s) of
*DEPEND themselves, so in the case of (R)DEPEND it wouldn't matter of
the package manager didn't expose the merge.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9spp8ACgkQAJxUfCtlWe1a2wD/YsHDM1hYik+d46fJ90yckI/U
OKr1ThK6hhJTbjmqGpgBAMekpXzx8NFIPerRPm037FgWQiCuUPDezAhmj8S73EPV
=CNHZ
-----END PGP SIGNATURE-----


ciaran.mccreesh at googlemail

Mar 23, 2012, 9:43 AM

Post #8 of 24 (452 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 23 Mar 2012 12:32:05 -0400
Ian Stakenvicius <axs [at] gentoo> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 23/03/12 12:19 PM, Ciaran McCreesh wrote:
> > On Fri, 23 Mar 2012 12:14:39 -0400 Ian Stakenvicius
> > <axs [at] gentoo> wrote:
> >> I don't know if I follow this one or not. When inheriting an
> >> eclass, all entities within the eclass get merged into the
> >> ebuild. As long as there aren't any special conditional tricks
> >> being used to assign to global variables like IUSE, it would
> >> still be invariant wouldn't it?
> >
> > The point is that the merging might be done inside the package
> > manager (not in bash code) on the IUSE metadata variable, and the
> > changes don't have to be reflected in the IUSE environment variable
> > inside the ebuild.
>
> If that was the case, then eclasses could no longer append deps to
> (R)DEPEND, either .....?

The point of the wording is to allow an eclass to do this:

DEPEND="cat/two"

and an ebuild do this:

DEPEND="cat/one"

and to have the package manager, but not necessarily bash code, know
that there are two dependencies. It also makes the annoying RDEPEND
value behaviour that older EAPIs specify possible.

So yes, you *could* argue that with the way it's worded, this in an
eclass isn't guaranteed to work:

DEPEND="cat/three"
DEPEND="${DEPEND} cat/four"

What the wording is supposed to imply is that if some bash code looks
at DEPEND, it could contain either "cat/three cat/four", or "cat/one
cat/three cat/four". If the first DEPEND looked like the second, then
it would also be allowed to contain "cat/one cat/one cat/three
cat/four" and similar.

What this really comes down to is that bash is the wrong tool for doing
what we're doing, and that we can't have this work "the way we want
it to" since bash doesn't provide the interfaces we need to get it
to work, and every time we try to be clever it breaks on newer bash
releases...

- --
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk9sqFAACgkQ96zL6DUtXhFnJgCfZhLF1/UsWWCARATI2I9pg5Yv
ATMAn3exnOUWgwQTt84v1q9mE9ptOiH/
=BQ2n
-----END PGP SIGNATURE-----


floppym at gentoo

Mar 23, 2012, 9:50 AM

Post #9 of 24 (454 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

On Fri, Mar 23, 2012 at 12:02 PM, Ciaran McCreesh
<ciaran.mccreesh [at] googlemail> wrote:
> On Fri, 23 Mar 2012 11:58:47 -0400
> Mike Gilbert <floppym [at] gentoo> wrote:
>> > oasis_src_compile() {
>> >     oasis_src_compile_no_doc
>> >     if has doc ${IUSE} && use doc; then
>> >             ocaml setup.ml -doc || die
>> >     fi
>> > }
>>
>> This should probably call use_if_iuse from eutils.eclass, which
>> handles IUSE="[+-]doc".
>
> Actually, neither way works. The spec says:
>
>    Global variables must only contain invariant values
>    (see~\ref{sec:metadata-invariance}). If a global variable's value is
>    invariant, it may have the value that would be generated at any
>    given point in the build sequence.
>
> So you can't rely upon IUSE having the "merged" value in an eclass.
>

use_if_iuse is called from functions in several eclasses already in
the tree. See chromium, kde4-base, qt4-build, and toolchain.

Are all of these usages incorrect? Do you have an alternate solution?


ciaran.mccreesh at googlemail

Mar 23, 2012, 9:52 AM

Post #10 of 24 (452 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

On Fri, 23 Mar 2012 12:50:51 -0400
Mike Gilbert <floppym [at] gentoo> wrote:
> use_if_iuse is called from functions in several eclasses already in
> the tree. See chromium, kde4-base, qt4-build, and toolchain.
>
> Are all of these usages incorrect? Do you have an alternate solution?

We had this discussion when the function was introduced, and we were
assured that it "would only be used correctly"... The correct solution
is probably to have ebuilds define a variable like "OASIS_WANT_DOCS",
and to use that.

--
Ciaran McCreesh
Attachments: signature.asc (0.19 KB)


floppym at gentoo

Mar 23, 2012, 9:58 AM

Post #11 of 24 (452 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

On Fri, Mar 23, 2012 at 12:52 PM, Ciaran McCreesh
<ciaran.mccreesh [at] googlemail> wrote:
> On Fri, 23 Mar 2012 12:50:51 -0400
> Mike Gilbert <floppym [at] gentoo> wrote:
>> use_if_iuse is called from functions in several eclasses already in
>> the tree. See chromium, kde4-base, qt4-build, and toolchain.
>>
>> Are all of these usages incorrect? Do you have an alternate solution?
>
> We had this discussion when the function was introduced, and we were
> assured that it "would only be used correctly"... The correct solution
> is probably to have ebuilds define a variable like "OASIS_WANT_DOCS",
> and to use that.
>

Ah. I'll have to review chromium.eclass then; I think I'm doing it wrong.


tetromino at gentoo

Mar 23, 2012, 10:09 AM

Post #12 of 24 (453 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

On Fri, 2012-03-23 at 12:50 -0400, Mike Gilbert wrote:
> On Fri, Mar 23, 2012 at 12:02 PM, Ciaran McCreesh
> <ciaran.mccreesh [at] googlemail> wrote:
> > On Fri, 23 Mar 2012 11:58:47 -0400
> > Mike Gilbert <floppym [at] gentoo> wrote:
> >> > oasis_src_compile() {
> >> > oasis_src_compile_no_doc
> >> > if has doc ${IUSE} && use doc; then
> >> > ocaml setup.ml -doc || die
> >> > fi
> >> > }
> >>
> >> This should probably call use_if_iuse from eutils.eclass, which
> >> handles IUSE="[+-]doc".
> >
> > Actually, neither way works. The spec says:
> >
> > Global variables must only contain invariant values
> > (see~\ref{sec:metadata-invariance}). If a global variable's value is
> > invariant, it may have the value that would be generated at any
> > given point in the build sequence.
> >
> > So you can't rely upon IUSE having the "merged" value in an eclass.
> >
>
> use_if_iuse is called from functions in several eclasses already in
> the tree. See chromium, kde4-base, qt4-build, and toolchain.
>
> Are all of these usages incorrect? Do you have an alternate solution?

By my count, there are already at least 19 eclasses in the tree that
access an ebuild's IUSE from eclass code (autotools-utils, chromium,
clutter, db, enlightenment, eutils, gnome2, gnome-python-common,
java-ant-2, java-pkg-2, java-utils-2, mozconfig-3, pam, qt4-build,
qt4-r2, ruby-ng, xfconf, x-modular, and xorg-2).

-Alexandre Rostovtsev.


aballier at gentoo

Mar 23, 2012, 11:03 AM

Post #13 of 24 (453 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

On Fri, 23 Mar 2012 11:58:47 -0400
Mike Gilbert <floppym [at] gentoo> wrote:

> On Fri, Mar 23, 2012 at 4:15 AM, Alexis Ballier <aballier [at] gentoo>
> wrote:
>
> > DEPEND=">=dev-lang/ocaml-3.12[ocamlopt?]"
> > DEPEND="${RDEPEND}"
>
> That looks like a typo.

yes, thanks for spotting

>
> > oasis_src_compile() {
> > oasis_src_compile_no_doc
> > if has doc ${IUSE} && use doc; then
> > ocaml setup.ml -doc || die
> > fi
> > }
>
> This should probably call use_if_iuse from eutils.eclass, which
> handles IUSE="[+-]doc".
>

hmm, actually, I like the idea of something like OASIS_WANT_DOCS as
suggested by Ciaran, this sounds simpler and, as a side effect, will
allow me to kill the useless oasis_src_compile_no_doc function.

I'll come back with something like this and post an update, most likely
next week, pilling up the reviews :=)


A.


antarus at gentoo

Mar 23, 2012, 11:17 AM

Post #14 of 24 (454 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

On Fri, Mar 23, 2012 at 10:09 AM, Alexandre Rostovtsev
<tetromino [at] gentoo> wrote:
> On Fri, 2012-03-23 at 12:50 -0400, Mike Gilbert wrote:
>> On Fri, Mar 23, 2012 at 12:02 PM, Ciaran McCreesh
>> <ciaran.mccreesh [at] googlemail> wrote:
>> > On Fri, 23 Mar 2012 11:58:47 -0400
>> > Mike Gilbert <floppym [at] gentoo> wrote:
>> >> > oasis_src_compile() {
>> >> >     oasis_src_compile_no_doc
>> >> >     if has doc ${IUSE} && use doc; then
>> >> >             ocaml setup.ml -doc || die
>> >> >     fi
>> >> > }
>> >>
>> >> This should probably call use_if_iuse from eutils.eclass, which
>> >> handles IUSE="[+-]doc".
>> >
>> > Actually, neither way works. The spec says:
>> >
>> >    Global variables must only contain invariant values
>> >    (see~\ref{sec:metadata-invariance}). If a global variable's value is
>> >    invariant, it may have the value that would be generated at any
>> >    given point in the build sequence.
>> >
>> > So you can't rely upon IUSE having the "merged" value in an eclass.
>> >
>>
>> use_if_iuse is called from functions in several eclasses already in
>> the tree. See chromium, kde4-base, qt4-build, and toolchain.
>>
>> Are all of these usages incorrect? Do you have an alternate solution?
>
> By my count, there are already at least 19 eclasses in the tree that
> access an ebuild's IUSE from eclass code (autotools-utils, chromium,
> clutter, db, enlightenment, eutils, gnome2, gnome-python-common,
> java-ant-2, java-pkg-2, java-utils-2, mozconfig-3, pam, qt4-build,
> qt4-r2, ruby-ng, xfconf, x-modular, and xorg-2).

Lets be clear here. Just because we do already it does not mean we
should keep doing it.

In general if you are going to say 'this usage is wrong' then you need
some kind of tool to detect and report on it; otherwise a subset of
developers will get it wrong. Don't make it easy to do the wrong
thing, make it easy to do the right thing.

-A

>
> -Alexandre Rostovtsev.
>
>


ciaran.mccreesh at googlemail

Mar 23, 2012, 12:37 PM

Post #15 of 24 (452 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

On Fri, 23 Mar 2012 11:17:56 -0700
Alec Warner <antarus [at] gentoo> wrote:
> In general if you are going to say 'this usage is wrong' then you need
> some kind of tool to detect and report on it; otherwise a subset of
> developers will get it wrong. Don't make it easy to do the wrong
> thing, make it easy to do the right thing.

Unfortunately, bash really doesn't make it easy for us to do that sort
of thing...

--
Ciaran McCreesh
Attachments: signature.asc (0.19 KB)


antarus at gentoo

Mar 23, 2012, 1:11 PM

Post #16 of 24 (454 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

On Fri, Mar 23, 2012 at 12:37 PM, Ciaran McCreesh
<ciaran.mccreesh [at] googlemail> wrote:
> On Fri, 23 Mar 2012 11:17:56 -0700
> Alec Warner <antarus [at] gentoo> wrote:
>> In general if you are going to say 'this usage is wrong' then you need
>> some kind of tool to detect and report on it; otherwise a subset of
>> developers will get it wrong. Don't make it easy to do the wrong
>> thing, make it easy to do the right thing.
>
> Unfortunately, bash really doesn't make it easy for us to do that sort
> of thing...

Its more a dig at the process in general. I don't aim for perfect
checks (bash is hard, waa waa waa), but arguably we don't even try to
write checks that are non-perfect. We end up in situations where one
guy does it the wrong way, then people copy and paste his code and
suddenly it is done wrong in dozens of places. QA warnings help let
people know that what they are doing is likely wrong.

-A

>
> --
> Ciaran McCreesh


slyfox at gentoo

Mar 23, 2012, 1:11 PM

Post #17 of 24 (452 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

> oasis_use_enable() {
> echo "--override $2 `use $1 && echo \"true\" || echo \"false\"`"
> }

Mike added 'usex' to 'eutils.eclass' recently, so you might like to use it:
(UNTESTED)
echo "--override $2 $(usex $1 true false)"

> oasis_src_configure() {
> ocaml setup.ml -configure \
> --prefix usr \
> --libdir /usr/$(get_libdir) \
> --docdir /usr/share/doc/${PF}/html \
> --destdir "${D}" \
> $(oasis_use_enable debug debug) \
> $(oasis_use_enable ocamlopt is_native) \
> ${oasis_configure_opts} \
> || die
> }

This configure hates gentoo prefix, right?
Might worth sprinkling "${EPREFIX}" around absolute paths.

--

Sergei
Attachments: signature.asc (0.19 KB)


aballier at gentoo

Mar 23, 2012, 1:24 PM

Post #18 of 24 (452 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

On Fri, 23 Mar 2012 23:11:46 +0300
Sergei Trofimovich <slyfox [at] gentoo> wrote:

> > oasis_use_enable() {
> > echo "--override $2 `use $1 && echo \"true\" || echo
> > \"false\"`" }
>
> Mike added 'usex' to 'eutils.eclass' recently, so you might like to
> use it: (UNTESTED)
> echo "--override $2 $(usex $1 true false)"

it needs to print the quotes too, so this wont work

i've been copy/pasting this 'formula' for a while, i know it works, and
i am too lazy to try to rewrite it to usex just for the sake of it :)

>
> > oasis_src_configure() {
> > ocaml setup.ml -configure \
> > --prefix usr \
> > --libdir /usr/$(get_libdir) \
> > --docdir /usr/share/doc/${PF}/html \
> > --destdir "${D}" \
> > $(oasis_use_enable debug debug) \
> > $(oasis_use_enable ocamlopt is_native) \
> > ${oasis_configure_opts} \
> > || die
> > }
>
> This configure hates gentoo prefix, right?
> Might worth sprinkling "${EPREFIX}" around absolute paths.
>

well, this will imply not supporting eapi2, i can live with it

however, usually, i prefer prefix guys that need it to submit patches
instead of trying to support it without testing.
eg: shall it be EPREFIX before the /usr's ? shall it be ED instead of
D? both ?

A.


tetromino at gentoo

Mar 23, 2012, 1:41 PM

Post #19 of 24 (454 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

On Fri, Mar 23, 2012 at 4:24 PM, Alexis Ballier <aballier [at] gentoo> wrote:
> On Fri, 23 Mar 2012 23:11:46 +0300
> Sergei Trofimovich <slyfox [at] gentoo> wrote:
>> > oasis_src_configure() {
>> >     ocaml setup.ml -configure \
>> >             --prefix usr \
>> >             --libdir /usr/$(get_libdir) \
>> >             --docdir /usr/share/doc/${PF}/html \
>> >             --destdir "${D}" \
>> >             $(oasis_use_enable debug debug) \
>> >             $(oasis_use_enable ocamlopt is_native) \
>> >             ${oasis_configure_opts} \
>> >             || die
>> > }
>>
>> This configure hates gentoo prefix, right?
>> Might worth sprinkling "${EPREFIX}" around absolute paths.
>>
>
> well, this will imply not supporting eapi2, i can live with it
>
> however, usually, i prefer prefix guys that need it to submit patches
> instead of trying to support it without testing.
> eg: shall it be EPREFIX before the /usr's?shall it be ED instead of
> D? both ?

You probably want ${EPREFIX} in front of every /usr passed to
configure. In other words,

ocaml setup.ml -configure --prefix "${EPREFIX}/usr" --libdir
"${EPREFIX}/blah" --docdir "${EPREFIX}/blargh" etc.

However, destdir should still be ${D}. That way, in src_install() your
package's files will be copied to ${D}${EPREFIX}/usr, better known as
${ED}usr.


slyfox at gentoo

Mar 23, 2012, 2:02 PM

Post #20 of 24 (455 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

> > > oasis_use_enable() {
> > > echo "--override $2 `use $1 && echo \"true\" || echo
> > > \"false\"`" }
> >
> > Mike added 'usex' to 'eutils.eclass' recently, so you might like to
> > use it: (UNTESTED)
> > echo "--override $2 $(usex $1 true false)"
>
> it needs to print the quotes too, so this wont work

It did not print quotes:
$ echo "--override bazz `true && echo \"true\" || echo \"false\"`"
--override bazz true

> i've been copy/pasting this 'formula' for a while, i know it works, and
> i am too lazy to try to rewrite it to usex just for the sake of it :)
>
> >
> > > oasis_src_configure() {
> > > ocaml setup.ml -configure \
> > > --prefix usr \
> > > --libdir /usr/$(get_libdir) \
> > > --docdir /usr/share/doc/${PF}/html \
> > > --destdir "${D}" \
> > > $(oasis_use_enable debug debug) \
> > > $(oasis_use_enable ocamlopt is_native) \
> > > ${oasis_configure_opts} \
> > > || die
> > > }
> >
> > This configure hates gentoo prefix, right?
> > Might worth sprinkling "${EPREFIX}" around absolute paths.
> >
>
> well, this will imply not supporting eapi2, i can live with it

Oh, right. I've forgot. Each EPREFIX usage would require something like the following:

has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=

> however, usually, i prefer prefix guys that need it to submit patches
> instead of trying to support it without testing.

Yeah, sounds fair.

--

Sergei
Attachments: signature.asc (0.19 KB)


aballier at gentoo

Mar 24, 2012, 6:19 AM

Post #21 of 24 (451 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

On Sat, 24 Mar 2012 00:02:15 +0300
Sergei Trofimovich <slyfox [at] gentoo> wrote:

> > > > oasis_use_enable() {
> > > > echo "--override $2 `use $1 && echo \"true\" || echo
> > > > \"false\"`" }
> > >
> > > Mike added 'usex' to 'eutils.eclass' recently, so you might like
> > > to use it: (UNTESTED)
> > > echo "--override $2 $(usex $1 true false)"
> >
> > it needs to print the quotes too, so this wont work
>
> It did not print quotes:
> $ echo "--override bazz `true && echo \"true\" || echo \"false\"`"
> --override bazz true

hu? i was pretty sure it was needed, but you're right, i dont know what
i was trying to achieve with those escaped quotes in there... i've
converted to your usex formula which is equivalent, thanks :)


> > > This configure hates gentoo prefix, right?
> > > Might worth sprinkling "${EPREFIX}" around absolute paths.
> > >
> >
> > well, this will imply not supporting eapi2, i can live with it
>
> Oh, right. I've forgot. Each EPREFIX usage would require something
> like the following:
>
> has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=

not worth it, ocaml ebuilds are all eapi2 and the eapi2->3 migration is
quite straightforward, so there's no point in supporting <eapi3.

A.


aballier at gentoo

Mar 24, 2012, 6:22 AM

Post #22 of 24 (453 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

On Fri, 23 Mar 2012 16:41:35 -0400
Alexandre Rostovtsev <tetromino [at] gentoo> wrote:

> On Fri, Mar 23, 2012 at 4:24 PM, Alexis Ballier <aballier [at] gentoo>
> wrote:
> > On Fri, 23 Mar 2012 23:11:46 +0300
> > Sergei Trofimovich <slyfox [at] gentoo> wrote:
> >> > oasis_src_configure() {
> >> >     ocaml setup.ml -configure \
> >> >             --prefix usr \
> >> >             --libdir /usr/$(get_libdir) \
> >> >             --docdir /usr/share/doc/${PF}/html \
> >> >             --destdir "${D}" \
> >> >             $(oasis_use_enable debug debug) \
> >> >             $(oasis_use_enable ocamlopt is_native) \
> >> >             ${oasis_configure_opts} \
> >> >             || die
> >> > }
> >>
> >> This configure hates gentoo prefix, right?
> >> Might worth sprinkling "${EPREFIX}" around absolute paths.
> >>
> >
> > well, this will imply not supporting eapi2, i can live with it
> >
> > however, usually, i prefer prefix guys that need it to submit
> > patches instead of trying to support it without testing.
> > eg: shall it be EPREFIX before the /usr's?shall it be ED instead of
> > D? both ?
>
> You probably want ${EPREFIX} in front of every /usr passed to
> configure. In other words,
>
> ocaml setup.ml -configure --prefix "${EPREFIX}/usr" --libdir
> "${EPREFIX}/blah" --docdir "${EPREFIX}/blargh" etc.
>
> However, destdir should still be ${D}. That way, in src_install() your
> package's files will be copied to ${D}${EPREFIX}/usr, better known as
> ${ED}usr.

will do that since it doesnt hurt, but it'll require testing anyway.
thanks for the explanations, but then beware of the findlib_src_preinst
call in src_install, which sets a variable so that findlib installs
stuff in $D; if at some point this will be changed to $ED for some
reason then oasis+findlib packages may go in a double prefix...


aballier at gentoo

Mar 24, 2012, 6:44 AM

Post #23 of 24 (452 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

eclass version 2.0, i hope i haven't forgotten any comment

I improved some comments/description after a second read also.
Attachments: oasis.eclass (2.86 KB)


aballier at gentoo

Mar 27, 2012, 2:01 PM

Post #24 of 24 (406 views)
Permalink
Re: New eclass: oasis.eclass for oasis-based ocaml packages. [In reply to]

On Sat, 24 Mar 2012 10:44:03 -0300
Alexis Ballier <aballier [at] gentoo> wrote:

> eclass version 2.0, i hope i haven't forgotten any comment
>
> I improved some comments/description after a second read also.

since there were no more comments: eclass committed, thanks all

Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.