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