# [solved] openobex-1.7.1.ebuild und gitorious

## schmidicom

Ich versuche nun schon seit Stunden ein ebuild zu schreiben das mir openobex in Version 1.7.1 baut und installiert scheitere jedoch laufend am Download.

http://www.gitorious.org/openobex/mainline/trees/1.7.1

Auf der Seite gibt es zwar einen Link zu einer tar.gz-Datei doch wie dieser Link in einem ebuild verwendet werden kann kapiere ich nicht. Und der Versuch das ebuild dazu zu bewegen das ganze über git herunter zu laden ist leider auch gescheitert.

Kann mir einer sagen wie ich das am besten zum laufen bringe?Last edited by schmidicom on Sun Aug 25, 2013 7:51 am; edited 1 time in total

----------

## franzf

Das ist ja der 1.7.1er branch, k.A. ob da noch was geändert wird - z.B. bugfixes. Dann kannst du unverhofft Probleme mit dem digest bekommen  :Wink: 

Aber im Wiki gibt's nen Link zum release tarball:

http://www.gitorious.org/openobex/pages/Home

----------

## schmidicom

Nein, das ist leider auch kein direkter Link und was anderes klappt nicht.

----------

## franzf

http://surfnet.dl.sourceforge.net/project/openobex/openobex/1.7.1/openobex-1.7.1-Source.tar.gz

----------

## schmidicom

Danke, der Download funktionierte damit und nach einigem Gefummel fing cmake sogar an....bevor es dann Selbstmord beging.

----------

## franzf

 *schmidicom wrote:*   

> Danke, der Download funktionierte damit und nach einigem Gefummel fing cmake sogar an....bevor es dann Selbstmord beging.

 

Kannst du mal ebuild und Selbstmordmotiv posten?

----------

## schmidicom

Ja klar, hier:

openobex-1.7.1.ebuild

build.log

----------

## franzf

Die top-level-CMakeLists.txt enthält "project ( openobex C )" - das reduziert die unterstützten Sprachen auf "C" - obwohl später explizit C++ verlangt wird (lies die Kommentare im CMakeLists.txt weiter unten).

Lösung: in src_prepare() ein sed, welches die project-Zeile durch "project ( openobex )" ersetzt. Keine angegebene Sprache == C+CXX -> passt.

Desweiteren: statt in src_unpack die SOurcen zu verschieben setzt du besser S:

```
S="${WORKDIR}/${P}-Source"
```

in dem Block mit SRC_URI usw.

----------

## schmidicom

Mit sed kann ich nicht umgehen aber ein patchfile tut es vermutlich auch.

----------

## franzf

```
EAPI=5

inherit cmake-utils

DESCRIPTION="An implementation of the OBEX protocol used for transferring data to mobile devices"

HOMEPAGE="http://sourceforge.net/projects/openobex/"

SRC_URI="http://surfnet.dl.sourceforge.net/project/openobex/openobex/${PV}/openobex-${PV}-Source.tar.gz"

LICENSE="GPL-2 LGPL-2.1"

SLOT="0"

KEYWORDS="~amd64 ~ppc ~ppc64 ~x86"

IUSE="bluetooth irda usb"

S="${WORKDIR}/${P}-Source"

RDEPEND="bluetooth? ( net-wireless/bluez )

    usb? ( virtual/libusb:1 )"

DEPEND="${RDEPEND}

    !<app-mobilephone/obexftp-0.24

    virtual/pkgconfig

    >=dev-util/cmake-2.8.5"

src_prepare() {

    sed -e 's/project ( openobex C )/project ( openobex )/' -i "${S}"/CMakeLists.txt || die "sed failed"

}

src_configure() {

    local mycmakeargs=(

        $(cmake-utils_use_with bluetooth OPENOBEX_BLUETOOTH)

        $(cmake-utils_use_with irda OPENOBEX_IRDA)

        $(cmake-utils_use_with usb OPENOBEX_USB)

    )

    cmake-utils_src_configure

}

src_install() {

    cmake-utils_src_install

    dodoc README AUTHORS NEWS ChangeLog

}

```

// edit:

Funktionen in die richtige Reihenfolge gebracht.Last edited by franzf on Thu Aug 22, 2013 9:19 am; edited 2 times in total

----------

## schmidicom

Ich dachte das prepare muss vor configure kommen?

----------

## franzf

 *schmidicom wrote:*   

> Ich dachte das prepare muss vor configure kommen?

 

Hab ich nicht gesehen, sollte aber reine Kosmetik sein. Das sind Funktionsdefinitionen. portage wird die im ebuild angegebenen Funktionen einfach aufrufen, die Reihenfolge sollte da nebensächlich sein.

Aber üblich ist es, die Funktionen auch in der aufgerufenen Reihenfolge ins ebuild zu setzen, das stimmt.

Funktionieren tut das ebuild jedenfalls.

----------

## schmidicom

Der Teil zumindest funktioniert aber leider nicht alles. Nach dem cmake soll man laut INSTALL das ganze mit make bauen nur da behauptet das ebuild:

