changeset 1245:37aa3912b501

improved coding style
author Volker Grabsch <vog@notjusthosting.com>
date Sat, 02 Oct 2010 13:14:16 +0200
parents 225608c7dee6
children 8e21c194b7d3
files Makefile doc/index.html
diffstat 2 files changed, 175 insertions(+), 153 deletions(-) [+]
line wrap: on
line diff
--- a/Makefile	Sat Oct 02 10:49:01 2010 +0200
+++ b/Makefile	Sat Oct 02 13:14:16 2010 +0200
@@ -15,10 +15,10 @@
 TOP_DIR    := $(patsubst %/,%,$(dir $(MAKEFILE)))
 PATH       := $(PREFIX)/bin:$(PATH)
 SHELL      := bash
-SED        := $(shell gsed --help >/dev/null 2>&1 && echo g)sed
-PATCH      := $(shell gpatch --help >/dev/null 2>&1 && echo g)patch
 INSTALL    := $(shell ginstall --help >/dev/null 2>&1 && echo g)install
 LIBTOOLIZE := $(shell glibtoolize --help >/dev/null 2>&1 && echo g)libtoolize
+PATCH      := $(shell gpatch --help >/dev/null 2>&1 && echo g)patch
+SED        := $(shell gsed --help >/dev/null 2>&1 && echo g)sed
 VERSION    := $(shell $(SED) -n 's,^.*<span id="latest-version">\([^<]*\)</span>.*$$,\1,p' '$(TOP_DIR)/doc/index.html')
 
 # unexport any environment variables that might cause trouble
--- a/doc/index.html	Sat Oct 02 10:49:01 2010 +0200
+++ b/doc/index.html	Sat Oct 02 13:14:16 2010 +0200
@@ -429,7 +429,7 @@
         <p>
         Almost all packages are updated to their latest version.
         </p>
-        
+
         <p>
         Support for OpenSolaris has been dropped.
         </p>
@@ -471,177 +471,199 @@
     feel free to join the
     <a href="http://lists.nongnu.org/mailman/listinfo/mingw-cross-env-list">project mailing list</a>.
     </p>
-    
-<h2 id="new-packages">New Package Submission</h2>
+
+<h2 id="creating-packages">Guidelines for Creating Packages</h2>
+
     <ol>
     <li>
-    <p>
-    The package should be a 
-    <a href="http://www.gnu.org/philosophy/free-sw.html">free</a> 
-    <a href="http://www.debian.org/social_contract#guidelines">software<a> 
-    <a href="http://www.opensource.org/osd.html">library</a> 
-    that is really used by one of your applications.
-    </p>
-    
-    <p>
-    BTW, we're always curious about the applications people are
-    porting. On our project website, there is a 
-    <a href="#used-by">list of projects</a> 
-    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.
-    </p>
-    
-    <p>
-    Also, feel free to link to us. :-)
-    </p>
+        <p>
+        The package should be a
+        <a href="http://www.gnu.org/philosophy/free-sw.html">free</a>
+        <a href="http://www.debian.org/social_contract#guidelines">software</a>
+        <a href="http://www.opensource.org/osd.html">library</a>
+        that is really used by one of your applications.
+        </p>
+
+        <p>
+        BTW, we're always curious about the applications people are porting.
+        We maintain is a
+        <a href="#used-by">list of projects</a>
+        which use mingw-cross-env.
+        No matter whether your project is free or proprietary
+        &ndash; as long as it has it's own website,
+        we'd be happy to link to it.
+        </p>
+
+        <p>
+        Also, feel free to link to us. :-)
+        </p>
     </li>
-    
+
     <li>
