Che cosa fa esattamente l'argomento `-arch` sulla riga di comando` candle`?

Question

Sto configurando versioni a 32 e 64 bit in WiX versione 3.7. La documentazione di WiX è difettosa nel spiegarlo adeguatamente. Nello documentation for Package/@Platform, si dice "L'uso di questo attributo è sconsigliato, invece, specificare l'opzione -arch alla riga di comando candle.exe", ma non c'è alcuna spiegazione di ciò che effettivamente fa questo argomento (almeno nessuno che io possa individuare). Lo "documentation" for the compiler merita completamente le virgolette d'aria intorno alla parola "documentazione", in quanto è fondamentalmente uno stub (a differenza dello linker documentation, ad esempio). Per il record storico, ecco la documentazione completa del compilatore:

Il compilatore XML di Windows Installer è esposto da candle.exe. La candela è responsabile della preelaborazione dei file .wxs di input in documenti XML ben formati contro lo schema WiX, wix.xsd. Quindi, ogni file sorgente post-elaborato viene compilato in un file .wixobj.

Il processo di compilazione è relativamente semplice. Lo schema WiX si presta a un semplice parser di discesa ricorsivo. Il compilatore elabora ogni elemento a sua volta creando nuovi simboli, calcolando i riferimenti necessari e generando i dati non elaborati per il file .wixobj.

L'aiuto della riga di comando offre un po ', ma non abbastanza.

-arch  set architecture defaults for package, components, etc. 
      values: x86, x64, or ia64 (default: x86) 

In una questione connessa, Platform identification in WiX 3.0, c'è one answer with a sliver of hint su ciò che potrebbe essere in corso, ma non è certo sufficiente, e non so se è preciso.

• Condivide la tesi -arch hanno lo stesso effetto di impostare l'attributo Package/@Platform, o lo fa fare di più?
• L'argomento influisce su qualsiasi elemento disponibile nello preprocessor? In particolare, imposta la variabile del preprocessore PLATFORM? Imposta qualcos'altro?
• Che cos'è un'architettura "predefinita"? Un attributo esplicito Package/@Platform sostituisce la riga di comando? O vice versa? O (meglio ancora) c'è un errore se c'è una dichiarazione di piattaforma incoerente?

Alcune di queste domande hanno risposte che sembrano dover essere ovvie, e infatti ho imparato qualcosa semplicemente scrivendo la domanda. Ma mi piacerebbe una risposta definitiva, preferibilmente (suggerimento) un link a una pagina di documentazione aggiornata e accurata per la riga di comando candle. Mi aspetto di averlo risolto nel momento in cui qualcuno risponde, tuttavia, risparmierò presto ad altre persone il tempo che avrò speso per capirlo.

---

Un'altra domanda correlata, WIX: is the Platform attribute of the Package element truly deprecated?, parla dell'attributo Package/@Platform, ma non indirizza l'argomento della riga di comando.

---

Informazioni su quella variabile del preprocessore PLATFORM. Ora è apparentemente BUILDARCH, anche se è difficile comprenderlo dalla documentazione.

warning CNDL1034 : The built-in preprocessor variable '$(sys.PLATFORM)' is 
deprecated. Please correct your authoring to use the new '$(sys.BUILDARCH)' 
preprocessor variable instead. 

Answer 1

risposte parziali:

• L'argomento -arch non impostare la variabile sys.BUILDARCH, così come il sys.PLATFORM uno.
• L'argomento -arch ignora in modo silente l'attributo Package/@Platform. Almeno sembra, se è sufficiente guardare sys.BUILDARCH.
  • Così l'aiuto della riga di comando è sbagliato. È un override, non un valore predefinito.

Answer 2

I seguenti frammenti di codice di abilitazione fase di compilazione di configurazione tra versioni a 32 bit ed a 64 bit senza introdurre una variabile utente rappresenta la piattaforma ma mediante quello fornito dal sistema. Entrambe le variabili definite sono generiche rispetto alle installazioni ordinarie. La versione minima è più alta per i sistemi a 64 bit. La directory dei file di programma di base differisce tra le versioni a 32 e 64 bit.

<?if $(sys.BUILDARCH)="x86"?> 
    <?define Minimum_Version="100"?> 
    <?define Program_Files="ProgramFilesFolder"?> 
<?elseif $(sys.BUILDARCH)="x64"?> 
    <?define Minimum_Version="200"?> 
    <?define Program_Files="ProgramFiles64Folder"?> 
<?else?> 
    <?error Unsupported value of sys.BUILDARCH=$(sys.BUILDARCH)?> 
<?endif?> 

---

Utilizzare queste definizioni nel corso della fonte WiX.

<Package [...] 
    InstallerVersion="$(var.Minimum_Version)" 
/> 

<Directory Id="$(var.Program_Files)"> 
    [...] 
</Directory> 

Answer 3

Oltre a definire l'architettura del MSI (Pacchetto/@ Platform) si imposta un valore di tabella componente predefinito per l'attributo msidbComponentAttributes64bit nel MSI (Win64 in WiX).

IE. se sys.BUILDARCH = x86 allora è non impostato, se x64 allora è impostato su (+256). Questo è non menzionato nel WIX.chm che appena ri-itera il Msi.chm circa l'attributo sopra

Impostare questo attributo per 'sì' per contrassegnare questo come un componente a 64 bit. Questo attributo facilita l'installazione dei pacchetti che includono sia componenti a 32 bit che a 64 bit. Se questo bit non è impostato , il componente è registrato come componente a 32 bit. ** Se questo è un componente a 64 bit che sostituisce un componente a 32 bit, impostare questo bit e assegnare un nuovo GUID nell'attributo Guid .

(Quindi non dice): Quando si utilizza BuildArch si solo bisogno all'autore attributo Win64 WiX quando si desidera sovrascrivere le impostazioni predefinite, utili per la costruzione di diversi MSI arco dallo stesso codice di WiX. In precedenza utilizzavo una variabile di ambiente per un attributo Win64 su ogni componente.