> 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.
But then we have to make sure, that both the lib and the headers are in the right directories to not break the compiling process for extension targets using them. > > > 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. That can also be done by providing a versioning system as suggested by Alex Beregszaszi on this list. > > > 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. No, please don't. That would become too complicated and convusing for developers, IMO. The number of extensions and libs will increase in future and not reduced. We should rewrite/redesign the build system in a way, that we can package and release each driver separately from the whole GGI extension/lib instead. > 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... That's a really good question. I don't know, who did that. IIRC, that was already done before I tested GGI the first time years ago. :) -- CU, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
"
Description: Binary data
