# suche Kritik und Vorschläge für mein ebuild

## Mr. Anderson

So, mein erstes ebuild (sci-mathematics/isabelle-2008) ist in einer ersten Fassung fertig, eine Version 0.0. Da sicher noch einiges besser gemacht werden kann, würde ich mich über konstruktive Kommentare freuen. (Tests insbesondere auf anderen Architekturen als amd64 wären hilfreich.)

```
# Copyright 1999-2009 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

# $Header: $

EAPI="2"

inherit eutils multilib

DESCRIPTION="Isabelle is a generic proof assistant"

HOMEPAGE="http://isabelle.in.tum.de/ http://www.cl.cam.ac.uk/research/hvg/Isabelle/"

SRC_URI="http://isabelle.in.tum.de/dist/Isabelle${PV}.tar.gz"

LICENSE="BSD"

SLOT="0"

KEYWORDS="~amd64"

IUSE="doc graphbrowsing +proofgeneral"

#upstream says

#bash 2.x/3.x, Poly/ML 5.x, Perl 5.x,

#for Proof General GNU Emacs 21/22, xemacs 21.4.x, NOT xemacs 21.5 beta

#for document preparation: complete LaTeX

DEPEND=">=app-shells/bash-3.0

   graphbrowsing? (

      virtual/jdk

   )"

#proofgeneral uses eclass elisp that depends on virtual/emacs-21

RDEPEND=">=dev-lang/polyml-5.2.1

   >=dev-lang/perl-5.8.8-r2

   doc? (

      virtual/latex-base

   )

   proofgeneral? (

      app-emacs/proofgeneral

   )

   ${DEPEND}"

S="${WORKDIR}"/Isabelle${PV}

TARGETDIR="/usr/share/Isabelle"${PV}

LIBDIR="/usr/"$(get_libdir)"/Isabelle"${PV}

pkg_setup() {

   if ! use proofgeneral

      then

      ewarn "You have deselected the Proof General interface."

      ewarn "Only a text terminal will be installed."

      ewarn "Emerge Isabelle with the proofgeneral USE flag enabled"

      ewarn "to get the common interface, that most people want."

   fi

}

src_prepare() {

   use proofgeneral && epatch ${FILESDIR}/isabelle-2008-proofgeneral-gentoo-path.patch

}

src_compile() {

   einfo "Building Isabelle logics. This may take some time."

   ./build -a -b || die "building logics failed"

   if use graphbrowsing

      then

      cd lib/browser

      emake clean || die "failed cleaning graph browser directory"

      emake || die "failed building the graph browser"

   fi

}

src_test() {

   einfo "Running tests. A test run can take up to several hours!"

   ./build -a -b -t

}

src_install() {

   exeinto ${TARGETDIR}/bin

   doexe bin/isabelle-interface bin/isabelle-process bin/isatool \

      || die "install failed"

   exeinto ${TARGETDIR}

   doexe build || die "install failed"

   insinto ${TARGETDIR}

   use doc && ( doins -r doc || die "install failed" )

   doins -r etc || die "install failed"

   dosym ${LIBDIR}/heaps ${TARGETDIR}/heaps

   insinto ${LIBDIR}

   doins -r heaps || die "install failed"

# use cp to keep file attributes

   cp -R lib ${D}${TARGETDIR} || die "install failed"

   bin/isatool install -d ${TARGETDIR} -p ${D}usr/bin

   newicon lib/icons/isabelle.xpm ${PN}.xpm

   make_desktop_entry Isabelle "Isabelle ${PV}" isabelle.xpm "Education;Math"

   dodoc ANNOUNCE CONTRIBUTORS INSTALL NEWS README \

      || die "dodoc failed"

}

pkg_postinst() {

   elog "You will need to re-emerge Isabelle after emerging polyml."

}

```

Patch ${FILESDIR}/isabelle-2008-proofgeneral-gentoo-path.patch

```
--- Isabelle/etc/settings.old   2009-02-06 21:18:36.000000000 +0100

+++ Isabelle/etc/settings       2009-02-06 21:17:15.000000000 +0100

@@ -195,6 +195,7 @@

   "/usr/share/ProofGeneral/isar/interface" \

   "/opt/ProofGeneral/isar/interface" \

   "/usr/share/emacs/ProofGeneral/isar/interface" \

+  "/usr/share/emacs/site-lisp/ProofGeneral/isar/interface" \

   "$ISABELLE_INTERFACE")

 PROOFGENERAL_OPTIONS=""

```

