Am Dienstag, 9. Mai 2006 10:55 schrieb Martijn van Oosterhout:
> Can you explain why? Unknown options don't do anything, so having users
> remove them seems like a good move.

Build system frameworks assume that they can pass any option and that unknown
options will be ignored. This grew out of the old Cygnus GNU megatree but as
you saw it is also used by package building frameworks like CDBS. In fact,
if we one day separate the PLs into separate source tarballs, I'd like to set
up a similar megatree system so building everything becomes easier.

I don't object to having a strict mode or printing warnings or printing a
summary at the end, but we are not in a position to redefine build system
practice.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Marko Kreen wrote:
> On 5/9/06, Peter Eisentraut <peter_e@gmx.net> wrote:
> > Am Freitag, 5. Mai 2006 20:07 schrieb Martijn van Oosterhout:
> > > 1. Provide an escape option they can add
> > > 2. Package systems can usually apply patches prior to compiling, they can
> > > always remove the offending line if they like.
> > > 3. Try and get feedback from them now rather than wait
> >
> > My feedback is this: You are going to enter a world of pain.
>
> Seems that way. Especially if the non-PGAC options won't be
> handled automatically.
>
> Some projects have solved the problem different way - by printing
> out the summary of most important options at the end of configure:
>
> PostgreSQL version X.X.X
> OpenSSL: no
> Integer datatime: yes
> Python: yes
> Perl: yes
>
> So at the end of configure the user can visually confirm
> his expectations without needing to parse the noise
> from full configure output. Maybe this would be better
> solution.

Seems we would be best printing out options we _didn't_ undertand at the
end of the build.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Tue, May 09, 2006 at 11:35:32AM -0400, Bruce Momjian wrote:
> > So at the end of configure the user can visually confirm
> > his expectations without needing to parse the noise
> > from full configure output. Maybe this would be better
> > solution.
>
> Seems we would be best printing out options we _didn't_ undertand at the
> end of the build.

I can live with that. It's a minor tweak...

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEYNJeIB7bNG8LQkwRAgMZAKCRlAzWoK2EiooTmyDcRx sgSHRV+gCfftXq
KxspyVE51ZBPkFe1u4RaVag=
=teTp
-----END PGP SIGNATURE-----

On Tue, May 09, 2006 at 02:00:34PM +0200, Peter Eisentraut wrote:
> Am Dienstag, 9. Mai 2006 10:55 schrieb Martijn van Oosterhout:
> > Can you explain why? Unknown options don't do anything, so having users
> > remove them seems like a good move.
>
> Build system frameworks assume that they can pass any option and that unknown
> options will be ignored. This grew out of the old Cygnus GNU megatree but as
> you saw it is also used by package building frameworks like CDBS. In fact,
> if we one day separate the PLs into separate source tarballs, I'd like to set
> up a similar megatree system so building everything becomes easier.
>
> I don't object to having a strict mode or printing warnings or printing a
> summary at the end, but we are not in a position to redefine build system
> practice.

Then it seems like the best way to go would be to provide
--disable-strict-mode. I dislike the idea of printing a summary, because
it's easy to miss problems there, and it's also very counter-intuitive.
Until now I'd always assumed that configure would always complain about
invalid arguments because I've seen it happen before; I didn't think
you'd actually have to write code to make it do that (talk about a
brain-dead tool...)

In any case, I think the real use case here is catching errors from
general users who are installing from source, which disqualifies
--enable-strict as well as setting a shell alias.

Hopefully no one finds any need to use --disable-strict and it can just
be dropped down the road...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend