Re: no library dependency in Makefile?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: 高增琦 <pgf00a(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: no library dependency in Makefile?
Date: 2017-11-19 18:25:07
Message-ID: 11328.1511115907@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

=?UTF-8?B?6auY5aKe55Cm?= <pgf00a(at)gmail(dot)com> writes:
> I very much look forward to hearing everyone's views on this issue.
> If the solution mentioned before is ok, I will start to complete it.

Please don't top-post, it makes the flow of the conversation very hard
to follow.

> Recently, I found 'psql' is not rebuilt automatically after
> editing 'fe_utils/psqlscan.l'.
> ...
> It's OK for 'libpq' since 'libpq' is a dynamic library.
> For a static library such as 'libpgfeutils.a', should we
> add dependency rule in Makefile?

Hm. I think what you're saying is that when we copied the makefile
patterns used for libpq.so to use for libpgport and libpgfeutils,
we did the wrong thing because those are static not dynamic libraries.
We don't have to relink psql if libpq.so gets some non-API-relevant
changes, but we do need to relink it if libpgport.a does, so I suppose
you are right. However, this doesn't seem like the right way to
fix it:

> # add STLIBS as normal prerequisite
> psql: $(OBJS) $(STLIBS) | submake-libpq submake-libpgport submake-libpgfeutils
> $(CC) $(CFLAGS) $(OBJS) $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $(at)$(X)

Your point is that the static libraries should be treated as normal
dependencies not order-only ones, so building that behavior like
this seems pretty bizarre.

I think what we want is something more like

../../src/port/libpgport.a: submake-libpgport

../../src/fe_utils/libpgfeutils.a: submake-libpgfeutils

psql: $(OBJS) ../../src/port/libpgport.a ../../src/fe_utils/libpgfeutils.a | submake-libpq
$(CC) $(CFLAGS) $(OBJS) $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $(at)$(X)

where of course the library file names need to be wrapped up in macros,
but this is what it'd look like after macro expansion. (I'm not sure
this is right in detail, but my point is that we don't want order-only
dependencies for these libraries.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-11-19 19:22:31 Re: Patch to add dependency between client executes and static libraries
Previous Message David Fetter 2017-11-19 17:49:38 Re: percentile value check can be slow