Re: Couple of build system points

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~