A simpler way to configure the source code?

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

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

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

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.

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

-----Original Message-----
From: Justin Clift [mailto:justin@postgresql.org]
Sent: 30 January 2002 14:19
To: Peter Eisentraut
Cc: PostgreSQL Development
Subject: Re: [HACKERS] A simpler way to configure the source code?

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.

+1 (not that this is a vote :-) )

Regards, Dave.

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.

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

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

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.

+1 (not that this is a vote :-) )

Hmmm...yuck. I think a --with-everything is a good idea, but surely all
that needs be done is make the regression test test everything? It's
annoying little setup scripts that make porting things to FreeBSD a pain...

-1

Chris

Christopher Kings-Lynne wrote:

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.

+1 (not that this is a vote :-) )

Hmmm...yuck. I think a --with-everything is a good idea, but surely all
that needs be done is make the regression test test everything? It's
annoying little setup scripts that make porting things to FreeBSD a pain...

-1

Hi Chris,

Would you consider it to be an "alright thing" if it was an optional
feature? As in, people could use the interactive menu if they wanted,
or they could do the --with-whatever (--with-everything is prob a good
idea too) as per normal?

:-)

Regards and best wishes,

Justin Clift

Chris

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

--
"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

Hi Chris,

Would you consider it to be an "alright thing" if it was an optional
feature? As in, people could use the interactive menu if they wanted,
or they could do the --with-whatever (--with-everything is prob a good
idea too) as per normal?

I'm sure I could deal :)

Chris

-----Original Message-----
From: Christopher Kings-Lynne [mailto:chriskl@familyhealth.com.au]
Sent: 31 January 2002 01:34
To: Dave Page; 'Peter Eisentraut'
Cc: 'PostgreSQL Development'
Subject: Re: [HACKERS] A simpler way to configure the source code?

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.

+1 (not that this is a vote :-) )

Hmmm...yuck. I think a --with-everything is a good idea, but
surely all that needs be done is make the regression test
test everything? It's annoying little setup scripts that
make porting things to FreeBSD a pain...

I seem to recall that Peter's proposal was for a script that drove configure
for you so presumably you could either use the script, or ignore it and
./configure --with..... if you preferred.

If this were the case I don't see how anyone could object as long as it's
nice and portable and is easy to maintain.

Regards, Dave.