Thread: Future of src/utils

We have src/utils for stuff supposedly that is used by the backend and
other binaries, and src/backend/port for stuff used only by the backend.

However, over time, this distinction has broken down and we have a
number of backend/port stuff used in other binaries.  I propose moving
the src/utils remaining items into src/backend/port, and removing the
src/utils directory.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Bruce Momjian writes:

> However, over time, this distinction has broken down and we have a
> number of backend/port stuff used in other binaries.  I propose moving
> the src/utils remaining items into src/backend/port, and removing the
> src/utils directory.

I propose the reverse operation.

-- 
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut wrote:
> Bruce Momjian writes:
> 
> > However, over time, this distinction has broken down and we have a
> > number of backend/port stuff used in other binaries.  I propose moving
> > the src/utils remaining items into src/backend/port, and removing the
> > src/utils directory.
> 
> I propose the reverse operation.

Yea, I thought of that.  Means all the subdirectores have to move too. 
It is more extreme than moving stuff from /src/utils, but it is more
logical.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > However, over time, this distinction has broken down and we have a
> > number of backend/port stuff used in other binaries.  I propose moving
> > the src/utils remaining items into src/backend/port, and removing the
> > src/utils directory.
>
> I propose the reverse operation.

The following patch moves dllinit.c and strdup.c into backend/port, and
removes the src/utils directory, for the time being.  It also cleans up
dllinit so it has its own variable to point to the file path rather than
having it hard-coded in all the makefiles.

When we decide to move everything to src/utils, it will be all ready.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql/configure.in,v
retrieving revision 1.189
diff -c -r1.189 configure.in
*** configure.in    15 Jul 2002 22:41:45 -0000    1.189
--- configure.in    16 Jul 2002 05:41:22 -0000
***************
*** 916,922 ****
  AC_SUBST(INET_ATON)
  AC_CHECK_FUNCS(strerror, [], STRERROR='$(top_builddir)/src/backend/port/strerror.o')
  AC_SUBST(STRERROR)
! AC_CHECK_FUNCS(strdup, [], STRDUP='$(top_builddir)/src/utils/strdup.o')
  AC_SUBST(STRDUP)
  AC_CHECK_FUNCS(strtol, [], STRTOL='$(top_builddir)/src/backend/port/strtol.o')
  AC_SUBST(STRTOL)
--- 916,922 ----
  AC_SUBST(INET_ATON)
  AC_CHECK_FUNCS(strerror, [], STRERROR='$(top_builddir)/src/backend/port/strerror.o')
  AC_SUBST(STRERROR)
! AC_CHECK_FUNCS(strdup, [], STRDUP='$(top_builddir)/src/backend/port/strdup.o')
  AC_SUBST(STRDUP)
  AC_CHECK_FUNCS(strtol, [], STRTOL='$(top_builddir)/src/backend/port/strtol.o')
  AC_SUBST(STRTOL)
***************
*** 924,929 ****
--- 924,936 ----
  AC_SUBST(STRTOUL)
  AC_CHECK_FUNCS(strcasecmp, [], STRCASECMP='$(top_builddir)/src/backend/port/strcasecmp.o')
  AC_SUBST(STRCASECMP)
+
+ # Set path of dllinit.c for cygwin
+ DLLINIT=""
+ case $host_os in
+   cygwin*) DLLINIT='$(top_builddir)/src/backend/port/dllinit.o' ;;
+ esac
+ AC_SUBST(DLLINIT)

  # On HPUX 9, rint() is not in regular libm.a but in /lib/pa1.1/libm.a;
  # this hackery with HPUXMATHLIB allows us to cope.
Index: src/Makefile.global.in
===================================================================
RCS file: /cvsroot/pgsql/src/Makefile.global.in,v
retrieving revision 1.148
diff -c -r1.148 Makefile.global.in
*** src/Makefile.global.in    28 May 2002 16:57:53 -0000    1.148
--- src/Makefile.global.in    16 Jul 2002 05:41:23 -0000
***************
*** 359,364 ****
--- 359,365 ----
  STRERROR    = @STRERROR@
  STRTOL      = @STRTOL@
  STRTOUL     = @STRTOUL@
+ DLLINIT     = @DLLINIT@

  TAS         = @TAS@

Index: src/Makefile.shlib
===================================================================
RCS file: /cvsroot/pgsql/src/Makefile.shlib,v
retrieving revision 1.58
diff -c -r1.58 Makefile.shlib
*** src/Makefile.shlib    24 May 2002 18:10:17 -0000    1.58
--- src/Makefile.shlib    16 Jul 2002 05:41:23 -0000
***************
*** 327,339 ****
  else # PORTNAME == win

  # WIN case
