2010/7/19 Volker Grabsch
<address@hidden>
Di Appoggio <address@hidden> schrieb:
> what's the best way to hope to see custom new packages? Sending patches?
Short answer:
Yes, just propose a *.mk file for your new package.
Long answer:
1) The package should be a free software library that is really
used by one of your applications.
BTW, I'm always curious about the applications people are
porting. On our project website, I maintain a list of projects
which use mingw-cross-env. No matter whether your project is
free or proprietary - as long as it has an own website, I'd be
happy to link to it.
Also, feel free to link to us. :-)
I'm not a real programmer, I simply prefer to a have a cross env to port my preferite multimedia projects to windows.
2) Grep through the src/*.mk files to find a project that is most
similar to yours. (Really, "grep" is your friend.)
E.g., when adding a GNU library, you should take a package like
gettext.mk or libiconv.mk as the base of your work. Or, when using
a SourceForge project, you should start with a copy of xmlwrapp.mk.
Already did.
3) Adjust the comments, fill in the $(PKG)_* fields, write your
$(PKG)_BUILD. Be especially careful with the $(PKG)_DEPS section.
Already did.
4) Write your $(PKG)_BUILD. If your library has a ./configure script,
enable/disable all depdency libraries explicitly via "--enable-*"
and "--disable-*" options.
Already did (but for some programs the task is quite expensive!)
5) You might also have to provide a patch for it. In that case, have
a look at other patches such as "glib-2-optional-gettext.patch".
In particular, each patch file should be named as:
PACKAGE-PATCHNUMBER-DESCRIPTION.patch
and should start with:
This file is part of mingw-cross-env.
See doc/index.html for further information.
This patch has been taken from:
https://...
where the URL points to the bugtracker entry, mailing list entry
or website you took the patch from.
If you created the patch yourself, please offer it to the project
first, and point to _that_ URL, using the same wording: "This
patch has been taken from:".
Depending on the feedback you get from the project, you might
want to improve your patch.
Sorry but this point is not quite clear for me, most of the patches are self made and only sometimes I've taken an advice from mailing lists. I mean: actually I don't remember where I've read these messages :-(
6) If you find some time, please provide a minimal test program for
it. It should be simple, stand alone and should work unmodified
for many (all?) future versions of the library. Test programs
are named as:
PACKAGE-test.c
or
PACKAGE-test.cpp
depending on whether it is a C or C++ library. To get a clue,
please have a look at existing test programs such as "sdl-test.c".
At the very end of your *.mk file you should build the test
program in a generic way. The last few lines of "sdl.mk" will
give you a clue.
Talking about ffmpeg or mplayer (for example), do I need to create a test program for EVERY library dependency????
7) You could also try to provide a $(PKG)_UPDATE section. However,
that requires some experience and "feeling" for it. So it is
perfectly okay if you leave the $(PKG)_UPDATE section empty.
I'll fill that in for you. It's a funny exercise.
Already did.
==> Just a suggestion: devs of some programs prefer (or force depending from the point of the view) the compilation of the latest source SVN revision.
So it's possible to add a way to manage svn downloads? Package version could be a particular revision number and PKG_UPDATE section could be filled by taking the output of a 'svn info'.
For MPlayer this is really important: with latest 1.0rc3, for example, SDL is not detected and BluRay support is missing...
8) Check that you don't have "dirty stuf" in your *.mk files, such
as TAB characters or trailing spaces at lines endings. Have
a look at random *.mk files to get a feeling for the coding
style.
The same holds for your test program.
However, patch files should always appear in the same coding
style as the files they are patching.
Finally, in your $(PKG)_BUILD section, please check that you
use our portability variables:
sed -> $(SED)
install -> $(INSTALL)
make -> $(MAKE)
bash -> $(SHELL)
Already did
8) Check whether everything runs fine. If you have some trouble,
don't hesitate to ask on the mailing list, providing your
*.mk file so far.
Already did
9) Propose your final *.mk file to the mailing list. Don't forget
to tell us if there are some pieces in your *.mk file you feel
unsure about. We'll then have a specific look at those parts,
which avoids trouble for you and us in the future.
I'll post ASAP
Greets,
Volker
Best Regards,
Marco