Auf längere Sicht hoffe ich, dass die Software in sunrise und schließlich in den regulären portage tree aufgenommen wird.  :Smile: Last edited by Mr. Anderson on Thu Feb 26, 2009 7:03 pm; edited 9 times in total

----------

## Necoro

Hinweise: 

du brauchst EAPI=1 für use-defaults

die auskommentierte IUSE-Zeile entfernen  :Wink: 

WORKDIR quoten (kann leerzeichen enthalten) (bei der S=... Zeile)

ich würde an deiner Stelle EAPI=2 nehmen und denn die src_unpack so aufteilen:

```
pkg_setup()

{

    if ! use proofgeneral; then ....

}

src_prepare()

{

   epatch ...

}
```

 du brauchst denn auch kein src_unpack

'emake || die failed cleaning graph browser directory ' <-- falsche die-msg

die dodir,cp-hölle so umschreiben:

```

insinto ${TARGETDIR}/bin

doins bin/isabelle-interface || die ...

...

```

 - doins kannst du auch mehrere dateien auf einmal übergeben - und auch ein '-r'

 warum installierst du überhaupt binarys und so in das share verzeichnis ... das wirkt komisch

/edit: Außerdem kann ich dir noch die Channels #gentoo-sunrise und #gentoo-dev-help empfehlen, wenn du deine Ebuilds reviewen lassen willst

/edit: Und ich schreib bei eben diesen Münchnern am Do ne Logik-Klausur ... *noch lernen muss*  :Sad: 

----------

## Mr. Anderson

Danke. Ist alles drin.

 *Necoro wrote:*   

> 
> 
> warum installierst du überhaupt binarys und so in das share verzeichnis ... das wirkt komisch

 

Weil es nicht wirklich Binaries sind. Es sind bash-Skripte, die architektur-unabhängig funktionieren sollten. Ein anderer Grund ist, dass ich anderenfalls noch mehr hätte patchen müssen.

 *Quote:*   

> /edit: Außerdem kann ich dir noch die Channels #gentoo-sunrise und #gentoo-dev-help empfehlen, wenn du deine Ebuilds reviewen lassen willst

 

IRC... ich meide ihn, wenn es geht  :Smile: 

 *Quote:*   

> /edit: Und ich schreib bei eben diesen Münchnern am Do ne Logik-Klausur ... *noch lernen muss* 

 

viel Erfolg ^^

edit: ein cp habe ich wieder reingenommen, da in lib die Rechte ziemlich durcheinander sind.

----------

## ocin

 *Necoro wrote:*   

> 
> 
> du brauchst EAPI=1 für use-defaults
> 
> 

 

Nein.

----------

## Necoro

 *ocin wrote:*   

>  *Necoro wrote:*   
> 
> du brauchst EAPI=1 für use-defaults
> 
>  
> ...

 

äh - dir ist schon bewusst, dass die Tabelle, die du da quotest genau das sagt, was ich sagte und dir widerspricht?

```
EAPI Supports IUSE defaults?

0    No

1    Yes

2    Yes 
```

----------

## ocin

Nein? Mit EAPI=2 geht es doch genau so. Wenn du deinem Satz ein "mindestens" hinzufügst dann stimmt es.

----------

## Necoro

 *ocin wrote:*   

> Nein? Mit EAPI=2 geht es doch genau so. Wenn du deinem Satz ein "mindestens" hinzufügst dann stimmt es.

 

Oh - das "mindestens" war für mich implizit  :Wink:  - da es bis jetzt noch keine EAPI gab, die Features entfernt hat.

----------

## ocin

 *Necoro wrote:*   

>  *ocin wrote:*   Nein? Mit EAPI=2 geht es doch genau so. Wenn du deinem Satz ein "mindestens" hinzufügst dann stimmt es. 
> 
> Oh - das "mindestens" war für mich implizit ;) - da es bis jetzt noch keine EAPI gab, die Features entfernt hat.

 