! $(shlib) lib$(NAME).a: $(OBJS) $(top_builddir)/src/utils/dllinit.o
      $(DLLTOOL) --export-all --output-def $(NAME).def $(OBJS)
!     $(DLLWRAP) -o $(shlib) --dllname $(shlib) --def $(NAME).def $(OBJS) $(top_builddir)/src/utils/dllinit.o
$(DLLINIT)$(DLLLIBS) $(SHLIB_LINK) 
      $(DLLTOOL) --dllname $(shlib) --def $(NAME).def --output-lib lib$(NAME).a

! $(top_builddir)/src/utils/dllinit.o: $(top_srcdir)/src/utils/dllinit.c
!     $(MAKE) -C $(top_builddir)/src/utils dllinit.o

  endif # PORTNAME == win

--- 327,339 ----
  else # PORTNAME == win

  # WIN case
! $(shlib) lib$(NAME).a: $(OBJS) $(DLLINIT)
      $(DLLTOOL) --export-all --output-def $(NAME).def $(OBJS)
!     $(DLLWRAP) -o $(shlib) --dllname $(shlib) --def $(NAME).def $(OBJS) $(DLLINIT) $(DLLLIBS) $(SHLIB_LINK)
      $(DLLTOOL) --dllname $(shlib) --def $(NAME).def --output-lib lib$(NAME).a

! $(DLLINIT):
!     $(MAKE) -C $(@D) $(@F)

  endif # PORTNAME == win

Index: src/backend/Makefile
===================================================================
RCS file: /cvsroot/pgsql/src/backend/Makefile,v
retrieving revision 1.79
diff -c -r1.79 Makefile
*** src/backend/Makefile    22 May 2002 21:46:40 -0000    1.79
--- src/backend/Makefile    16 Jul 2002 05:41:24 -0000
***************
*** 43,49 ****

  # No points for style here. How about encapsulating some of these
  # commands into variables?
! postgres: $(OBJS) $(top_builddir)/src/utils/dllinit.o postgres.def libpostgres.a
      dlltool --dllname $@$(X) --output-exp $@.exp --def postgres.def
      gcc $(LDFLAGS) -g -o $@$(X) -Wl,--base-file,$@.base $@.exp $(OBJS) $(DLLLIBS)
      dlltool --dllname $@$(X) --base-file $@.base --output-exp $@.exp --def postgres.def
--- 43,49 ----

  # No points for style here. How about encapsulating some of these
  # commands into variables?
! postgres: $(OBJS) $(DLLINIT) postgres.def libpostgres.a
      dlltool --dllname $@$(X) --output-exp $@.exp --def postgres.def
      gcc $(LDFLAGS) -g -o $@$(X) -Wl,--base-file,$@.base $@.exp $(OBJS) $(DLLLIBS)
      dlltool --dllname $@$(X) --base-file $@.base --output-exp $@.exp --def postgres.def
***************
*** 67,80 ****
  postgres.def: $(OBJS)
      $(DLLTOOL) --export-all --output-def $@ $(OBJS)

! libpostgres.a: $(OBJS) $(top_builddir)/src/utils/dllinit.o postgres.def
      $(DLLTOOL) --dllname postgres.exe --def postgres.def --output-lib $@

  endif # MAKE_DLL


! $(top_builddir)/src/utils/dllinit.o: $(top_srcdir)/src/utils/dllinit.c
!     $(MAKE) -C $(top_builddir)/src/utils dllinit.o

  # The postgres.o target is needed by the rule in Makefile.global that
  # creates the exports file when MAKE_EXPORTS = true.
--- 67,80 ----
  postgres.def: $(OBJS)
      $(DLLTOOL) --export-all --output-def $@ $(OBJS)

! libpostgres.a: $(OBJS) $(DLLINIT) postgres.def
      $(DLLTOOL) --dllname postgres.exe --def postgres.def --output-lib $@

  endif # MAKE_DLL


! $(DLLINIT):
!     $(MAKE) -C $(@D) $(@F)

  # The postgres.o target is needed by the rule in Makefile.global that
  # creates the exports file when MAKE_EXPORTS = true.
