Guidelines for Creating Packages

- 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. - We maintain 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 here.) -

- -

- For instance, - when adding a GNU library, - you should take a package like - gettext.mk - or - libiconv.mk - as the base of your work. - When using a SourceForge project, - you could start with a copy of - xmlwrapp.mk. - And so on. -

- -

- 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. - That is, - initialize mingw-corss-env with make gcc only. -

- -

- Always list the dependency on gcc explicitly: -

$(PKG)_DEPS     := gcc ...

- -

- 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 upstream 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: -

- - - - - - - -

bash	→	$(SHELL)
install	→	$(INSTALL)
libtoolize	→	$(LIBTOOLIZE)
make	→	$(MAKE)
patch	→	$(PATCH)
sed	→	$(SED)

- -

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

@@ -697,7 +498,7 @@

openSUSE

- +

@@ -1024,6 +825,217 @@

Guidelines for Creating Packages

+ +

+
+ 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. + We maintain is a + list of projects + which use mingw-cross-env. + No matter whether your project is free or proprietary + – as long as it has its 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 here.) +
+ +
+ For instance, + when adding a GNU library, + you should take a package like + gettext.mk + or + libiconv.mk + as the base of your work. + When using a SourceForge project, + you could start with a copy of + xmlwrapp.mk. + And so on. +
+
+
+ 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. + That is, + initialize mingw-corss-env with make gcc only. +
+ +
+ Always list the dependency on gcc explicitly: +
+
```
$(PKG)_DEPS     := gcc ...
```
+
+
+ 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 upstream 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: +
+

Autoconf

≥ 2.62

+ + + + + + +

`bash`	→	`$(SHELL)`
`install`	→	`$(INSTALL)`
`libtoolize`	→	`$(LIBTOOLIZE)`
`make`	→	`$(MAKE)`
`patch`	→	`$(PATCH)`
`sed`	→	`$(SED)`

+ + +

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

MinGW cross compiling environment

Guidelines for Creating Packages

Guidelines for Creating Packages

Copyright © 2007, 2008, 2009, 2010