Hörte sich für mich so an als ob es _nur_ mit EAPI=1 geht.

----------

## Mr. Anderson

ich hab das auch als "mindestens" gelesen  :Razz: 

Können wir zum Thema zurückkehren?  :Smile: 

Ich bin noch auf Probleme gestoßen, wenn man isabelle mehrfach emerged und wieder löscht. Muss das mal genauer unter die Lupe nehmen. Aber wahrscheinlich heute nicht mehr.

----------

## Necoro

Noch ein Hinweis: wenn du sachen wie if use flag; then do_something; fi hast (also das do_something nur eine Zeile ist), wird von den Devs folgende Schreibweise bevorzugt:

use flag && do_something

Außerdem gibt es noch die gentoo-devhelp@gentoo.org mailing liste. zugegebener maßen hab ich da bis jetzt noch nie wirklich was drauf gesehen - aber man kanns ja mal versuchen  :Wink: 

----------

## Mr. Anderson

Ist drin. Und zwei andere Fehler sind auch behoben  :Smile: . Logik-Klausur schon rum? ^^

----------

## Necoro

 *Mr. Anderson wrote:*   

> Logik-Klausur schon rum? ^^

 

Nope - startet erst in 40 Minuten  :Wink: 

Mir ist noch was aufgefallen -> die "use bla && do_sth || die" Combo funktioniert nicht ...

Beispiel:

```
> false && true || echo "muh"

muh
```

Da das auch in vielen Ebuilds verwendet wird, sieht mir das nach ner großen Bugquelle aus ...  :Smile: 

/edit: also das richtige ist: "use bla && { do_sth || die; }"

----------

## Mr. Anderson

lol

ich hatte eben im www gesucht nach einer Tabelle der Präzedenzen der bash-Operatoren. Nachdem ich nicht schnell fündig wurde, beschloss ich, in anderen ebuilds nachzusehen. Nachdem ich über 10 ebuilds gefunden habe, in denen genau diese Konstruktion vorkommt (und keine andere mit Klammern), habe ich es genauso gemacht. Da dann ein probeweises emerge sauber durchgelaufen ist (aber mit USE="doc"), war das für mich erledigt. Ich hätte es ausprobieren sollen mit einem Beispiel wie Deinem, aber auf die einfachsten Lösungen komme ich manchmal nicht :-/. Ich schaue mir diese anderen ebuilds mal näher an...

edit: bisher sieht das alles in Ordnung aus in anderen ebuilds. Das hat überall etwas andere Effekte zur Folge.

Außerdem funktioniert meine Zeile ./build -a -b || die "building logics failed" nicht so wie sie soll. Wenn Fehler auftreten, wird der Ausdruck trotzdem zu true ausgewertet und nicht die ausgeführt.

Und nach einem Blick in man bash ersetze ich die geschweiften Klammern durch runde und verzichte auf ein Semikolon.  :Smile: 

----------

## Necoro

 *Mr. Anderson wrote:*   

> Außerdem funktioniert meine Zeile ./build -a -b || die "building logics failed" nicht so wie sie soll. Wenn Fehler auftreten, wird der Ausdruck trotzdem zu true ausgewertet und nicht die ausgeführt.

 

Denn scheint das ./build komisch zu sein, und immer 0 zurück zu geben

 *Quote:*   

> Und nach einem Blick in man bash ersetze ich die geschweiften Klammern durch runde und verzichte auf ein Semikolon. 

 

Nope - runde Klammern öffnen eine Subshell, geschweifte definieren nur Blöcke. Und eine Subshell ist ein extra Prozess und damit unnötiger Ballast  :Smile: 

----------

## Mr. Anderson

 *Necoro wrote:*   

> Denn scheint das ./build komisch zu sein, und immer 0 zurück zu geben

 

So meinte ich das auch. Lösen muss ich es trotzdem  :Smile: 

 *Quote:*   

> Nope - runde Klammern öffnen eine Subshell, geschweifte definieren nur Blöcke. Und eine Subshell ist ein extra Prozess und damit unnötiger Ballast 

 

Hm... gutes Argument. Dann gibt's doch wieder geschweifte Klammern.

----------

## mv

 *Mr. Anderson wrote:*   

