Christoph Egger writes: > > 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. > > If there is a way to still allow this with Eric's suggestion, then we go his > way, IMO.
Well, I see nothing wrong with keeping these headers in the module directories, and install them with the lib itself. > > Well, said app is so simple it isn't worth it's own inode, The application may not be very complicated but it can help installing modules automatically. > > 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. > > Indeed We could enforce this by taking the whole display/input dir out of the libs tree and create a separate 'modules' repository, with one subdir for each lib/extension. Then we could provide separate releases for driver updates. BTW, I'm not sure I understand the 'default/' in libgii. AFAIK, it's for generic code that can be shared by different targets. So it's ok for linear_*, but why fbdev is not in display? And there are lots of kgi stuff too... Eric. --
