Re: [pgadmin-hackers] SVN Commit by dpage: r4203 - trunk/pgadmin3/xtra/pgagent/pgaevent
-Original Message- From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 18 May 2005 18:02 To: Dave Page Cc: pgadmin-hackers@postgresql.org Subject: Re: [pgadmin-hackers] SVN Commit by dpage: r4203 - trunk/pgadmin3/xtra/pgagent/pgaevent [EMAIL PROTECTED] wrote: Author: dpage Date: 2005-05-18 11:59:26 +0100 (Wed, 18 May 2005) New Revision: 4203 Modified: trunk/pgadmin3/xtra/pgagent/pgaevent/Makefile.am Log: Hmm, wonder why this isn't working as expected. Easily explained: It should look $Id: $ The general format is Dollar, keyword, Colon, some stuff from RCS/CVS/SVN/younameit, Dollar. Nope - $Id$ should work according to the docs (and does in fact). Turns out that keyword expansion is turned off by default in SVN. To turn it on for Id, LastChangedDate and Author for example, you need to run: svn propset svn:keywords Id LastChangedDate Author filename Haven't figured out how to do that in Tortoise yet though Thanks, Dave ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[pgadmin-hackers] SVN Commit by dpage: r4213 - trunk/pgadmin3
Author: dpage
Date: 2005-05-19 09:31:32 +0100 (Thu, 19 May 2005)
New Revision: 4213
Modified:
trunk/pgadmin3/acinclude.m4
Log:
Attached is a new acinclude.m4, and a patch to our current acinclude,
that relies on wx-config for all the flags. Gone is all the
complicated stuff. The only thing this new acinclude doesn't do is
warn about a missing stc or ogl. It will link against them, but if a
user doesn't have them, their compile will fail. I'll be adding in
stub programs to test for this in my next version. In the meantime,
test and enjoy.
[Adam H. Pendleton]
Modified: trunk/pgadmin3/acinclude.m4
===
--- trunk/pgadmin3/acinclude.m4 2005-05-18 11:34:46 UTC (rev 4212)
+++ trunk/pgadmin3/acinclude.m4 2005-05-19 08:31:32 UTC (rev 4213)
@@ -50,23 +50,15 @@
[AC_ARG_ENABLE(debug,
[ --enable-debug build a debug version of pgAdmin3],
[pg_debug_build=yes
-CFLAGS=-Wall -g -O0
-CXXFLAGS=-Wall -g -O0],
+CLFAGS=`${WX_CONFIG} --cflags --debug`
+CFLAGS=$CFLAGS -Wall -g -O0
+CPPFLAGS=`${WX_CONFIG} --cppflags --debug`
+CPPFLAGS=$CPPFLAGS -Wall -g -O0],
[pg_debug_build=no])
])
AC_SUBST(pg_debug_build)
-# Static build of pgAdmin3 #
-
-AC_DEFUN([ENABLE_STATIC],
-[AC_ARG_ENABLE(static,
-[ --enable-static build a static version of pgAdmin3],
-[pg_static_build=yes],
-[pg_static_build=no])
-])
-
-
# Build an pgAdmin III.app #
AC_DEFUN([ENABLE_APPBUNDLE],
@@ -263,246 +255,11 @@
LDFLAGS=$LDFLAGS -L${WX_HOME}/lib
WX_OLD_LDFLAGS=$LDFLAGS
WX_OLD_CPPFLAGS=$CPPFLAGS
-if test $pg_static_build = yes
-then
-WX_NEW_LDFLAGS=`${WX_CONFIG} --static --libs`
-else
-WX_NEW_LDFLAGS=`${WX_CONFIG} --libs`
-fi
-
-# Which version of wxWindows is this?
-WX_VERSION=`${WX_CONFIG} --version`
-case ${WX_VERSION} in
-2.6*)
-WX_VERSION=2.6
-;;
-2.5*)
-WX_VERSION=2.5
-;;
-*)
-;;
-esac
-
-# Here we go!!
-if test $pg_static_build = yes
-then
-case ${WX_NEW_LDFLAGS} in
-*libwx_mswud-*)
-LIBS=$LIBS ${WX_HOME}/lib/libwx_mswud_stc-${WX_VERSION}.a
${WX_HOME}/lib/libwx_mswud_ogl-${WX_VERSION}.a
-LIBS=$LIBS $WX_NEW_LDFLAGS
-LDFLAGS=$LDFLAGS -mwindows -Wl,--subsystem,windows
-;;
-*libwx_mswu-*)
-LIBS=$LIBS ${WX_HOME}/lib/libwx_mswu_stc-${WX_VERSION}.a
${WX_HOME}/lib/libwx_mswu_ogl-${WX_VERSION}.a
-LIBS=$LIBS $WX_NEW_LDFLAGS
-LDFLAGS=$LDFLAGS -mwindows -Wl,--subsystem,windows
-;;
-*libwx_mswd-*)
-LIBS=$LIBS ${WX_HOME}/lib/libwx_mswd_stc-${WX_VERSION}.a
${WX_HOME}/lib/libwx_mswd_ogl-${WX_VERSION}.a
-LIBS=$LIBS $WX_NEW_LDFLAGS
-LDFLAGS=$LDFLAGS -mwindows -Wl,--subsystem,windows
-;;
-*libwx_msw-*)
-LIBS=$LIBS ${WX_HOME}/lib/libwx_msw_stc-${WX_VERSION}.a
${WX_HOME}/lib/libwx_msw_ogl-${WX_VERSION}.a
-LIBS=$LIBS $WX_NEW_LDFLAGS
-LDFLAGS=$LDFLAGS -mwindows -Wl,--subsystem,windows
-;;
-*libwx_macud-*)
-LIBS=$LIBS ${WX_HOME}/lib/libwx_macud_stc-${WX_VERSION}.a
${WX_HOME}/lib/libwx_macud_ogl-${WX_VERSION}.a
-LIBS=$LIBS $WX_NEW_LDFLAGS
-;;
-*libwx_macud_core*)
-LIBS=$LIBS ${WX_HOME}/lib/libwx_macud_stc-${WX_VERSION}.a
${WX_HOME}/lib/libwx_macud_ogl-${WX_VERSION}.a
-LIBS=$LIBS $WX_NEW_LDFLAGS
-;;
-*libwx_macd-*)
-LIBS=$LIBS ${WX_HOME}/lib/libwx_macd_stc-${WX_VERSION}.a
${WX_HOME}/lib/libwx_macd_ogl-${WX_VERSION}.a
-LIBS=$LIBS $WX_NEW_LDFLAGS
-;;
-*libwx_macd_core*)
-LIBS=$LIBS ${WX_HOME}/lib/libwx_macd_stc-${WX_VERSION}.a
${WX_HOME}/lib/libwx_macd_ogl-${WX_VERSION}.a
-LIBS=$LIBS $WX_NEW_LDFLAGS
-;;
-*libwx_mac-*)
-LIBS=$LIBS ${WX_HOME}/lib/libwx_mac_stc-${WX_VERSION}.a
${WX_HOME}/lib/libwx_mac_ogl-${WX_VERSION}.a
-LIBS=$LIBS $WX_NEW_LDFLAGS
-;;
-*libwx_mac_core*)
-LIBS=$LIBS ${WX_HOME}/lib/libwx_mac_stc-${WX_VERSION}.a
${WX_HOME}/lib/libwx_mac_ogl-${WX_VERSION}.a
-LIBS=$LIBS $WX_NEW_LDFLAGS
-;;
-*libwx_macu-*)
-LIBS=$LIBS ${WX_HOME}/lib/libwx_macu_stc-${WX_VERSION}.a
${WX_HOME}/lib/libwx_macu_ogl-${WX_VERSION}.a
-LIBS=$LIBS $WX_NEW_LDFLAGS
-;;
-*libwx_macu_core*)
-LIBS=$LIBS ${WX_HOME}/lib/libwx_macu_stc-${WX_VERSION}.a
Re: [pgadmin-hackers] New acinclude.m4
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam H. Pendleton Sent: 18 May 2005 22:26 To: pgadmin-hackers@postgresql.org Subject: [pgadmin-hackers] New acinclude.m4 Attached is a new acinclude.m4, and a patch to our current acinclude, that relies on wx-config for all the flags. Gone is all the complicated stuff. The only thing this new acinclude doesn't do is warn about a missing stc or ogl. It will link against them, but if a user doesn't have them, their compile will fail. I'll be adding in stub programs to test for this in my next version. In the meantime, test and enjoy. Great, thanks Adam - committed. On another note, could someone please check out ./pkg/mac/complete- bundle.sh and chmod +x it? The compile on mac fails with an error because the execute bit is not set. It's already mode 755 on a fresh checkout here. Regards, Dave ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[pgadmin-hackers] SVN Commit by dpage: r4214 - trunk/pgadmin3/xtra/pgagent
Author: dpage
Date: 2005-05-19 10:27:24 +0100 (Thu, 19 May 2005)
New Revision: 4214
Modified:
trunk/pgadmin3/xtra/pgagent/job.cpp
trunk/pgadmin3/xtra/pgagent/pgagent.sql
Log:
Rename jslstarted - jslstart for consistency
Modified: trunk/pgadmin3/xtra/pgagent/job.cpp
===
--- trunk/pgadmin3/xtra/pgagent/job.cpp 2005-05-19 08:31:32 UTC (rev 4213)
+++ trunk/pgadmin3/xtra/pgagent/job.cpp 2005-05-19 09:27:24 UTC (rev 4214)
@@ -144,7 +144,7 @@
rc=serviceConn-ExecuteVoid(
UPDATE pgagent.pga_jobsteplog
- SET jslduration = now() - jslstarted,
+ SET jslduration = now() - jslstart,
jslresult = + NumToStr(rc) + , jslstatus = ' +
stepstatus + '
WHERE jslid= + jpsid);
if (rc != 1 || stepstatus == f)
Modified: trunk/pgadmin3/xtra/pgagent/pgagent.sql
===
--- trunk/pgadmin3/xtra/pgagent/pgagent.sql 2005-05-19 08:31:32 UTC (rev
4213)
+++ trunk/pgadmin3/xtra/pgagent/pgagent.sql 2005-05-19 09:27:24 UTC (rev
4214)
@@ -131,7 +131,7 @@
jslcode text NOT NULL,
jslstatuschar NOT NULL CHECK (jslstatus IN ('r',
's', 'i', 'f')) DEFAULT 'r', -- running, success, ignored, failed
jslresultint2 NULL,
-jslstarted timestamptz NOT NULL DEFAULT current_timestamp,
+jslstart timestamptz NOT NULL DEFAULT current_timestamp,
jslduration interval NULL
) WITHOUT OIDS;
CREATE INDEX pga_jobsteplog_jslid ON pgagent.pga_jobsteplog(jsljlgid);
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[pgadmin-hackers] SVN Commit by dpage: r4215 - trunk/pgadmin3/xtra/pgagent
Author: dpage
Date: 2005-05-19 10:42:43 +0100 (Thu, 19 May 2005)
New Revision: 4215
Modified:
trunk/pgadmin3/xtra/pgagent/job.cpp
trunk/pgadmin3/xtra/pgagent/pgagent.sql
Log:
No need to dup the dbname and code from the step into the step log.
Modified: trunk/pgadmin3/xtra/pgagent/job.cpp
===
--- trunk/pgadmin3/xtra/pgagent/job.cpp 2005-05-19 09:27:24 UTC (rev 4214)
+++ trunk/pgadmin3/xtra/pgagent/job.cpp 2005-05-19 09:42:43 UTC (rev 4215)
@@ -89,8 +89,8 @@
{
jpsid=id-GetString(id);
DBresult *res=serviceConn-Execute(
- INSERT INTO pgagent.pga_jobsteplog(jslid,
jsljlgid, jsldbname, jslcode)
- SELECT + jpsid + , + jobid + , ' +
steps-GetString(jstdbname) + ', jstcode
+ INSERT INTO pgagent.pga_jobsteplog(jslid,
jsljlgid, jslstatus)
+ SELECT + jpsid + , + jobid + , 'r'
FROM pgagent.pga_jobstep WHERE jstid= +
steps-GetString(jstid));
if (res)
Modified: trunk/pgadmin3/xtra/pgagent/pgagent.sql
===
--- trunk/pgadmin3/xtra/pgagent/pgagent.sql 2005-05-19 09:27:24 UTC (rev
4214)
+++ trunk/pgadmin3/xtra/pgagent/pgagent.sql 2005-05-19 09:42:43 UTC (rev
4215)
@@ -114,21 +114,19 @@
CREATE TABLE pgagent.pga_joblog (
jlgidserial NOT NULL PRIMARY KEY,
jlgjobid int4 NOT NULL REFERENCES pgagent.pga_job
(jobid) ON DELETE CASCADE ON UPDATE RESTRICT,
-jlgstatuschar NOT NULL CHECK (jlgstatus IN ('r',
's', 'f', 'i', 'd')) DEFAULT 'r', -- running, success, failed, internal
failure, died
+jlgstatuschar NOT NULL CHECK (jlgstatus IN ('r',
's', 'f', 'i')) DEFAULT 'r', -- running, success, failed, internal failure
jlgstart timestamptz NOT NULL DEFAULT current_timestamp,
jlgduration interval NULL
) WITHOUT OIDS;
CREATE INDEX pga_joblog_jobid ON pgagent.pga_joblog(jlgjobid);
COMMENT ON TABLE pgagent.pga_joblog IS 'Job run logs.';
-COMMENT ON COLUMN pgagent.pga_joblog.jlgstatus IS 'Status of job: r=running,
s=successfully finished, f=failed';
+COMMENT ON COLUMN pgagent.pga_joblog.jlgstatus IS 'Status of job: r=running,
s=successfully finished, f=failed, i=no steps to execute';
CREATE TABLE pgagent.pga_jobsteplog (
jslidserial NOT NULL PRIMARY KEY,
jsljlgid int4 NOT NULL REFERENCES
pgagent.pga_joblog (jlgid) ON DELETE CASCADE ON UPDATE RESTRICT,
-jsldbnamename NOT NULL,
-jslcode text NOT NULL,
jslstatuschar NOT NULL CHECK (jslstatus IN ('r',
's', 'i', 'f')) DEFAULT 'r', -- running, success, ignored, failed
jslresultint2 NULL,
jslstart timestamptz NOT NULL DEFAULT current_timestamp,
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[pgadmin-hackers] SVN Commit by dpage: r4216 - trunk/pgadmin3/xtra/pgagent
Author: dpage
Date: 2005-05-19 10:53:11 +0100 (Thu, 19 May 2005)
New Revision: 4216
Modified:
trunk/pgadmin3/xtra/pgagent/job.cpp
Log:
Properly reference the job log from the step log
Modified: trunk/pgadmin3/xtra/pgagent/job.cpp
===
--- trunk/pgadmin3/xtra/pgagent/job.cpp 2005-05-19 09:42:43 UTC (rev 4215)
+++ trunk/pgadmin3/xtra/pgagent/job.cpp 2005-05-19 09:53:11 UTC (rev 4216)
@@ -81,16 +81,16 @@
while (steps-HasData())
{
DBconn *conn;
-string jpsid, jpecode;
+string jslid, jpecode;
DBresult *id=serviceConn-Execute(
SELECT nextval('pgagent.pga_jobsteplog_jslid_seq') AS
id);
if (id)
{
- jpsid=id-GetString(id);
+ jslid=id-GetString(id);
DBresult *res=serviceConn-Execute(
INSERT INTO pgagent.pga_jobsteplog(jslid,
jsljlgid, jslstatus)
- SELECT + jpsid + , + jobid + , 'r'
+ SELECT + jslid + , + logid + , 'r'
FROM pgagent.pga_jobstep WHERE jstid= +
steps-GetString(jstid));
if (res)
@@ -146,7 +146,7 @@
UPDATE pgagent.pga_jobsteplog
SET jslduration = now() - jslstart,
jslresult = + NumToStr(rc) + , jslstatus = ' +
stepstatus + '
- WHERE jslid= + jpsid);
+ WHERE jslid= + jslid);
if (rc != 1 || stepstatus == f)
{
status = 'f';
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[pgadmin-hackers] SVN Commit by dpage: r4217 - trunk/pgadmin3/xtra/pgagent
Author: dpage
Date: 2005-05-19 11:06:30 +0100 (Thu, 19 May 2005)
New Revision: 4217
Modified:
trunk/pgadmin3/xtra/pgagent/job.cpp
trunk/pgadmin3/xtra/pgagent/pgagent.sql
Log:
Include the step id in the step log
Modified: trunk/pgadmin3/xtra/pgagent/job.cpp
===
--- trunk/pgadmin3/xtra/pgagent/job.cpp 2005-05-19 09:53:11 UTC (rev 4216)
+++ trunk/pgadmin3/xtra/pgagent/job.cpp 2005-05-19 10:06:30 UTC (rev 4217)
@@ -81,17 +81,19 @@
while (steps-HasData())
{
DBconn *conn;
-string jslid, jpecode;
+string jslid, stepid, jpecode;
+stepid = steps-GetString(jstid);
+
DBresult *id=serviceConn-Execute(
SELECT nextval('pgagent.pga_jobsteplog_jslid_seq') AS
id);
if (id)
{
jslid=id-GetString(id);
DBresult *res=serviceConn-Execute(
- INSERT INTO pgagent.pga_jobsteplog(jslid,
jsljlgid, jslstatus)
- SELECT + jslid + , + logid + , 'r'
- FROM pgagent.pga_jobstep WHERE jstid= +
steps-GetString(jstid));
+ INSERT INTO pgagent.pga_jobsteplog(jslid,
jsljlgid, jsljstid, jslstatus)
+ SELECT + jslid + , + logid + , +
stepid + , 'r'
+ FROM pgagent.pga_jobstep WHERE jstid= +
stepid);
if (res)
{
@@ -116,7 +118,7 @@
conn=DBconn::Get(steps-GetString(jstdbname));
if (conn)
{
-LogMessage(Executing step + steps-GetString(jstid) +
on database + steps-GetString(jstdbname), LOG_DEBUG);
+LogMessage(Executing step + stepid + on database +
steps-GetString(jstdbname), LOG_DEBUG);
rc=conn-ExecuteVoid(steps-GetString(jstcode));
}
else
Modified: trunk/pgadmin3/xtra/pgagent/pgagent.sql
===
--- trunk/pgadmin3/xtra/pgagent/pgagent.sql 2005-05-19 09:53:11 UTC (rev
4216)
+++ trunk/pgadmin3/xtra/pgagent/pgagent.sql 2005-05-19 10:06:30 UTC (rev
4217)
@@ -127,6 +127,7 @@
CREATE TABLE pgagent.pga_jobsteplog (
jslidserial NOT NULL PRIMARY KEY,
jsljlgid int4 NOT NULL REFERENCES
pgagent.pga_joblog (jlgid) ON DELETE CASCADE ON UPDATE RESTRICT,
+jsljstid int4 NOT NULL REFERENCES
pgagent.pga_jobstep (jstid) ON DELETE CASCADE ON UPDATE RESTRICT,
jslstatuschar NOT NULL CHECK (jslstatus IN ('r',
's', 'i', 'f')) DEFAULT 'r', -- running, success, ignored, failed
jslresultint2 NULL,
jslstart timestamptz NOT NULL DEFAULT current_timestamp,
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[pgadmin-hackers] SVN Commit by dpage: r4218 - in trunk/pgadmin3/src/agent: . include
Author: dpage
Date: 2005-05-19 11:30:28 +0100 (Thu, 19 May 2005)
New Revision: 4218
Modified:
trunk/pgadmin3/src/agent/include/pgaJob.h
trunk/pgadmin3/src/agent/include/pgaStep.h
trunk/pgadmin3/src/agent/pgaJob.cpp
trunk/pgadmin3/src/agent/pgaStep.cpp
Log:
Display job step stats
Modified: trunk/pgadmin3/src/agent/include/pgaJob.h
===
--- trunk/pgadmin3/src/agent/include/pgaJob.h 2005-05-19 10:06:30 UTC (rev
4217)
+++ trunk/pgadmin3/src/agent/include/pgaJob.h 2005-05-19 10:30:28 UTC (rev
4218)
@@ -30,6 +30,7 @@
int GetIcon() { return enabled ? PGAICON_JOB : PGAICON_JOBDISABLED; }
void ShowTreeDetail(wxTreeCtrl *browser, frmMain *form=0, ctlListView
*properties=0, ctlSQLBox *sqlPane=0);
+ void ShowStatistics(frmMain *form, ctlListView *statistics);
static pgObject *ReadObjects(pgCollection *collection, wxTreeCtrl
*browser, const wxString restriction=wxEmptyString);
pgObject *Refresh(wxTreeCtrl *browser, const wxTreeItemId item);
bool DropObject(wxFrame *frame, wxTreeCtrl *browser, bool cascaded);
Modified: trunk/pgadmin3/src/agent/include/pgaStep.h
===
--- trunk/pgadmin3/src/agent/include/pgaStep.h 2005-05-19 10:06:30 UTC (rev
4217)
+++ trunk/pgadmin3/src/agent/include/pgaStep.h 2005-05-19 10:30:28 UTC (rev
4218)
@@ -33,6 +33,7 @@
int GetIcon() { return PGAICON_STEP; }
void ShowTreeDetail(wxTreeCtrl *browser, frmMain *form=0, ctlListView
*properties=0, ctlSQLBox *sqlPane=0);
+ void ShowStatistics(frmMain *form, ctlListView *statistics);
static pgObject *ReadObjects(pgCollection *collection, wxTreeCtrl
*browser, const wxString restriction=wxEmptyString);
pgObject *Refresh(wxTreeCtrl *browser, const wxTreeItemId item);
bool DropObject(wxFrame *frame, wxTreeCtrl *browser, bool cascaded);
Modified: trunk/pgadmin3/src/agent/pgaJob.cpp
===
--- trunk/pgadmin3/src/agent/pgaJob.cpp 2005-05-19 10:06:30 UTC (rev 4217)
+++ trunk/pgadmin3/src/agent/pgaJob.cpp 2005-05-19 10:30:28 UTC (rev 4218)
@@ -160,9 +160,67 @@
return job;
}
+void pgaJob::ShowStatistics(frmMain *form, ctlListView *statistics)
+{
+wxString sql =
+wxT(SELECT jlgid)
+wxT(, jlgstatus)
+ wxT(, jlgstart)
+ wxT(, jlgduration)
+wxT(, (jlgstart + jlgduration) AS endtime)
+ wxT( FROM pgagent.pga_joblog\n)
+ wxT( WHERE jlgjobid = ) + NumToStr(GetRecId()) +
+wxT( ORDER BY jlgstart DESC);
+if (statistics)
+{
+wxLogInfo(wxT(Displaying statistics for job %s),
GetFullIdentifier());
+
+// Add the statistics view columns
+ statistics-ClearAll();
+ statistics-AddColumn(_(Run), 70);
+statistics-AddColumn(_(Status), 90);
+ statistics-AddColumn(_(Start time), 125);
+ statistics-AddColumn(_(End time), 125);
+ statistics-AddColumn(_(Duration), 110);
+
+pgSet *stats = database-ExecuteSet(sql);
+ wxString status;
+ wxDateTime startTime;
+ wxDateTime endTime;
+
+if (stats)
+{
+while (!stats-Eof())
+{
+ if (stats-GetVal(1) == wxT(r))
+status = _(Running);
+ else if (stats-GetVal(1) == wxT(s))
+status = _(Successful);
+ else if (stats-GetVal(1) == wxT(f))
+status = _(Failed);
+ else if (stats-GetVal(1) == wxT(i))
+status = _(No steps);
+ else
+status = _(Unknown);
+
+ startTime.ParseDateTime(stats-GetVal(2));
+ endTime.ParseDateTime(stats-GetVal(4));
+
+long pos=statistics-AppendItem(stats-GetVal(0), status,
startTime.Format());
+statistics-SetItem(pos, 3, endTime.Format());
+ statistics-SetItem(pos, 4, stats-GetVal(3));
+
+ stats-MoveNext();
+}
+delete stats;
+}
+}
+}
+
pgaJobObject::pgaJobObject(pgaJob *_job, int newType, const wxString newName)
: pgDatabaseObject(newType, newName)
{
job=_job;
}
+
Modified: trunk/pgadmin3/src/agent/pgaStep.cpp
===
--- trunk/pgadmin3/src/agent/pgaStep.cpp2005-05-19 10:06:30 UTC (rev
4217)
+++ trunk/pgadmin3/src/agent/pgaStep.cpp2005-05-19 10:30:28 UTC (rev
4218)
@@ -142,3 +142,65 @@
}
return step;
}
+
+
+void pgaStep::ShowStatistics(frmMain *form, ctlListView *statistics)
+{
+wxString sql =
+
Re: [pgadmin-hackers] New acinclude.m4
On May 19, 2005, at 4:34 AM, Dave Page wrote:It's already mode 755 on a fresh checkout here.Hmmm, it seems that everything gets a mode of 644 when I use the "download tarball" option from the cvsweb interface (still waiting for a Fink binary for Tiger!).ahp
[pgadmin-hackers] SVN Commit by dpage: r4219 - in trunk/pgadmin3/xtra/pgagent: . include
Author: dpage
Date: 2005-05-19 15:53:32 +0100 (Thu, 19 May 2005)
New Revision: 4219
Modified:
trunk/pgadmin3/xtra/pgagent/connection.cpp
trunk/pgadmin3/xtra/pgagent/include/connection.h
trunk/pgadmin3/xtra/pgagent/include/job.h
trunk/pgadmin3/xtra/pgagent/include/pgAgent.h
trunk/pgadmin3/xtra/pgagent/job.cpp
trunk/pgadmin3/xtra/pgagent/misc.cpp
trunk/pgadmin3/xtra/pgagent/pgAgent.cpp
trunk/pgadmin3/xtra/pgagent/pgAgent.dsp
trunk/pgadmin3/xtra/pgagent/unix.cpp
trunk/pgadmin3/xtra/pgagent/win32.cpp
Log:
Dynamic connection pooling in preparation for threaded operation.
Modified: trunk/pgadmin3/xtra/pgagent/connection.cpp
===
--- trunk/pgadmin3/xtra/pgagent/connection.cpp 2005-05-19 10:30:28 UTC (rev
4218)
+++ trunk/pgadmin3/xtra/pgagent/connection.cpp 2005-05-19 14:53:32 UTC (rev
4219)
@@ -13,18 +13,15 @@
#include libpq-fe.h
#include time.h
-
-// entries in the connection pool
-int connPoolCount=5;
-
-
-DBconn **DBconn::pool=0;
+DBconn *DBconn::primaryConn;
string DBconn::basicConnectString;
-
DBconn::DBconn(const string name)
{
dbname = name;
+ inUse = false;
+ next=0;
+ prev=0;
Connect(basicConnectString + dbname= + dbname);
}
@@ -32,6 +29,9 @@
DBconn::DBconn(const string connectString, const string name)
{
dbname = name;
+ inUse = false;
+ next=0;
+ prev=0;
Connect(connectString);
}
@@ -65,21 +65,12 @@
DBconn *DBconn::InitConnection(const string connectString)
{
-if (!pool)
-{
-pool = new DBconn*[connPoolCount];
-if (pool)
-memset(pool, 0, sizeof(DBconn*) * connPoolCount);
-}
-if (!pool)
-LogMessage(Out of memory for connection pool, LOG_ERROR);
-
basicConnectString=connectString;
string dbname;
int pos=basicConnectString.find(dbname=);
if (pos == -1)
-dbname = dba;
+dbname = pgadmin;
else
{
dbname = basicConnectString.substr(pos+7);
@@ -93,89 +84,84 @@
dbname = dbname.substr(0, pos);
}
}
-pool[0] = new DBconn(connectString, dbname);
-pool[0]-primary = true;
+primaryConn = new DBconn(connectString, dbname);
-return pool[0];
+if (!primaryConn)
+LogMessage(Failed to create primary connection!, LOG_ERROR);
+
+ primaryConn-inUse = true;
+
+return primaryConn;
}
-DBconn *DBconn::Get(const string dbname, bool asPrimary)
+DBconn *DBconn::Get(const string dbname)
{
-if (!pool)
-{
-pool = new DBconn*[connPoolCount];
-if (pool)
-memset(pool, 0, sizeof(DBconn*) * connPoolCount);
-}
-if (!pool)
-LogMessage(Out of memory for connection pool, LOG_ERROR);
+ DBconn *thisConn = primaryConn, *testConn;
-int i;
-DBconn **emptyConn=0, **oldestConn=0;
-
// find an existing connection
-for (i=0 ; i connPoolCount ; i++)
+do
{
-if (pool[i])
-{
-if (dbname == pool[i]-dbname)
-return pool[i];
+if (dbname == thisConn-dbname !thisConn-inUse)
+ {
+ LogMessage(Allocating existing connection to database
+ thisConn-dbname, LOG_DEBUG);
+ thisConn-inUse = true;
+return thisConn;
+ }
-// while searching, also mark the oldest non-primary connection
-if (!pool[i]-primary)
-{
-if (!oldestConn || pool[i]-timestamp
(*oldestConn)-timestamp)
-oldestConn=pool+i;
-}
-}
-else
-{
-// while searching, mark the first empty slot
-if (!emptyConn)
-emptyConn=pool+i;
-}
-}
-if (!emptyConn)
-{
-delete *oldestConn;
-emptyConn=oldestConn;
-*emptyConn=0;
-}
+ testConn = thisConn;
+ if (thisConn-next != 0)
+ thisConn = thisConn-next;
-DBconn *conn=new DBconn(dbname);
-if (conn-conn)
+} while (testConn-next != 0);
+
+
+ // No suitable connection was found, so create a new one.
+DBconn *newConn=new DBconn(dbname);
+if (newConn-conn)
{
-*emptyConn=conn;
+ LogMessage(Allocating new connection to database +
newConn-dbname, LOG_DEBUG);
+ newConn-inUse = true;
+ newConn-prev = thisConn;
+ thisConn-next = newConn;
}
-return *emptyConn;
+ else
+ LogMessage(Failed to create new connection to database: +
dbname, LOG_ERROR);
+
+return newConn;
}
+void DBconn::Return()
+{
+ LogMessage(Returning connection to database + this-dbname,
LOG_DEBUG);
+ inUse = false;
+}
void DBconn::ClearConnections(bool all)
{
-// clears all connections, except for the primary one.
-// if all is true, even the primary
Re: [pgadmin-hackers] New acinclude.m4
Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam H. Pendleton Sent: 18 May 2005 22:26 To: pgadmin-hackers@postgresql.org Subject: [pgadmin-hackers] New acinclude.m4 Attached is a new acinclude.m4, and a patch to our current acinclude, that relies on wx-config for all the flags. Gone is all the complicated stuff. The only thing this new acinclude doesn't do is warn about a missing stc or ogl. It will link against them, but if a user doesn't have them, their compile will fail. I'll be adding in stub programs to test for this in my next version. In the meantime, test and enjoy. Great, thanks Adam - committed. I have warning concerning ENABLE_STATIC in configure script. Shouldn't we also remove it crom configure.ac ? (patch attached). Regards, Raphaël Index: configure.ac === --- configure.ac (revision 4219) +++ configure.ac (working copy) @@ -35,7 +35,6 @@ CHECK_WX_CONFIG_BINARY CHECK_PGSQL_INCLUDE ENABLE_DEBUG -ENABLE_STATIC CHECK_PGSQL CHECK_WXWINDOWS ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] New acinclude.m4
Yes. Nice catch. On May 19, 2005, at 1:07 PM, Raphaël Enrici wrote: Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam H. Pendleton Sent: 18 May 2005 22:26 To: pgadmin-hackers@postgresql.org Subject: [pgadmin-hackers] New acinclude.m4 Attached is a new acinclude.m4, and a patch to our current acinclude, that relies on wx-config for all the flags. Gone is all the complicated stuff. The only thing this new acinclude doesn't do is warn about a missing stc or ogl. It will link against them, but if a user doesn't have them, their compile will fail. I'll be adding in stub programs to test for this in my next version. In the meantime, test and enjoy. Great, thanks Adam - committed. I have warning concerning ENABLE_STATIC in configure script. Shouldn't we also remove it crom configure.ac ? (patch attached). Regards, Raphaël Index: configure.ac === --- configure.ac(revision 4219) +++ configure.ac(working copy) @@ -35,7 +35,6 @@ CHECK_WX_CONFIG_BINARY CHECK_PGSQL_INCLUDE ENABLE_DEBUG -ENABLE_STATIC CHECK_PGSQL CHECK_WXWINDOWS ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-hackers] New acinclude.m4
Message d'origine Copie à: Dave Page dpage@vale-housing.co.uk, De: Adam H.Pendleton [EMAIL PROTECTED] Sujet: Re: [pgadmin-hackers] New acinclude.m4 Date: Thu, 19 May 2005 13:14:47 -0400 A: Raphaël Enrici [EMAIL PROTECTED] Yes. Nice catch. A small one compared to the work you did! The new acinclude.m4 works like a charm even with wxWid --flavour and even on pgAdmin REL-1_2_0_PATCHES branch. Do you think to any problem including it in 1.2.x branch apart from the fact that you invoke 'ogl' which is not required for 1.2.2 but does not harm the 1.2.x build ? Regards, Raphaël On May 19, 2005, at 1:07 PM, Raphaël Enrici wrote: Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam H. Pendleton Sent: 18 May 2005 22:26 To: pgadmin-hackers@postgresql.org Subject: [pgadmin-hackers] New acinclude.m4 Attached is a new acinclude.m4, and a patch to our current acinclude, that relies on wx-config for all the flags. Gone is all the complicated stuff. The only thing this new acinclude doesn't do is warn about a missing stc or ogl. It will link against them, but if a user doesn't have them, their compile will fail. I'll be adding in stub programs to test for this in my next version. In the meantime, test and enjoy. Great, thanks Adam - committed. I have warning concerning ENABLE_STATIC in configure script. Shouldn't we also remove it crom configure.ac ? (patch attached). Regards, Raphaël Index: configure.ac === --- configure.ac(revision 4219) +++ configure.ac(working copy) @@ -35,7 +35,6 @@ CHECK_WX_CONFIG_BINARY CHECK_PGSQL_INCLUDE ENABLE_DEBUG -ENABLE_STATIC CHECK_PGSQL CHECK_WXWINDOWS ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgadmin-hackers] New acinclude.m4
Raphaël Enrici wrote: I have warning concerning ENABLE_STATIC in configure script. Shouldn't we also remove it crom configure.ac ? (patch attached). Does this mean the linking statically is not possible anymore? Or has the check just moved to another place? greetings, Florian Pflug ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] New acinclude.m4
Florian G. Pflug wrote: Raphaël Enrici wrote: I have warning concerning ENABLE_STATIC in configure script. Shouldn't we also remove it crom configure.ac ? (patch attached). Does this mean the linking statically is not possible anymore? Or has the check just moved to another place? To me, as Adam is making the build relying on wx-config flags, the build is considered static if wxWid was built with --disabled-shared passed to its configure. In the case where wxWidgets has been built with --enable-shared, pgadmin will inherit this default and build dynamically (same thing if both shared and static wxWid libs were built, the shared build will become the default...). Maybe it would be worth to still being able to force a static build by passing --static to wx-config in our acinclude.m4. Something like : if we pas --enable-static to our configure, then pass --static to wx-config so that we build statically, if not then don't pass anything in particular. Adam ? Regards, Raphaël ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgadmin-hackers] New acinclude.m4
Raphaël Enrici wrote: Florian G. Pflug wrote: Raphaël Enrici wrote: I have warning concerning ENABLE_STATIC in configure script. Shouldn't we also remove it crom configure.ac ? (patch attached). Does this mean the linking statically is not possible anymore? Or has the check just moved to another place? To me, as Adam is making the build relying on wx-config flags, the build is considered static if wxWid was built with --disabled-shared passed to its configure. In the case where wxWidgets has been built with --enable-shared, pgadmin will inherit this default and build dynamically (same thing if both shared and static wxWid libs were built, the shared build will become the default...). Will a statically-built wx make the _whole_ pgadmin link statically too, or will only the wx-libraries be linkes statically and e.g. libpq dynamically. It would be the right thing to do, I guess - but then there would be need for a global --enable-static flag, that defined the linking-type for all other libs beside wx. At least for OSX, linking the release-versions statically it the most reliable method, while keeping the resulting app small. Maybe it would be worth to still being able to force a static build by passing --static to wx-config in our acinclude.m4. Something like : if we pas --enable-static to our configure, then pass --static to wx-config so that we build statically, if not then don't pass anything in particular. Sounds reasonable - additionally --enable-static should link e.g. libpq statically too. greetings, Florian Pflug ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[pgadmin-hackers] Debian files update for REL-1_2_0_PATCHES branch
Hi Dave, here is an update to the pkg/debian for REL-1_2_0_PATCHES branch. After that and the latest acinclude.m4 discussion, it should be fine for me to go for a release. Cheers, Raphaël Index: pkg/debian/control === --- pkg/debian/control (revision 4219) +++ pkg/debian/control (working copy) @@ -2,7 +2,7 @@ Section: misc Priority: optional Maintainer: Raphael Enrici [EMAIL PROTECTED] -Build-Depends: debhelper (= 4.1.0), postgresql-dev (=7.3), devscripts, libwxgtk2.5-dev (= 2.5.3.2) +Build-Depends: debhelper (= 4.1.0), postgresql-dev (=7.3), devscripts, pgadmin3-libwxgtk2ud2.6, automake1.9, autoconf Standards-Version: 3.6.1 Package: pgadmin3 Index: pkg/debian/changelog === --- pkg/debian/changelog (revision 4219) +++ pkg/debian/changelog (working copy) @@ -1,3 +1,17 @@ +pgadmin3 (1.2.1pre1.2.2-0.1) experimental; urgency=low + + * Just a build of what should become 1.2.2. + * Replaced libwxgtk2.5-dev by pgadmin3-libwxgtk2ud2.6 in debian/control. +until Ron is able to provide an updated wx2.6 package for Debian. + * Added automake1.9 and autoconf to debian/control. (automake1.9 should +be rechecked...). + * Changed wx-config to wx-config-pgadmin3 in debian/rules. + * Added bootstrap sequence to the build. + * New Adam's acinclude.m4 will be incorporated to this build if not +included in the 1.2.x branch. + + -- Raphael Enrici pgadmin-hackers@postgresql.org Thu, 19 May 2005 19:13:44 + + pgadmin3 (1.2.0-2) unstable; urgency=low * Renamed debian/NEWS.Debian to debian/pgadmin3.NEWS so that it is correctly Index: pkg/debian/rules === --- pkg/debian/rules (revision 4219) +++ pkg/debian/rules (working copy) @@ -10,7 +10,7 @@ pkg-data=$(pkg)-data # The name of the wxWidgets config script we invoke later in configure -_PGA3_WXCONFIG ?= wx-config +_PGA3_WXCONFIG ?= wx-config-pgadmin3 # A hack to get it compile without errors concerning MNU_NEW _pgsql_inc:=/usr/include/postgresql -I./include @@ -42,6 +42,8 @@ #endif # Here goes the pgAdmin3 stuff +configure: + sh bootstrap config.status: configure dh_testdir @@ -72,6 +74,7 @@ # Add here commands to clean up after the build process. -$(MAKE) clean -$(MAKE) distclean + -rm configure -rm config.status -rm config.cache ifneq $(wildcard /usr/share/misc/config.sub) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgadmin-hackers] New acinclude.m4
Florian G. Pflug wrote:
Raphaël Enrici wrote:
Florian G. Pflug wrote:
Raphaël Enrici wrote:
I have warning concerning ENABLE_STATIC in configure script. Shouldn't
we also remove it crom configure.ac ? (patch attached).
Does this mean the linking statically is not possible anymore?
Or has the check just moved to another place?
To me, as Adam is making the build relying on wx-config flags, the build
is considered static if wxWid was built with --disabled-shared passed
to its configure. In the case where wxWidgets has been built with
--enable-shared, pgadmin will inherit this default and build dynamically
(same thing if both shared and static wxWid libs were built, the shared
build will become the default...).
Will a statically-built wx make the _whole_ pgadmin link statically too,
or will only the wx-libraries be linkes statically and e.g. libpq
dynamically.
To me, second case. wx static the rest of the world dynamic.
It would be the right thing to do, I guess - but then there
would be need for a global --enable-static flag, that defined
the linking-type for all other libs beside wx. At least for OSX,
linking the release-versions statically it the most reliable method,
while keeping the resulting app small.
So, if I'm right we have lost this functionnality. But, again, I may be
wrong.
Can you try the patch attached on OSX with a fresh checkout (don't
apply the configure.ac I just sent) ? (I need to rebuild wxWid to
generate static libs... it may take a moment).
Cheers,
Raphaël
Maybe it would be worth to still being able to force a static build by
passing --static to wx-config in our acinclude.m4. Something like :
if we pas --enable-static to our configure, then pass --static to
wx-config so that we build statically, if not then don't pass anything
in particular.
Sounds reasonable - additionally --enable-static should link e.g. libpq
statically too.
greetings, Florian Pflug
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Index: acinclude.m4
===
--- acinclude.m4 (revision 4219)
+++ acinclude.m4 (working copy)
@@ -59,6 +59,18 @@
AC_SUBST(pg_debug_build)
+# Static build of pgAdmin3 #
+
+AC_DEFUN([ENABLE_STATIC],
+[AC_ARG_ENABLE(static,
+[ --enable-static build a static version of pgAdmin3],
+[pg_static_build=yes
+WX_STATIC=--static],
+[pg_static_build=no
+WX_STATIC=])
+])
+
+
# Build an pgAdmin III.app #
AC_DEFUN([ENABLE_APPBUNDLE],
@@ -255,8 +267,8 @@
LDFLAGS=$LDFLAGS -L${WX_HOME}/lib
WX_OLD_LDFLAGS=$LDFLAGS
WX_OLD_CPPFLAGS=$CPPFLAGS
-WX_NEW_LIBS=`${WX_CONFIG} --libs`
-WX_NEW_CONTRIB_LIBS=`${WX_CONFIG} --libs stc,ogl`
+WX_NEW_LIBS=`${WX_CONFIG} ${WX_STATIC} --libs`
+WX_NEW_CONTRIB_LIBS=`${WX_CONFIG} ${WX_STATIC} --libs stc,ogl`
LIBS=$LIBS $WX_NEW_LIBS $WX_NEW_CONTRIB_LIBS
WX_NEW_CPPFLAGS=`${WX_CONFIG} --cppflags`
CPPFLAGS=$CPPFLAGS $WX_NEW_CPPFLAGS
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [pgadmin-hackers] New acinclude.m4
On May 19, 2005, at 3:24 PM, Florian G. Pflug wrote: Raphaël Enrici wrote: Florian G. Pflug wrote: Raphaël Enrici wrote: I have warning concerning ENABLE_STATIC in configure script. Shouldn't we also remove it crom configure.ac ? (patch attached). Does this mean the linking statically is not possible anymore? Or has the check just moved to another place? To me, as Adam is making the build relying on wx-config flags, the build is considered static if wxWid was built with --disabled-shared passed to its configure. In the case where wxWidgets has been built with --enable-shared, pgadmin will inherit this default and build dynamically (same thing if both shared and static wxWid libs were built, the shared build will become the default...). Will a statically-built wx make the _whole_ pgadmin link statically too, or will only the wx-libraries be linkes statically and e.g. libpq dynamically. It would be the right thing to do, I guess - but then there would be need for a global --enable-static flag, that defined the linking-type for all other libs beside wx. At least for OSX, linking the release-versions statically it the most reliable method, while keeping the resulting app small. I ran into some real problems trying to link the whole app statically, especially on Linux. There is a flag that can be passed (to ld I think) that makes all linking static, but IIRC I found that some linux libraries didn't like that much, and would require dynamic linking. Besides, in this day and age, there really isn't any reason to completely statically link, except for debugging purposes, and it's really only statically linking against wx that we care about in that case. ahp ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgadmin-hackers] New acinclude.m4
On May 19, 2005, at 3:46 PM, Raphaël Enrici wrote: Can you try the patch attached on OSX with a fresh checkout (don't apply the configure.ac I just sent) ? (I need to rebuild wxWid to generate static libs... it may take a moment). Your attached patch isn't going to do anything. `wx-config --libs` and `wx-config --libs --static` both return the same thing, unless you have both a static and dynamic version of wx2 in the same tree. For 99% of us, adding the --static flag makes no difference. ahp ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] New acinclude.m4
On May 19, 2005, at 2:13 PM, Florian G. Pflug wrote: Raphaël Enrici wrote: I have warning concerning ENABLE_STATIC in configure script. Shouldn't we also remove it crom configure.ac ? (patch attached). Does this mean the linking statically is not possible anymore? Or has the check just moved to another place? Static linking is totally dependent on how wx2 was built. If wx2 was built statically, we link statically. If it was not a static build we dynamically link. ahp ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-hackers] New acinclude.m4
Adam H. Pendleton wrote: On May 19, 2005, at 3:24 PM, Florian G. Pflug wrote: Raphaël Enrici wrote: Florian G. Pflug wrote: Raphaël Enrici wrote: I have warning concerning ENABLE_STATIC in configure script. Shouldn't we also remove it crom configure.ac ? (patch attached). Does this mean the linking statically is not possible anymore? Or has the check just moved to another place? To me, as Adam is making the build relying on wx-config flags, the build is considered static if wxWid was built with --disabled-shared passed to its configure. In the case where wxWidgets has been built with --enable-shared, pgadmin will inherit this default and build dynamically (same thing if both shared and static wxWid libs were built, the shared build will become the default...). Will a statically-built wx make the _whole_ pgadmin link statically too, or will only the wx-libraries be linkes statically and e.g. libpq dynamically. It would be the right thing to do, I guess - but then there would be need for a global --enable-static flag, that defined the linking-type for all other libs beside wx. At least for OSX, linking the release-versions statically it the most reliable method, while keeping the resulting app small. I ran into some real problems trying to link the whole app statically, especially on Linux. There is a flag that can be passed (to ld I think) that makes all linking static, but IIRC I found that some linux libraries didn't like that much, and would require dynamic linking. Besides, in this day and age, there really isn't any reason to completely statically link, except for debugging purposes, and it's really only statically linking against wx that we care about in that case. On OSX, you have to include any non-standard (not included in OSX) lib into your application bundle - at least, if you want people to be able to take the .app, drag it into their applications folder, and run it - which people on OSX expect, since it works that way for 90% of the software (Even for MS-Office ;-) ). The complete-bundle.sh in the pgadmin sources takes care of this - it moves all shared-libs pgadmin3 depends on into the bundle, and patches pgadmin3 to search for them there. This, howevery, causes bloat, because you can't strip a shared library - it always contains all symbols, no matter if your app nees them or not. OTOH, if you link statically, you can strip the resulting binary, and only retain the symbols that you really need. As long as wx is linked statically, howevery, the difference will hopefully by small for pgadmin3 I guess, since libpq is quite slim. But things grow out of hand quickly, if you start linking dynamically against wx - because the libs are _hughe_. I'll now go and test a compile with the new acinclude.m4, and see what happens ;-) greetings, Florian Pflug smime.p7s Description: S/MIME Cryptographic Signature
Re: [pgadmin-hackers] New acinclude.m4
Adam H. Pendleton wrote: On May 19, 2005, at 3:46 PM, Raphaël Enrici wrote: Can you try the patch attached on OSX with a fresh checkout (don't apply the configure.ac I just sent) ? (I need to rebuild wxWid to generate static libs... it may take a moment). Your attached patch isn't going to do anything. `wx-config --libs` and `wx-config --libs --static` both return the same thing, unless you have both a static and dynamic version of wx2 in the same tree. For 99% of us, adding the --static flag makes no difference. I'm glad to be so rare... It seems I belong to the 1%: I have a dynamic build. ;) Please also note that the patch attached reintroduce your code concerning the static link of the rest of the libs (libpq and sons). However, you are the ac guru and I'm fully satisfied by a dynamic linking with the new acinclude.m4 (+ the configure.ac patch). The real question is: - do we still need full static linking (at least libpq, ssl,..?). If yes, then the new acinclude.m4 does not provide it anymore and we need to rework on it. Regards, Raphaël ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [pgadmin-hackers] New acinclude.m4
On May 19, 2005, at 4:30 PM, Raphaël Enrici wrote: Adam H. Pendleton wrote: I'm glad to be so rare... It seems I belong to the 1%: I have a dynamic build. ;) Please also note that the patch attached reintroduce your code concerning the static link of the rest of the libs (libpq and sons). However, you are the ac guru and I'm fully satisfied by a dynamic linking with the new acinclude.m4 (+ the configure.ac patch). The real question is: - do we still need full static linking (at least libpq, ssl,..?). If yes, then the new acinclude.m4 does not provide it anymore and we need to rework on it. Are you saying that `wx-config --libs` and `wx-config --libs -- static` produce two different outputs on your system? If you built wx dynamically then either a) the output from --libs --static is nonsense, or b) it's the same as --libs. Either way, the current acinclude will link the same way you linked wx. As for the full static linking, --enable-static never performed a full static link, it only statically linked against wxWindows. Personally, I don't like static linking. It creates huge executables, eats up memory, and slows down performance. We should link dynamically wherever possible. ahp ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] New acinclude.m4
Adam H. Pendleton wrote: On May 19, 2005, at 4:30 PM, Raphaël Enrici wrote: Adam H. Pendleton wrote: I'm glad to be so rare... It seems I belong to the 1%: I have a dynamic build. ;) Please also note that the patch attached reintroduce your code concerning the static link of the rest of the libs (libpq and sons). However, you are the ac guru and I'm fully satisfied by a dynamic linking with the new acinclude.m4 (+ the configure.ac patch). The real question is: - do we still need full static linking (at least libpq, ssl,..?). If yes, then the new acinclude.m4 does not provide it anymore and we need to rework on it. Are you saying that `wx-config --libs` and `wx-config --libs -- static` produce two different outputs on your system? If you built wx dynamically then either a) the output from --libs --static is nonsense, or b) it's the same as --libs. Either way, the current acinclude will link the same way you linked wx. What I'm trying to say is this: I've a dynamic only build. So, wx-config --libs is ok. wx-config --static --libs gives an error. According to what I understand from the wx-config --help output is: if I had both built and would like to get informations concerning the static wxWid libs, then I'd need to pass --static to wx-config. Right? As for the full static linking, --enable-static never performed a full static link, it only statically linked against wxWindows. Personally, I don't like static linking. It creates huge executables, eats up memory, and slows down performance. We should link dynamically wherever possible. yup, _I HATE STATIC BUILDS TOO_ :)) But, it seems that at least for Florian this is important. The latest patch I sent just does two things: a) force static parameters of wxWid, just in case the wx-config --libs would not give the _static_ lib informations when both shared and static are installed on the system. b) re-introduce the pg_static_build=yes variable which is later interpreted just as in previous versions because the old code is still there. Does it makes sens? (in case someone for some bad or good reason need a 95% static build) Raphaël ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgadmin-hackers] New acinclude.m4
On May 19, 2005, at 4:54 PM, Raphaël Enrici wrote: What I'm trying to say is this: I've a dynamic only build. So, wx-config --libs is ok. wx-config --static --libs gives an error. According to what I understand from the wx-config --help output is: if I had both built and would like to get informations concerning the static wxWid libs, then I'd need to pass --static to wx-config. Right? Yes. The --static flag is only useful in the case where a user has both a static and dynamic build of wxWidgets in the same tree. yup, _I HATE STATIC BUILDS TOO_ :)) But, it seems that at least for Florian this is important. The latest patch I sent just does two things: a) force static parameters of wxWid, just in case the wx-config --libs would not give the _static_ lib informations when both shared and static are installed on the system. Yes, your patch would add support for those people with both build types. b) re-introduce the pg_static_build=yes variable which is later interpreted just as in previous versions because the old code is still there. There are no references to pg_static_build in acinclude any more. Well, okay there's one, but it doesn't do anything because pg_static_build isn't set anywhere (sans your patch, of course). Your patch is fine, just know that it terms of statically linking pgAdmin3 as a whole it does nothing. It only helps any user with both a dynamic and static wx select the one they want. ahp ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgadmin-hackers] New acinclude.m4
Raphaël Enrici wrote:
Adam H. Pendleton wrote:
On May 19, 2005, at 4:30 PM, Raphaël Enrici wrote:
Adam H. Pendleton wrote:
I'm glad to be so rare... It seems I belong to the 1%: I have a
dynamic build. ;)
Please also note that the patch attached reintroduce your code
concerning the static link of the rest of the libs (libpq and sons).
However, you are the ac guru and I'm fully satisfied by a dynamic
linking with the new acinclude.m4 (+ the configure.ac patch).
The real question is:
- do we still need full static linking (at least libpq, ssl,..?).
If yes, then the new acinclude.m4 does not provide it anymore and we
need to rework on it.
Are you saying that `wx-config --libs` and `wx-config --libs --
static` produce two different outputs on your system? If you built
wx dynamically then either a) the output from --libs --static is
nonsense, or b) it's the same as --libs. Either way, the current
acinclude will link the same way you linked wx.
What I'm trying to say is this:
I've a dynamic only build. So, wx-config --libs is ok. wx-config
--static --libs gives an error.
According to what I understand from the wx-config --help output is:
if I had both built and would like to get informations concerning the
static wxWid libs, then I'd need to pass --static to wx-config. Right?
As for the full static linking, --enable-static never performed a
full static link, it only statically linked against wxWindows.
Personally, I don't like static linking. It creates huge
executables, eats up memory, and slows down performance. We should
link dynamically wherever possible.
Actually, it linked wx _and_ libpq statically - this is what
acinclude.m4 says:
if test $pg_static_build = yes
then
if test $build_cpu-$build_vendor = powerpc-apple
then
CRYPT_LIB=
else
CRYPT_LIB=-lcrypt
fi
if test $pgsql_ssl_libpq = yes
then
LIBS=${LIBPQ_HOME}/lib/libpq.a $CRYPT_LIB $LIBS -lssl
-lcrypto
else
LIBS=${LIBPQ_HOME}/lib/libpq.a $CRYPT_LIB $LIBS -lcrypto
fi
else
if test $pgsql_ssl_libpq = yes
then
LIBS=$LIBS -lssl -lcrypto -lpq
else
LIBS=$LIBS -lcrypto -lpq
fi
fi
So, it linkes libpq statically, and the rest dynamically - which
I believe is correct, since libssl is pretty much a standard
library, which you can expect to find on most systems - libpq
OTOH is not that-much-standard ;-)
yup, _I HATE STATIC BUILDS TOO_ :)) But, it seems that at least for
Florian this is important. The latest patch I sent just does two things:
a) force static parameters of wxWid, just in case the wx-config --libs
would not give the _static_ lib informations when both shared and static
are installed on the system.
b) re-introduce the pg_static_build=yes variable which is later
interpreted just as in previous versions because the old code is still
there.
Sounce good to me - but if there is no interest in supporting
static builds on all plattforms, I could also special-case
OSX, and turn static linking of libpq on when building a .app-bundle.
greetings, Florian Pflug
smime.p7s
Description: S/MIME Cryptographic Signature
[SUMMARY] Re: [pgadmin-hackers] New acinclude.m4
To summarize :
- we reject the configure.ac.patch which removed ENABLE_STATIC and
should not have been included in trunk yet
- we keep the latest acinclude_static.patch which re-add support for
pg_static_build=yes + takes care of systems where wxWid installations
are both static dynamic.
Everybody is ok with this?
Raphaël
Florian G. Pflug wrote:
Raphaël Enrici wrote:
Adam H. Pendleton wrote:
On May 19, 2005, at 4:30 PM, Raphaël Enrici wrote:
Adam H. Pendleton wrote:
I'm glad to be so rare... It seems I belong to the 1%: I have a
dynamic build. ;)
Please also note that the patch attached reintroduce your code
concerning the static link of the rest of the libs (libpq and sons).
However, you are the ac guru and I'm fully satisfied by a dynamic
linking with the new acinclude.m4 (+ the configure.ac patch).
The real question is:
- do we still need full static linking (at least libpq, ssl,..?).
If yes, then the new acinclude.m4 does not provide it anymore and we
need to rework on it.
Are you saying that `wx-config --libs` and `wx-config --libs --
static` produce two different outputs on your system? If you built
wx dynamically then either a) the output from --libs --static is
nonsense, or b) it's the same as --libs. Either way, the current
acinclude will link the same way you linked wx.
What I'm trying to say is this:
I've a dynamic only build. So, wx-config --libs is ok. wx-config
--static --libs gives an error.
According to what I understand from the wx-config --help output is:
if I had both built and would like to get informations concerning the
static wxWid libs, then I'd need to pass --static to wx-config. Right?
As for the full static linking, --enable-static never performed a
full static link, it only statically linked against wxWindows.
Personally, I don't like static linking. It creates huge
executables, eats up memory, and slows down performance. We should
link dynamically wherever possible.
Actually, it linked wx _and_ libpq statically - this is what
acinclude.m4 says:
if test $pg_static_build = yes
then
if test $build_cpu-$build_vendor = powerpc-apple
then
CRYPT_LIB=
else
CRYPT_LIB=-lcrypt
fi
if test $pgsql_ssl_libpq = yes
then
LIBS=${LIBPQ_HOME}/lib/libpq.a $CRYPT_LIB $LIBS -lssl
-lcrypto
else
LIBS=${LIBPQ_HOME}/lib/libpq.a $CRYPT_LIB $LIBS -lcrypto
fi
else
if test $pgsql_ssl_libpq = yes
then
LIBS=$LIBS -lssl -lcrypto -lpq
else
LIBS=$LIBS -lcrypto -lpq
fi
fi
So, it linkes libpq statically, and the rest dynamically - which
I believe is correct, since libssl is pretty much a standard
library, which you can expect to find on most systems - libpq
OTOH is not that-much-standard ;-)
yup, _I HATE STATIC BUILDS TOO_ :)) But, it seems that at least for
Florian this is important. The latest patch I sent just does two things:
a) force static parameters of wxWid, just in case the wx-config --libs
would not give the _static_ lib informations when both shared and static
are installed on the system.
b) re-introduce the pg_static_build=yes variable which is later
interpreted just as in previous versions because the old code is still
there.
Sounce good to me - but if there is no interest in supporting
static builds on all plattforms, I could also special-case
OSX, and turn static linking of libpq on when building a .app-bundle.
greetings, Florian Pflug
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [SUMMARY] Re: [pgadmin-hackers] New acinclude.m4
On May 19, 2005, at 5:27 PM, Raphaël Enrici wrote:To summarize :- we reject the configure.ac.patch which removed ENABLE_STATIC andshould not have been included in trunk yetYou mean reject my entire patch? It did much more than just remove ENABLE_STATIC, so it should not be rejected.- we keep the latest "acinclude_static.patch" which re-add support forpg_static_build=yes + takes care of systems where wxWid installationsare both static dynamic.We should add your patch to what is already in the trunk.ahp
