andere Plugins bauen .

[MPC823]

Ich habe versucht andere Plugins zu bauen und bleibe aber immer wieder an der gleichen Stelle hängen.

tuxcom läuft durch aber alle andere bleiben an der selben Stelle hängen .

Code: Alles auswählen

make[3]: Entering directory `/home/martin/development/dragon/buildsystem-cs/build_tmp/neutrino-hd-plugins/tuxmail'
Making all in tuxmail
/bin/sh: Zeile 17: cd: tuxmail: Datei oder Verzeichnis nicht gefunden
make[3]: *** [all-recursive] Fehler 1
make[3]: Leaving directory `/home/martin/development/dragon/buildsystem-cs/build_tmp/neutrino-hd-plugins/tuxmail'
make[2]: *** [all-recursive] Fehler 1
make[2]: Leaving directory `/home/martin/development/dragon/buildsystem-cs/build_tmp/neutrino-hd-plugins'
make[1]: *** [all] Fehler 2
make[1]: Leaving directory `/home/martin/development/dragon/buildsystem-cs/build_tmp/neutrino-hd-plugins'
make: *** [plugins] Fehler 2

Ich habe versucht in plugins.mk den make aufruf mit -d zu machen aber bekomme immer noch nicht raus in welcher Datei er angeblich was ausführen will was angeblich nicht da ist.

Wie bekomme ich raus an welcher Stelle make wo abricht. ? oder wo diese ominöse "/bin/sh: Zeile 17" ist.

Ich habe schon alle Dateien angeschaut nachdem ich nicht weiss welche aber es gibt keine datei wo in Zeile 17 ein aufruf drinsteht. Sagen wir so ich habe Sie nicht gefunden

Martin

Platform = tripledragon

[GetAway]

Vergiss es. Außer Tuxcom, ist nichts für die Tripledragon portiert.

[MPC823]

Auf der Spark ist es ja genauso also liegt es ja nicht an etwas TD spezifischem.

obwohl tuxmail und tuxcom fast identische makefiles.am haben baut der aufruf von "make SUBDIRS=tuxcom" durch und "make SUBDIRS=tuxmail" nicht.

Bei Tuxcom wechselt make nur nach "buildsystem-cs/build_tmp/neutrino-hd-plugins/tuxcom" und bei Tuxmail will make nach "buildsystem-cs/build_tmp/neutrino-hd-plugins/tuxmail/tuxmail" wechseln was es aber gar nicht gibt.

Martin

[doc]

Wie bekomme ich raus an welcher Stelle make wo abricht. ? oder wo diese ominöse "/bin/sh: Zeile 17" ist.

Das ist die Zeile 17 vom entsprechenden Aufruf im Makefile (logisch soweit ), und zwar im entsprechenden Target. Wenn keine Subshell weiter gestartet wird also einfach in der ersten Zeile vom Target an zählen. In welcher Subshell Make sich befindet siehst du in der Zahl die in eckigen Klammern aufgeführt ist. In Deinem Fall die dritte Subshell.

Ansonsten ist es so wie GetAway schreibt, da ist noch nichts weiter portiert, die eben nicht wirklich vorhandene Pluginschnittstelle ist eben nicht motivierend da was zu machen.

[dbt]

die eben nicht wirklich vorhandene Pluginschnittstelle ist eben nicht motivierend da was zu machen.

Genau da liegt der Hund begraben. Neutrino könnte man als "Grundausstattung" hinstellen, mit relaitiv wenigen aber sehr stabilen Grundfunktionen und alles andere an Funktionalität würden die Plugins ausmachen. Es gäbe wohl schon Hunderte Plugins, wenn es eine satte Schnittstelle gäbe, so baut man halt Standalone Programme, die man als Plugins bezeichnet und es für jeden, der da einsteigen will, relativ Horror ist, überhaupt was zu machen. Aber was nicht ist...

[MPC823]

