Come posso usare un server di compilazione con Keil uVision4 (MDK-ARM), scrivere una build, usare un makefile?

Vorrei eseguire build giornaliere o check-in / commit build innescate di progetti basati su Keil MDK-ARM. Finora ho fatto le cose con la funzione di file batch dell'IDE. Ciò richiede di compilare il progetto almeno una volta con l'IDE, quindi di archiviare il file batch, i file associati .__ie i ._iafile creati dall'IDE.

Inoltre, l'IDE inserisce molte cose specifiche dell'utente nel file batch come la variabile PATH di Windows. Questo potrebbe diventare un problema con più sviluppatori, perché il file batch per la costruzione potrebbe essere modificato ad ogni commit da uno sviluppatore diverso.

In definitiva, è sufficiente tenere traccia dei vari switch per armcc , armasm e ArmLink .

Esiste un modo per utilizzare un makefile più standard per creare progetti Keil uVision? Esiste un metodo per tradurre un file di progetto uVision in uno script di build più gestibile?

Questo è il metodo migliore che ho escogitato di recente:

Nelle opzioni di generazione, selezionare Crea file batch.

Quando si avvia una build dall'IDE, viene creato un file batch insieme a diversi file di testo in base alle opzioni impostate nell'IDE. È necessario tenere traccia di questi file generati dall'IDE nel controllo del codice sorgente:

• * .bat
• * .ini
• *.__io
• * ._ ia
• * .lnp
• * .sct

Quindi foo.bat può essere avviato da uno script di build.

Sebbene ciò crei file extra che devono essere monitorati nel controllo del codice sorgente se si desidera compilare in modo affidabile dal file batch generato, rimuove la necessità di fare affidamento sul file di progetto Keil (foo.uvproj) e sull'IDE. Trovo più facile confrontare le differenze e quindi tenere traccia delle modifiche ai file di testo generati (* .__ i) che contengono flag del compilatore rispetto al file .uvproj. Inoltre, il file batch chiama direttamente i vari strumenti, armasm, armcc, armlink. Ciò fornisce l'output diretto di ciascuno di questi passaggi, nonché un potenziale apparentemente migliore per la migrazione di un progetto in una catena di strumenti diversa in futuro, se necessario.

Mi rendo conto che questa risposta assomiglia molto alla mia domanda originale, ma sinceramente non conosco un modo migliore di eseguire una build con script con gli strumenti di Keil. Ho chiesto di vedere cosa potrebbe venire fuori dagli altri. Non sono completamente in disaccordo con la risposta di @digikata, ma preferisco avere i flag del compilatore e la mappa di memoria in un formato più semplice per il tracciamento e utilizzare più strumenti in stile unix per la compilazione piuttosto che lanciare una compilation all-in-one con l'IDE. Penso che la compilazione all-in-one dell'IDE funzioni bene sulla mia workstation, ma non per il server di build.

EDIT : il server di build funziona su Windows Server 2003. Devo confessare di aver rinunciato a utilizzare l'interfaccia della riga di comando IDE anziché un file batch. Questo è diventato troppo difficile da gestire.

Chiamo l'IDE Keil tramite riga di comando per creare (non un file batch generato) da un Makefile. Di solito funziona meglio per bloccare i file di progetto tramite scm, o prendere una copia di build di riferimento rinominando i nomi dei progetti rilevanti mentre lo si fa.

L'IDE è perfettamente felice di lavorare con file di progetto di sola lettura, quindi se li blocchi, l'irritante è che devi sbloccarli per modificare le impostazioni, salvarli e ricontrollarli. Se sei abbastanza stabile punto nel progetto questo è piuttosto secondario - anche desiderabile.

Se si prende una copia di riferimento, la build tende a interrompersi quando cambiano le impostazioni del progetto, specialmente quando i file di progetto vengono aggiunti o eliminati dalla compilation. Catturare esplicitamente tali modifiche non è necessariamente negativo, ma è un ulteriore passaggio necessario per mantenere le build.

In entrambi i casi, il reindirizzamento dell'output su un file di registro tramite l'opzione "-o" consente di accedere al registro di output completo. Il registro non esce una riga alla volta, ma sembra essere tutto lì. (In realtà analizzo il formato di errore Keil su GNU fmt per l'integrazione con l'ambiente CDT di eclipse. Questo mi permette di passare direttamente agli errori / avvisi dopo la compilazione)

La build da riga di comando genera anche i file __i, __ia, quindi anche quelli non devono andare nel controllo di versione per il server di build.

Spero che sia di aiuto.