English Portuguese (Brazil)
# Static subpackages are optional (as mentioned earlier)
The base packages provide a root filesystem, base libraries, binutils (basic programs like 'strip', 'ld' etc), the compiler (gcc) and the Win32/Win64 API. Packages may need to depend on one or more of these. In particular, almost all packages should BuildRequire `+mingw32-filesystem+`, `+mingw64-filesystem+`, `+mingw32-gcc+` and `+mingw64-gcc+`. The correct Requires flags will get added automatically when the `+%{?mingw_package_header}+` macro is mentioned in the spec file (as will be described later on in these guidelines)
The Fedora MinGW project's mission is to provide an excellent development environment for Fedora users who wish to cross-compile their programs to run on Windows, minimizing the need to use Windows at all. In the past developers have had to port and compile all of the libraries and tools they have needed, and this huge effort has happened independently many times over. We aim to eliminate duplication of work for application developers by providing a range of libraries and development tools which have already been ported to the MinGW cross-compiler environment. This means that developers will not need to recompile the application stack themselves, but can concentrate just on the changes needed to their own application.
The `+%files+` section must list DLLs and import libraries separately. Packages must NOT use `+%{mingw32_bindir}/*+` or `+%{mingw32_libdir}/*+`
The following macros are for the %build and %install section of the spec
The following macros are for use in %build, %install and %files sections of the RPM spec
The `+foo.dll+` file is the main library, `+foo.dll.a+` is a stub linked to applications so they can find the library at runtime. All of these files are required in those locations in order to link successfully. The `+.dll+` may contain a version number although not always (e.g., `+foo-0.dll+`).
The goal of the MinGW framework is to provide an easy way for package maintainers to build their packages for multiple targets using one .spec file. To aid developers in this several RPM macros have been developed which are part of the mingw-filesystem package. These RPM macros will be explained later on in these guidelines.
The location for Win32 target is provided by the macro:
The MinGW cross-compilers and binutils are Fedora binaries and are therefore placed in `+%{_bindir}+` (i.e., `+/usr/bin+`) according to the FHS and Fedora guidelines.
The MinGW cross-compilers and binutils which generate i686 binaries for Windows are named:
The `+%{?mingw_debug_package}+` line must be placed after the `+%description tag+`. Otherwise spectool and other RPM tools may fail to function
The `+mingw-filesystem+` package provides a number of convenience macros for the cross compiled sysroot directories, and toolchain. It is mandatory to use these macros in all MinGW cross compiled packages submitted to Fedora.
The MinGW SIG have written an RPM comparison tool which makes it possible to compare cross compiled MinGW packages with the Fedora native packages, in order to determine whether versions, patches and configuration are aligned.
The `+minimum-version+` must be at least 95 or any later version which provides the functionality you need
then two files will get created named `+mingw32-foo.lang+` and `+mingw64-foo.lang+`. These file lists can be included in the %files section for the targets:
There are various types of files which are simply duplicates of equivalent files found in Fedora native packages. These files should not be packaged in the MinGW package. The following files don't need to be packaged in the MinGW package when their native counterpart already contains them:
The reason for this is that libtool is very fragile and will give up on building a DLL very easily. Therefore we force the name of the DLL to be listed explicitly in the `+%files+` section in order to catch this during RPM builds.
The root filesystem contains Windows executables and DLLs and any other Windows-only files. It is necessary both because we need to store Windows libraries in order to link further libraries which depend on them, and also because MinGW requires a root filesystem location.