2010-12-11 9 views
7

Correlato a using cmake to link object files into lib.xxxx.a file, ma non esattamente la stessa cosa, ho creato diverse librerie statiche su Windows utilizzando CMake 2.8.x utilizzando VS2008 SP1 . C'è un modo solo tramite CMake di ricollegare tutti i file .obj all'interno di tutte quelle librerie statiche esistenti in una libreria monolitica più grande, preferibilmente tramite la funzione CMake add_library o un altro costrutto simile?Collegamento di più file .lib statici in un file .lib monolitico utilizzando VS2008 SP1 utilizzando CMake 2.8.x

Penso che la risposta è "no", e così ho pensato di rotazione mia tramite un comando personalizzato tramite il consueto approccio add_custom_command + add_custom_target, che costruisce semplicemente la libreria manualmente, fornendo tutte le altre librerie obj file quando si chiama LINK.EXE. Ma vedo qualche problema con questo approccio:

  1. non riuscivo a trovare una variabile CMake che indica il percorso completo al LINK.EXE eseguibile. Dovrei quindi derivare in qualche modo il percorso a LINK.EXE utilizzando un euristico fragile: è fragile nel senso che diverse versioni di Visual Studio possono individuare il file LINK.EXE in diverse directory, e ho bisogno che questo funzioni sia per 32-bit sia per Condizioni del compilatore di Windows a 64 bit e resilienza agli aggiornamenti tra VS2008 e future revisioni del compilatore.
  2. avrei dovuto trovare un modo per trovare tutti i file obj delle altre librerie statiche, al momento della compilazione rispetto al momento CMake, dato che al momento CMake i file obj naturalmente non lo fanno (sempre) esiste. Per motivi di prestazioni di creazione, desidero non ricorrere all'estrazione dei file obj dai file .lib per aggiungerli alla riga di comando LINK.EXE, quindi un costrutto FILE(GLOB...) sarebbe la mia seconda migliore alternativa in questo caso.
  3. Potrebbe essere possibile chiamare semplicemente LINK.EXE via: LINK.EXE /OUT:monolithic.lib lib1.lib lib2.lib ..., ma forse non tutti obj di sarà incluso (EDIT: mi hanno confermato che LINK.EXE omette alcuni file obj da lib1.lib lib2.lib ... senza messaggi di diagnostica spiegare perché, per cui questo approccio è un non-starter); i documenti online per LINK.EXE non sono chiari a quel punto. Qualcuno ha qualche esperienza con l'utilizzo di LINK.EXE in questo modo?

Grazie,

Brent

P.S., so come creare una DLL utilizzando CMake, ma io in particolare non voglio ricorrere alla costruzione di una DLL a questo punto nel tempo.

risposta

10

Creare una libreria statica "unita" con un file di origine fittizio e aggiungere librerie da unire a STATIC_LIBRARY_FLAGS, in modo che siano input aggiuntivi per lib.exe.

Questo sarebbe qualcosa di simile:

ADD_LIBRARY (fusa dummy.c STATICO)

SET_TARGET_PROPERTIES (PROPERTIES fuse
STATIC_LIBRARY_FLAGS "\ Percorso completo \ a \ lib1.lib piena \ percorso \ a \ lib2 .lib ")

Questo approccio è utilizzato all'interno di MySQL; qui è disponibile una macro più generale per unire le librerie statiche che funzionano su piattaforme incrociate. Può essere trovato qui http://www.mail-archive.com/[email protected]/msg28670/libutils.cmake

+0

MERGE_STATIC_LIBS macro definita in http://www.mail-archive.com/[email protected]/msg28670/libutils.Il link cmake è molto vicino a quello che avrei implementato. Un avvertimento: quel collegamento punta a un file che è specifico per mysql, quindi dovrebbe essere generalizzato perché sia ​​praticabile nella pratica. – bgoodr

+0

Il file libutils.cmake in effetti non funziona autonomamente, poiché fa riferimento a configurabile merge_archives_unix.cmake.in Questo file è disponibile all'indirizzo http://www.mail-archive.com/[email protected]/msg28670/merge_archives_unix.cmake. in –

Problemi correlati