Thread: no library dependency in Makefile?
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?
--
Is this a problem or not?
A simple fix:
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)
$(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 afterediting 'fe_utils/psqlscan.l'.The detail is:'psqlscan.l' is part of 'libpgfeutils.a' which will be builtinto 'psql' statically. But there is no dependency rule betweenthem.It's OK for 'libpq' since 'libpq' is a dynamic library.For a static library such as 'libpgfeutils.a', should weadd dependency rule in Makefile?
--
--
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:2. using GNU make's function to generate '-Lxxx -lxxx' for items in STLIBSFor example: libpgfeutils.a in psql's Makefile:'''# function to generate '-Lxxx -lxxx', may put in another fileexpand_stlibs = $(patsubst %,-L%,$(dir $(1))) $(patsubst lib%.a,-l%,$(notdir $(1)))# static libSTLIBS := $(top_builddir)/src/fe_utils/libpgfeutils.a # add STLIBS as normal prerequisitepsql: $(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 afterediting 'fe_utils/psqlscan.l'.The detail is:'psqlscan.l' is part of 'libpgfeutils.a' which will be builtinto 'psql' statically. But there is no dependency rule betweenthem.It's OK for 'libpq' since 'libpq' is a dynamic library.For a static library such as 'libpgfeutils.a', should weadd dependency rule in Makefile?
--
--
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:2. using GNU make's function to generate '-Lxxx -lxxx' for items in STLIBSFor example: libpgfeutils.a in psql's Makefile:'''# function to generate '-Lxxx -lxxx', may put in another fileexpand_stlibs = $(patsubst %,-L%,$(dir $(1))) $(patsubst lib%.a,-l%,$(notdir $(1)))# static libSTLIBS := $(top_builddir)/src/fe_utils/libpgfeutils.a# add STLIBS as normal prerequisitepsql: $(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 afterediting 'fe_utils/psqlscan.l'.The detail is:'psqlscan.l' is part of 'libpgfeutils.a' which will be builtinto 'psql' statically. But there is no dependency rule betweenthem.It's OK for 'libpq' since 'libpq' is a dynamic library.For a static library such as 'libpgfeutils.a', should weadd dependency rule in Makefile?
----
--
高增琦 <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>:
高增琦 <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.
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>:高增琦 <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 laneThank you, I will try it this way.
--
Attachment
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 dependencyfor 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>:高增琦 <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 laneThank you, I will try it this way.
--