Thread
-
A simpler way to configure the source code?
Peter Eisentraut <peter_e@gmx.net> — 2002-01-30T00:33:29Z
The other day, I did a test build of "everything", which involved specifying 17 command-line arguments to configure. This is probably the reason why some fringe features are not tested very often: the list of options is pretty overwhelming. I remembered that in the old days PHP had an interactive setup script, that asked you mainly yes/no questions about each feature you wanted, and would run "configure" based on the answers it got. This sort of thing might help our situation, because instead of having to specify all the options, users can just keep pressing Y all the time. Of course it could also be considered as a general improvement in user-friendliness. Now I just realized that the latest PHP source code doesn't have this thing anymore, so maybe they didn't like it? What do you think? As far as maintaining something like this goes, I think I have an idea that would basically require zero effort, so at least that shouldn't be too much of a concern. -- Peter Eisentraut peter_e@gmx.net
-
Re: A simpler way to configure the source code?
Don Baccus <dhogaza@pacifier.com> — 2002-01-30T00:43:01Z
Peter Eisentraut wrote: > Now I just realized that the latest PHP source code doesn't have this > thing anymore, so maybe they didn't like it? What do you think? The linux kernel has something like this, maybe PHP was using it and maybe they dropped it when they went from the GPL to the more liberal license they're using now? -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org
-
Re: A simpler way to configure the source code?
Tom Lane <tgl@sss.pgh.pa.us> — 2002-01-30T00:44:11Z
Peter Eisentraut <peter_e@gmx.net> writes: > The other day, I did a test build of "everything", which involved > specifying 17 command-line arguments to configure. This is probably the > reason why some fringe features are not tested very often: the list of > options is pretty overwhelming. "--with-everything"? Or more usefully, "--with-everything --without-perl" if, say, you don't have Perl installed. Or you could just reverse the defaults on all the options, but that'd likely provoke a revolt. > I remembered that in the old days PHP had an interactive setup script, Perl's got one of those too, and I hate it ... regards, tom lane
-
Re: A simpler way to configure the source code?
Mitch <mitch@doot.org> — 2002-01-30T01:33:22Z
> > I remembered that in the old days PHP had an interactive setup script, > > Perl's got one of those too, and I hate it ... As do I.. I disliked the PHP one too. Getting all the options setup initially is a bit daunting but once you have your options, you can save it and cut/paste it in the future (which is what I do, I have an entire doc dedicated to configure options and such of the servers I configure)... Still, I'm not sure it's a huge issue as normal users probably don't recompile very often... I don't think switching to an interactive script would be good but giving people the option will make some users happy I'm sure.. -Mitchell
-
Re: A simpler way to configure the source code?
Haroldo Stenger <hstenger@adinet.com.uy> — 2002-01-30T02:41:29Z
Tom Lane wrote: > > I remembered that in the old days PHP had an interactive setup script, > > Perl's got one of those too, and I hate it ... Yes, it sucks. Linux for instance, offers three (up to my knowledge) ways of handling setup. A) A yes/no array of questios B) A text mode, menuized approach C) A graphic mode, with buttons which open menus. I find B) especially friendly. Regards, Haroldo.
-
Re: A simpler way to configure the source code?
Justin Clift <justin@postgresql.org> — 2002-01-30T14:19:03Z
Peter Eisentraut wrote: > > The other day, I did a test build of "everything", which involved > specifying 17 command-line arguments to configure. This is probably the > reason why some fringe features are not tested very often: the list of > options is pretty overwhelming. > > I remembered that in the old days PHP had an interactive setup script, > that asked you mainly yes/no questions about each feature you wanted, and > would run "configure" based on the answers it got. This sort of thing > might help our situation, because instead of having to specify all the > options, users can just keep pressing Y all the time. Of course it could > also be considered as a general improvement in user-friendliness. > > Now I just realized that the latest PHP source code doesn't have this > thing anymore, so maybe they didn't like it? What do you think? > > As far as maintaining something like this goes, I think I have an idea > that would basically require zero effort, so at least that shouldn't be > too much of a concern. I feel having the "fringe features" more tested is a great idea, and will lead to a better PostgreSQL, and therefore happier users. :) A friendly, and decently-easy-to-user interactive setup (Linux "menuconfig" kernel style?) would be beneficial. If it doesn't add signifcant overhead to maintenance, and is very portable, it sounds to me like a good idea. :-) Regards and best wishes, Justin Clift > > -- > Peter Eisentraut peter_e@gmx.net > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
-
Re: A simpler way to configure the source code?
Trond Eivind Glomsrød <teg@redhat.com> — 2002-01-30T15:50:05Z
Peter Eisentraut <peter_e@gmx.net> writes: > The other day, I did a test build of "everything", which involved > specifying 17 command-line arguments to configure. This is probably the > reason why some fringe features are not tested very often: the list of > options is pretty overwhelming. > > I remembered that in the old days PHP had an interactive setup script, > that asked you mainly yes/no questions about each feature you wanted, and > would run "configure" based on the answers it got. This sort of thing > might help our situation, because instead of having to specify all the > options, users can just keep pressing Y all the time. Of course it could > also be considered as a general improvement in user-friendliness. I hated that (same for perl). -- Trond Eivind Glomsrød Red Hat, Inc.
-
Re: A simpler way to configure the source code?
Kaare Rasmussen <kar@kakidata.dk> — 2002-01-30T19:46:09Z
> Perl's got one of those too, and I hate it ... You mean the endless number of questions when making Perl? No, the Linux kernel has a nice menu based script. It will remember the last choice if you build more than one time and you only have to choose the areas you'd like to change. It's very nice. There's a tk based frontend, I think, and there's extensive explanation for each point, so you almost always know why you have to choose on or off even for features you may not know too well. -- Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582 Kaki Data tshirts, merchandize Fax: 3816 2501 Howitzvej 75 Åben 14.00-18.00 Web: www.suse.dk 2000 Frederiksberg Lørdag 11.00-17.00 Email: kar@kakidata.dk
-
Re: A simpler way to configure the source code?
Don Baccus <dhogaza@pacifier.com> — 2002-01-30T20:05:18Z
Kaare Rasmussen wrote: >>Perl's got one of those too, and I hate it ... >> > > You mean the endless number of questions when making Perl? > > No, the Linux kernel has a nice menu based script. It will remember the last > choice if you build more than one time and you only have to choose the areas > you'd like to change. and there's a feature that hides everything except new options. If you've built an older kernel, update, and there are new configuration options you can choose to just see those, and your past choices for older configuration parameters are kept. Handy when someone adds configuration parameters for yet-another-IDE chipset that you don't really give care about. -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org