Короткий вопрос
Есть ли способ контролировать/гарантировать архитектуру (32 бит против 64 бит) при создании исполняемого файла pyinstaller?
Фон
Я перешел из py2exe в pyinstaller из-за отсутствия 64-битной поддержки, а также множества мелких вещей, с которыми мне трудно смотреть в прошлое. Поэтому на этой ноте я бы предпочел не возвращаться к ней. Я разработал два приложения, использующие Python 2.7 64bit, и у меня возникают проблемы с производительностью при работе на них 32-битных машинах.
Первый - это простой графический интерфейс wxPython (версия 2.9) и подключается к файлу DLL Windows для USB-драйвера. Это кажется "безопасным" для 32-разрядной версии, потому что нет модулей, которые имеют только 64-битный код. Однако это приложение при работе на 32-битной Windows XP имеет проблемы с производительностью при разговоре с USB-устройством.
Второе приложение намного больше, и я еще не пытался строить и запускать из-за страха перед проблемами архитектуры. Это приложение имеет только 64-битные модули (psycopg2 для одного), используемые в нем. Я хотел бы держаться подальше от попытки построить это, если невозможно запустить как 32-битный исполняемый файл.
Текущие мысли
Я считаю, что это возможно (если модули поддерживают 32 бит), запустив build.py с Python, принудительно в 32-битном режиме. Есть ли в этом смысл?
Обновление
У меня было несколько прорывов по первой программе, которую я строил. Оказывается, проблемы с производительностью основывались исключительно на скорости двух машин. Моя машина Dev имела достаточно мощности, чтобы опробовать USB-устройство достаточно быстро, а на гораздо более медленной тестовой платформе (Windows XP) этого не произошло.
Я исправил эту проблему, изменив способ опроса USB-порта. Теперь, когда это было исправлено, я мог запустить exe на обеих системах. При попытке создать исполняемый файл в виде одного файла возникла новая проблема. При запуске pyinstaller Build.py он загружает всю требуемую DLL, которую приложение должно запускать. Сначала это выглядело отлично, но когда я попытался запустить одиночный exe, который я построил на Windows 7 64bit, он не будет работать в Windows XP, потому что DLL-ключ USB-порта не был признан допустимой DLL.
Чтобы запустить один exe для работы в обеих системах, я сначала попытался удалить DLL из файла .spec(который выглядит как python script). Это было удобно, потому что я смог изменить список включений до команды сборки с помощью обычных модификаторов списка python. Я надеюсь, что если DLL не была найдена в каталоге exe temp, она найдет ее в системе PATH. Хотя этот подход может работать, я не мог заставить его работать без большого количества ошибок.
Моя вторая попытка состояла в том, чтобы создать приложение на компьютере под управлением Windows XP (оставив встроенную DLL) в надежде, что Windows XP будет работать в Windows 7. Успех! Эта конфигурация работает хорошо; однако я уверен, что это не лучшее решение, поскольку оно зависит исключительно от старой DLL, работающей на более новой ОС.
