Re: Future of src/utils

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026