```
*** Keine Targets angegeben und keine »make«-Steuerdatei gefunden.  Schluss.
```

EDIT:

Offensichtlich wird der "make" Befehl im falschen Verzeichnis abgesetzt wird, warum weiß ich noch nicht...Last edited by schmidicom on Thu Aug 22, 2013 9:01 am; edited 1 time in total

----------

## franzf

Hast du mein ebuild genommen?

Hast du noch ein eigenes src_compile() und src_install drinnen?

Ich habe auch noch "base" aus dem inherit genommen. Das überschreibt die beiden Funktionen in einer für cmake inkompatiblen Version. cmake baut standardmäßig out-of-source ($WORKDIR/$P_build). Dort liegt das Makefile. cmake-utils bringt dafür selber cmake-utils_src_*-Funktionen mit. Ohne "inherit base" werden die auch automatisch genommen. Wenn du selber in src_compile/src_install was machen willst (dodoc, z.B.) kannst du vorher die Funktion aufrufen. z.B.

```
src_install() {

    cmake-utils_src_install

    # was auch immer noch installiert werden soll

}
```

----------

## schmidicom

Jetzt verstehe ich gar nichts mehr...

Wenn kein src_compile und src_install mehr vorhanden ist woher soll dann emerge wissen was es damit anfangen soll und was ist mit "dodoc README AUTHORS NEWS ChangeLog" aus den alten ebuilds?

----------

## franzf

In der cmake-utils.eclass steht:

```
CMAKE_EXPF="src_compile src_test src_install"

case ${EAPI:-0} in

    2|3|4|5) CMAKE_EXPF+=" src_prepare src_configure" ;;

    1|0) eerror "cmake-utils no longer supports EAPI 0-1." && die

    ;;

    *) die "Unknown EAPI, bug eclass maintainers." ;;

esac

EXPORT_FUNCTIONS ${CMAKE_EXPF}
```

Wenn du NUR cmake-utils im ebuild einbindest, oder eine eclass, die nicht auch die obigen Funktionen exportiert, hast du automatisch ein passendes src_compile usw. Du musst da GAR NICHTS MEHR (!) selber machen.

base.eclass allerdings exportiert diese Funktionen:

```
BASE_EXPF="src_unpack src_compile src_install"

case "${EAPI:-0}" in

    2|3|4|5) BASE_EXPF+=" src_prepare src_configure" ;;

    *) ;;

esac

EXPORT_FUNCTIONS ${BASE_EXPF}
```

Diese überdecken die aus cmake-utils in einer für cmake inkompatiblen Version. Da du nichts aus base brauchst, hab ich das einfach rausgeworfen  :Wink: 

Wg. dem dodoc müsste ich erst noch schauen, sollte aber einfach so funktionieren  :Wink: 

// edit:

Ja, docs geht straight-forward  :Smile:  ebuild oben angepasst

----------

## schmidicom

So hat es auch geklappt:

```
EAPI=5

inherit cmake-utils base

DESCRIPTION="An implementation of the OBEX protocol used for transferring data to mobile devices"

HOMEPAGE="http://sourceforge.net/projects/openobex/"

SRC_URI="http://surfnet.dl.sourceforge.net/project/openobex/openobex/${PV}/openobex-${PV}-Source.tar.gz"

LICENSE="GPL-2 LGPL-2.1"

SLOT="0"

KEYWORDS="~amd64 ~ppc ~ppc64 ~x86"

IUSE="bluetooth irda usb"

S="${WORKDIR}/${P}-Source"

RDEPEND="bluetooth? ( net-wireless/bluez )

        usb? ( virtual/libusb:1 )"

DEPEND="${RDEPEND}

        !<app-mobilephone/obexftp-0.24

        virtual/pkgconfig

        >=dev-util/cmake-2.8.5"

src_unpack() {

        unpack ${A}

}

src_prepare() {

        sed -e 's/project ( openobex C )/project ( openobex )/' -i "${S}"/CMakeLists.txt || die "sed failed"

}

src_configure() {

        local mycmakeargs=(

                $(cmake-utils_use_with bluetooth OPENOBEX_BLUETOOTH)

                $(cmake-utils_use_with irda OPENOBEX_IRDA)

                $(cmake-utils_use_with usb OPENOBEX_USB)

        )

        cmake-utils_src_configure

}

src_install() {

        cmake-utils_src_install

        dodoc README AUTHORS NEWS ChangeLog

}
```

Aber leider baut jetzt dafür obex-data-server nicht mehr, ist wohl nicht kompatibel mit openobex-1.7.1.

Damit kann man diesen Teil meines Versuchs das versenden von Dateien per Bluetooth wieder zum laufen zu bekommen wohl auch als gescheitert ansehen. Vielleicht bastle ich noch ein ebuild für obexftp-0.24, das wäre dann die letzte mir verbleibende Möglichkeit das in den Griff zu bekommen.

----------

