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

[Volker Grabsch]

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


    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.


    3)  Adjust the comments, fill in the $(PKG)_* fields, write your
        $(PKG)_BUILD. Be especially careful with the $(PKG)_DEPS section.


    4)  Write your $(PKG)_BUILD. If your library has a ./configure script,
        enable/disable all depdency libraries explicitly via "--enable-*"
        and "--disable-*" options.


    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.


    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.


    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.


    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)


    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.


    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.



Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR