2012-08-15 11 views
11

Ho cercato di compilare Qt su Windows e ho riscontrato un problema interessante con #include in mancanza dell'errore che il file da includere non esiste ("Nessun file di questo tipo o directory "). Tuttavia il file esiste. I file che fanno il inclusi sono file generati automaticamente "moc" (realizzati da Qt) che hanno un include come la seguente:Visual Studio C++ include lunghezza massima della stringa

#include "../../../../../../../../qt-everywhere-opensource-src-4.8.2/examples/tools/plugandpaintplugins/extrafilters/extrafiltersplugin.h"

la stringa che includono una lunghezza di 127 caratteri. Ci sono molti file "moc" prodotti e compilati nella build, ma solo quelli con lunghezze molto lunghe come questa (127+ caratteri) falliscono.

I file in questione si trovano su un sistema UNIX, condivisi tramite Samba su Windows. Sono stato in grado di risolvere il problema creando un collegamento simbolico e sostituendo "qt-everywhere-opensource-src-4.8.2" con "qt-4.8.2" nei file interessati. Il derivano sono:

#include "../../../../../../../../qt-4.8.2/examples/tools/plugandpaintplugins/extrafilters/extrafiltersplugin.h"

è lunga solo 102 caratteri e funziona bene.

Ho cercato in giro e non ho trovato alcun riferimento a questo. Né potrei replicare il problema al di fuori di questa build Qt (semplicemente facendo nomi di file arbitrariamente lunghi e cercando di includerli). Quindi è possibile che in qualche modo i makefile nmake creati da Qt stiano facendo qualcosa quando eseguono cl che lo fa rifiutare in un modo lungo gli include.

Qualcuno ha ulteriori informazioni su questo?

+0

qual è la lunghezza del percorso assoluto in entrambi i casi? cioè quando si risolvono i vari ../../. C'è un limite di percorso massimo di 256 caratteri sulla maggior parte dei vecchi sistemi Windows. – TemplateRex

+0

Il percorso completo per questo esempio è di 132 e 106 caratteri, rispettivamente. Ma il sistema operativo non ha problemi ad aprire il file (ad esempio, nel blocco note o nella shell cmd). btw, Ho dimenticato di menzionare che sto usando MSVS 2008. –

+0

Ho usato una montatura Samba quando non sono riuscito a replicare il problema. Sulla base di alcuni altri commenti che ho trovato online ho pensato che potrebbe essere la lunghezza della directory e non la lunghezza del file, quindi ho creato alcune directory finte davvero lunghe, ma ancora nessun problema. Ma poi ho provato a mettere il file sorgente nella lunga directory e includendo ../../really-long-dir/7890123...890/a.h e ho ricevuto l'errore. Ciò accade fino a circa 131 caratteri. Ma posso avere lunghezze di percorso totali più lunghe con meno ".." nel percorso. Molto strano. Mi chiedo se questo è un bug nel preprocessore. –

risposta

1

Poiché questo viene utilizzato per trovare il file incluso, tendo a credere che sia collegato alle restrizioni del percorso del file system.

Forse l'implementazione del preprocessore in qualche modo lo limita, ma sarebbe specifico per ogni compilatore.

0

In uno dei miei luoghi di lavoro in passato, abbiamo avuto un altro problema simile. Il progetto era molto grande e conteneva così tanti file che il comando del compilatore generato da Visual Studio durante la creazione del progetto era così lungo da superare il limite e la compilazione non riusciva. Questo, tuttavia, stava accadendo su Visual Studio 2008, non so di quelli più recenti.

So che non è correlato, ma questa è solo un'informazione aggiuntiva. Potrebbe aiutare qualcuno.

0

Potrebbe esserci una limitazione impostata dal framework .NET ma non ha ancora trovato la linea esatta su questo.

Ecco alcuni link interessanti su questo: su social msdn e blog msdn.

0

Ho riscontrato lo stesso problema durante la creazione di progetti con GCC su Windows. La questione sembra riguardare il modo in cui è montato il Sentiero,

../../../../../../../../qt-everywhere-opensource-src-4.8.2/examples/tools/plugandpaintplugins/extrafilters/extrafiltersplugin.h

diventa

c:/some/working/structure/that_is/at_least/as_deep/as_the_up/levels/are/../../../../../../../../qt-everywhere-opensource-src-4.8.2/examples/tools/plugandpaintplugins/extrafilters/extrafiltersplugin.h

(ad esempio, non può essere in scala, Non ho contato i personaggi. ..)
A questo punto la gestione del percorso si interrompe a causa dell'eccessiva durata.Nel nostro caso, costringendo al compilatore di utilizzare una versione contratta,

c:/some/qt-everywhere-opensource-src-4.8.2/examples/tools/plugandpaintplugins/extrafilters/extrafiltersplugin.h

renderebbe il problema andare via.
MSDN contiene alcuni suggerimenti del problema in http://msdn.microsoft.com/en-us/library/windows/desktop/aa364963(v=vs.85).aspx
Si noti che l'alternativa, il supporto più lungo, formato di percorso, \? \, Non sembra supportare percorsi relativi.

Correzione rapida: non utilizzare percorsi relativi di tale profondità.

0

Dovresti solo aggiungere il percorso che stai reindirizzando alle opzioni del compilatore, piuttosto che usare qualcosa di così orribile.

+0

Sia il makefile che gli include in questione vengono generati automaticamente dal sistema di generazione Qt. Ho un controllo limitato su di loro. Fortunatamente, questa è una build una tantum, non qualcosa che faccio ogni giorno. –

0

Selezionare la scheda "Progetto" e deselezionare "Creazione ombra" ha risolto il mio problema.

0

mi sono imbattuto in esattamente lo stesso problema di recente, quando si costruisce qt su Windows utilizzando msys & mingw. Il sistema di compilazione non è stato in grado di trovare il file di intestazione incluso nel seguente percorso relativo:

"../../../../../../../qt-everywhere-opensource-src- 5.0.1/qtbase/src/platformsupport/fontdatabases/basic/qbasicfontdatabase_p.h"

Ma era presente il file e il percorso era corretto pure.

Ho creato una struttura di file simile all'esterno dell'albero dei sorgenti qt ed è stato in grado di riprodurre il problema utilizzando g ++ dalla riga di comando.

Ho armeggiato un po ', riducendo il numero di caratteri di un file uno alla volta. Cinque personaggi in meno e gli errori svaniti. g ++ ha trovato improvvisamente il file.

Ha funzionato quando caratteri totali nella dichiarazione di inclusione erano pari a . Questa è solo una cifra quantitativa per dare un'idea approssimativa di quale potrebbe essere il limite sotto il cofano. Potrebbe essere diverso per diverse versioni del compilatore. Non penso che il SO abbia alcuna parte nel determinarlo. Questo collo di bottiglia sembra più dovuto al pre-processore.

Problemi correlati