Рекомендации по упаковке для кросс-компиляторов MinGW

Миссия проекта Fedora MinGW — предоставить превосходную среду разработки для пользователей Fedora, желающих кросс-компилировать свои программы для запуска в Windows, минимизируя необходимость использования Windows вообще. В прошлом разработчикам приходилось портировать и компилировать все библиотеки и инструменты, которые им были нужны, и эта огромная работа выполнялась независимо много раз. Мы стремимся устранить дублирование работы для разработчиков приложений, предоставляя набор библиотек и инструментов разработки, которые уже были портированы в среду кросс-компилятора MinGW. Это означает, что разработчикам не нужно будет перекомпилировать стек приложений самостоятельно, а можно сосредоточиться только на изменениях, необходимых для их собственного приложения.

Цели Win32 и Win64 поддерживаются со средой выполнения MSVCRT. Цель Win64 со средой выполнения UCRT также поддерживается, однако только для базового инструментария. Сборки для UCRT не включены для пакетов выше инструментария на данный момент.

Существует два разрешённых способа предоставления сборок MinGW программного обеспечения в Fedora:

Традиционный подход полностью разделённых исходных пакетов был принят изначально из-за опасений, что нестабильность в инструментарии MinGW или сборках Windows может помешать своевременным обновлениям нативного пакета. Опыт в Fedora с тех пор показал, что это, как правило, не проблема, влияющая на большинство пакетов, особенно там, где поддержка Windows является явно тестируемым результатом проекта upstream.

Использование подхода с отдельной упаковкой имеет значительно более высокие накладные расходы:

При подходе с интегрированной упаковкой существует небольшая дополнительная нагрузка на мейнтейнера нативного пакета для обеспечения работоспособности сборок MinGW и небольшая дополнительная нагрузка в виде специфичных для MinGW отчётов об ошибках. Это обычно незначительно по сравнению с накладными расходами на поддержку разделённых пакетов.

С учётом этого рекомендация рабочей группы MinGW SIG такова:

Когда соответствующий нативный пакет ещё не существует, всегда потребуется пройти стандартный процесс проверки новых пакетов Fedora. Предлагаемая поддержка MinGW ДОЛЖНА следовать интегрированному подходу к упаковке, чтобы обеспечить как сборки MinGW, так и нативные, где это технически возможно. Как отмечено в предыдущем разделе, в некоторых редких ситуациях не будет соответствующего нативного пакета, что потребует использования отдельного подхода к упаковке.

Когда соответствующий нативный пакет уже присутствует в Fedora, предпочтительно добавить поддержку MinGW к нативному исходному пакету.

Когда изменения исходного пакета просты, контрибьютор СЛЕДУЕТ:

Таким образом, существующий мейнтейнер нативного пакета получает чёткое представление о влиянии дополнений MinGW на свой пакет, чтобы оценить жизнеспособность следования интегрированному подходу к упаковке.

Если есть сомнения в жизнеспособности следования интегрированному подходу к упаковке, МОЖЕТ быть открыт баг к пакету до начала работы, чтобы обсудить два варианта упаковки с мейнтейнером нативного пакета.

Если нативный мейнтейнер отклоняет предложение добавить поддержку MinGW к существующему пакету, ДОЛЖЕН быть соблюдён обычный процесс Fedora для новых пакетов, чтобы ввести поддержку MinGW в соответствии с отдельным подходом к упаковке.

В общих чертах, кросс-компилированные версии MinGW пакетов, которые уже доступны нативно в Fedora, должны следовать нативному пакету Fedora как можно точнее. Это означает, что они должны оставаться на той же версии, включать все те же патчи, что и нативный пакет Fedora, и собираться с теми же параметрами конфигурации.

Предпочтительным способом достижения этой цели является использование поддержкой MinGW интегрированного подхода к упаковке.

Кросс-компилированные пакеты MinGW должны следовать политике Fedora, за исключением случаев, отмеченных в этом документе. Кросс-компилированные пакеты проходят тот же процесс проверки, процесс администрирования GIT и т. д., что и другие пакеты Fedora.

Пакеты MinGW требуют специального именования для обозначения соответствующей архитектуры ЦП, для которой были собраны двоичные файлы. Во время сборки никогда не должно быть пакета с префиксом mingw-. Префикс mingw- используется исключительно для имён RPM spec-файлов и имени файла исходного RPM. Пакеты, специфичные для архитектуры ЦП, создаются разделами с %files -n mingw32-foo, %files -n mingw64-foo или %files -n ucrt64-foo.

Базовые пакеты предоставляют корневую файловую систему, базовые библиотеки, binutils (базовые программы, такие как 'strip', 'ld' и т. д.), компилятор (gcc) и API Win32/Win64. Пакеты могут зависеть от одного или нескольких из них. В частности, почти все пакеты должны иметь BuildRequire mingw32-filesystem, mingw64-filesystem, mingw32-gcc и mingw64-gcc.

