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
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
> > 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
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():
for g_name, g_targets in intall.items():
target_names = [ ]
for t in g_targets:
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: firstname.lastname@example.org
> For additional commands, e-mail: email@example.com
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
Received on Sat Oct 21 14:36:37 2006
- application/pgp-signature attachment: stored