On Sun, 20 Apr 2008 19:01:44 -0700 James Keenan (via RT) <[EMAIL PROTECTED]> wrote:
Hi! As one of the guilty parties, I'm not sure whether I get a vote, but... > * 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 new step X::X is not necessary for Parrot, what makes it > *desirable*? Why should it be included at the cost of increased > complexity in configuration, build and testing? When I checked in Opengl, it did seem like something that wasn't absolutely necessary. But I have to admit, I checked it in for other reasons. My reasoning was as follows: 1. It seemed more relevant than some stuff that's already in parrot. (I have more machines with OpenGL installed than have postgresql, for example.) 2. The author (Geoff) was responsive, willing and able to fix issues as they arose. Thus, if someone had a problem, we also had someone motivated to fix it. (Your process of silently writing tests, while very helpful and appreciated, negated this effect somewhat.) 3. We didn't have a release pending, thus we are not in feature freeze. > I would like to propose both short-term and long-term remedies. > > Short-term: If you are proposing a new configuration step, or doing > a significant overhaul of any existing step, please post an RT with > the code and with a [TODO] tag several days ahead of time. This > will give people a chance to run it on different OSes right away, > without compromising trunk. And if I get advance notice of any new > config step, I pledge to work with you to develop tests for that step. > > Long-term: We need a Parrot design document on configuration. Such > a document should cover what configuration is, why we have decided > to include the configuration steps already there, what we need and > what we don't need. Such a document should distinguish between what > we need between now and 1.0 OTOH and post-1.0 OTO. And we also need a document defining what steps an implementer should follow when adding or modifying configuration steps. You are right, the process for OpenGL was a bit rocky, but in my defense, "I didn't know any better". Actually, I don't really know much at all about the config system, or the testing thereof. docs/configuration.pod doesn't seem to mention tests at all. Maybe if it did, then the next time someone like me comes along and breaks everything, then you'll have something to whack them over the head with. 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. 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? 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. :) Mark
