From 636318211e7ce38ca613041e5e548e8d3841e4fd Mon Sep 17 00:00:00 2001
From: Volker Grabsch
+ The package should be a + free + software + library + that is really used by one of your applications. +
+ ++ BTW, we're always curious about the applications people are + porting. On our project website, there is a + list of projects + which use mingw-cross-env. No matter whether your project is + free or proprietary - as long as it has it's own website, we'd be + happy to link to it. +
+ ++ Also, feel free to link to us. :-) +
++ 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. +
+
+ Adjust the comments, fill in the $(PKG)_*
fields.
+ Be especially careful with the $(PKG)_DEPS
section.
+ The easiest way to get the dependencies right is to start with
+ a minimal setup i.e. make gcc
only.
+
+ Write your $(PKG)_BUILD
. If your library has a
+ ./configure script, enable/disable all depdency libraries
+ explicitly via "--enable-*"
and
+ "--disable-*"
options.
+
+ You might also have to provide a patch for it. In that case, have + a look at other patches such as + + sdl-2-fix-dinput.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 + upstream 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. +
++ 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, using strict compiler flags. The + last few lines of + sdl.mk + will give you a clue. +
+
+ 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. We'll fill that
+ in for you. It's a funny exercise.
+
+ 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) + make -> $(MAKE) + bash -> $(SHELL) + patch -> $(PATCH) + install -> $(INSTALL) + libtoolize -> $(LIBTOOLIZE)+
+ 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. +
++ 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. +
++ See something missing? Feel free to propose a new package. +