cvs commit: fptools/libraries/OpenGL/Graphics/Rendering/OpenG L/GL U Constants.hs fptools/libraries/OpenGL/specs/enumerant ConvertEnumSpec.hs test.stdout

Simon Marlow simonmar@microsoft.com
Mon, 10 Feb 2003 10:10:50 -0000


> panne       2003/02/09 14:41:07 PST
>=20
>   Modified files:
>     libraries/OpenGL/Graphics/Rendering/OpenGL/GLU Constants.hs=20
>     libraries/OpenGL/specs/enumerant ConvertEnumSpec.hs=20
>                                      test.stdout=20
>   Log:
>   Splitting object files is crucial for a large library like HOpenGL,
>   but the files generated by ConvertEnumSpec hit several system limits
>   quite severly:
>  =20
>      * Compilation time for the stuff generated from enum.spec was
>        almost 15min on an Athlon 2000 XP+ before the commandline limit
>        for the linker was finally reached.
>  =20
>      * Even if the problem above was fixed, there are far=20
> more than 7000
>        object files for this single Haskell module, which=20
> will probably
>        generate lots of linking fun with the current GNU linker on
>        WinDoze.
>  =20
>      * A lot of (un-)marshalers are generated which are never needed.
>  =20
>   So I bit the bullet and made ConvertEnumSpec emit an #ifdef around
>   every data type and its (un-)marshalers, giving quite some=20
> flexibility
>   at the #include site. The downside is that we now have another
>   dependency on the preprocessor, something which I initially hoped to
>   avoid completely. But on the other hand, HOpenGL already depends on
>   the preprocessor for handling the different calling conventions on
>   normal *nix systems and WinDoze DLLs. *sigh*

Just a thought, but if the module in question contains lots of datatypes
you might want to try with -fno-generics, which will cut down on some of
the code we generate for each datatype, provided you don't use generics.

Cheers,
	Simon