From 636318211e7ce38ca613041e5e548e8d3841e4fd Mon Sep 17 00:00:00 2001 From: Volker Grabsch Date: Sat, 2 Oct 2010 16:03:48 +1000 Subject: add new package submission guidelines to docs --- doc/index.html | 186 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 186 insertions(+) diff --git a/doc/index.html b/doc/index.html index dae332c..48a3c76 100644 --- a/doc/index.html +++ b/doc/index.html @@ -471,6 +471,189 @@ USE_OSGPLUGIN(<plugin2>) feel free to join the project mailing list.

+ +

New Package Submission

+
+ 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. +
+

@@ -813,6 +996,9 @@ sudo gcc_select gcc40

+ See something missing? Feel free to propose a new package. +

-- cgit v0.12