better gcc support in compile.lua

[chaz/yoink] / README

diff --git a/README b/README
index bd05038886201b7330ff66ad1c62266985be565d..9a83126ee869cd4aa2e4537cde1fcffaca35e861 100644 (file)
--- a/README
+++ b/README
@@ -13,7 +13,6 @@ II.  Developers
   b)   Sending patches
 III. Packagers
   a)   The build system
   b)   Sending patches
 III. Packagers
   a)   The build system

-  b)   Targeting Win32

 
 
 I. Users
 
 
 I. Users


@@ -35,8 +34,8 @@ libpng
 libvorbis
 Lua
 OpenAL
 libvorbis
 Lua
 OpenAL

-OpenGL
-pkgconfig (build-time dependency)
+OpenGL (including GLU)
+pkgconfig

 SDL
 
 c) License
 SDL
 
 c) License


@@ -54,7 +53,7 @@ a) Notes regarding the code
 
 The code is a complete rewrite, containing none of the original code.  I've
 made some effort to put the more generic or reusable code into a separate
 
 The code is a complete rewrite, containing none of the original code.  I've
 made some effort to put the more generic or reusable code into a separate

-library called Moof.  I've also made an effort to incorporate 3rd-party
+library called libmoof.  I've also made an effort to incorporate 3rd-party

 code that happened to fit well into what I needed.  So, generally, the
 source code is separated into these three categories:
 
 code that happened to fit well into what I needed.  So, generally, the
 source code is separated into these three categories:
 


@@ -64,12 +63,12 @@ This is the code directly in src/.  These classes reside in no namespace.
 
 2. Reusable code.
 
 
 2. Reusable code.
 

-Currently, the code is in src/Moof/, and it is compiled as a convenience
-library.  These classes and helper functions reside in the Mf namespace.
+Currently, the code is in src/moof/, and it is compiled as a convenience
+library.  These classes and helper functions reside in the moof namespace.

 Since I wrote this code alongside the Yoink-specific stuff, there is
 somewhat of a blurry line between the two categories, unfortunately.
 
 Since I wrote this code alongside the Yoink-specific stuff, there is
 somewhat of a blurry line between the two categories, unfortunately.
 

-3. 3rd-party code.
+3. Third-party code.

 
 This is made up of free code from other projects or libraries (aside from
 the explicit dependencies above), the licenses of which are also in the
 
 This is made up of free code from other projects or libraries (aside from
 the explicit dependencies above), the licenses of which are also in the


@@ -83,7 +82,7 @@ email me your stuff or tell me where to pull from (git).  If you're
 interested in that, please observe the following:
 
 *  Stick to the coding style of the source code files you edit.  Follow the
 interested in that, please observe the following:
 
 *  Stick to the coding style of the source code files you edit.  Follow the

-   general style of method and variable naming, as well as white spacing
+   general style of method and variable naming, as well as white space

    formatting.  In particular, use literal tabs with an assumed tabstop of
    4 characters.  Also, limit line lengths to 75 characters.
 
    formatting.  In particular, use literal tabs with an assumed tabstop of
    4 characters.  Also, limit line lengths to 75 characters.
 


@@ -91,8 +90,8 @@ interested in that, please observe the following:
    You must also agree to license your changes according to the same terms
    and conditions as the files you edit, usually the 2-clause BSD license.
 
    You must also agree to license your changes according to the same terms
    and conditions as the files you edit, usually the 2-clause BSD license.
 

-*  If you want to add your contact information to the file AUTHORS, please
-   just do it in the patch you provide.
+*  If you want your name and contact information in the file AUTHORS,
+   please make it so in the patch you provide.

 
 
 III. Packagers
 
 
 III. Packagers


@@ -101,24 +100,7 @@ III. Packagers
 a) The build system
 
 You can probably tell that the build system of this package is built from
 a) The build system
 
 You can probably tell that the build system of this package is built from

-autoconf and automake.  It should be fairly sane.  If you find any build
-system problems or code which doesn't compile cleanly on your platform,
-feel free to send back patches.
-
-b) Targeting Win32
-
-If you have a working mingw32 toolchain with all the dependencies, you can
-build a win32 binary using a command such as this:
-
-./configure --host=mingw32 --prefix=/usr/mingw32/usr
-
-where mingw32 is the correct name of your toolchain and the prefix points
-to the installation of your toolchain.  I maintain an archive of most of
-the dependencies.  The package is in the git repository; just unzip it onto
-your toolchain and configure/compile.  If everything goes smoothly, you
-should have a new, shiny yoink.exe.  You can then build a complete
-installer using "make package" if you have nsis installed.
-
-I haven't tried building with cygwin or mingw32 on an actual Windows
-machine, let alone VS.  You're on your own if you go that route.
+autoconf and automake.  It should be fairly sane.  If you find any
+packaging-related problems or code which doesn't compile cleanly on your
+platform, feel free to send patches.