On Mon Apr 21 17:02:58 2008, [EMAIL PROTECTED] wrote: [snip] > > > * Is new configuration step X::X *necessary* for the functioning > > of the Parrot virtual machine? > > Frankly, probably nothing but the basic "does the compiler exist, and is > it sane" type of tests meet that qualification. >
If we do write a PDD for configuration, we should probably identify the config steps that do this and distinguish them from the library-locators. > > [snip] > > And we also need a document defining what steps an implementer should > follow when adding or modifying configuration steps. ... docs/configuration.pod doesn't > seem to mention tests at all. Once everyone has had her/his say, on this issue, we can remedy that. > > All this feature detection stuff is very interdependent, and when a > new feature comes along without sufficient testing, there is a chance > that it will get in everyone else's way. So in the short term, where > each such feature incurs some maintenance overhead and breakage affects > people working on unrelated things, you are making a very valid point. > > In the longer term, I am hoping that we end up with a sort of "CPAN for > Parrot". Specifically, for all of: Parrot applications, Parrot language > modules, and Parrot library-wrapper plugins, like opengl. (And gettext. > And readline. And sdl. And postgresql. And bigint.) And they can > all do whatever system detection they need, and they can all depend on > each other as needed. > > But the core of that strategy is, if these things have their own > detection/generation process which isn't always run for everybody, they > don't get in the way of people who don't care about them. > > So I guess my idea of the the status quo is, "until we can split our > thousands of obscure features into separate packages, we sorta just > have to live with them". But maybe we could have a happy medium: > suppose you only get opengl when you specify --enable-opengl on the > command line? Or it could be generated from "make opengl" or by > running "make" in a special directory or some such? This kind of > mechanism might not be good in the long term, but in the short term, it > should prevent people from stomping on each other so much. > Very good points. > Another note, slightly off-topic: does OpenGL actually need a > configuration/detection step at all? I notice neither SDL or > PostgreSQL seem to have one. Maybe they're detecting everything at > runtime, or maybe their generated stuff runs from make instead of from > configure? As purl would say, I haven't the foggiest how they work in Parrot. On the other hand, the config system is modularized into > nice neat little steps, which makes them terribly easy to write and > maintain, so it seems a shame not to use them. :) > particle suggested on #parrot the weekend before last that the config system should be completely pluggable, which means that, among other things, config step classes should be able to call other config step classes from inside them. That would mean that our config system would have to be even more modularized than it is today. Thanks for taking the time to provide this feedback. kid51
