BinIO and TextIO refectored...

[Anoq of the Sun]

This is a multi-part message in MIME format.
--------------FD92785678017B863F401298
Content-Type: text/plain; charset=iso-8859-7
Content-Transfer-Encoding: 7bit



Stephen Weeks wrote:
> I've incorporated your code into our internal version.  Thanks!

Great! :) As I wrote, I believe it is quite well-tested now (at least
on Linux).

I have also added the #includes needed to get SDL to work again -
it's in the attached libmlton.h from runtime/.

To use it you need to set the flag -DUSE_SDL and probably
setup the include paths correctly for SDL and WinMain (for Win32):
http://www.HardcoreProcessing.com/pro/winmain/index.html

I think it's quite ugly to have something like this in the
compiler so maybe it would be better to throw the main function
into a separate library to link with the rest of the MLton runtime?

What is happening with the includes is the following:
Linux / no SDL: standard main file
Linux / SDL   : SDL needs to use it's own main
Win32 / no SDL: WinMain needs to create the WinMain function for Windows
Win32 / SDL   : SDL needs to use it's own main

I would propose to implement a "libMLonmain" as something like the
following:

---

#if defined(_WIN32)

#if defined(USE_SDL)
// For Win32 applications with SDL support
#include "/usr/local/cross-tools/i386-mingw32msvc/include/SDL/SDL.h"
#else
// For Win32 applications without SDL
#include "/usr/local/devtools/C_CPP/WinMain/srcC/winmain.h"
// FIXME: Maybe this is better: "/usr/local/WinMain/winmain.h" ?
#endif

#else // i.e.: not _WIN32

#if defined(USE_SDL)
// For applications with SDL support
#include "/usr/include/SDL/SDL.h"
#endif

#endif // not _WIN32

int main(int argc, char **argv)
{
  return MLton_main(argc, argv);
}

---

Then compile this into different libraries depending on platform
and SDL-support or not. E.g.:

libMLtonmain_x86Linux.a
libMLtonmain_x86Linux_SDL.a
libMLtinmain_x86Win32.a
libMLtonmain_x86Win32_SDL.a

The rest of the runtime would then just need to use MLton_main
instead of main as it's main function. Which of these libraries
to link with could be a compiler flag.

I don't know what you think?

Also, I would still very much like to port to the Mingw32
compiler - so please tell me when you have a version of
MLton that I should start modifying :) (or if I should just
modify the MLton version I use now?)


Cheers
-- 
http://www.HardcoreProcessing.com
--------------FD92785678017B863F401298
Content-Type: application/x-unknown-content-type-ProjectBuilder.h;
 name="libmlton.h"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="libmlton.h"

LyogQ29weXJpZ2h0IChDKSAxOTk3LTE5OTkgTkVDIFJlc2VhcmNoIEluc3RpdHV0ZS4KICog
UGxlYXNlIHNlZSB0aGUgZmlsZSBMSUNFTlNFIGZvciBsaWNlbnNlIGluZm9ybWF0aW9uLgog
Ki8KI2lmbmRlZiBfTElCTUxUT05fSAojZGVmaW5lIF9MSUJNTFRPTl9ICgojdW5kZWYgaTM4
NgojdW5kZWYgaTQ4NgoKI2lmIGRlZmluZWQoX1dJTjMyKQoKI2lmIGRlZmluZWQoVVNFX1NE
TCkKLy8gRm9yIFdpbjMyIGFwcGxpY2F0aW9ucyB3aXRoIFNETCBzdXBwb3J0CiNpbmNsdWRl
ICIvdXNyL2xvY2FsL2Nyb3NzLXRvb2xzL2kzODYtbWluZ3czMm1zdmMvaW5jbHVkZS9TREwv
U0RMLmgiCiNlbHNlCi8vIEZvciBXaW4zMiBhcHBsaWNhdGlvbnMgd2l0aG91dCBTREwKI2lu
Y2x1ZGUgIi91c3IvbG9jYWwvZGV2dG9vbHMvQ19DUFAvV2luTWFpbi9zcmNDL3dpbm1haW4u
aCIKI2VuZGlmCgojZWxzZSAvLyBpLmUuOiBub3QgX1dJTjMyCgojaWYgZGVmaW5lZChVU0Vf
U0RMKQovLyBGb3IgYXBwbGljYXRpb25zIHdpdGggU0RMIHN1cHBvcnQKI2luY2x1ZGUgIi91
c3IvaW5jbHVkZS9TREwvU0RMLmgiCiNlbmRpZgoKI2VuZGlmIC8vIG5vdCBfV0lOMzIKCiNp
bmNsdWRlICJiYXNpcy1jb25zdGFudHMuaCIKI2luY2x1ZGUgImdjLmgiCiNpbmNsdWRlICJJ
bnRJbmYuaCIKI2luY2x1ZGUgIm1sdG9uLWJhc2lzLmgiCiNpbmNsdWRlICJtbHRvbi1wb3Np
eC5oIgojaW5jbHVkZSAibXktbGliLmgiCiNpbmNsdWRlICJwb3NpeC1jb25zdGFudHMuaCIK
CmV4dGVybiBzdHJ1Y3QgR0Nfc3RhdGUgZ2NTdGF0ZTsKCi8qIGluaXRpYWxpemUgdGhlIG1h
Y2hpbmUgKi8Kdm9pZCBNTHRvbl9pbml0KGludCBhcmdjLCAKCQljaGFyICoqYXJndiwKCQkv
KiBSZWFkIHRoZSBnbG9iYWxzIGZyb20gdGhlIHdvcmxkIGZpbGUuICovCgkJdm9pZCAoKmxv
YWRHbG9iYWxzKShGSUxFICpmaWxlKSk7CgovKiBQcmludCBhIHN0cmluZywgZXNjYXBpbmcg
ZXZlcnkgY2hhcmFjdGVyIHdpdGggZGVjaW1hbCBlc2NhcGVzLiAqLwp2b2lkIE1MdG9uX3By
aW50U3RyaW5nRXNjYXBlZChGSUxFICpmLCB1bnNpZ25lZCBjaGFyICpzKTsKCiNlbmRpZiAv
KiAjaWZuZGVmIF9MSUJNTFRPTl9IICovCgo=
--------------FD92785678017B863F401298--