GNU make: Versteckte Fehlermeldungen / Mehr verbose machen

[buhtz]

Hallo,

ich nutze "make" in einem Python Projekt. Ja, das ist unüblich. Ich arbeite bereits an einer Migration, aber dass ist eine Mammutaufgabe.

Lokal auf meiner Maschine kann ich keine Fehler provozieren bzw. reproduzieren. Läuft das unter TravisCI produziert ein make Aufruf aber einen Error Code 2. Jedoch fehlt hier eine weitere Fehlerbeschreibung.

Ich weiß nicht, ob das spezifisch für TravisCI ist, oder ob das auch lokal mit make passieren würde, wenn ich den Fehler provozieren könnte. Die Frage ist, wie ich make gesprächiger machen kann, um den eigentlichen Fehler entdecken zu können.

Hier ein kurzer Ausschnitt aus der Fehlermeldung bei TravisCI:


Ja, es hat wohl mit dem Aufruf von "coverage" zu tun. Wir sind der Sache auf der Spur und tappen nicht völlig im Dunkeln. Mir geht es bei diesem Post hier wirklich nur um die Verbosity von make.

Hintergrundinfos:
Hier der Link zum originalen Build auf Travis. Ich weiß nicht, ob ihr das ohne Login sehen könnt. Dazu gibt es auch noch einen offenen PR im Projekt backintime.

[tijuca]

Code: Alles auswählen

coverage run -p -m unittest -v -b test/test_backintime.py
WARNING: 'import keyring' failed with: ModuleNotFoundError("No module named 'keyring'")
test_diagnostics_arg (test.test_backintime.TestBackInTime) ... Traceback (most recent call last):
  File "/home/travis/build/bit-team/backintime/common/backintime.py", line 27, in <module>
    import tools
  File "/home/travis/build/bit-team/backintime/common/tools.py", line 37, in <module>
    from packaging.version import Version
ModuleNotFoundError: No module named 'packaging'
ERROR

Sieht für mich recht klar aus was da fehlt. Das hat nichts mit einem Verbosity Level von Make zu tun. Wie man "mehr Output" bei make bekommt finden man in der Manpage von make, Option -d bzw. --debug.

[buhtz]

Ähm... Wo genau hast du denn jetzt diesen Output her?

[JTH]

Ähm... Wo genau hast du denn jetzt diesen Output her?

Taucht auch im Log des von dir verlinkten Travis-Builds auf https://app.travis-ci.com/github/bit-te ... #L382-L390

Hier ein kurzer Ausschnitt aus der Fehlermeldung bei TravisCI:
Bild

Das Bild können wir übrigens nicht sehen, vermutlich da es von https://private-user-images.githubusercontent.com/ kommt.

[buhtz]

Der Wald und die Bäume... Peinlich.

[Meillo]

Der Wald und die Bäume... Peinlich.

Nicht peinlich, sondern gut, dass du gefragt hast! Wir kennen diese Situationen doch alle und das schlechteste Verhalten darin ist es, nichts zu sagen und selber die Antwort finden zu wollen, was meist aber Frust erzeugt und Zeit verbraet. Es ist gut und sinnvoll, nachzufragen. Und ich freue mich auch um solche Threads, weil ich beim nebenbei Mitlesen auch noch etwas lerne. Wir brauchen also eine Umkehr der Betrachtungsweise in so Faellen!

[buhtz]

Danke für eure Nachsicht. Ich muss nochmal was zu meiner Verteidigung anbringen.

Im ursprünglich verlinkten Build Log war der Fehler tatsächlich zu sehen. Warum ich diesen hier verlinkt habe, kann ich mir gar nicht erklären. Muss ein Versehen gewesen sein, denn dieser hat mit einem anderen (älteren) PR zu tun. Jedenfalls hatte ich den gar nicht intensiv betrachtet - offensichtlich.

In den aktuellen Build Logs sehe ich (ihr auch?) aber das beschriebenen Verhalten. Make wirft einen Code 2 und sonst sehe ich da aber nicht viel.

https://app.travis-ci.com/github/bit-te ... /616932983

Ja ein make -d (im Beispiel nicht verwendet) bringt mehr Output und zeigt auch einen der zwei ModuleNotFound Meldungen. Allerdings zeigt es immer noch nicht den vollen tracestack (nennt man das so?), so wie es ein fehlgeschlagener Python Test zeigen würde. Der Fehler ist im debug output extrem leicht zu übersehen (1 Zeile von über 100 anderen). Ebenso nehme ich eigentlich an, dass ein "-d" nix mit Fehlermeldungen zu tun haben dürfte. Debug und Error sind IMHO zwei verschiedene Dinge. Fehler müssen sichtbar sein, per default. Make ist sehr alt, im Sinne von gut abgehangen und ich eben weniger alt. Daher gehe ich davon aus, dass make schon alles richtig macht, nur ich irgendetwas an dem Konzept nicht verstanden habe. Oder Travis fuscht da irgendwie mit rein. Ich meine, wenn ich mir die Zeilennummern in dem Log anschauen, sind diese ja auch nicht linear, sondern durch gewürfelt.

