I'm in the process of moving the X11 libraries over from hslibs into fptools/libraries and thought I'd better check I'm doing it the approved way before I commit. At present, I'm modelling my infrastructure (Makefiles, directory structure, etc) on the HOpenGL infrastructure so, naturally, I'm putting it in fptools/libraries/X11 and have the following modules: module X11 -- reexports X11.Types and X11.Xlib module X11.StdDIS module X11.Types module X11.Xlib The X11 module lives in fptools/libraries/X11.hs. The X11 library is only built if GhcLibsWithX11 is set. The X11 library is covered by the same license as GHC, Hugs, etc. 1) Is this the right place to put X11 in the directory tree or should I put it under libraries/base or some other existing directory? 2) Is this the right place to put the X11 module in the hierarchial namespace? I'm hoping to get round to moving the Win32 and HGL libraries over pretty soon as well so whatever answer you give should apply to them too. -- Alastair ps The makefiles seem to be entirely for GHC usage but we will want to build X11 and Win32 for Hugs and NHC as well. Since we already have makefiles and other scripts for doing this (Hugs only at present), the easy way to do this would be to copy over the existing scripts and completely ignore the fptools Makefile infrastructure - but it would perhaps be nicer if we could easily exploit the existing infrastructure. (This applies to all the existing stuff in fptools/libraries/base too - the Hugs distro contains stuff to compile all the files that contain ffi code but this largely replicates the instructions from the fptools makefile.) pps Should I continue the unsavoury practice of committing GreenCard generated code to the repository? (Currently done for Win32, I'd do it for Xlib too for the sake of consistency.)
Alastair Reid
At present, I'm modelling my infrastructure (Makefiles, directory structure, etc) on the HOpenGL infrastructure so, naturally, I'm putting it in fptools/libraries/X11 and have the following modules:
module X11 -- reexports X11.Types and X11.Xlib module X11.StdDIS module X11.Types module X11.Xlib
1) Is this the right place to put X11 in the directory tree or should I put it under libraries/base or some other existing directory?
Yes, I'm sure your current location is fine. Presumably it will appear as a ghc/nhc98 "package", just like HOpenGL, HaXml, etc.
2) Is this the right place to put the X11 module in the hierarchial namespace?
Probably not. HOpenGL uses a Graphics.Rendering.OpenGL prefix, whilst GLUT uses Graphics.UI.GLUT and these accurately reflect the nature of the libraries. I don't know exactly what your X11 library provides, but assuming that it has a mix of rendering and user interface capabilities, I would guess that Graphics.X11 might be an OK location? On the other hand, HGL would probably fit better into Graphics.Rendering.HGL since it is mostly concerned with drawing, yes? As for your Win32 library, again I don't know exactly what capabilities it provides. If it is mainly a mixture of graphical things, then Graphics.Win32 would be right, but if it is wider in scope, such as perhaps interfacing to the entire win32 DLL, then System.Win32 would seem more appropriate. Regards, Malcolm
Yes, I'm sure your current location is fine. Presumably it will appear as a ghc/nhc98 "package", just like HOpenGL, HaXml, etc.
That's the plan - I'm copying package descriptions over from HOpenGL in the hope that they will work after suitable tweaking.
2) Is this the right place to put the X11 module in the hierarchial namespace?
I don't know exactly what your X11 library provides, but assuming that it has a mix of rendering and user interface capabilities, I would guess that Graphics.X11 might be an OK location?
X11 provides most of what /usr/X11R6/lib/libX11.a contains. That is, operations for input (mouse/kbd events and the like) and operations for output (create windows, draw lines, fonts, etc.) It doesn't provide any higher-level stuff like scrollbars, menus, etc.
As for your Win32 library, again I don't know exactly what capabilities it provides. If it is mainly a mixture of graphical things, then Graphics.Win32 would be right, but if it is wider in scope, such as perhaps interfacing to the entire win32 DLL, then System.Win32 would seem more appropriate.
It provides graphics (as in X11), input (as in X11), dialogue boxes (unlike X11), file I/O (as in Posix), Win32 registry stuff, and a bunch of other stuff. It seems like System.Win32 is the right place to put this in analogy to System.Posix. A
participants (2)
-
Alastair Reid -
Malcolm Wallace