future of mingw

[Farkas Levente]

hi,
first of all i really appreciate the work done by mingw people and this
mail only try to help to improve mingw packages. so even if my style is
not proper it's just the bottle of wine that needed for me to (finally)
finish gstreamer mingw package for rhel-6 (and i still can't finish,
only for fedora). but during the buildsys building i try to collect my
opinion.

imho as in f16 there'll be a mingw32->mingw transition it's time to
change everything which is not perfect (even if it's never perfect).
afais mingw is now very similar to elrepo (or Driver Update Program
http://dup.et.redhat.com/). why?
- both provides a lots of similar packages,
- both are a made for something already in the base os,
- have generated subpackages eg: foo-kmod has generated kmod-foo(-PAE)
subpackage(s),
- the user written spec file is very short (relative to the generated ones),
- both use some kind of (dozens of) macros and scripts to help create
spec files.
even if i not always agree with the current state of elrepo they are
really getting better.

so my i should have to start with my default sentence (to my
programmer): what is on the cover? (of the cover of the practice of
programming)
simplicity, clarity, generality.
now see what i think about it related to mingw (of course the main
questions here the filesystem package and spec files).

generality:
there're a lots of people who'd like to use it: fedora, rhel/centos,
suse, mandrake not to mention the hidden people. would be useful for the
"community" to create something which is (very easily) reusable. means
only a rebuild needed (and may be the filesystem package can be
different for the different disto/people).
currently it's much more complicated. yes i know it's only for fedora,
but if it's only required a little more work why not we do it in that
way? see later my proposal.

clarity:
it's always tell "if it's shorter than it's better, since cleaner and
more easily readable". does the current spec file the cleaner and
shortest? imho not. see later my proposal.
what's the current rules? do we need static and debuginfo packages for
mingw or not? half of the packages has these subpackages half doesn't.
it'd be useful to clear it also.
anyway what's the debuginfo packages good for in case of mingw? or they
are only for cygwin gdb on windows?

simplicity:
the current spec file the simplest and easily created ones?
if i see any of my programmer doing copy'n'paste they already know i'll
be very angry. let's see
http://fedoraproject.org/wiki/Packaging:MinGW_Future
does the current spec file has any copy'n'paste?
imho much more then needed.
do you really think that the current mingw32-/mingw64- subpackage
definition is the simplest, easiest?
do you really think that anything from %description to %prep has any
value? if we drop docs, man pages, etc. cause we referring to the
original (non mingw package) then these part has any value?
imho almost nothing.
here the situation is exactly the same as in kmodtool (ie. elrepo case).
their spec files are very similar so they create a template and a shell
script which generate most of the common part of the spec file. i never
agree with them to use kmodtool in stead of rpm macros for this (what's
more copy to all packages:-() but the base idea can be steal from there.
they drop su


so my proposal:
- start from the end and create the ideal spec file template.
- enhance filesystem with a few macros to support the ideal spec file.
- make some decision (do we need static and debuginfo or not).
- let's create some macros which generate the common part of all spec files.
- propose the new guideline to FESCo.
- rewrite all spec file.

the ideal spec file only contains which has any relevant info (let's
drop everything else:-) from the
-------------------------------------
Name:           cross-example
Version:        1.0.0
Release:        1%{?dist}
Summary:        Cross compiled example library
License:        LGPLv2+
URL:            http://fedoraproject.org
Source0:        http://fedoraproject.org/example-%{version}.tar.bz2

// all of these defines are optional
%global cross_build_requires gettext win-iconv zlib
%global cross_build_win 1 // equal to the two next defs
%global cross_build_win32 1
%global cross_build_win64 1
%global cross_build_darwinx 1
%global cross_no_debug 1
%global cross_no_static 1
%{?cross_spec_begin}

%prep
%setup -q -n %{cross_pkg_name}-%{version}

%build
%{cross_configure "--enable-static" "--enable-shared" "--enable-foo"}
%{cross_make %{?_smp_mflags}}

%install
%{cross_make_install "DESTDIR=$RPM_BUILD_ROOT"}

%{cross_find_lang %{mingw_pkg_name}}

%{cross_files "" "%{cross_bindir}/libexample-0.dll \
%{cross_includedir}/example/ \
%{cross_libdir}/libexample.dll.a \
%{cross_libdir}/libexample.la \
%{cross_libdir}/pkgconfig/example.pc"}

// for tools subpackage
%{cross_files "tools" "%{cross_libdir}/libexample.a"}

%{?cross_spec_end}


%changelog
-------------------------------------
isn't it much simple and easier to read?
is there any _useful_ info missing from it?
can it be generated by macros? ok i don't really know that, but i assume
it's possible. and if you also think we can choose this way i start to
implement it (may be some others can help me:-)

ps. imho it's time to drink a lots of water and sleep:-)

-- 
  Levente                               "Si vis pacem para bellum!"