Wir sind dem eigentlichen Problem aber auf der Spur. Vermutlich sind die beiden fehlenden Pakete innerhalb des virtual environments nicht verfügbar.

[JTH]

In den aktuellen Build Logs sehe ich (ihr auch?) aber das beschriebenen Verhalten.

Jo.

Ja ein make -d (im Beispiel nicht verwendet) bringt mehr Output und zeigt auch einen der zwei ModuleNotFound Meldungen. Allerdings zeigt es immer noch nicht den vollen tracestack (nennt man das so?), so wie es ein fehlgeschlagener Python Test zeigen würde. Der Fehler ist im debug output extrem leicht zu übersehen (1 Zeile von über 100 anderen). Ebenso nehme ich eigentlich an, dass ein "-d" nix mit Fehlermeldungen zu tun haben dürfte. Debug und Error sind IMHO zwei verschiedene Dinge. Fehler müssen sichtbar sein, per default. Make ist sehr alt, im Sinne von gut abgehangen und ich eben weniger alt. Daher gehe ich davon aus, dass make schon alles richtig macht, nur ich irgendetwas an dem Konzept nicht verstanden habe. Oder Travis fuscht da irgendwie mit rein. Ich meine, wenn ich mir die Zeilennummern in dem Log anschauen, sind diese ja auch nicht linear, sondern durch gewürfelt.

Richtig, -d oder generell make gesprächiger zu machen, hilft dir hier wahrscheinlich gar nichts. Das würde dir nur zeigen, welche Schritte make tut, etwa

Code: Alles auswählen

backintime/common$ make -d unittest-v
GNU Make 4.3
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Reading makefile 'Makefile'...
Updating makefiles....
 Considering target file 'Makefile'.
  Looking for an implicit rule for 'Makefile'.
  Trying pattern rule with stem 'Makefile'.
  
[Eine Latte an „Trying pattern rule …“]

   Trying implicit prerequisite 'SCCS/s.Makefile.sh'.
  No implicit rule found for 'Makefile'.
  Finished prerequisites of target file 'Makefile'.
 No need to remake target 'Makefile'.
Updating goal targets....
Considering target file 'unittest-v'.
 File 'unittest-v' does not exist.
 Finished prerequisites of target file 'unittest-v'.
Must remake target 'unittest-v'.
/usr/bin/pytest -v
Putting child 0x5651a9ab84b0 (unittest-v) PID 29648 on the chain.
Live child 0x5651a9ab84b0 (unittest-v) PID 29648 

[Nur hier kommt Ausgabe von pytest und co.]

Reaping losing child 0x5651a9ab84b0 PID 29648 
make: *** [Makefile:565: unittest-v] Error 2
Removing child 0x5651a9ab84b0 PID 29648 from chain.

Normalerweise beeinflusst make nicht die Ausgabe der Kommandos, die in den Rules ausgeführt werden. Die kommen einfach genauso raus, wie wenn man die Kommandos alle von Hand ausführen würde.

Oder Travis fuscht da irgendwie mit rein.

Könnte sein. Oder

Code: Alles auswählen

/usr/bin/python3 -m coverage run -p -m unittest -v -b test/test_applicationinstance.py

hat einfach keine Ausgabe, sondern nur einen nicht erfolgreichen Exitcode?

Ich meine, wenn ich mir die Zeilennummern in dem Log anschauen, sind diese ja auch nicht linear, sondern durch gewürfelt.

Wo sind die denn durcheinander? Hab ich auf die Schnelle nichts gesehen.

[buhtz]

Wo sind die denn durcheinander? Hab ich auf die Schnelle nichts gesehen.

Ja, in dem verlinkten Beispiel mal wieder nicht. Egal.

Wir haben das Problem gelöst, ohne die Ursache wirklich zu kennen. Ist OK, weil wir langfristig das build system sowieso modernisieren und von make weggehen.

Bezüglich der verschluckten Fehlermeldung, werde ich mal den Travis support anfragen. Vielleicht haben die eine Idee. Die sind recht fix und kreativ bei solchen Sachen, auch wenn man kein zahlender Kunde ist.