> ich hatte eben im www gesucht nach einer Tabelle der Präzedenzen der bash-Operatoren.

 

Such nicht nach bash, such nach dem Standard. Das wäre ja noch schöner, wenn die bash hier auch noch eine unnötige Extra-Wurst braten würde.  *Quote:*   

> The operators "&&" and "||" shall have equal precedence and shall be evaluated with left associativity

  Das beschriebene Problem ist übrigens einer der beiden Gründe, weshalb die Konstruktion mit "if" oft doch sinnvoll ist (und genutzt wird): 

```
a && b || c
```

 ist weder äquivalent zu 

```
if a; then b; else c; fi
```

 noch zu 

```
if a; then b || c; fi
```

Der andere Grund ist, dass 

```
a && b
```

 i.a. einen anderen return-code liefert als 

```
if a; then b; fi
```

----------

## Mr. Anderson

An der bash hatte ich mich orientiert, da in der Dokumentation zu ebuilds am Anfang steht, dass ebuilds zu den bash-Skripten gehören. Aber sich am Standard zu orientieren, ist natürlich schon irgendwo sinnvoll. Asche auf mein Haupt.

Dass das nicht äquivalent ist, ist mir klar. Aber ich leg mich nicht mit den devs an, wenn sie das mit den Operatoren && und || so möchten.  :Wink: 

----------

## mv

 *Mr. Anderson wrote:*   

> da in der Dokumentation zu ebuilds am Anfang steht, dass ebuilds zu den bash-Skripten gehören.

 

Ja, es ist explizit (leider) erlaubt, bashismen zu benutzen. Der vorgebliche Grund ist, dass viele Benutzer an bash gewöhnt sind, aber eben trotzdem schnell ein ebuild zusammenhacken können sollen.

 *Quote:*   

> Aber ich leg mich nicht mit den devs an, wenn sie das mit den Operatoren && und || so möchten. ;)

 

Ich kann mir nicht vorstellen, dass jemand falschen Code will. In dem Moment, in dem es äquivalent ist, ist etwa 

```
use bla && ein_kommando
```

 bietet sich halt das "&&" an, einfach weil es kürzer ist. Falls ein "if" kürzer ist, würde es mich sehr wundern, wenn jemand etwas dagegen hätte. Solche Konstrukte wie 

```
use bla && { a || die; }
```

 findet man sicher manchmal, aber oft einfach, weil das "|| die" noch im Nachhinein eingefügt wurde.

----------

## Necoro

 *mv wrote:*   

> Solche Konstrukte wie 
> 
> ```
> use bla && { a || die; }
> ```
> ...

 

Die findet man recht häufig  :Wink: . Ich bin auch schon über sachen wie foo || bar && moep || die gestolpert - und das ist denn definitiv zu viel des Guten  :Wink: 

----------

## Mr. Anderson

```
use bla && ein_kommando
```

Wirklich äquivalent ist es auch nicht, denn so weit ich das sehe, gibt z. B. 

```
false && foo
```

ein false zurück, wohingegen ein

```
if false; then foo; fi
```

true zurückgibt.

Wie dem auch sei. So, wie die Zeile jetzt ist, ist sie korrekt, effizient, kurz und in der gewünschten Form.

----------

## mv

 *Mr. Anderson wrote:*   

> Wirklich äquivalent ist es auch nicht

 

Das hatte ich ja zuvor geschrieben (als "zweiten" Grund, weshalb "if" manchmal besser ist). Aber es passiert in der Praxis natürlich äußerst selten, dass der return-code eines if-Kommandos wichtig ist.

----------

## Mr. Anderson

Ja, hattest Du geschrieben. Und ich hab's gelesen und wieder vergessen und nochmal festgestellt. :-/

----------

## Mr. Anderson

Sowas. Da wollte ich eben mein isabelle-ebuild auf den neuesten Stand bringen, und nun sehe ich, dass jemand sich der Sache angenommen hat und ein aktuelles ebuild nun im Portage Tree liegt. Das spart mir ein paar Stunden Arbeit.

Siehe auch Bug 397995

Vielen Dank an Mark Wright für die geleistete Arbeit.

Thank you very much Mark Wright. You have saved me hours of work.

----------

