Example "cross-zlib" package added to Mercurial

Farkas Levente lfarkas at lfarkas.org
Sun Feb 15 19:18:18 UTC 2009


Richard W.M. Jones wrote:
> Here is the annotated diff from the current mingw32-zlib.spec file to
> the proposed new spec file that would build to multiple architectures.
> 
>     --- mingw32-zlib.spec	2009-01-19 19:03:53.000000000 +0000
>     +++ mingw32-zlib.spec	2009-02-14 14:06:48.000000000 +0000
>     @@ -6,8 +6,8 @@
>      
>      Name:           mingw32-zlib
>      Version:        1.2.3
>     -Release:        12%{?dist}
>     -Summary:        MinGW Windows zlib compression library
>     +Release:        13%{?dist}
>     +Summary:        Cross-compiled zlib compression library
> 
> As a general cleanup, we need to go through all the summary lines and
> remove "Windows" (trademark, see[1]) and "MinGW" (no longer
> appropriate for these packages).  At the same time we don't want to
> get confused with other cross-compiler packages in Fedora.
> Suggestions welcome on a good summary line.

what's the plane here?
do you wanna include it in f10/f11 somehow or just an example?
i still prefer to rename the main package to cross-zlib. it's very
strance to be a mingw32-zlib which produce mingw64-zlib what's more
darwin-zlib?

> [1] https://www.redhat.com/archives/fedora-devel-announce/2009-January/msg00012.html
>      
>      License:        zlib
>      Group:          Development/Libraries
>     @@ -27,19 +27,42 @@
>      BuildRequires:  mingw32-filesystem >= 23
>      BuildRequires:  mingw32-gcc
>      BuildRequires:  mingw32-binutils
>     +BuildRequires:  mingw64-filesystem >= 10

ihmo here again would be better to one common cross-filesystem which
contains all macros, script, dirs etc. why we create 3 such packages? i
think now and in a few months as many things get clear (as daniel
suggested) would be better to create test packages based on a new
'feature for f12 cross-compiler'.

>     +BuildRequires:  mingw64-gcc
>     +BuildRequires:  mingw64-binutils

and again if we create cross-xxx packages then we can create
meta-packages like cross-gcc which requires all gcc and these BR can be
3 times shorter.

>      %description
>     -MinGW Windows zlib compression library.
>     +Cross-compiled zlib compression library.
>     +
>     +
>     +%package -n mingw64-zlib
>     +Summary:        Cross-compiled zlib compression library
>     +Group:          Development/Libraries
>     +
>     +
>     +%description -n mingw64-zlib
>     +Cross-compiled zlib compression library.
> 
> Since we are going to build for Win32 and Win64, we need the extra
> BuildRequires and the extra subpackage.
> 
>      %prep
>     -%setup -q -n zlib-1.2.3
>     +%setup -q -c -n %{name}-%{version} -a 0
>     +mv zlib-%{version} mingw32
>     +%setup -q -c -D -n %{name}-%{version} -a 0
>     +mv zlib-%{version} mingw64
>
> This is one of several ways to set up a directory structure like this:
> 
>   mingw32-zlib-1.2.3/
>     mingw32     # full copy of the source
>     mingw64     # second full copy of the source
> 
> zlib has a strange build system with a custom configure script.  For
> autoconf packages we could do this more efficiently using a single
> copy of the source and separate build directories.
> 
> [Which reminds me -- we need to modify %{_mingw32_configure} so that
> it looks for a configure script in . and ..]
> 
>     +pushd mingw32
>     +%patch100 -p1
>     +popd
>      
>     +pushd mingw64
>      %patch100 -p1
>     +popd

why not used the same way as in kmod packages:
- first setup and patch the source
- then create as many new copy as required
- then build:
--------------------
%prep
%setup -q -c -T -a 0
%patch0 -p1
for kvariant in %{kvariants} ; do
        cp -a %{kmod_name}-%{version} _kmod_build_${kvariant}
done

%build
for kvariant in %{kvariants}; do
        pushd _kmod_build_${kvariant}

ksrc=%{_usrsrc}/kernels/%{kverrel}${kvariant:+-$kvariant}-%{_target_cpu}
                make %{?_smp_mflags} -C "${ksrc}" SUBDIRS=${PWD} modules
        popd
done

%install
rm -rf $RPM_BUILD_ROOT
for kvariant in %{kvariants}; do

ksrc=%{_usrsrc}/kernels/%{kverrel}${kvariant:+-$kvariant}-%{_target_cpu}
        pushd _kmod_build_$kvariant
                make -C "${ksrc}" INSTALL_MOD_PATH=$RPM_BUILD_ROOT
INSTALL_MOD_DIR=extra/%{kmod_name} modules_install M=$PWD
        popd
done
--------------------
in our case it can be like this:
--------------------
%prep
%setup -q -c -T -a 0
%patch0 -p1
for cvariant in %{cvariants} ; do
        cp -a %{name}-%{version} _build_${cvariant}
done

%build
for cvariant in %{cvariants}; do
	pushd _build_${cvariant}
		%{_${cvariant}_configure}
		%{_${cvariant}_make}
	popd
done

%install
rm -rf $RPM_BUILD_ROOT
for cvariant in %{cvariants}; do
	pushd _build_$cvariant
                %{_${cvariant}_makeinstall}
        popd
done
--------------------
where cvariants can be mingw32, mingw32, darwinx.
it can work both autoconf and none autoconf case and imho it's not worth
to bother with autoconf case where the source copy is not required (it's
really minimal disk space during compile). and it's clear, short and
easier to read and document.

> In this case (non-autoconf) we need to apply all patches twice,
> 
>      %build
>     +pushd mingw32
>     +
>      CC=%{_mingw32_cc} \
>      CFLAGS="%{_mingw32_cflags}" \
>      RANLIB=%{_mingw32_ranlib} \
>     @@ -49,15 +72,37 @@
>        STRIP=%{_mingw32_strip} \
>        all
>      
>     +popd
>     +
>     +pushd mingw64
>     +
>     +CC=%{_mingw64_cc} \
>     +CFLAGS="%{_mingw64_cflags}" \
>     +RANLIB=%{_mingw64_ranlib} \
>     +./configure
>     +
>     +make -f win32/Makefile.gcc \
>     +  CFLAGS="%{_mingw64_cflags}" \
>     +  CC=%{_mingw64_cc} \
>     +  AR=%{_mingw64_ar} \
>     +  RC=%{_mingw64_windres} \
>     +  DLLWRAP=%{_mingw64_dllwrap} \
>     +  STRIP=%{_mingw64_strip} \
>     +  all
>     +
>     +popd
>     +

here also would be easier %{_mingw64_make}

>     +%files -n mingw64-zlib
>     +%defattr(-,root,root)
>     +%{_mingw64_includedir}/zconf.h
>     +%{_mingw64_includedir}/zlib.h
>     +%{_mingw64_libdir}/libz.dll.a
>     +%{_mingw64_bindir}/zlib1.dll
> 
> and also %files is duplicated for the second subpackage.

and probably we can shorten the files section with a few helper macros too.

-- 
  Levente                               "Si vis pacem para bellum!"



More information about the mingw mailing list