Project

General

Profile

Actions

Support Request #3483

closed

EBPRODUCTSUPPORT-835 Debug version of ADTF Control uses RelWithDebInfo version of ADTF Launcher as default

Added by hidden almost 6 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Normal
Customer:
ELEKTROBIT
Department:
SUPPORT
Requester's Priority:
Normal
Support Level:
2nd Level
Resolution:
Product Issue Opened
Affected Products:
Platform:
Topic:
ADTF::Control
FAQ Links:

Description

Supportanfrage

Im Zuge unserer Lizenzanpassungen fand Fabian noch dieses Problem:

"Beim Verwenden von <adtf-dir>/bin/debug/adtf_control wird implizit der (release) "adtf" Launcher verwendet. Nicht der "adtf_debug" Launcher, wie man es erwarten würde. Das führt dazu, dass die Release Plugins geladen werden, welche wiederum die Release licenser.so laden. Das führt bei mir zu dem Fehler unten auf dem Screenshot.

Bitte nicht auf das Laden der Release licenser.so Lib eingehen, darum geht es hier nicht (das behebe ich selber - es dient nur als Aufhänger für die folgende Diskussion).

Das eigentliche Problem ist, das implizit der "adtf" Lauchner verwendet, obwohl adtf_control per Debug gestartet wurde. Das ist nicht intuitiv. Mir ist bekannt, dass man es mit Angabe von -lauchner=adtf_debug umgehen kann.
Es gibt auch keinen Hinweis in der Konsolenausgabe des adtf_control noch Hinweise in der Doku (und nur ein Hinweis in der Doku allein genügt eh nicht - das würden zu viele Kunden erst hinterher lesen). Eigentlich sollte adtf_control im Debug auch implizit den "adtf_debug" Launcher verwenden (und parallel noch ausgeben, welchen Launcher es verwendet).

Beispiel Problem: ein Entwickler schreibt ein Plugin, baut es meist während der Entwicklung nur im Debug. Ab und an mal zwischendurch auch im Release. Er hat also zwischenzeitlich Änderungen im Debug, aber nicht im Release Binary. Ohne das Wissen über die implizite Verwendung des Release "adtf" Launchers wundert er sich, warum ein seine Änderungen nicht zum Tragen kommen."
Könnt ihr euch das mal anschauen?

Lösung

Mit einen ADTF Control / ADTF GUI Control startest oder hängst du dich bewusst an einen Launcher, das hat nichts mit einer default Toolchain zu tun.
Wenn es nach mir geht, fallen die Debug Tools in der Lieferung weg, es gibt nur einen Debug Launcher, der steuert die Debug Plugins an.
Der CE macht das ja genau so... er startet auch nicht im Debug Fall den ADTF Control Debug sondern ganz normal, nimmt aber den Debug Launcher.
Das ist ja das was interessiert, Control ist ja nur die "Fernbedienung".

Desweiteren ist der default Fall der Anwender, also RelWithDebInfo.

Von einen Entwickler erwarte ich, dass er weiß was er tut.

Und wenn du 'help launch' aufrufst, sagt dir die Hilfe auch, dass er den default Launcher verwendet, also den ersten.
Welcher das ist, erfährst du mir 'launchers'.

Ich fasse zusammen:
1) Ich halte das Verhalten für absolut richtig
2) Ich plädiere dazu, die Debug Tools zu entfernen (bis auf Debug Launcher & Plugin Description Generator) (ACORE-9606)
3) Ich würde die Anregung insgesamt mitnehmen und die Rückgabe des 'info' Commands um den aktuellen verwendeten Launcher zu erweitern (ACORE-9607)


Related issues

Related to Public Support - Support Request #6388: EBPRODUCTSUPPORT-3057 Missing some executables in debug directory since ADTF 3.4.0ClosedActions
Actions

Also available in: Atom PDF