Цель фреймворка MinGW — предоставить простой способ для мейнтейнеров пакетов собирать свои пакеты для нескольких целей, используя один .spec-файл. Чтобы помочь разработчикам в этом, было разработано несколько RPM-макросов, которые являются частью пакета mingw-filesystem. Эти RPM-макросы будут объяснены далее в этих рекомендациях.

По умолчанию поддержка MinGW будет собрана как для целей Win32, так и Win64 со средой выполнения MSVCRT. Сборка цели Win64 со средой выполнения UCRT64 пока не включена по умолчанию.

Когда пакет может быть собран только для подмножества этих целей, это можно указать, задав один или несколько из следующих параметров:

Каждый кросс-компилированный пакет MinGW, который собирает двоичные файлы для конкретной цели, должен помещать двоичные файлы для этой цели в отдельный подпакет. Так если пакет mingw-foo или foo собирает двоичные файлы для целей Win32 и Win64 со средой выполнения MSVCRT, то исходный RPM должен предоставлять два подпакета с именами mingw32-foo и mingw64-foo. Если пакет собирается для среды выполнения UCRT, он также будет иметь подпакет ucrt64-foo.

Это означает, что spec-файл должен содержать разделы %package и %files для всех целей.

При использовании отдельного подхода к упаковке пакеты, содержащие переводы, должны использовать %mingw_find_lang вместо %find_lang.

При использовании интегрированного подхода к упаковке пакеты, содержащие переводы, должны использовать %find_lang`, за которым следует `%mingw_find_lang+.

Это приводит к тому, что все списки файлов переводов разделяются на списки файлов для каждой цели. Например: когда spec-файл содержит что-то вроде этого:

то будет создан один файл на каждую цель mingw с именами mingw32-foo.lang, mingw64-foo.lang и ucrt64-foo.lang. Эти списки файлов можно включить в раздел %files для соответствующих целей:

Интеграция в основную структуру корневой файловой системы следующая:

Основная часть упакованного содержимого находится под соответствующим корнем MinGW, одним из /usr/i686-w64-mingw32, /usr/x86_64-w64-mingw32 и /usr/x86_64-w64-mingw32ucrt:

Кросс-компиляторы и binutils MinGW являются двоичными файлами Fedora и поэтому размещаются в %{_bindir} (то есть /usr/bin) согласно FHS и рекомендациям Fedora.

Кросс-компиляторы и binutils MinGW, которые генерируют двоичные файлы i686 для Windows со средой выполнения MSVCRT, называются:

Те же самые двоичные файлы присутствуют в %{_prefix}/i686-w64-mingw32/bin без какого-либо префикса в имени, то есть:

То же самое относится и к цели x86_64 с обеими средами выполнения MSVCRT и UCRT. Цель с MSVCRT использует 'x86_64-w64-mingw32' в качестве префикса вместо 'i686-w64-mingw32', тогда как UCRT использует 'x86_64-w64-mingw32ucrt'.

Корневая файловая система содержит исполняемые файлы Windows и DLL, а также любые другие файлы, предназначенные только для Windows. Она необходима как потому, что нам нужно хранить библиотеки Windows для компоновки дальнейших библиотек, которые от них зависят, так и потому, что MinGW требует расположения корневой файловой системы.

Расположение для цели Win32 со средой выполнения MSVCRT предоставляется макросом:

Цель Win64 со средой выполнения MSVCRT предоставляется макросом:

Цель Win64 со средой выполнения UCRT предоставляется макросом:

Пакет mingw-filesystem предоставляет ряд удобных макросов для кросс-компилированных каталогов sysroot и инструментария. Обязательно использовать эти макросы во всех кросс-компилированных пакетах MinGW, отправляемых в Fedora.

Чтобы собрать двоичные файлы для нескольких целей, нам приходится вызывать команды, такие как ./configure и make, несколько раз (по одному разу для каждой цели). Если приходится всё это прописывать в spec-файле, это приводит к дублированию кода. Чтобы уменьшить объём дублирования, было введено несколько RPM-макросов для помощи в компиляции. Эти макросы — %mingw_configure, %mingw_cmake, %mingw_cmake_kde4, %mingw_qmake_qt4, %mingw_qmake_qt5 и %mingw_make

Эти макросы используют компиляцию вне источника для сборки двоичных файлов для всех целей. Почти все пакеты поддерживают компиляцию вне источника или требуют небольшого патча. Единственные известные на сегодняшний день исключения — zlib и openssl. Пакеты, которые не поддерживают компиляцию вне источника, могут требовать иного подхода, например выполнения всего в фазе %install. Если вам случайно попадётся пакет, требующий иного подхода, не стесняйтесь связаться с нами в списке рассылки Fedora MinGW

Некоторые пакеты нужно собирать несколько раз для каждой цели. Примерами этого являются пакеты, которые нужно собрать один раз для статической версии и один раз для разделяемой версии. Такие пакеты могут добавить собственный суффикс к используемому каталогу сборки. Допустим, у вас есть что-то вроде приведённого ниже:

