Re: no library dependency in Makefile?

From: 高增琦 <pgf00a(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: no library dependency in Makefile?
Date: 2017-11-26 06:18:16
Message-ID: CAFmBtr3Drr2Kw+_+eXjMVPv0n=yJH22mNy4H=4fnxfSTm0dXPg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi, all

Update version:
1. Re-base with head of master
2. Add some basic support for PGXS

After replacing submake-libpgport/submake-libpgfeutils with
$(stlib_pgport)/$(stlib_pgfeutils) in
Makefiles of client programs, I think, may be we should add static lib
dependency for PGXS.

I can think two ways to do that: first, add a new PG_STLIBS variable, user
need to
add static libs to it; second, we generate static lib dependency
automatically
from PG_LIBS variable. Which one is better?

Thanks

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

> 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
>

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

Attachment Content-Type Size
0001-Add-build-dependency-between-client-and-static-lib.patch application/octet-stream 18.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-11-26 07:40:16 Re: Code cleanup patch submission for extended_stats.c
Previous Message Tom Lane 2017-11-26 03:55:00 Re: [PATCH] Fix crash in int8_avg_combine().