On Tue, 2010-04-13 at 00:11 +0200, Andreas Rottmann wrote: > On the other hand, I have some uses of `include' in > my own libraries; using (ported private include) from e.g. spells would > feel kind of dirty. I could imagine getting rid of `include' in spells, > but there might be people who prefer this style of separating the code > and the library metadata.
I wouldn't do that. Keep using your own include for your own stuff. I plan to do that. I like that our personal collections explore differences. > Thus IMHO, it there would be merit in > providing such a basic tool as `include' in a public package, separate > from the `ported' collection of packages. There is merit in consolidated functionality, but as our different include libraries show, as well as more fundamental differences such as locating the files in some other way (e.g. relative to the including file, instead of searching the library search path), there's different ways to do it, and I don't want to take on The One Include Library to Rule Them All and Make Everyone Happy. > I can't think of a decent name for such a > package, however. That's another reason I'm wanting to keep include stuff private to separate projects. We'll have to start another project of public general-purpose utilities to make everyone happy, and I think it's too early for that and it may never work out. > > My main point was that because these (ported ---) libraries' usage of > > include or pathname functionality is behind-the-scenes, you and I don't > > need to focus on consolidating our personal libraries of such > > functionality. > > > Don't we essentially already need to do that for the `ported' project? I think we should review the aspects of our different include libraries, which might result in some consolidation, but the consolidation I've been saying not to do is making a public include library advertised for use in other projects. > I'm leaning towards > something closer to xitomatl than spells, as spells' `include' in its > current form drags along a whole bunch of other stuff -- I want the > include facility to be as lightweight as reasonable for the ported > project. I want it lightweight like that too, but I'd like it to use stale-when, read-annotated, and file-mtime (or equivalents) for the reasons Xitomatl's does, but maybe it shouldn't. This is what I'm talking about, we don't know how we want it to be for this project, so let's not try to make something for broad public use pretending we know how it should be for other projects. -- : Derick ----------------------------------------------------------------