Это можно переписать примерно так:

Большинство пакетов использовали команду make %{?_smp_mflags} для сборки пакета. В фреймворке кросс-компилятора MinGW вы должны использовать %mingw_make %{?_smp_mflags} для сборки пакета для всех настроенных целей. Как и с макросом %mingw_configure, вы также можете использовать переменную окружения MINGW_BUILDDIR_SUFFIX, чтобы указать собственный суффикс для используемого каталога сборки

Для установки пакета команда make install DESTDIR=$RPM_BUILD_ROOT использовалась почти во всех случаях. Это можно переписать как %mingw_make install DESTDIR=$RPM_BUILD_ROOT, чтобы установить пакет для всех настроенных целей. Переменную окружения MINGW_BUILDDIR_SUFFIX также можно использовать здесь.

Некоторые пакеты требуют некоторых пользовательских инструкций, прежде чем файлы будут готовы к упаковке. Такой код может остаться как есть. Однако вам может потребоваться дублировать эти инструкции несколько раз (для всех настроенных целей).

Если пакет содержит двоичные файлы, которые зависят от DLL, предоставляемой другим пакетом, эти зависимости должны быть выражены в форме:

где foo.dll — имя DLL. Имя должно быть преобразовано в нижний регистр, потому что двоичные файлы Windows содержат зависимости без учёта регистра. Форма 'mingw32(foo.dll)' должна использоваться для двоичных файлов Win32, а форма 'mingw64(foo.dll)' — для двоичных файлов Win64.

Правильная генерация зависимостей выполняется автоматически. Упаковщикам следует начинать свои spec-файлы с этой строки:

Все бинарные пакеты должны зависеть от mingw32-filesystem или mingw64-filesystem (в зависимости от файлов в пакете).

Все spec-файлы должны иметь BuildRequire как минимум одного из этих (в зависимости от целей, для которых вы хотите собирать):

и любые другие BuildRequires, которые им нужны.

Можно предположить, что большинство RPM-макросов mingw существуют во всех не-EOL выпусках Fedora. Однако если пакет полагается на недавно введённый макрос, следует использовать версионную зависимость от пакетов mingw-XX-filesystem.

Все пакеты должны иметь:

если только они не содержат нативных исполняемых файлов Fedora. При использовании отдельного подхода к упаковке тег BuildArch должен присутствовать в общем заголовке spec-файла. При использовании интегрированного подхода к упаковке тег BuildArch должен присутствовать в заголовке %package для каждого присутствующего под-RPM MinGW.

Все библиотеки должны быть собраны как DLL.

Из-за особенности Windows DLL хранятся в каталоге %{mingw32_bindir} вместе с управляющим файлом в каталоге %{mingw32_libdir}. Например, для библиотеки с именем foo там будет:

Файл foo.dll — это основная библиотека, foo.dll.a — это заглушка, скомпонованная с приложениями, чтобы они могли найти библиотеку во время выполнения. Все эти файлы требуются в этих расположениях для успешной компоновки. .dll может содержать номер версии, хотя и не всегда (например, foo-0.dll).

Пакеты MinGW предназначены для того, чтобы позволить разработчикам компилировать и тестировать поддержку Windows своих приложений. Кроме того, ожидается, что разработчики будут создавать установщики Windows (MSI) для своих приложений, используя содержимое пакета MinGW.

Таким образом, список файлов пакета Fedora MinGW должен включать содержимое, необходимое для удовлетворения либо использования при сборке/тестировании, либо создания установщиков Windows.

В целом возможно преобразование в любом направлении между отдельным и интегрированным подходами к упаковке. Оба подхода дают абсолютно одинаковые бинарные RPM для содержимого MinGW, отличаясь только исходным RPM spec-файлом.

Чтобы преобразовать из отдельной в интегрированную упаковку

Чтобы преобразовать из интегрированной в отдельную упаковку

В обоих случаях опыт обновления должен быть прозрачным для пользователей, устанавливающих и обновляющих развёртывания Fedora.

Рекомендуется выполнять такие преобразования только в Rawhide. Если возникает необходимость выполнить преобразование из интегрированной в отдельную упаковку в стабильном потоке выпуска, одно обновление Bohdi должно включать как нативную, так и сборки пакетов mingw.

При использовании интегрированного подхода к упаковке ДОЛЖНА быть возможность отключить сборку под-RPM MinGW, и сборка ДОЛЖНА быть отключена по умолчанию, за исключением цели дистрибутива Fedora. Это гарантирует, что нативный пакет всё ещё можно собрать в производных дистрибутивах, таких как RHEL, где инструментарии MinGW не включены. Это достигается включением условного оператора в начале spec-файла:

а затем обернуть все связанные с MinGW определения %package / %files` и соответствующие команды `%build+ или %install в условную проверку:

Spec-файл отдельного пакета по существу извлекает всё содержимое внутри условий %{with mingw} из предыдущего примера и помещает его в автономный spec-файл.