Co dokładnie robi argument "-arch" na linii komend `candle`?

Question

Konfiguruję kompilacje 32- i 64-bitowe w wersji 3.7 WiX. Dokumentacja WiX jest wadliwa w odpowiednim wyjaśnieniu tego. W dokumencie documentation for Package/@Platform jest napisane: "Odradzam używanie tego atrybutu, zamiast tego określ przełącznik -arch przy linii poleceń candle.exe", ale nie ma wyjaśnienia, co właściwie robi ten argument (a przynajmniej nie mogę go znaleźć). The "documentation" for the compiler całkowicie zasługuje na notowania lotnicze wokół słowa "dokumentacja", ponieważ jest to po prostu skrót (na przykład w przypadku linker documentation). W odniesieniu do historycznych rekordów, oto w całości dokumentacja kompilatora:

Kompilator XML Instalatora Windows jest ujawniony przez candle.exe. Świeca jest odpowiedzialna za wstępne przetwarzanie wejściowych plików .wxs do poprawnych dobrze uformowanych dokumentów XML w stosunku do schematu WiX, wix.xsd. Następnie każdy przetworzony plik źródłowy jest kompilowany do pliku .wixobj.

Proces kompilacji jest stosunkowo prosty. Schemat WiX nadaje się do prostego parsera rekursywnego zejścia. Kompilator przetwarza każdy element z kolei, tworząc nowe symbole, obliczając niezbędne odniesienia i generując nieprzetworzone dane dla pliku .wixobj.

Pomoc wiersza poleceń oferuje nieco, ale za mało.

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

W podobnym pytaniem Platform identification in WiX 3.0, tam one answer with a sliver of hint o tym, co może się dziać, ale to ledwie wystarczające, a ja nie wiem, czy to jest poprawne.

• Czy -arch argumentem mają taki sam efekt jak ustawienie atrybutu Package/@Platform, czy też zrobić więcej?
• Czy argument ma wpływ na wszystko, co dostępne w preprocessor? W szczególności, czy ustawia on zmienną preprocesora PLATFORM? Czy ustawi coś jeszcze?
• Co to jest architektura "domyślna"? Czy wyraźny atrybut Package/@Platform przesłania wiersz polecenia? Lub odwrotnie? Lub (jeszcze lepiej) czy wystąpił błąd w przypadku niespójnej deklaracji platformy?

Niektóre z tych pytań mają odpowiedzi, które wydają się być oczywiste, i rzeczywiście nauczyłem się czegoś po prostu pisania tego pytania. Ale chciałbym uzyskać ostateczną odpowiedź, najlepiej (podpowiedź) link do zaktualizowanej i dokładnej strony dokumentacji dla linii poleceń candle. Spodziewam się, że rozwiązałem to do czasu, gdy ktokolwiek odpowie, ale tak samo szybko ocaliłbym innych ludzi, których czasu poświęcę na zastanowienie się nad tym.

---

Inne powiązane pytanie, WIX: is the Platform attribute of the Package element truly deprecated?, mówi o atrybucie Package/@Platform, ale nie odnosi się do argumentu wiersza poleceń.

---

O tej PLATFORM zmiennej preprocesora. Teraz jest widocznie BUILDARCH, choć trudno byłoby o tym wiedzieć z dokumentacji.

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

częściowe odpowiedzi:

• -arch argumentem jest ustawić zmienną sys.BUILDARCH, jak również jeden sys.PLATFORM.
• Argument -arch po cichu przesłania atrybut Package/@Platform. Przynajmniej wydaje się, że wystarczy spojrzeć na sys.BUILDARCH.
  • W ten sposób pomoc wiersza poleceń jest niepoprawna. To przesłonięcie, a nie domyślne.

Answer 2

Następujące fragmenty umożliwiają w czasie kompilacji konfigurację pomiędzy 32-bitowym i 64-bitowej, bez wprowadzania zmiennej użytkownika reprezentujący platformy, lecz stosując dostarczoną przez system. Obie zdefiniowane zmienne są ogólne dla zwykłych instalacji. Minimalna wersja jest wyższa dla systemów 64-bitowych. Podstawowy katalog plików programowych różni się między wersjami 32- i 64-bitowymi.

<?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?> 

---

Poniższe definicje później w źródle WiX.

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

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

Answer 3

Oprócz definiowania architektury (pakiet MSI/@ Platform) to ustawia wartość domyślną tabelę komponent atrybutu msidbComponentAttributes64bit w MSI (Win64 w WiX).

IE. jeśli sys.BUILDARCH = x86 to jest nie zestaw, jeśli x64 to jest jest zestaw (+256). To nie wymienione w WIX.chm który po prostu ponownie iteracje z Msi.chm o powyższym atrybutu

ustawić ten atrybut na „tak”, aby oznaczyć to jako 64-bitowe komponentu. Ten atrybut ułatwia instalację pakietów , które zawierają składniki zarówno 32-bitowe, jak i 64-bitowe. Jeśli ten bit nie jest ustawiony, , składnik jest rejestrowany jako składnik 32-bitowy. ** Jeśli jest to 64-bitowy komponent zastępujący komponent 32-bitowy, ustaw ten bit i przypisz nowy identyfikator GUID do atrybutu Guid .

(Więc nie powiedzieć): W przypadku korzystania BUILDARCH tylko trzeba autorowi Win64 WiX atrybutu, jeśli chcesz nadpisać domyślne, pomocne przy budowaniu inny arch MSis z tego samego kodu WiX. Poprzednio używałem zmiennej środowiskowej dla atrybutu Win64 na co komponent.