Index: src/makefiles/Makefile.win
===================================================================
RCS file: /cvsroot/pgsql/src/makefiles/Makefile.win,v
retrieving revision 1.15
diff -c -r1.15 Makefile.win
*** src/makefiles/Makefile.win    6 Sep 2001 02:58:33 -0000    1.15
--- src/makefiles/Makefile.win    16 Jul 2002 05:41:25 -0000
***************
*** 17,23 ****

  %.dll: %.o
      $(DLLTOOL) --export-all --output-def $*.def $<
!     $(DLLWRAP) -o $@ --def $*.def $< $(top_builddir)/src/utils/dllinit.o $(DLLLIBS)
      rm -f $*.def

  ifeq ($(findstring backend,$(subdir)), backend)
--- 17,23 ----

  %.dll: %.o
      $(DLLTOOL) --export-all --output-def $*.def $<
!     $(DLLWRAP) -o $@ --def $*.def $< $(DLLINIT) $(DLLLIBS)
      rm -f $*.def

  ifeq ($(findstring backend,$(subdir)), backend)

Bruce Momjian writes:

> Yea, I thought of that.  Means all the subdirectores have to move too.
> It is more extreme than moving stuff from /src/utils, but it is more
> logical.

I don't think we need to move the subdirectories, which involve stuff
that's heavily tied to the backend.  But the generic C library replacement
files should move into src/utils preferably.  In fact, what we could do is
assemble all the files we need (as determined by configure) into a static
library and link all executables with that.  That way we don't have to
deal with the individual files in each individual makefile.

-- 
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:
> I don't think we need to move the subdirectories, which involve stuff
> that's heavily tied to the backend.  But the generic C library replacement
> files should move into src/utils preferably.  In fact, what we could do is
> assemble all the files we need (as determined by configure) into a static
> library and link all executables with that.  That way we don't have to
> deal with the individual files in each individual makefile.

I like that a lot.  But will it work for libpq?  I have a feeling we'd
end up linking *all* the replacement functions into libpq, which might
create some namespace issues for client applications.  Ideally we should
only link the functions libpq actually needs into libpq, but I'm not
sure that works with standard linker behavior.
        regards, tom lane

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > I don't think we need to move the subdirectories, which involve stuff
> > that's heavily tied to the backend.  But the generic C library replacement
> > files should move into src/utils preferably.  In fact, what we could do is
> > assemble all the files we need (as determined by configure) into a static
> > library and link all executables with that.  That way we don't have to
> > deal with the individual files in each individual makefile.
> 
> I like that a lot.  But will it work for libpq?  I have a feeling we'd

Yes, I like it too, and I like the fact that the subdirectories stay,
because those are so backend-specific, it doesn't make any sense to move
them.

Can we move them to src/port rather than src/utils?  Port makes more
sense to me because that's what they are.  Maybe is should be called
src/libc?

> end up linking *all* the replacement functions into libpq, which might
> create some namespace issues for client applications.  Ideally we should
> only link the functions libpq actually needs into libpq, but I'm not
> sure that works with standard linker behavior.

Linkers work per object file, so if each member of the library has only
one function in it (which is how we do it now anyway) a linker will pick
out only the object files it needs.  Many C libraries have multiple
functions per object file, and that's where you see the namespace
pollution.

Actually, our current setup is more prone to pollution becuse we
unconditionally add *.o files to the link line.  Add a library makes
sure only the object files needed are added to the executable.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Tom Lane writes:

> > assemble all the files we need (as determined by configure) into a static
> > library and link all executables with that.  That way we don't have to
> > deal with the individual files in each individual makefile.
>
> I like that a lot.  But will it work for libpq?

No, just for executables.  Otherwise you'd get into a big PIC mess.

-- 
Peter Eisentraut   peter_e@gmx.net

Bruce Momjian writes:

> Can we move them to src/port rather than src/utils?  Port makes more
> sense to me because that's what they are.  Maybe is should be called
> src/libc?

Well, there is a bit of a history in picking a really silly name for this
library.  GCC calls it libiberty, Kerberos calls it libroken.  Make up
your own.  "port" makes sense, though.

-- 
Peter Eisentraut   peter_e@gmx.net

Peter Eisentraut wrote:
> Tom Lane writes:
> 
> > > assemble all the files we need (as determined by configure) into a static
> > > library and link all executables with that.  That way we don't have to
> > > deal with the individual files in each individual makefile.
> >
> > I like that a lot.  But will it work for libpq?
> 
> No, just for executables.  Otherwise you'd get into a big PIC mess.

Oh, OK, so we keep the same object file variables, but just move them to
src/port.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026