Crossprofiling con gcov, ma GCOV_PREFIX e GCOV_PREFIX_STRIP vengono ignorati

Voglio utilizzare GCOV per eseguire la copertura del codice ma i test verranno eseguiti su un’altra macchina. Quindi il percorso cablato per i file .gcda nell’eseguibile non funzionerà.

Per cambiare questa directory predefinita posso usare i vv di GCOV_PREFIX e GCOV_PREFIX_STRIP, come si dice qui .

Ecco i miei comandi che ho usato:

$ export GCOV_PREFIX="/foo/bar" $ export GCOV_PREFIX_STRIP="3" $ gcc main.c -fprofile-arcs -ftest-coverage $ strings a.out | grep gcda /home/calmarius/blahblah/main.c.gcda 

Il percorso rimane lo stesso. Qualcuno ha esperienza con questo?

    Le variabili di ambiente vengono prese in considerazione quando si esegue il codice.

    Impostali sui valori appropriati sul computer di destinazione prima di eseguire i test e i file .gcda verranno generati dove vuoi.

    ************ ARRRRGGGGGHHHHH ************

    Per favore, per favore vota per la risposta di Mat.

    Le variabili di ambiente vengono prese in considerazione quando si esegue il codice.

    Questa frase manca apparentemente da OGNI documento che ho letto su come spostare l’output!

    In effetti, permettimi di espandere la risposta un po ‘.

    GCOV_PREFIX è un runtime – come apposto per build il tempo – variabile di ambiente e determina la directory root in cui sono scritti i file di output gcov (* .gcda).

    GCOV_PREFIX_STRIP = X è anche una variabile di runtime e ha l’effetto di rimuovere gli elementi X dal percorso trovato nei file object (stringhe XXXX.o)

    Ciò significa:

    Quando si crea il progetto, i file object vengono scritti con il percorso completo della posizione di ciascun file sorgente responsabile per ciascun file object incorporato all’interno di essi.

    Quindi, immagina di scrivere un eseguibile MyApp e una libreria MyLib in una directory come questa:

     /MyProject |-MyApp |--MyLib 

    Avviso MyLib è una sottodirectory di MyApp

    Diciamo che MyApp ha 2 file sorgente e MyLib ne ha 3

    Dopo aver creato il flag “-coverage”, avrai generato 5 file .gcno, 1 per ciascun file object.

    Incorporato nei file .o per MyApp sarà il percorso assoluto ** / MyProject / MyApp / ** a_source_file.cpp Analogamente, incorporato nei file .o per MyLib sarà il percorso ** / MyProject / MyApp / MyLib / ** another_source_file.cpp

    Ora, diciamo che sei come me, e sposta quei file su una macchina completamente diversa con una struttura di directory diversa da quella in cui sono stati creati. Nel mio caso la macchina target è in realtà un’architettura totalmente diversa. Mi schiero su / alcuni / deploy / path non / MyProject su quella macchina.

    Se esegui semplicemente l’app, i dati di gcov proveranno a scrivere i corrispondenti file .gcda su / MyProject / MyApp e / MyProject / MyApp / MyLib per ogni file object nel tuo progetto, perché quello è il percorso indicato dai file .o, e dopo tutti, MyApp e MyLib sono semplicemente raccolte di file .o archiviati insieme, con qualche altra magia per sistemare puntatori e funzioni.

    È probabile che queste directory non esistano e probabilmente non stai eseguendo come root (sei?), Quindi neanche queste directory verranno create. Soooo .. non vedrai alcun file gcda all’interno della posizione di distribuzione / my / deploy / path.

    Questo è totalmente confuso, giusto!?! ??!?!?!?

    Qui entra in gioco GCOV_PREFIX e GCOV_PREFIX_STRIP.

    (BAM! Pugno colpisce la fronte) È necessario istruire il **** runtime **** che il percorso incorporato nei file .o non è proprio ciò che si desidera. Si desidera “rimuovere” parte del percorso e sostituirlo con la directory di distribuzione.

    Quindi, si imposta la directory di distribuzione tramite GCOV_PREFIX = / some / deploy / path e si desidera rimuovere / MyProject dai percorsi .gcda generati in modo da impostare GCOV_PREFIX_STRIP = 1

    Con queste due variabili di ambiente impostate, eseguite la vostra app e poi guardate in / some / deploy / path / MyApp e / some / deploy / path / MyApp / MyLib ed ecco che i 5 file gcda appaiono miracolosamente, uno per ogni object file.

    Nota: il problema è aggravato se si eseguono build di origine. Il punto .o punta al sorgente, ma il gcda verrà scritto in relazione alla cartella di costruzione.