2013-10-18 10 views
9

Sto lavorando in una squadra che sta sviluppando software Android. Alcuni membri del team usano Windows, altri usano Mac e sono stato conosciuto per usare Linux. Tutti usano Eclipse.Eclipse project.properties percorsi backslash considerati dannosi

Eclipse scrive un file chiamato project.properties; ecco un esempio. La parte importante sono le ultime tre righe, i percorsi di riferimento della libreria Android.

# This file is automatically generated by Android Tools. 
# Do not modify this file -- YOUR CHANGES WILL BE ERASED! 
# 
# This file must be checked in Version Control Systems. 
# 
# To customize properties used by the Ant build system edit 
# "ant.properties", and override values to adapt the script to your 
# project structure. 
# 
# To enable ProGuard to shrink and obfuscate your code, uncomment this (available properties: sdk.dir, user.home): 
#proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt 

# Project target. 
target=android-17 
android.library.reference.1=../private-code/lib/SomeLibrary 
android.library.reference.2=../google-play-services_lib 
android.library.reference.3=../FacebookSDK 

Quanto sopra è ciò che il file sembra quando Eclipse su Mac o Linux scrive. Quando Eclipse su Windows lo scrive, le linee di riferimento della libreria sono scritte con barre retroverse.

Ovviamente su Windows, le barre retroverse sono separatori di percorso accettabili. Ma su Mac e Linux questi percorsi non funzionano. Il fatto è che su Windows le barre di avanzamento funzionano perfettamente. Quindi, la nostra politica ora è sempre quella di impegnare il file con barre in avanti, in modo che funzioni per tutti.

Ma questo è un problema per i nostri utenti Windows, ed è un problema per noi quando gli utenti di Windows commettono un errore, quindi sto cercando una soluzione tecnica. Ho due idee:

  • trovare un'impostazione da qualche parte in Eclipse su Windows, dicendogli di usare le barre quando si salvano i percorsi nei file come project.properties. (Perché diamine non è quella predefinita?!?)

  • Usiamo Mercurial, quindi: installa una sorta di "ganci" che risolverà il problema.

    • Installare un commit gancio sui computer Windows, in modo che il file si è impegnata nel repository con i backslash sostituiti da slash.
    • Installare un gancio di trazione sui computer Mac e Linux; quindi se il file viene commesso con barre rovesciate, vengono sistemati prima che i file vengano scritti.

Il commit hook sembra più pulito, quindi se entrambi sono disponibili mi piacerebbe prendere un commit gancio sopra un gancio di trazione.

Ho trovato un'estensione Mercurial che modifica le schede in spazi, che è almeno in qualche modo simile a quello che voglio. È abbastanza complesso da essere un po 'diffidente nel cercare di modificarlo in ciò di cui ho bisogno.

https://www.mercurial-scm.org/wiki/CheckFilesExtension

L'altra strategia è quello di aggiungere un gancio che rileva backslash nei percorsi, e semplicemente interrompe il commit, costringendo l'utente di Windows per correggere il file manualmente prima di impegnarsi. Sarebbe meglio di niente.

+0

Affrontare questo problema ora. Su quale soluzione si è insediata la tua squadra? –

+1

Non ho ancora risolto. Sono giunto alla conclusione che la soluzione migliore è quella semplice: gli hook che fanno fallire un commit se i backslash sono nel modo sbagliato, e gli utenti di Windows dovranno solo aggiustarlo a mano. Al momento, nessuno sta apportando modifiche di base a quel file, quindi questo problema non ci ha morso, e siamo stati tutti occupati e non ci abbiamo pensato. – steveha

risposta

0

Abbiamo affrontato la situazione simile a causa del percorso della libreria locale varia, quindi dopo aver cercato un po 'abbiamo trovato la migliore pratica per utilizzare strumenti di repository centralizzati (Git per noi), "Rimuovi tutte le eclissi dipendenti/Impostazioni specifiche file dal repository ". E questo funziona bene per noi. In questo modo, la modifica al file delle impostazioni di Eclipse non influirà sul repository centrale o non verrà commesso.

1

vorrei mantenere entrambe le versioni del progetto (come project.properties.windows e project.properties.linux) e creare un collegamento simbolico che punta al file giusto in base al sistema operativo. Chiama questo link simbolico project.properties e lascia che sia ignorato dal controllo di versione.

Ovviamente lo svantaggio di questa configurazione è che quando gli utenti Windows Update loro project.properties file (che indica project.properties.windows), la versione Linux deve essere aggiornato manualmente, e viceversa, ma non sembra un grosso problema, presumo che non aggiorni questo file molto spesso.

- per creare i collegamenti -

Creare un file make_link.sh per ambienti Linux di impostazione, con il seguente comando:

ln -s $(readlink -m project.properties.linux) $(readlink . -m)/project.properties 

Creare un file make_link.bat a configurare gli ambienti Windows, con il seguente comando:

mklink project.properties project.properties.windows 

È anche possibile eseguire il commit di tali script.