[Bug 673790] Rename Request: mingw32-w32api -> mingw-headers - Win32/Win64 header files and stubs

bugzilla at redhat.com bugzilla at redhat.com
Wed Feb 22 13:06:58 UTC 2012


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=673790

Kalev Lember <kalevlember at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |kalevlember at gmail.com
         AssignedTo|nobody at fedoraproject.org    |kalevlember at gmail.com

--- Comment #10 from Kalev Lember <kalevlember at gmail.com> 2012-02-22 08:06:56 EST ---
Taking for review.


> %global mingw_pkg_name headers

This doesn't appear to be used anywhere in the spec file, is it actually
needed?


> Summary: Win32/Win64 header files and stubs

The old summary read "MinGW Windows cross-compiler Win32 header files" and most
of the MinGW cross-compiled library packages so far have used the "MinGW
Windows ..." prefix for summary. I think it would be useful to keep using a
distinct summary for all of the MinGW cross compiled packages, although I'm not
insisting on keeping "MinGW Windows ...", could be something else as well.

"MinGW Windows ..."
"MinGW cross-compiled ..."
"Windows cross-compiled ..."

Opinions on which one of them would be best? Now that we're going to rebuild
all the MinGW packages with the new toolchain, it might be a good time to make
sure the summaries are all uniform.

The reason I like uniformity is that it gives nice visual clues when searching
for packages in a package manager. It's easier for humans to parse output if
it's all aligned up nicely with similar prefix.


> %if 0%{?snapshot_date}
> Source0:        http://sourceforge.net/projects/mingw-w64/files/Toolchain%20sources/Automated%20Builds/mingw-w64-src_%{snapshot_date}.tar.bz2
> %else
> Source0:        http://downloads.sourceforge.net/project/mingw-w64/mingw-w64/mingw-w64-release/mingw-w64-v%{version}.tar.gz
> %endif

Could use just
http://downloads.sourceforge.net/mingw-w64/mingw-w64-src_20120120.tar.bz2 and
http://downloads.sourceforge.net/mingw-w64/mingw-w64-v2.0.1.tar.gz , no need to
include all the directory names for sourceforge URLs.


> %description -n mingw32-headers
> MinGW Windows cross-compiler Win32 and Win64 header files.

This is only for Win32.


> %description -n mingw64-headers
> MinGW Windows cross-compiler Win32 and Win64 header files.

This is only for Win64.


> %mingw_configure "--enable-sdk=all" "--enable-secure-api"

I am not very fond of the quotes, but they are currently necessary because of
the way the %mingw_configure macro is written, to avoid getopt(3) parsing. One
way to avoid the quotes would be to use --:
%mingw_configure -- \
  --enable-sdk=all \
  --enable-secure-api

Or we could rewrite the %mingw_configure macro. I gave a stab at improving the
macro to avoid getopt, how about this?

%mingw_set_suffix                           \
if [ $# -gt 1 ] && [ x"$1" = x"-s" ] ; then \
    BUILDDIR_SUFFIX=_"$2"                   \
    shift; shift                            \
fi

%mingw_configure                        \
run_mingw_configure()                   \
{                                       \
%{mingw_set_suffix}                     \
%{?mingw_build_win32:                   \
mkdir build_win32$BUILDDIR_SUFFIX       \
pushd build_win32$BUILDDIR_SUFFIX       \
    %{?mingw32_configure} $@            \
popd }                                  \
%{?mingw_build_win64:                   \
mkdir build_win64$BUILDDIR_SUFFIX       \
pushd build_win64$BUILDDIR_SUFFIX       \
    %{?mingw64_configure} $@            \
popd }                                  \
}                                       \
run_mingw_configure


> %mingw_make_install "DESTDIR=$RPM_BUILD_ROOT"

Ditto.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


More information about the mingw mailing list