Also da Problem liegt daran das in der Buildumgebung von NeutrinoHD und das betrifft auch Spark eine Variable doppelt genutzt wird.

in plugins.mk wird mit "$(MAKE) SUBDIRS="$(PLUGINS_TO_BUILD)" der bau angeworfen. Dort wird mit SUBDIRS eine Variable übergeben um vermutlich rekursiv zu bauen was oben "eingeschaltet" wurde.

Wenn nun aber in dem make Steuerfile innerhalb des zu bauenden Pluginsverz es ein Unterverzeichnis gibt wie tuxmail z.B "daemon" dann muss dieses im Steuerfile (alt) angegeben.

Code: Alles auswählen

SUBDIRS = daemon

AM_CPPFLAGS = \
	@FREETYPE_CFLAGS@ \
	-I$(top_srcdir)/include

noinst_LTLIBRARIES = tuxmail.la

tuxmail_la_SOURCES = tuxmail.c

tuxmail_la_LIBADD = \
	@FREETYPE_LIBS@

tuxmail_la_LDFLAGS = -rpath $(PLUGINDIR) -module -avoid-version

install-exec-local:
	install -d $(DESTDIR)$(PLUGINDIR)
	install -d $(DESTDIR)$(CONFIGDIR)
	install -d $(DESTDIR)$(CONFIGDIR)/tuxmail
	$(LIBTOOL) --mode=install install tuxmail.la $(DESTDIR)$(PLUGINDIR)
	install -m 0644 $(srcdir)/tuxmail.cfg $(DESTDIR)$(PLUGINDIR)
	install -m 0644 $(srcdir)/tuxmail.conf $(DESTDIR)$(CONFIGDIR)/tuxmail

Das bringt dann aber make etwas durcheinander das er dann in ~/neutrino-hd-plugins/tuxmail nach tuxmail sucht und das natürlich nicht findet.

Bei tuxcom tritt das Problem nicht auf da tuxcom keine Unterverz hat. Auch ander plugins lässen sich bauen die keine Unterverzeichnisse haben. (Ob diese dann laufen ist wieder was anderes)

Hat jemand dafür eine Saubere Lösungsidee ? Wenn möglich mit etwas pratischer Hilfe . das wäre schön.

Dann könnte man das Seife geben damit er das ins git reinschiebt.

Was mir auch noch aufgefallen istb das der main loop der Plugins sich verändert hat.

Früher war das immer :

Code: Alles auswählen

******************************************************************************
 * plugin_exec
 ******************************************************************************/

void plugin_exec(PluginParam *par)

nun sollte es

Code: Alles auswählen

/******************************************************************************
 * plugin_exec                                                                *
 ******************************************************************************/

int main()

sein. Hat woll was mit den ausführbaren scripten zu tun. Somit hat sich ja im vgl zu ganz früher doch ein bischen was getan wenn auch wenig das die plugins immer noch eigenständig sind und nicht an Neutrino andocken.

Also wäre schön wenn mir jemand da unter die Arme greifen kann wie man das "RICHTIG" macht eine wurstelidee habe ich , aber das ist nur ein hack und von dem sind in Neutrino ja genug drin.

Martin

[WerN]

Hallo,

das wäre noch die Krönung wenn diverse plugins wie tuxmail, callmonitor oder auch tuxcal auf der GM 990 laufen würden.
Wünsche Dir viel Glück dabei.

WerN

[MPC823]

Tuxmail bekomme ich schon gebaut bis auf den daemon da kommt sich leider die variable in die quere.


Martin

[MPC823]

Laut recherche lässt sich das rekursiv schon realisieren siehe

http://debianforum.de/forum/viewtopic.php?f=34&t=37715

aber so wie das aussieht make einen bug und überschreibt oder übergibt die variablen nicht richtig an die subshell.

Von der ersten an die zweite das klappt ja noch aber von der zweiten an die dritte läft es schief.

Martin