On Mon, Feb 18, 2013 at 4:10 AM, Gabriela Gibson
<gabriela.gib...@gmail.com> wrote:
> I've written up some documentation about the build system, could I
> please have some feedback as to usefulness, style, shape etc?
Seems plenty useful for someone that isn't familiar with our build
system. The major comment I have is you're really mostly talking
about the Unix build system. You do mention some of the pieces of the
Windows setup but your explanation here really is about how the Unix
side works. I wouldn't worry too much about that since I'm not
inclined to send you in the dark hole that is the Windows build.
> Next, configure uses configure.ac, Makefile.in and build-outputs.mk
> to generate the Makefile.
I'd say this is a tad inaccurate. build-outputs.mk is not used to
generate the Makefile but is included at runtime. It is just another
makefile.
> Then, a section had to be added to build.conf:
>
> Index: build.conf
> ===================================================================
> --- build.conf (revision 1441170)
> +++ build.conf (working copy)
> @@ -62,7 +62,6 @@ private-built-includes =
> subversion/svn/svn-help.inc
> subversion/svn/svn-help.man
>
> -
> test-scripts =
> subversion/tests/cmdline/*_tests.py
>
Spurious whitespace change in this diff that creates an additional
block that's not needed.
> --- get-deps.sh (revision 1442814)
> +++ get-deps.sh (working copy)
> @@ -115,7 +115,11 @@ get_gtest() {
>
> unzip -q $TEMPDIR/$GTEST.zip
>
> - mv $GTEST gtest
> + mv $GTEST libgtest
> + echo "Gtest has been installed, please note:"
> + echo "autogen.sh will issue spurious header warnings."
> + echo "./configure --enable-gtest will issue repeated spurious warnings
> that"
> + echo "the option --enable-gtest is not recognsed."
Why is that? I haven't really been following the gtest work that much
but the spurious warnings issue seems like an issue in what you did
rather than something you should be adding documentation around. Also
typo of recognized/recognised (depending on preference US vs UK
spelling).
> build.conf Data file used by gen-make.py to generate
> build-outputs.mk
> build-outputs.mk see build.conf
I'd say that build-outputs.mk is a makefile generated based on
build.conf here and is included by Makefile.
> config.log log of the most recent comile to aid debugging
This should be log of most recent configure.
> find_python.sh check for the correct pytho version
typo of python
> computes the header dependencies (not sure what this means)
This computes the headers that a given target depends on beyond just
the sources listed in build.conf. So that if a header is changed then
the target will properly rebuild. You can easily see the difference
by running `./autogen.sh` saving the build-outputs.mk and then running
`./autogen.sh -s` and comparing the results.
> write the (above obtained?) sqlite headers
Nope this is where the transform_sql.py code gets run.
> offer debug output if --debug is defined
You skipped the primary function of gen-make.py which is caused by
this call "generator.write()". This produces whatever output is
required for the build setup being run. For Unix that's primarily
build-outputs.mk but also autogen-standalone.mk (which is used for
producing the generated SWIG code when autogen.sh is run in release
mode) and build/transform_libtool_scripts.sh (which is used to modify
the libtool scripts to preload local libraries). For Windows it'll
produce the project files.
> useage_exit & class Options:
> It also offers interactive useage service -- when is that used?
Typo should be usage. gen-make.py is invoked directly when doing a
Windows build since there is no ./autogen.sh or ./configure
equivalents. So the usage output exists to aid those users.
> [libsvn_fs_base]
implementation of the BDB backend.
> [libsvn_fs_fs]
implementation of the fsfs backend.
> [libsvn_ra_local] Accessing repositories via direct libsvn_fs
More accurately: Accessing repositories via direct libsvn_repos.
Primarily this is implemented on top of libsvn_repos but some things
end up using functions in libsvn_fs. So I wouldn't mention libsvn_fs.
> trang
> doxygen
> Check for trang.
> Check for doxygen
Duplicated lines.
There's the whole Perl bindings situation but I'm not sure documenting
that is really worth your time. The Perl bindings don't generate
their targets via the gen-make.py process but rather have a
Makefile.PL.in that generates a Makefile.PL (by way of configure) that
then generates a Makefile (this is a standard way of generating
Makefiles for Perl modules). There are other obscure pieces that I
probably haven't thought of.
