no library dependency in Makefile?

Is this a problem or not?

A simple fix:
1. add a STLIBS variable in Makefiles as normal prerequisite
<https://www.gnu.org/software/make/manual/make.html#Prerequisite-Types&gt;
2. using GNU make's function to generate '-Lxxx -lxxx' for items in STLIBS

For example: libpgfeutils.a in psql's Makefile:
'''
# function to generate '-Lxxx -lxxx', may put in another file
expand_stlibs = $(patsubst %,-L%,$(dir $(1))) $(patsubst
lib%.a,-l%,$(notdir $(1)))

# static lib
STLIBS := $(top_builddir)/src/fe_utils/libpgfeutils.a

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

2017-11-15 16:10 GMT+08:00 高增琦 <pgf00a@gmail.com>:

Hi,

Recently, I found 'psql' is not rebuilt automatically after
editing 'fe_utils/psqlscan.l'.

The detail is:
'psqlscan.l' is part of 'libpgfeutils.a' which will be built
into 'psql' statically. But there is no dependency rule between
them.

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?

--
GaoZengqi
pgf00a@gmail.com
zengqigao@gmail.com

--
GaoZengqi
pgf00a@gmail.com
zengqigao@gmail.com

LDFLAGS in the example changed to:

'''
override LDFLAGS := $(call expand_stlibs,$(STLIBS)) $(libpq_pgport)
$(LDFLAGS)
'''

2017-11-16 20:50 GMT+08:00 高增琦 <pgf00a@gmail.com>:

Is this a problem or not?

A simple fix:
1. add a STLIBS variable in Makefiles as normal prerequisite
<https://www.gnu.org/software/make/manual/make.html#Prerequisite-Types&gt;
2. using GNU make's function to generate '-Lxxx -lxxx' for items in STLIBS

For example: libpgfeutils.a in psql's Makefile:
'''
# function to generate '-Lxxx -lxxx', may put in another file
expand_stlibs = $(patsubst %,-L%,$(dir $(1))) $(patsubst
lib%.a,-l%,$(notdir $(1)))

# static lib
STLIBS := $(top_builddir)/src/fe_utils/libpgfeutils.a

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

2017-11-15 16:10 GMT+08:00 高增琦 <pgf00a@gmail.com>:

Hi,

Recently, I found 'psql' is not rebuilt automatically after
editing 'fe_utils/psqlscan.l'.

The detail is:
'psqlscan.l' is part of 'libpgfeutils.a' which will be built
into 'psql' statically. But there is no dependency rule between
them.

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?

--
GaoZengqi
pgf00a@gmail.com
zengqigao@gmail.com

--
GaoZengqi
pgf00a@gmail.com
zengqigao@gmail.com

--
GaoZengqi
pgf00a@gmail.com
zengqigao@gmail.com

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.

thanks

高增琦 <pgf00a@gmail.com>于2017年11月16日 周四20:51写道：

LDFLAGS in the example changed to:

'''
override LDFLAGS := $(call expand_stlibs,$(STLIBS)) $(libpq_pgport)
$(LDFLAGS)
'''

2017-11-16 20:50 GMT+08:00 高增琦 <pgf00a@gmail.com>:

Is this a problem or not?

A simple fix:
1. add a STLIBS variable in Makefiles as normal prerequisite
<https://www.gnu.org/software/make/manual/make.html#Prerequisite-Types&gt;
2. using GNU make's function to generate '-Lxxx -lxxx' for items in STLIBS

For example: libpgfeutils.a in psql's Makefile:
'''
# function to generate '-Lxxx -lxxx', may put in another file
expand_stlibs = $(patsubst %,-L%,$(dir $(1))) $(patsubst
lib%.a,-l%,$(notdir $(1)))

# static lib
STLIBS := $(top_builddir)/src/fe_utils/libpgfeutils.a

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

2017-11-15 16:10 GMT+08:00 高增琦 <pgf00a@gmail.com>:

Hi,

Recently, I found 'psql' is not rebuilt automatically after
editing 'fe_utils/psqlscan.l'.

The detail is:
'psqlscan.l' is part of 'libpgfeutils.a' which will be built
into 'psql' statically. But there is no dependency rule between
them.

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?

--
GaoZengqi
pgf00a@gmail.com
zengqigao@gmail.com

--
GaoZengqi
pgf00a@gmail.com
zengqigao@gmail.com

--
GaoZengqi
pgf00a@gmail.com
zengqigao@gmail.com

--
GaoZengqi
pgf00a@gmail.com
zengqigao@gmail.com

=?UTF-8?B?6auY5aKe55Cm?= <pgf00a@gmail.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 $@$(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 $@$(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

2017-11-20 2:25 GMT+08:00 Tom Lane <tgl@sss.pgh.pa.us>:

=?UTF-8?B?6auY5aKe55Cm?= <pgf00a@gmail.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 $@$(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 $@$(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@gmail.com
zengqigao@gmail.com

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

2017-11-20 12:58 GMT+08:00 高增琦 <pgf00a@gmail.com>:

2017-11-20 2:25 GMT+08:00 Tom Lane <tgl@sss.pgh.pa.us>:

=?UTF-8?B?6auY5aKe55Cm?= <pgf00a@gmail.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 $@$(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 $@$(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@gmail.com
zengqigao@gmail.com

--
GaoZengqi
pgf00a@gmail.com
zengqigao@gmail.com

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@gmail.com>:

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

2017-11-20 12:58 GMT+08:00 高增琦 <pgf00a@gmail.com>:

2017-11-20 2:25 GMT+08:00 Tom Lane <tgl@sss.pgh.pa.us>:

=?UTF-8?B?6auY5aKe55Cm?= <pgf00a@gmail.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

$@$(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 $@$(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@gmail.com
zengqigao@gmail.com

--
GaoZengqi
pgf00a@gmail.com
zengqigao@gmail.com

--
GaoZengqi
pgf00a@gmail.com
zengqigao@gmail.com

This burned me recently.

On Sun, Nov 26, 2017 at 02:18:16PM +0800, 高增琦 wrote:

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.

Maybe. Naming an installed file as a Make prerequisite can break if installed
to a directory containing a space. If that works now, we shouldn't break it
for this. Otherwise, naming the installed prerequisites sounds fine.

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?

I prefer the second one. With the first one, it's easy to miss omissions. I
think that concept is useful beyond PG_LIBS and beyond PGXS. For example:

-initdb: $(OBJS) | submake-libpq submake-libpgport submake-libpgfeutils
+initdb: $(OBJS) $(stlib_pgport) $(stlib_pgfeutils) | submake-libpq
$(CC) $(CFLAGS) $(OBJS) $(LDFLAGS) $(LDFLAGS_EX) $(LIBS) -o $@$(X)

This could look like

initdb: $(OBJS) $(call lib_prereq,$(LDFLAGS) $(LDFLAGS_EX) $(LIBS))

where lib_prereq is a GNU make function that translates -lpgcommon to
SOMEDIR/libpgcommon.a, translates unrecognized arguments to nothing, etc.
This avoids the need to edit the "initdb" rule every time you edit LIBS. It's
easy to miss doing that, due to distance between the places that edit LIBS and
the places that read it. For example, Makefile.global is one of the editors
of LIBS. How do you see it?

Thanks,
nm