Uso dei percorsi assoluti per le dipendenze di build

Question

Uso dei percorsi assoluti per le dipendenze di build

#1 da (1 voti)
#2 da (0 voti)

4

Attualmente utilizziamo Source Safe e abbiamo avviato la migrazione a Subversion. Tutti i nostri SDK esterni (> 500 MB) sono conservati in Source Safe in questo momento e sto cercando modi per spostarli da VSS a un repository.

Abbiamo progetti C ++ (principalmente), C # (molti), Java (pochi). Centinaia di progetti, tutti in esecuzione su Windows.

Ho esaminato un paio di gestori delle dipendenze ma non sono soddisfatto:

NuGet - buono per .Net ma doloroso per C ++
Ivy - non guarda in profondità, ma non sembra accettabile per C ++

Prima domanda: che altro dovrei controllare? Dovrebbe essere facile da usare per uno sviluppatore front-end. Il caso migliore è una semplice build all'interno dell'IDE.

Attualmente sono propenso a questa soluzione:

Assegna un disco usato raramente, come S: e dichiaralo come "DEV HOME".

Quindi posiziona gli esterni qui:

S:\SDK\boost.30\...
S:\SDK\boost.45\...
S:\SDK\oracle\agile_9.0.0.0\...
S:\SDK\IBM\lotus_8.0\...
S:\SDK\IBM\lotus_9.0\...
S:\Tools\NuGet\nuget.exe
S:\Tools\clr\gacutil.exe

La macchina di costruzione automatica terrà la copia master di questa 'DEV HOME'. Ogni sviluppatore dovrebbe copiare gli SDK necessari dalla macchina da autobuild a quella locale e creare un disco "falso" con subst .

Non riesco a trovare grossi problemi con questa soluzione:

Filiali. I progetti in diversi rami contengono riferimenti a diverse versioni di SDK (ad esempio boost)
La versione del componente esterno non cambierà troppo frequentemente, quindi non ci saranno centinaia di, per esempio, versioni boost.
Facile da configurare per gli sviluppatori.
Percorsi assoluti supportati da qualsiasi strumento.

Problemi minori:

Personalmente per me non è una soluzione bellissima.
Il disco (S :) può essere occupato
Non può essere fatto in Linux (ma al momento non ci interessa)

Seconda domanda: quali problemi puoi vedere con questa soluzione?

c# c++ dependencies

posta Sergey Azarkevich 09.04.2013 - 08:11

fonte

2 risposte

Leggi altre domande sui tag c# c++ dependencies

MVVM ViewModel dovrebbe iniettare un modello HTML per la visualizzazione predefinita? Modo efficiente per creare una stima del codice / specifiche tecniche in un ambiente in rapido movimento

score 1 · Answer 1

Il più grande problema con un'unità mappata è che fallisce completamente se qualcuno decide di usare quell'unità per qualcos'altro. Potresti affermare che non accadrà; Potrei contrastare questa affermazione con molta esperienza e cinismo e dire "Hah!"

Praticamente tutti gli strumenti di sviluppo in questi giorni sono perfettamente contenti di lavorare con quasi tutto ciò che viene fatto con percorsi relativi. Una volta che li usi, dovresti scoprire che puoi evitare di commettere qualsiasi percorso assoluto al repository di codice (o ai repository) e tutto sarà molto più ordinato. Le uniche parti che ottengono percorsi assoluti sono cose come i file di configurazione IDE, e sono il tipo di cosa che è meglio lasciare senza impegno. (Non vorresti condividere la disposizione delle finestre degli strumenti? Allora perché condividere i percorsi?)

Per i manager delle dipendenze, ti suggerisco di usare uno nativo per ogni lingua. Usa un buon prodotto come NuGet solo per quello che è buono piuttosto che cercare di incunearsi in uno strumento magico globale. "Tuttofare; master of none. "(Inoltre, la gestione delle dipendenze con C ++ non è così avanzata come con C # e Java, ma invece puoi fare trucchi più cool con associazioni alternative di implementazione ...)

Per la gestione del codice sorgente, ti consiglio di tenere il maggior numero possibile di dati binari dal repository. Accetta solo file che sono originali, non copie di qualcosa che si trova in altre parti del mondo.

score 0 · Answer 2

Per rispondere alla seconda domanda, il problema principale con l'utilizzo di un'unità condivisa per l'hosting del codice è che le prestazioni non saranno ottimali. Probabilmente incontrerai problemi di concorrenza e velocità in generale. Raccomanderei di avere le dipendenze di ciascun progetto memorizzate con il repository SVN, ma al di fuori della cartella trunk principale (per evitare la duplicazione sulla ramificazione). O se si hanno molte dipendenze comuni, si potrebbe avere un repository separato per questo e usare gli "esternali" di SVN per gestirlo.

In termini di manager delle dipendenze nessuno può consigliarti chi soddisferà tutte le tue esigenze individuali, ognuna con benefici e compromessi, specialmente considerando la tua vasta gamma di lingue. Ritorno a Google ho paura:)