Thread: palloc.h again
I just noticed that the palloc.h problem still exists. That is we do not install utils/mcxt.h but is included by palloc.h. Did we find a solution for this yet? Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael.Meskes@gmx.net | Use PostgreSQL!
Michael Meskes <Michael_Meskes@topmail.de> writes:
> I just noticed that the palloc.h problem still exists. That is we do not
> install utils/mcxt.h but is included by palloc.h.
I was hoping that Jan would try to reduce the number of include files
that are now needed by palloc(). But definitely something will have
to be done about this before we release.
regards, tom lane
>
> Michael Meskes <Michael_Meskes@topmail.de> writes:
> > I just noticed that the palloc.h problem still exists. That is we do not
> > install utils/mcxt.h but is included by palloc.h.
>
> I was hoping that Jan would try to reduce the number of include files
> that are now needed by palloc(). But definitely something will have
> to be done about this before we release.
Hmmm - how should I reduce the number of include files? All
the palloc stuff is macroized now, so using palloc() results
in MemoryContextAlloc() calls. Reduces one brain dead
function call (the old versions of palloc() etc. simply did
that - wasting one stack frame).
Thus, we definitely need mcxt.h where we need palloc() and
that's why I've put the include of mcxt.h into palloc.h.
What I'm in doubt about is, why (if) we don't want to install
mcxt.h? It is required (since my changes) by every user
built backend-loadable module. So it should be installed.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
jwieck@debis.com (Jan Wieck) writes:
> What I'm in doubt about is, why (if) we don't want to install
> mcxt.h? It is required (since my changes) by every user
> built backend-loadable module. So it should be installed.
If it's only mcxt.h that is newly required, we may as well just export
it and be done with it. My recollection of the original report was
that *several* formerly backend-private headers needed to be added to
the export set, and I thought that wasn't a very good idea...
regards, tom lane
On Wed, 3 Mar 1999, Tom Lane wrote: > jwieck@debis.com (Jan Wieck) writes: > > What I'm in doubt about is, why (if) we don't want to install > > mcxt.h? It is required (since my changes) by every user > > built backend-loadable module. So it should be installed. > > If it's only mcxt.h that is newly required, we may as well just export > it and be done with it. My recollection of the original report was > that *several* formerly backend-private headers needed to be added to > the export set, and I thought that wasn't a very good idea... > It's been a while since I switched to CVS but I remember other .h dependencies with each .h file I added starting with palloc.h. I ended up getting tired of it and just copied the contents of the include dir over rather than fight with it. So unless somethings changed there are more headers needed that palloc.h and mcxt.h Sorry I don't have better details as to which ones it needed. I'll be doing a fresh install this weekend, if it'd help I'll make a list. ->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-< James Thompson 138 Cardwell Hall Manhattan, Ks 66506 785-532-0561 Kansas State University Department of Mathematics ->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
On Tue, 2 Mar 1999, Michael Meskes wrote: > I just noticed that the palloc.h problem still exists. That is we do not > install utils/mcxt.h but is included by palloc.h. > After doing a clean install of todays CVS, I tried to compile one of the ecpg based programs. These are the dependencies that failed as a copied the needed files into place. [jamest@calvin obelib]$ make make: *** No rule to make target `/usr/local/pgsql/include/utils/mcxt.h', needed by `packet.lo'. Stop. [jamest@calvin obelib]$ make make: *** No rule to make target `/usr/local/pgsql/include/nodes/memnodes.h', needed by `packet.lo'. Stop. [jamest@calvin obelib]$ make make: *** No rule to make target `/usr/local/pgsql/include/lib/fstack.h', needed by `packet.lo'. Stop. [jamest@calvin obelib]$ make make: *** No rule to make target `/usr/local/pgsql/include/utils/memutils.h', needed by `packet.lo'. Stop. [jamest@calvin obelib]$ make make: *** No rule to make target `/usr/local/pgsql/include/nodes/nodes.h', needed by `packet.lo'. Stop. ->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-< James Thompson 138 Cardwell Hall Manhattan, Ks 66506 785-532-0561 Kansas State University Department of Mathematics ->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
James Thompson <jamest@math.ksu.edu> writes:
> After doing a clean install of todays CVS, I tried to compile one of the
> ecpg based programs.
Wait a sec ... ecpg? ecpg shouldn't be depending on backend internals
at all, should it? I thought we were talking about support for
dynamically loaded backend extensions.
> These are the dependencies that failed as a copied
> the needed files into place.
> include/utils/mcxt.h
> include/nodes/memnodes.h
> include/lib/fstack.h
> include/utils/memutils.h
> include/nodes/nodes.h
OK, thanks for the list. Now the question is do we want to expose that
much of the backend internals to dynamically loaded extensions in order
to allow palloc() to be a macro.
It looks to me like there's no real need for mcxt.h to import
memnodes.h; as far as most users of palloc are concerned, the type
MemoryContext is just an abstract token. I propose puttingtypedef struct MemoryContextData *MemoryContext;typedef
structGlobalMemoryData *GlobalMemory;
in mcxt.h instead of including memnodes.h. Then we avoid needing to
export more than mcxt.h... should speed up backend rebuilds a little bit
too, as palloc.h is included in a lot of files that don't need the rest
of that stuff...
I'll try this and see if it compiles that way.
regards, tom lane
On Sun, 7 Mar 1999, Tom Lane wrote: > James Thompson <jamest@math.ksu.edu> writes: > > After doing a clean install of todays CVS, I tried to compile one of the > > ecpg based programs. > > Wait a sec ... ecpg? ecpg shouldn't be depending on backend internals I should have left the ecpg part out as I don't think it was important. All my code requires ecpg and it was easy to just build what I'm familure with and submit the results. I didn't try a libpg based program. ->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-< James Thompson 138 Cardwell Hall Manhattan, Ks 66506 785-532-0561 Kansas State University Department of Mathematics ->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
On Sun, Mar 07, 1999 at 02:22:28PM -0500, Tom Lane wrote: > Wait a sec ... ecpg? ecpg shouldn't be depending on backend internals > at all, should it? I thought we were talking about support for > dynamically loaded backend extensions. Hmm, historically ecpg's ecpglib.h includes postgres.h which include palloc.h. But scanning through postgres.h I wonder why. I will check that as soon as I find time. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael.Meskes@gmx.net | Use PostgreSQL!
Michael Meskes <meskes@postgreSQL.org> writes:
> On Sun, Mar 07, 1999 at 02:22:28PM -0500, Tom Lane wrote:
>> Wait a sec ... ecpg? ecpg shouldn't be depending on backend internals
>> at all, should it? I thought we were talking about support for
>> dynamically loaded backend extensions.
> Hmm, historically ecpg's ecpglib.h includes postgres.h which include
> palloc.h. But scanning through postgres.h I wonder why.
It'd probably be better if you could make ecpg code depend only on
postgres_ext.h. However, I did commit fixes yesterday to solve the
immediate problem with mcxt.h.
regards, tom lane
On Mon, Mar 08, 1999 at 09:39:05AM -0500, Tom Lane wrote: > It'd probably be better if you could make ecpg code depend only on > postgres_ext.h. However, I did commit fixes yesterday to solve the > immediate problem with mcxt.h. I found I essantially need only c.h (and config.h of course). I will change my include file to just include these. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael.Meskes@gmx.net | Use PostgreSQL!