You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kevin Pilch-Bisson <ke...@pilch-bisson.net> on 2001/08/27 16:30:47 UTC
Couple of build system points
Hey All,
A couple of issues I've found regarding the build system.
1) Make extraclean:
When doing make extraclean, we skip neon. Firstly, we also need to skip
db/dist. Secondly, we should 'make distclean' instead.
I plan on fixing this by the patch at the end of this mail.
2) When the db-in-tree is built, we need to do a couple of things:
a) Make sure it is a valid version
b) Make sure it finishes building before we try to link against it(think
make -j here).
Not sure of the best approach here.
3) When we have no db or apache, we need to make sure that the install
target doesn't depend on the fs/module components, or else we try
to build it at install time.
My plan for this was to change the way build.conf works, by combining the
group and install options. Thus we would have install values of
lib, fs-lib, bin, fs-bin, sbin, fs-sbin, test, fs-test. Then change
gen-make.py and configure.in to make rules for each of the existing install
values, and substitute the ones that are needed back into the makefile. What
do you all think about this approach and the patch below?
Index: Makefile.in
===================================================================
RCS file: /usr/local/tigris/data/helm/cvs/repository/subversion/Makefile.in,v
retrieving revision 1.28
diff -u -r1.28 Makefile.in
--- Makefile.in 2001/08/20 20:32:01 1.28
+++ Makefile.in 2001/08/27 16:33:04
@@ -150,14 +150,19 @@
echo "------ completed $$target in $$i"; \
done;
-### temporary hack. Neon does not have an "extraclean"
+### temporary hack. Neon does not have an "extraclean" and neither does db
+### If we don't have extraclean -- do the next best thing.
external-extraclean:
@list='$(EXTERNAL_PROJECT_DIRS)'; \
for i in $$list; do \
- if test "$$i" != "neon"; then \
- echo "------ making extraclean in $$i"; \
- (cd $$i && $(MAKE) extraclean) || exit 1; \
- echo "------ completed extraclean in $$i"; \
+ if test "$$i" != "neon" && test "$$i" != "db/dist"; then \
+ echo "------ making extraclean in $$i"; \
+ (cd $$i && $(MAKE) extraclean) || exit 1; \
+ echo "------ completed extraclean in $$i"; \
+ else \
+ echo "------ making distclean(no extraclean) in $$i": \
+ (cd $$i && $(MAKE) distclean) || exit 1; \
+ echo "------ completed distclean(no extraclean) in $$i"; \
fi; \
done;
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Couple of build system points
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Mon, Aug 27, 2001 at 10:18:30PM -0700, Greg Stein wrote:
>[ urf. wrote this earlier today, but got distracted and forgot about it... ]
>
> On Mon, Aug 27, 2001 at 12:30:47PM -0400, Kevin Pilch-Bisson wrote:
> > Hey All,
> >
> > A couple of issues I've found regarding the build system.
> >
> > 1) Make extraclean:
> > When doing make extraclean, we skip neon. Firstly, we also need to skip
> > db/dist. Secondly, we should 'make distclean' instead.
>
> The "make distclean" should have occurred when extraclean invoked the
> distclean rule. IOW, extraclean simply shouldn't worry about neon and db.
> But it should worry about APR since we (normally) pull that from CVS.
not really, we have this:
extraclean: external-extraclean local-extraclean
local-extraclean: local-distclean
# Stuff
external-extraclean:
@list=`echo ...
So we don't do an external-distclean(and we can't, since it would remove the
Makefiles, preventing us from actually doing an extraclean.
>
> [ extraclean is about cleaning a directory from "dist-ready" (i.e. files
> such as ./configure are present) to its cleanest form: like when it comes
> straight from CVS
Yes, but I would expect that make distclean would in fact remove the object
files.
>
> > I plan on fixing this by the patch at the end of this mail.
> >
> > 2) When the db-in-tree is built, we need to do a couple of things:
> > a) Make sure it is a valid version
>
> Shouldn't be hard, but no immediate ideas here...
>
> > b) Make sure it finishes building before we try to link against it(think
> > make -j here).
>
> I guess this would imply that we create a rule for building the library,
> which recurses into the db directory.
>
> > Not sure of the best approach here.
> >
> > 3) When we have no db or apache, we need to make sure that the install
> > target doesn't depend on the fs/module components, or else we try
> > to build it at install time.
> >
> > My plan for this was to change the way build.conf works, by combining the
> > group and install options. Thus we would have install values of
> > lib, fs-lib, bin, fs-bin, sbin, fs-sbin, test, fs-test. Then change
>
> Well... combining them is somewhat combinatorial. Note there is also an
> fs-lib-test and a lib-test. (or is that test-lib? :-)
>
> For the install issue, I just tried the attached patch and it created an
> install-fs-libs rule for me, and removed the FS libs from the main
> install-lib rule. Then, we would just have a little tweak in configure.in
> and Makefile.in to set up the install stuff. (no gen-make changes needed)
Well yes you have a rule for installing fs-libs. What about fs-bins, and
fs-sbins.
In testing I also found that we are going to have to separate out which tests
we are going to run into fs and non-fs.
>
> [ of course, I *do* see that group and install are somewhat/usually related,
> but I'm also a bit leery of all the various combos. it seems somewhat
> preferable to specify them independently ]
>
I don't really see why, essentially the only significant change to gen-make.py
is that the
for g_name, g_targets in groups.items():
becomes
for g_name, g_targets in intall.items():
target_names = [ ]
for t in g_targets:
target_names.append(t.name)
It just seems very redundant to have to specify
group=fs-programs AND install=fs-bin
when install=fs-bin is contains all the information of fs-programs, and more.
>
> --
> Greg Stein, http://www.lyra.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Couple of build system points
Posted by Greg Stein <gs...@lyra.org>.
And we'll attach the patch...
On Mon, Aug 27, 2001 at 10:18:30PM -0700, Greg Stein wrote:
> [ urf. wrote this earlier today, but got distracted and forgot about it... ]
>
> On Mon, Aug 27, 2001 at 12:30:47PM -0400, Kevin Pilch-Bisson wrote:
> > Hey All,
> >
> > A couple of issues I've found regarding the build system.
> >
> > 1) Make extraclean:
> > When doing make extraclean, we skip neon. Firstly, we also need to skip
> > db/dist. Secondly, we should 'make distclean' instead.
>
> The "make distclean" should have occurred when extraclean invoked the
> distclean rule. IOW, extraclean simply shouldn't worry about neon and db.
> But it should worry about APR since we (normally) pull that from CVS.
>
> [ extraclean is about cleaning a directory from "dist-ready" (i.e. files
> such as ./configure are present) to its cleanest form: like when it comes
> straight from CVS ]
>
> > I plan on fixing this by the patch at the end of this mail.
> >
> > 2) When the db-in-tree is built, we need to do a couple of things:
> > a) Make sure it is a valid version
>
> Shouldn't be hard, but no immediate ideas here...
>
> > b) Make sure it finishes building before we try to link against it(think
> > make -j here).
>
> I guess this would imply that we create a rule for building the library,
> which recurses into the db directory.
>
> > Not sure of the best approach here.
> >
> > 3) When we have no db or apache, we need to make sure that the install
> > target doesn't depend on the fs/module components, or else we try
> > to build it at install time.
> >
> > My plan for this was to change the way build.conf works, by combining the
> > group and install options. Thus we would have install values of
> > lib, fs-lib, bin, fs-bin, sbin, fs-sbin, test, fs-test. Then change
>
> Well... combining them is somewhat combinatorial. Note there is also an
> fs-lib-test and a lib-test. (or is that test-lib? :-)
>
> For the install issue, I just tried the attached patch and it created an
> install-fs-libs rule for me, and removed the FS libs from the main
> install-lib rule. Then, we would just have a little tweak in configure.in
> and Makefile.in to set up the install stuff. (no gen-make changes needed)
>
> [ of course, I *do* see that group and install are somewhat/usually related,
> but I'm also a bit leery of all the various combos. it seems somewhat
> preferable to specify them independently ]
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
--
Greg Stein, http://www.lyra.org/
Re: Couple of build system points
Posted by Greg Stein <gs...@lyra.org>.
[ urf. wrote this earlier today, but got distracted and forgot about it... ]
On Mon, Aug 27, 2001 at 12:30:47PM -0400, Kevin Pilch-Bisson wrote:
> Hey All,
>
> A couple of issues I've found regarding the build system.
>
> 1) Make extraclean:
> When doing make extraclean, we skip neon. Firstly, we also need to skip
> db/dist. Secondly, we should 'make distclean' instead.
The "make distclean" should have occurred when extraclean invoked the
distclean rule. IOW, extraclean simply shouldn't worry about neon and db.
But it should worry about APR since we (normally) pull that from CVS.
[ extraclean is about cleaning a directory from "dist-ready" (i.e. files
such as ./configure are present) to its cleanest form: like when it comes
straight from CVS ]
> I plan on fixing this by the patch at the end of this mail.
>
> 2) When the db-in-tree is built, we need to do a couple of things:
> a) Make sure it is a valid version
Shouldn't be hard, but no immediate ideas here...
> b) Make sure it finishes building before we try to link against it(think
> make -j here).
I guess this would imply that we create a rule for building the library,
which recurses into the db directory.
> Not sure of the best approach here.
>
> 3) When we have no db or apache, we need to make sure that the install
> target doesn't depend on the fs/module components, or else we try
> to build it at install time.
>
> My plan for this was to change the way build.conf works, by combining the
> group and install options. Thus we would have install values of
> lib, fs-lib, bin, fs-bin, sbin, fs-sbin, test, fs-test. Then change
Well... combining them is somewhat combinatorial. Note there is also an
fs-lib-test and a lib-test. (or is that test-lib? :-)
For the install issue, I just tried the attached patch and it created an
install-fs-libs rule for me, and removed the FS libs from the main
install-lib rule. Then, we would just have a little tweak in configure.in
and Makefile.in to set up the install stuff. (no gen-make changes needed)
[ of course, I *do* see that group and install are somewhat/usually related,
but I'm also a bit leery of all the various combos. it seems somewhat
preferable to specify them independently ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org