Proposed patch to remove .so pattern rules from platform Makefiles
I've wanted for a long time to get rid of the pattern rules in the
port-specific Makefiles that generate shared libraries from single
object files. These patterns duplicate (or, more often, fail to
completely duplicate) the knowledge in Makefile.shlib. So from
a maintenance point of view centralizing that knowledge is a good
thing.
The stumbling block has been partly that the regression-test makefile
depended on the pattern rules (easily fixed by using Makefile.shlib)
and partly that pgxs.mk (and its predecessor contrib-global.mk) depended
on the pattern rules to handle Makefiles that wanted to build multiple
.so files. Since Makefile.shlib is designed to handle only one shlib
per build, there wasn't any obvious way to fix that.
The attached proposed patch gets around this by invoking Makefile.shlib
in a way that produces a pattern rule "lib%.so : %.o". This is
moderately ugly but it gets the job done without changing Makefile.shlib
itself. Possibly it could be done more cleanly if we were willing
to introduce pattern rules inside Makefile.shlib.
I am not sure if the patch works on non-Unix platforms --- could someone
test on Win32 and Cygwin, in particular? AIX is weird enough to need
testing too.
Any other comments?
regards, tom lane
The patch works on AIX with one small tweak to Makefile.shlib
(attached). This is needed because of the clever trick with using % as
name, and when its evaulated for the mkldexport.
Also, it appears that the changes for regress/GNUmakefile are already
applied.
I am able to build everything and pass the regression tests. This just
leaves the contrib/pgport issue from letting AIX go green on the
buildfarm.
Thanks for getting this simplification done!
-rocco
Show quoted text
-----Original Message-----
From: pgsql-patches-owner@postgresql.org
[mailto:pgsql-patches-owner@postgresql.org] On Behalf Of Tom Lane
Sent: Sunday, July 24, 2005 6:00 PM
To: pgsql-patches@postgresql.org
Subject: [PATCHES] Proposed patch to remove .so pattern rules
from platform MakefilesI've wanted for a long time to get rid of the pattern rules in the
port-specific Makefiles that generate shared libraries from single
object files. These patterns duplicate (or, more often, fail to
completely duplicate) the knowledge in Makefile.shlib. So from
a maintenance point of view centralizing that knowledge is a good
thing.The stumbling block has been partly that the regression-test makefile
depended on the pattern rules (easily fixed by using Makefile.shlib)
and partly that pgxs.mk (and its predecessor
contrib-global.mk) depended
on the pattern rules to handle Makefiles that wanted to build multiple
.so files. Since Makefile.shlib is designed to handle only one shlib
per build, there wasn't any obvious way to fix that.The attached proposed patch gets around this by invoking
Makefile.shlib
in a way that produces a pattern rule "lib%.so : %.o". This is
moderately ugly but it gets the job done without changing
Makefile.shlib
itself. Possibly it could be done more cleanly if we were willing
to introduce pattern rules inside Makefile.shlib.I am not sure if the patch works on non-Unix platforms ---
could someone
test on Win32 and Cygwin, in particular? AIX is weird enough to need
testing too.Any other comments?
regards, tom lane
Attachments:
makefile.shlibapplication/octet-stream; name=makefile.shlibDownload+2-2
Import Notes
Resolved by subject fallback
Please disregard this patch. I have a ton of lib%.exp and similar files
created currently.
I am working on a new patch to deal with the MODULES expansion
correctly.
Thanks,
-rocco
Show quoted text
-----Original Message-----
From: pgsql-patches-owner@postgresql.org
[mailto:pgsql-patches-owner@postgresql.org] On Behalf Of Rocco Altier
Sent: Monday, July 25, 2005 1:17 PM
To: Tom Lane; pgsql-patches@postgresql.org
Subject: Re: [PATCHES] Proposed patch to remove .so pattern
rules from platform MakefilesThe patch works on AIX with one small tweak to Makefile.shlib
(attached). This is needed because of the clever trick with
using % as
name, and when its evaulated for the mkldexport.Also, it appears that the changes for regress/GNUmakefile are already
applied.I am able to build everything and pass the regression tests.
This just
leaves the contrib/pgport issue from letting AIX go green on the
buildfarm.Thanks for getting this simplification done!
-rocco
-----Original Message-----
From: pgsql-patches-owner@postgresql.org
[mailto:pgsql-patches-owner@postgresql.org] On Behalf Of Tom Lane
Sent: Sunday, July 24, 2005 6:00 PM
To: pgsql-patches@postgresql.org
Subject: [PATCHES] Proposed patch to remove .so pattern rules
from platform MakefilesI've wanted for a long time to get rid of the pattern rules in the
port-specific Makefiles that generate shared libraries from single
object files. These patterns duplicate (or, more often, fail to
completely duplicate) the knowledge in Makefile.shlib. So from
a maintenance point of view centralizing that knowledge is a good
thing.The stumbling block has been partly that the
regression-test makefile
depended on the pattern rules (easily fixed by using Makefile.shlib)
and partly that pgxs.mk (and its predecessor
contrib-global.mk) depended
on the pattern rules to handle Makefiles that wanted tobuild multiple
.so files. Since Makefile.shlib is designed to handle only
one shlib
per build, there wasn't any obvious way to fix that.
The attached proposed patch gets around this by invoking
Makefile.shlib
in a way that produces a pattern rule "lib%.so : %.o". This is
moderately ugly but it gets the job done without changing
Makefile.shlib
itself. Possibly it could be done more cleanly if we were willing
to introduce pattern rules inside Makefile.shlib.I am not sure if the patch works on non-Unix platforms ---
could someone
test on Win32 and Cygwin, in particular? AIX is weirdenough to need
testing too.
Any other comments?
regards, tom lane
Import Notes
Resolved by subject fallback
"Rocco Altier" <RoccoA@Routescape.com> writes:
Please disregard this patch. I have a ton of lib%.exp and similar files
created currently.
Yeah, that was one of the reasons I called it ugly :-(. I had put in an
"rm" step to get rid of lib%.so, you could probably fix the extraneous
.exp files similarly.
Alternatively we could look at expanding Makefile.shlib to provide %.so
pattern rules directly. My patch was more intended as proof of concept
than anything we necessarily wanted to apply as-is.
regards, tom lane
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]"Rocco Altier" <RoccoA@Routescape.com> writes:
Please disregard this patch. I have a ton of lib%.exp and
similar files created currently.Yeah, that was one of the reasons I called it ugly :-(. I
had put in an
"rm" step to get rid of lib%.so, you could probably fix the extraneous
.exp files similarly.
If they are part of the rule, they get expanded, but if its part of the
commands to run, they don't, which is where I was getting the lib%.exp
from.
I have gotten them to where they will be expanded for the .exp, so that
there are the multiple files correctly, instead of just the one
lib%.exp. I will look at doing the same for lib%.so, etc.
Alternatively we could look at expanding Makefile.shlib to
provide %.so pattern rules directly.
If I am reading the affect on the makefiles correctly, that is basically
what is happening. We get a bunch of pattern rules...
From gmake -p (in contrib/spi - a multiple MODULES rule):
lib%.a: %.o
# commands to execute (from `../../src/Makefile.shlib', line 281):
$(LINK.static) $@ $^
$(RANLIB) $@
lib%.so: lib%.a
# commands to execute (from `../../src/Makefile.shlib', line 313):
$(MKLDEXPORT) $< > $(subst .a,$(EXPSUFF),$<)
$(COMPILER) $(LDFLAGS_SL) -o $@ $< $(LDFLAGS) $(SHLIB_LINK)
-Wl,-bI:$(top_builddir)/src/backend/$(POSTGRES_IMP) -Wl,-bE:$(subst
.a,$(EXPSUFF),$<)
%.so: lib%.so
# commands to execute (from `../../src/makefiles/pgxs.mk', line 85):
rm -f $@
ln $< $@
rm -f $(shlib_major)
...
(Substituted rules with autoinc later..)
My patch was more intended as proof of concept
than anything we necessarily wanted to apply as-is.
I have been trying to iron out some of the wrinkles, but over all its
definitely a good place to start.
Thanks,
-rocco
Import Notes
Resolved by subject fallback