Robert Haas wrote: > On Fri, Jan 15, 2010 at 11:47 AM, Heikki Linnakangas > <heikki.linnakan...@enterprisedb.com> wrote: >> Tom Lane wrote: >>> Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> writes: >>>> Yep. What's happening is that "make -j" starts building libpq and >>>> walreceiver.so simultaneously, because of the above line in the >>>> Makefile. We actually have the same problem in src/bin/*/Makefile, but >>>> we don't notice it there because src/interfaces is listed before src/bin >>>> in src/Makefile, so when you do "make -j" at the top-level, libpq is >>>> built first. >>> I'm actually fairly uncomfortable with the notion that something buried >>> deep within the src/backend tree is going to reach over and cause libpq >>> to get built. Maybe the real answer is that you put walreceiver in the >>> wrong place, and it ought to be under src/bin/. >> That feels even more wrong to me. Walreceiver is a postmaster >> subprocess, tightly integrated with the rest of the backend. > > The major problem with having one part of the tree depend on a > completely different part of the tree is that it's easy for the > dependencies to be wrong. If the backend depends on libpq, then it > depends implicitly on all the things on which libpq depends. If > something that libpq depends on, but that the backend does not depend > on directly, gets updated, does the backend get rebuilt?
The backend doesn't get rebuilt, and it doesn't need to be. The fact that walreceiver is a dynamically loaded module should isolate changes in libpq or its dependencies from affecting the rest of the backend. I moved the line for src/backend/replication/walreceiver in src/Makefile further down, after src/interfaces. That should fix the build failures for now, but I'm all ears if there's better suggestions. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
