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