new build system (was: Re: CVS update: MODIFIED: ac-helpers ...)

On Thu, May 24, 2001 at 01:40:17PM -0000, gstein@tigris.org wrote:
> User: gstein
> Date: 01/05/24 06:40:17
>
> Modified: ac-helpers .cvsignore svn-apache.m4
> Added: . Makefile.in
> Log:
> Switch over to the new non-recursive build system.
>...

Okay... this is it. We're now on the build system.

    "It works on my machine."

I suspect there may be some tweaks to make on differents OSs. I'd be
interested to hear if Ben can really build with normal BSD make. It should
be possible.

The code supports building, installation, checking, and dependencies. It
does *NOT* yet deal with the doc/ subdirectory. That is next; I figured this
could be rolled out and get the kinks worked out while I do the doc/ stuff.
Oh, it doesn't build Neon or APR yet either. I also saw a problem where
libsvn_fs wasn't getting built before linking one of the test proggies (see
below).

Basic operation: same as before.

$ ./autogen.sh
$ ./configure OPTIONS
$ make
$ make check
$ make install

There are some "make check" scripts that need to be fixed up. That'll happen
RSN. Some of them create their own log, rather than spewing to stdout (where
the top-level make will place the output into [TOP]/tests.log).

The old Makefile.am files are still around, but I'll be tossing those along
with a bunch of tweaks to all the .cvsignore files. There are a few other
cleanups, too. But that can happen as a step two.

[ $ cvs rm -f `find . -name Makefile.rm`

  See the mistake in that line? I didn't when I typed it. The find returned
  nothing, so cvs rm -f proceeded to delete my entire tree. And the -f made
  sure to delete all my source files, too. Good fugging thing that I had my
  mods in some Emacs buffers, or I'd be bitching.

  I am *so* glad that Ben coded SVN to *not* delete locally modified files
  *and* that we have an "undel" command. I had to go and tweak a bazillion
  Entries files to undo the delete...
]

The top-level make has a number of shortcuts in it (well, actually in
build-outputs.mk):

$ make subversion/libsvn_fs/libsvn_fs.la

or

$ make libsvn_fs

The two are the same. So... when your test proggie fails to link because
libsvn_fs isn't around, just run "make libsvn_fs" to build it immediately,
then go back to the regular "make".

Note that the system still conditionally builds the FS stuff based on
whether DB is available, and mod_dav_svn if Apache is available.

Handy hint: if you don't like dependencies, then you can do:

$ ./autogen.sh -s

That will skip the dependency generation that goes into build-outputs.mk. It
makes the script run quite a bit faster (48 secs vs 2 secs on my poor little
Pentium 120).

Note that if you change build.conf, you can simply run:

$ ./gen-make.py build.conf

to regen build-outputs.mk. You don't have to go back through the whole
autogen.sh / configure process.

You should also note that autogen.sh and configure run much faster now that
we don't have the automake crap. Oh, and our makefiles never re-run
configure on you out of the blue (gawd, I hated when automake did that to
me).

Obviously, there are going to be some tweaky things going on. I also think
that the "shadow" builds or whatever they're called (different source and
build dirs) are totally broken. Something tweaky will have to happen there.
But, thankfully, we only have one Makefile to deal with.

Note that I arrange things so that we have one generated file
(build-outputs.mk), and one autoconf-generated file (Makefile from .in).
I also tried to shove as much logic/rules into Makefile.in. Keeping
build-outputs.mk devoid of rules (thus, implying gen-make.py devoid of rules
in its output generation) manes that tweaking rules in Makefile.in is much
more approachable to people.

I think that is about it. Send problems to the dev@ list and/or feel free to
dig in and fix them yourself. My next steps are mostly cleanup. After that,
I'm going to toss out our use of libtool and rely on APR's libtool setup (no
need for us to replicate what APR already did).

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