Thread: Autoconf options

Here is the list of options that I am going to support.  If anyone has
comments, changes, etc.  please let me know, otherwise I will go ahead
with these options:

--with-wx=DIR  Specifies the root directory of the wxWindows
installation (--prefix=DIR passed to configure when building
wxWindows).  If this setting is *not* specified, then configure will
search for wxWindows in /usr, /usr/local, and /usr/local/wx2.

--with-pgsql=DIR  Same as above, except configure searches for pgsql in
/usr, /usr/local, and /usr/local/pgsql

--with-pgsql-include=DIR Explicitly specify the pgsql includes directory

--enable-debug  Compiles a debug version of pgAdmin3.  This will
override CFLAGS and CXXFLAGS and pass "-g -Wall -O0" to both of them,
ensuring no optimization code is used.

--enable-static  Compiles a static (as static as possible, that is)
version of pgAdmin3.  This will pass a --static and --static-glibc
option to the linker, to link against libc statically (this really won't
do much, but it doesn't hurt).  This will also link against static
version of pgsql and wxWindows.


DEPRECATED:

--enable-wx-gtk2 Compiles against the gtk2 version of wxWindows

--enable-wx-unicode Compiles against the unicode version of wxWindows

--enable-wx-release  Compiles against the release version of wxWindows

--with-wx-config=FILE Explicitly specify which wx-config program to use,
full path not necessary


COMMENTS:

Here are my comments about the above options.  I, personally, don't like
the last four options, because they are only necessary when a user has
more than one version of wxWindows on their box.  I am *not* going to
include them unless I hear otherwise, and here's why.  If a user, or a
developer, wants to compile against multiple version of wxWindows to
test options, etc. (a perfectly reasonable situation), then they can
compile and install wxWindows with different prefixes.  So pass a
different --prefix=DIR to the wxWindows configure, and then pass that
directory to the pgAdmin3 configure with --with-wx=DIR, and pgAdmin3
will compile against that version.  Installing two different versions of
wxWindows to the same prefix is probably bad news anyway (what if there
are different versions of headers for Unicode?  The old versions would
get overwritten).  I don't think it's necessary to support different
versions in the same directory structure, and I see no need to do so.
Correct me if I am wrong, but otherwise the pgAdmin3 configure will
automagically detect which version of wxWindows you have specified and
link accordingly.

As for creating backwards-compatible versions of the autoconf scripts,
Andreas is right.  There is no need to do this.   You do *not* need to
run 'bootstrap' to create a snapshot, you only need to run 'configure'.
In truth, it's probably not necessary to even distribute bootstrap,
configure.ac, Makefile.am, or acinclude.m4 in our snapshots.  The only
reason for doing so is to help support platforms where the configure
code fails (it happens, but not very often).  Distributing those files
would allow a user to re-generate configure if needed.  In most cases,
it is not necessary.  So unless 'configure' doesn't run on Mandrake or
SuSE or Debian or whatever, I feel no need to produce
backwards-compatible scripts.   Obviously I bow to the core developers
on this one, just let me know.

ahp

> -----Original Message-----
> From: Adam H. Pendleton [mailto:fmonkey@fmonkey.net]
> Sent: 20 June 2003 17:02
> To: pgadmin-hackers@postgresql.org
> Subject: [pgadmin-hackers] Autoconf options
>
>
> Here is the list of options that I am going to support.  If
> anyone has
> comments, changes, etc.  please let me know, otherwise I will
> go ahead
> with these options:
>
> --with-wx=DIR  Specifies the root directory of the wxWindows
> installation (--prefix=DIR passed to configure when building
> wxWindows).  If this setting is *not* specified, then configure will
> search for wxWindows in /usr, /usr/local, and /usr/local/wx2.

OK.

> --with-pgsql=DIR  Same as above, except configure searches
> for pgsql in
> /usr, /usr/local, and /usr/local/pgsql

OK.

> --with-pgsql-include=DIR Explicitly specify the pgsql
> includes directory

${PGHOME}/lib will still be used to find libpq.a I assume?

> --enable-debug  Compiles a debug version of pgAdmin3.  This will
> override CFLAGS and CXXFLAGS and pass "-g -Wall -O0" to both of them,
> ensuring no optimization code is used.

OK.

> --enable-static  Compiles a static (as static as possible, that is)
> version of pgAdmin3.  This will pass a --static and --static-glibc
> option to the linker, to link against libc statically (this
> really won't
> do much, but it doesn't hurt).  This will also link against static
> version of pgsql and wxWindows.

OK. Don't forget stc and xrc - that's what I had to fix this morning (it
was good pratice!) :-)

>
> DEPRECATED:
>
> --enable-wx-gtk2 Compiles against the gtk2 version of wxWindows

Should we deprecate this yet? How long has GTK2 been fairly standard?

> --enable-wx-unicode Compiles against the unicode version of wxWindows

Yes. GTK2 should imply Unicode. I see no reason why you might want GTK2
without it.

> --enable-wx-release  Compiles against the release version of wxWindows

Yes, should be default now, with the --enable-debug implicity requiring
the debug version of wx.

> --with-wx-config=FILE Explicitly specify which wx-config
> program to use,
> full path not necessary

See below.

>
> COMMENTS:
>
> Here are my comments about the above options.  I, personally,
> don't like
> the last four options, because they are only necessary when a
> user has
> more than one version of wxWindows on their box.  I am *not* going to
> include them unless I hear otherwise, and here's why.  If a
> user, or a
> developer, wants to compile against multiple version of wxWindows to
> test options, etc. (a perfectly reasonable situation), then they can
> compile and install wxWindows with different prefixes.  So pass a
> different --prefix=DIR to the wxWindows configure, and then pass that
> directory to the pgAdmin3 configure with --with-wx=DIR, and pgAdmin3
> will compile against that version.  Installing two different
> versions of
> wxWindows to the same prefix is probably bad news anyway
> (what if there
> are different versions of headers for Unicode?  The old
> versions would
> get overwritten).  I don't think it's necessary to support different
> versions in the same directory structure, and I see no need
> to do so.
> Correct me if I am wrong, but otherwise the pgAdmin3 configure will
> automagically detect which version of wxWindows you have
> specified and
> link accordingly.

This would require modification of the symlink to switch between release
and debug versions of wxWindows which should certainly have the same
headers. I agree having multiple versions of WX is bad in general (and
if you're clever enough to do it, you should be able to fix the
resulting mess), but debug & release versions should be permitted imho.

Regards, Dave.

Adam H. Pendleton wrote:

> Here is the list of options that I am going to support.  If anyone has
> comments, changes, etc.  please let me know, otherwise I will go ahead
> with these options:
>
> --with-wx=DIR  Specifies the root directory of the wxWindows
> installation (--prefix=DIR passed to configure when building
> wxWindows).  If this setting is *not* specified, then configure will
> search for wxWindows in /usr, /usr/local, and /usr/local/wx2.
>
> --with-pgsql=DIR  Same as above, except configure searches for pgsql
> in /usr, /usr/local, and /usr/local/pgsql
>
> --with-pgsql-include=DIR Explicitly specify the pgsql includes directory
>
> --enable-debug  Compiles a debug version of pgAdmin3.  This will
> override CFLAGS and CXXFLAGS and pass "-g -Wall -O0" to both of them,
> ensuring no optimization code is used.
>
> --enable-static  Compiles a static (as static as possible, that is)
> version of pgAdmin3.  This will pass a --static and --static-glibc
> option to the linker, to link against libc statically (this really
> won't do much, but it doesn't hurt).  This will also link against
> static version of pgsql and wxWindows.
>
>
> DEPRECATED:
>
> --enable-wx-gtk2 Compiles against the gtk2 version of wxWindows
>
> --enable-wx-unicode Compiles against the unicode version of wxWindows
>
> --enable-wx-release  Compiles against the release version of wxWindows
>
> --with-wx-config=FILE Explicitly specify which wx-config program to
> use, full path not necessary
>
>
> COMMENTS:
>
> Here are my comments about the above options.  I, personally, don't
> like the last four options, because they are only necessary when a
> user has more than one version of wxWindows on their box.  I am *not*
> going to include them unless I hear otherwise, and here's why.  If a
> user, or a developer, wants to compile against multiple version of
> wxWindows to test options, etc. (a perfectly reasonable situation),
> then they can compile and install wxWindows with different prefixes.
> So pass a different --prefix=DIR to the wxWindows configure, and then
> pass that directory to the pgAdmin3 configure with --with-wx=DIR, and
> pgAdmin3 will compile against that version.  Installing two different
> versions of wxWindows to the same prefix is probably bad news anyway
> (what if there are different versions of headers for Unicode?  The old
> versions would get overwritten).  I don't think it's necessary to
> support different versions in the same directory structure, and I see
> no need to do so.  Correct me if I am wrong, but otherwise the
> pgAdmin3 configure will automagically detect which version of
> wxWindows you have specified and link accordingly.

I totally agree.

> As for creating backwards-compatible versions of the autoconf scripts,
> Andreas is right.  There is no need to do this.   You do *not* need to
> run 'bootstrap' to create a snapshot, you only need to run
> 'configure'.  In truth, it's probably not necessary to even distribute
> bootstrap, configure.ac, Makefile.am, or acinclude.m4 in our
> snapshots.  The only reason for doing so is to help support platforms
> where the configure code fails (it happens, but not very often).
> Distributing those files would allow a user to re-generate configure
> if needed.  In most cases, it is not necessary.  So unless 'configure'
> doesn't run on Mandrake or SuSE or Debian or whatever, I feel no need
> to produce backwards-compatible scripts.   Obviously I bow to the core
> developers on this one, just let me know.

dito.

Regards,
Andreas

Dave Page wrote:

${PGHOME}/lib will still be used to find libpq.a I assume?

Yes.

OK. Don't forget stc and xrc - that's what I had to fix this morning (it
was good pratice!) :-)

