On Mon, 18 Mar 2002, Eric Faurot wrote:
> I have two questions concerning the files include/ggi/input/*.h
> and include/ggi/display/*.h
>
> Why are these found in the main ggi include dir? I think they
> should rather be in g[gi]i/{input|filter|display}/* and get
> installed only if necessary.
I think Christoph had a reason for moving those, but my memory is vague.
If we move them back we should have a document defining the rationale
behind the source tree structure, such that later on someone doesn't
decide they belong back where they are now.
> This leads me to my second question:
> Why are they installed anyway? Is there a particular reason for
> which an application or module would mess with the internals of
> another module?
Extension sublibs source trees will use these files in order to access
target-private structures. All the extensions may currently be ours
and in GGI CVS, but there's no guarantee that things will stay that way.
If company XYZ is developing an in-house extension technically they should
be able to compile it with only the GGI development headers installed.
> A clearer separation should be made between the core libs and
> their modules. Ideally, the build system should work like
> the linux kernel, separated compile and install process for modules.
> A simple app could be written to add/remove modules in the
> lib*.conf: something like : "ggiconf add <module name> <path/to/so>"
> This would also make it easier for third-party to provide modules.
>
> Comments?
Well, said app is so simple it isn't worth it's own inode, but I agree with
the major point, being discrete module build/install would be a neat
feature. Being able to plop a target subdirectory into the source tree and
include it in the build by only editing 1 or 2 simple files would be sweet.
If Thayne is still alive :) I'd be interested in hearing his opinion on
what this would take.
--
Brian
