2012-11-01 11 views
7

Ho un progetto con alcune cartelle che contengono i file di origine con gli stessi nomi.Qmake: evitare conflitti di nomi di file in diverse cartelle senza introdurre librerie

Il mio albero fonte assomiglia a questo:

project.pro 

foo/ 
    conflict.h 
    conflict.cpp 

bar/ 
    conflict.h 
    conflict.cpp 

some.h 
other.h 
files.h 
main.cpp 

Per impostazione predefinita, qmake genera un Makefile che produrrà un albero di build come questa:

conflict.o 
main.o 
target 

Dove conflict.o è il file oggetto risultante per entrambi foo/conflict.cpp e foo/conflict.h.

Non riesco a cambiare i loro nomi perché vengono generati utilizzando uno strumento esterno e forzando nomi di file diversi implicherebbe di modificare il loro contenuto, quindi questa non è un'opzione.

anche io non voglio usare qmake SUBDIRS modello, perché questo implicherebbe che (1) ogni sottodirectory è costruito separatamente come una biblioteca, e quindi molto complicare il processo di costruzione complessivo (ai miei occhi almeno) e (2) nella directory di livello superiore non posso avere alcun file sorgente. O mi sbaglio?

Non posso semplicemente dire a qmake di scrivere i file oggetto in directory separate all'interno della directory di build? Quindi il mio albero di compilazione sarà simile a questa:

foo/ 
    conflict.o 

bar/ 
    conflict.o 

main.o 
target 

o ci sono altre soluzioni che richiedono né per rinominare i file di origine, né l'introduzione di qualcosa di complicato come librerie statiche? Non riesco a credere che Qt non abbia risolto questo problema (ai miei occhi semplici) per anni. (Ho già risolto questo problema 4 anni fa ma potrei rinominare i file in quel progetto, mentre qui non posso.)

Se è importante: utilizzo Qt 4.8 sia su Ubuntu con G ++ che su Windows con mingw32.

+0

Non è possibile. –

+0

@NikosC. Posso avere un file pro per i file di livello superiore che collegheranno con le altre librerie + un file SUBDIRS pro di livello superiore che avrà la sottodirectory '.'? Ciò richiederebbe anche la sovrascrittura del file .pro perché questo sottodir sia diverso dal file .pro di livello superiore per l'intera app. Spero tu capisca quello che intendo. Voglio solo evitare di spostare tutti i file di livello superiore in una sottodirectory fisica. – leemes

+0

Probabilmente dovresti usare solo un file di progetto aggiuntivo per 'foo', e mantenerne uno esistente per la directory principale e' bar'. Un'altra opzione consiste nel collegare simbolicamente il nome file in conflitto: 'ln -s bar/conflict.cpp bar/conflict_bar.cpp' e quindi utilizzare il collegamento simbolico nel file di progetto. –

risposta

2

Sei legato a qmake? In caso contrario, un'alternativa potrebbe essere quella di utilizzare cmake. Ho appena verificato il vostro caso d'uso con un semplice CMakeLists.txt come

cmake_minimum_required (VERSION 2.6) 
project (conflict) 
add_executable(conflict foo/conflict.cpp bar/conflict.cpp main.cpp) 

che comprendeva anche un file di origine nella directory di livello superiore (main.cpp). Questo costruisce correttamente l'eseguibile - i file oggetto vengono creati in sottodirectory come

./CMakeFiles/conflict.dir/main.cpp.o 
./CMakeFiles/conflict.dir/bar/conflict.cpp.o 
./CMakeFiles/conflict.dir/foo/conflict.cpp.o 

cmake include anche il supporto per Qt4, per tirare automaticamente i percorsi e le librerie necessarie includere. Potrebbe essere necessario un certo sforzo per migrare da qmake a cmake, ma visti i requisiti richiesti, farei un tentativo.

+0

Il problema è che per i file di codice generati viene generato anche un file .pri che aiuta a legare tutti i file generati a un progetto reale. Ma dal momento che il generatore di codice è stato scritto da me, potrei riscriverlo per usare cmake, tuttavia, questo sarebbe ancora più complicato che usare i sottodirmi di qmake, penso. Ma questa sarebbe una buona soluzione per gli altri utenti, quindi la tua risposta si adatta bene :) – leemes

+0

Peccato;) Quindi, probabilmente il modo più semplice è in effetti utilizzare le sottodirectory, probabilmente creando librerie statiche e infine collegandole tutte insieme. –

+0

Sì. Ma voglio avere un progetto di root che non sia un progetto di sottodirectory ma dipenderà comunque dalla costruzione delle sottodirectory ... Non so come posso farlo. – leemes