Makefile.am für zapit ist korrupt

[SnowHead]

Das vor vier Tagen eingecheckte Makefile.am in apps/dvb/zapit/src/ ist korrupt. Es fehlt der Eintrag

Code: Alles auswählen

controldc_SOURCES = \
	controldc.cpp

deshalb bricht das make mangels target ab.

[rhabarber1848]

Ich habe es committed: http://article.gmane.org/gmane.comp.vid ... ox.scm/721
da es nicht schaden kann. Bei mir trat allerdings kein build-Fehler auf
(yadd-neutrino flash-neutrino-squashfs-all), controldc war in /bin auch
vorhanden. Könntest Du bitte Deine Fehlermeldung posten?

[SnowHead]

Build-Target war "flash-neutrino-squashfs-all". Habe den genauen Wortlaut der Fehlermeldung jetzt nicht mehr im Kopf und auch nicht mehr verfügbar, da das Build ja jetzt durchläuft, aber sinngemäß wurde moniert, daß kein Target zum Bau von controldc.o gefunden wurde. "zapit" wurde gelöscht und das make abgebrochen. Ist eigentlich auch nachvollziehbar, wenn in den "bin_PROGRAMS" controldc zwar angegeben wird, aber keine Quellen dafür festgelegt werden. Ich staune daher, daß es bei Dir durchlief.

Edit: Habe die Makefile.am noch mal rückgebaut und nach der Konfiguration das Make gestartet. Ergebnis:

Code: Alles auswählen

make[3]: Entering directory `/home/image/tuxbox-cvs/apps/dvb/zapit/src'
make[3]: *** Keine Regel vorhanden, um das Target »controldc.c«,
  benötigt von »controldc.o«, zu erstellen.  Schluss.

[Barf]

Natürlich habe ich probiert, dass es am mindestens bei mir läuft, bevor einchecken . Nicht nur bei mir und rhabarber, sondern auch bei dietmarw hat es geklappt. (Bei Verdacht um kaputten CVS schaue ich immer als aller erstes bei dietmarw nach.)

Der Fix schadet sicherlich auch nicht.

Edit: Habe die Makefile.am noch mal rückgebaut und nach der Konfiguration das Make gestartet. Ergebnis:
Code:
make[3]: Entering directory `/home/image/tuxbox-cvs/apps/dvb/zapit/src'
make[3]: *** Keine Regel vorhanden, um das Target »controldc.c«,
benötigt von »controldc.o«, zu erstellen. Schluss.

Aha. SnowHeads make hat irgendwie andere Defaultregeln als bei mir/rhabarber/dietmarw (%.o: %.cpp).

[SnowHead]

Hmm, dann frage ich mich aber, wo ich diese Defaultregeln beeinflussen kann. Ich habe diesmal komplett neu ausgecheckt und an Configs nur das ausgeführt:

Code: Alles auswählen

./configure --prefix="$DBOX" --with-cvsdir="$CVS" --enable-flashrules --with-customizationsdir=$CHANGE_DIR/customize --with-rootpartitionsize=$SQ_PARTSIZE --enable-ide --enable-xfs --with-filesystems=ext2,ext3,vfat,xfs,cifs,nfs,lufs --enable-dosfstools --enable-nfsserver --enable-upnp --enable-esd --enable-german-keymaps --enable-lirc --enable-cdkVcInfo --with-checkImage=rename --with-logosdir="$MYVAR/tuxbox/boot"

Betriebssystem ist Suse 10.1.
Na ja, wenn es auch nicht jedem nützt, schaden tut die Ergänzung jedenfalls nicht.

[seife]

Da ist sicher ein unterschied in der automake-Version dran "schuld".

[SnowHead]

Ich habe die automake-Version 1.9.6. Und dieses makefile war das einzige, welches angemeckert wurde. Na ja, zumindest läuft das make jetzt wieder durch.

[seife]

Keine Frage - das File war "suboptimal", um den Genossen Schröder zu zitieren, aber es fiel halt keinem auf, weil anscheinend fast alle schon neuere Versionen verwenden, die das zulassen.

Jetzt ist es auf jeden Fall besser.

[rhabarber1848]

Ich habe die automake-Version 1.9.6.

Auf Debian Etch mit automake 1.9.6 keine Kompilierprobleme.
Ich vermute eher, dass GNU make der Schuldige ist. Auf Suse 10.1
gibt es Version 3.80, andernorts 3.81. Ist aber nur eine Vermutung,
da meine Suse 10.1-Installation sich etwas zickig anstellt beim
Nachinstallieren von Paketen.
Hat jemand eine URL für ein komplettes Suse 10.1-Repo?

[seife]

10.1 ist lange abgekündigt, insofern weiss ich auch nicht, wo da noch was sein könnte...