Re: no library dependency in Makefile?

The attached patch use normal dependency instead of order-only dependency
for static libraries.

2017-11-20 12:58 GMT+08:00 高增琦 <pgf00a(at)gmail(dot)com>:

>
>
> 2017-11-20 2:25 GMT+08:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>
>> =?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.
>>
>
> Sorry, my fault, I am so anxious.
>
>
>> > 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
>>
>
> Thank you, I will try it this way.
>
>
> --
> GaoZengqi
> pgf00a(at)gmail(dot)com
> zengqigao(at)gmail(dot)com
>

--
GaoZengqi
pgf00a(at)gmail(dot)com
zengqigao(at)gmail(dot)com