-    <p>
-    Grep through the src/*.mk files to find a project that is most
-    similar to yours. (Really, "grep" is your friend.)
-    </p>
-    
-    <p>
-    E.g., when adding a GNU library, you should take a package like 
-    <a href="http://hg.savannah.gnu.org/hgweb/mingw-cross-env/file/tip/src/gettext.mk">gettext.mk</a> 
-    or 
-    <a href="http://hg.savannah.gnu.org/hgweb/mingw-cross-env/file/tip/src/libiconv.mk">libiconv.mk</a> 
-    as the base of your work. Or, when using 
-    a SourceForge project, you should start with a copy of 
-    <a href="http://hg.savannah.gnu.org/hgweb/mingw-cross-env/file/tip/src/xmlwrapp.mk">xmlwrapp.mk</a>.
-    </p>
+        <p>
+        Grep through the src/*.mk files
+        to find a project that is most similar to yours.
+        (Really, <code>grep</code> is your friend here.)
+        </p>
+
+        <p>
+        For instance,
+        when adding a GNU library,
+        you should take a package like
+        <a href="http://hg.savannah.gnu.org/hgweb/mingw-cross-env/file/tip/src/gettext.mk">gettext.mk</a>
+        or
+        <a href="http://hg.savannah.gnu.org/hgweb/mingw-cross-env/file/tip/src/libiconv.mk">libiconv.mk</a>
+        as the base of your work.
+        When using a SourceForge project,
+        you could start with a copy of
+        <a href="http://hg.savannah.gnu.org/hgweb/mingw-cross-env/file/tip/src/xmlwrapp.mk">xmlwrapp.mk</a>.
+        And so on.
+        </p>
     </li>
-    
-    <li>
-    <p>
-    Adjust the comments, fill in the <code>$(PKG)_*</code> fields. 
-    Be especially careful with the <code>$(PKG)_DEPS</code> section. 
-    The easiest way to get the dependencies right is to start with 
-    a minimal setup i.e. <code>make gcc</code> only.
-    </p>
-    </li>
-    
+
     <li>
-    <p>
-    Write your <code>$(PKG)_BUILD</code>. If your library has a 
-    ./configure script, enable/disable all depdency libraries 
-    explicitly via <code>"--enable-*"</code> and 
-    <code>"--disable-*"</code> options.
-    </p>
+        <p>
+        Adjust the comments,
+        fill in the <code>$(PKG)_*</code> fields.
+        </p>
+
+        <p>
+        Be especially careful with the <code>$(PKG)_DEPS</code> section.
+        The easiest way to get the dependencies right
+        is to start with a minimal setup.
+        That is,
+        initialize mingw-corss-env with <code>make gcc</code> only.
+        </p>
+
+        <p>
+        Always list the dependency on <code>gcc</code> explicitly:
+        </p>
+        <pre>$(PKG)_DEPS     := gcc ...</pre>
     </li>
-    
+
     <li>
-    <p>
-    You might also have to provide a patch for it. In that case, have
-    a look at other patches such as 
-    <a href="http://hg.savannah.gnu.org/hgweb/mingw-cross-env/file/tip/src/sdl-2-fix-dinput.patch">
-        sdl-2-fix-dinput.patch</a>. 
-    In particular, each patch file should be named as:
-    </p>
-    
-    <p>
-    <pre>PACKAGE-PATCHNUMBER-DESCRIPTION.patch</pre>
-    </p>
-    <p>
-    and should start with:
-    </p>
-    <pre>
-This file is part of mingw-cross-env.
+        <p>
+        Write your <code>$(PKG)_BUILD</code>.
+        If your library has a <code>./configure</code> script,
+        enable/disable all depdency libraries explicitly
+        via <code>"--enable-*"</code> and <code>"--disable-*"</code> options.
+        </p>
+    </li>
+
+    <li>
+        <p>
+        You might also have to provide a patch for it.
+        In that case, have a look at other patches such as
+        <a href="http://hg.savannah.gnu.org/hgweb/mingw-cross-env/file/tip/src/sdl-2-fix-dinput.patch">sdl-2-fix-dinput.patch</a>.
+        In particular, each patch file should be named as:
+        </p>
+        <pre>PACKAGE-PATCHNUMBER-DESCRIPTION.patch</pre>
+        <p>
+        and should start with:
+        </p>
+        <pre>This file is part of mingw-cross-env.
 See doc/index.html for further information.
 
 This patch has been taken from:
-https://...
-    </pre>
-    <p>
-    where the URL points to the bugtracker entry, mailing list entry
-    or website you took the patch from.
-    </p>
-    
-    <p>
-    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:".
-    </p>
-    
-    <p>
-    Depending on the feedback you get from the project, you might
-    want to improve your patch.
-    </p>
+https://...</pre>
+        <p>
+        where the URL points to the
+        bugtracker entry,
+        mailing list entry or
+        website
+        you took the patch from.
+        </p>
+
+        <p>
+        If you created the patch yourself,
+        please offer it to the upstream project first,
+        and point to <em>that</em> URL,
+        using the same wording:
+        "This patch has been taken from:".
+        </p>
+
+        <p>
+        Depending on the feedback you get from the upstream project,
+        you might want to improve your patch.
+        </p>
     </li>
-    
+
     <li>
-    <p>
-    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:
-    </p>
-    <pre>PACKAGE-test.c
-    or
-PACKAGE-test.cpp</pre>
+        <p>
+        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:
+        </p>
+        <pre>PACKAGE-test.c</pre>
+        or
+        <pre>PACKAGE-test.cpp</pre>
+        <p>
+        depending on whether it is a C or C++ library.
+        To get a clue,
+        please have a look at existing test programs such as
+        <a href="http://hg.savannah.gnu.org/hgweb/mingw-cross-env/file/tip/src/sdl-test.c">sdl-test.c</a>.
+        </p>
 
-    <p>
-    depending on whether it is a C or C++ library. To get a clue,
-    please have a look at existing test programs such as 
-    <a href="http://hg.savannah.gnu.org/hgweb/mingw-cross-env/file/tip/src/sdl-test.c">sdl-test.c</a>.
-    </p>
-    
-    <p>
-    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 
-    <a href="http://hg.savannah.gnu.org/hgweb/mingw-cross-env/file/tip/src/sdl.mk">sdl.mk</a> 
-    will give you a clue.
-    </p>
+        <p>
+        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
+        <a href="http://hg.savannah.gnu.org/hgweb/mingw-cross-env/file/tip/src/sdl.mk">sdl.mk</a>
+        will give you a clue.
+        </p>
     </li>
-    
+
     <li>
-    <p>
-    You could also try to provide a <code>$(PKG)_UPDATE</code> 
-    section. However, that requires some experience and 
-    "feeling" for it. So it is perfectly okay if you leave the 
-    <code>$(PKG)_UPDATE</code> section empty. We'll fill that 
-    in for you. It's a funny exercise.
-    </p>
+        <p>
+        You could also try to provide a <code>$(PKG)_UPDATE</code> section.
+        However, that requires some experience and "feeling" for it.
+        So it is perfectly okay if you leave the <code>$(PKG)_UPDATE</code> section empty.
+        We'll fill that in for you.
+        It's a funny exercise.
+        </p>
     </li>
-    
+
     <li>
-    <p>
-    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.
-    </p>
-    
-    <p>
-    The same holds for your test program.
-    </p>
-    
-    <p>
-    However, patch files should always appear in the same coding
-    style as the files they are patching.
-    </p>
-    
-    <p>
-    Finally, in your <code>$(PKG)_BUILD</code> section, please 
-    check that you use our portability variables:
-    </p>
-    <pre>
-    sed        -> $(SED)
-    make       -> $(MAKE)
-    bash       -> $(SHELL)
-    patch      -> $(PATCH)
-    install    -> $(INSTALL)
-    libtoolize -> $(LIBTOOLIZE)</pre>
+        <p>
+        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.
+        </p>
+
+        <p>
+        The same holds for your test program.
+        </p>
+
+        <p>
+        However, patch files should always appear
+        in the same coding style as the files they are patching.
+        </p>
+
+        <p>
+        Finally, in your <code>$(PKG)_BUILD</code> section,
+        please check that you use our portability variables:
+        </p>
+        <table>
+            <tr><td>bash</td>      <td>&rarr;</td><td>$(SHELL)</td></tr>
+            <tr><td>install</td>   <td>&rarr;</td><td>$(INSTALL)</td></tr>
+            <tr><td>libtoolize</td><td>&rarr;</td><td>$(LIBTOOLIZE)</td></tr>
+            <tr><td>make</td>      <td>&rarr;</td><td>$(MAKE)</td></tr>
+            <tr><td>patch</td>     <td>&rarr;</td><td>$(PATCH)</td></tr>
+            <tr><td>sed</td>       <td>&rarr;</td><td>$(SED)</td></tr>
+        </table>
     </li>
-    
+
     <li>
     <p>
     Check whether everything runs fine. If you have some trouble,
-    don't hesitate to ask on the 
-    <a href="http://lists.nongnu.org/mailman/listinfo/mingw-cross-env-list">mailing list</a>, 
+    don't hesitate to ask on the
+    <a href="http://lists.nongnu.org/mailman/listinfo/mingw-cross-env-list">mailing list</a>,
     providing your *.mk file so far.
     </p>
     </li>
@@ -997,7 +1019,7 @@
     <table id="package-list">
     </table>
     <p>
-    See something missing? Feel free to <a href="#new-packages">propose a new package</a>.
+    See something missing? Feel free to <a href="#creating-packages">create a new package</a>.
     </p>
 </div>