Skip site navigation (1) Skip section navigation (2)

Re: Autoconf options

From: Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>
To: "Adam H(dot) Pendleton" <fmonkey(at)fmonkey(dot)net>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Autoconf options
Date: 2003-06-20 16:21:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
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.
> --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
> 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,,, 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.



In response to

pgadmin-hackers by date

Next:From: Jean-Michel POUREDate: 2003-06-20 16:30:16
Subject: Re: I'm Back
Previous:From: Dave PageDate: 2003-06-20 16:20:12
Subject: Re: Autoconf options

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group