[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mingw-cross-env-list] How to suggest new packages?

From: Di Appoggio
Subject: Re: [Mingw-cross-env-list] How to suggest new packages?
Date: Wed, 21 Jul 2010 09:59:33 +0200

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:


       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:

       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:


       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

       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



Best Regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]