From: <do...@co...> - 2000-01-29 20:17:14
|
> > > >> There are plenty of large projects with their own make programs. > > > this is BAD. > > I disagree. I think it's fine, for instance, that cl-http comes with > > its own build-cl-http function. I don't know or care how it's > > implemented. > > The question you should ask is "why does CL-HTTP comes with its own > build utilitiy?" > > I believe the answer is "because up to now there was no acceptable and > docemented and stand-alone 'defsystem' running on all implementations. > > I bet that the CL-HTTP developers would have chosen MK:DEFSYSTEM > (which does not have the pretense of "being better") had it been > "available" when they started (where "available" is to be intended in > a wide, license-encompassing, way). This is certainly one possibility, and my view is that if this is the case, nobody should mind that they don't rush to replace whatever they have with a standard defsystem. > > Do you imagine that there is no cost to replacing something that > > already works? Generally it takes a considerable effort even to > > determine that the replacement actually has all the capabilities that > > you need. I don't know much about mk defsystem (other than what I've > > read in the last hour), but I'm willing to bet right now that it does > > not have all that I'd need to replace the homegrown defsystems that > > I've been maintaining. > > Well, try MK:DEFSYSTEM out and make a list of missing features. Then, > if you are still not satisfied advocate the use of your defsystem and > make it available as a standalone module. You imagine there is one ideal defsystem for all uses. I don't buy that. A system that supports lots of complex features is not worth the trouble for simple uses. Just like defsystem is not worth the trouble for very small facilities. [[my tangled dependency hierarchy nightmare]] > Allow me to say that this is the situation you run in C/C++ I agree, but that doesn't make it any more attractive. > programming as well. So you should not be terrified by it. As far as > the CLOCC is concerned I'd hope that the code appearing here would be > tested as much as possible on as many platforms as possible. So, the > possibility to run into errors should be minimized. My point is that we can minimize the problem by minimizing dependencies to those that are essential. [[examples of such problems]] > What are you supposed to do in this case? Write code that does not > use these fetures because it may cause problems to somebody wanting to > use your code? Or do you work around them? I choose to work around > them and hope the the full code will be therefore more useful. I agree this is better. It's impossible to avoid features that don't work in implementations you don't even know about. > Logically "a system" should be standalone. If your system depends on > another system, then this should mean that you are using the > "advertised interface" provied to you by the designer of the > system/library/whatever. Yes, that is correct. If your system is stand alone then I am happy (in the sense of this discussion) since there are NO dependencies. I begin to see that part of the question here is what constitutes a system. One of my desires is that I should be able to get not much more code than I need. That argues that Sam's cllib should not be one system, take it or leave it. I should be able to get the url stuff without getting the animals or gnuplot stuff (I don't really know whether these are realistic examples). On the other hand, if he breaks cllib into 10 systems, there will be a lot of dependencies between them. I don't mind that, as long as those are really essential dependencies, e.g., getting stock quotes off the web relies on web stuff. What the downloading user then needs (I don't know what we have now) is (1) a tar/gzip bundle of all the files that make up one system so he doesn't have to find and download them separately, and (2) some facility for tracing the dependencies among systems that helps him to download the transitive closure of those systems needed by the one he wants. Since we do seem to have versioning, it would be nice if these things were version sensitive. That is, the "database" I have in mind should indicate that system get-quote version 3.2 relies on system web-interface version 5.3. If I want to load get-quote 3.2 and also animals 4.5, and one of these relies on base 2.1 while the other relies on base 2.2, there's an incompatibility. (BTW, this is the kinds of thing that is supported by on of the build facilities I mentioned earlier.) > > More to the point, though, even if you could do this, the dependencies > > are only among files, right? Or is there a model of dependency among > > individual top level forms? (We used to have something like this in > > a project I worked on, but I've never seen it anywhere else.) > > You may ahev dependencies among "modules" (i.e. collections of > components, e.g. files). It seems to me that you are wanting a very > fine grained dependency definition. What is the "semantic" ground you > base this request? This was not actually a request. The point is that without such a fine grained dependency model you have to put some effort into organizing files so as to minimize dependencies. |