Of course.  :-)

DEPRECATED:

--enable-wx-gtk2 Compiles against the gtk2 version of wxWindows   

Should we deprecate this yet? How long has GTK2 been fairly standard?

Deprecated because it will automatically be detected.

--enable-wx-unicode Compiles against the unicode version of wxWindows   

Yes. GTK2 should imply Unicode. I see no reason why you might want GTK2
without it.

Same situation here.

This would require modification of the symlink to switch between release
and debug versions of wxWindows which should certainly have the same
headers. I agree having multiple versions of WX is bad in general (and
if you're clever enough to do it, you should be able to fix the
resulting mess), but debug & release versions should be permitted imho.
 

Okay, I will add the --with-wx-config=FILE option so that a wx-config file can be specified explicitly.  This should allow side-by-side linking against debug and release.  Without that option specified, release will be the default, and debug will be linked against in --enable-debug is passed.  One question, what if the symlink wx-config points to a debug version of wxWindows, but they don't specify --enable-debug or --with-wx-config.  We would then link against a debug version of the wx library, but release versions of stc and xrc.  Do we care?

ahp

On Friday 20 June 2003 18:02, Adam H. Pendleton wrote:
> --with-pgsql-include=DIR Explicitly specify the pgsql includes directory

This line is really needed for compilation under Mandrake 9.1. Otherwise, the
configure script does not find libpq-fe.h. Same as for SuSE 8.2.

I transfered RedHat configure script on the Mandrake host. It seems to run
well apart from the --with-pgsql-include=DIR problem.

Cheers,
Jean-Michel

-----Original Message-----
From: Adam H. Pendleton [mailto:fmonkey@fmonkey.net]
Sent: 20 June 2003 17:34
To: Dave Page
Cc: pgadmin-hackers@postgresql.org
Subject: Re: [pgadmin-hackers] Autoconf options

This would require modification of the symlink to switch between release
and debug versions of wxWindows which should certainly have the same
headers. I agree having multiple versions of WX is bad in general (and
if you're clever enough to do it, you should be able to fix the
resulting mess), but debug & release versions should be permitted imho.
 

Okay, I will add the --with-wx-config=FILE option so that a wx-config file can be specified explicitly.  This should allow side-by-side linking against debug and release.  Without that option specified, release will be the default, and debug will be linked against in --enable-debug is passed.  One question, what if the symlink wx-config points to a debug version of wxWindows, but they don't specify --enable-debug or --with-wx-config.  We would then link against a debug version of the wx library, but release versions of stc and xrc.  Do we care?