Max Bowsher wrote:
> Documentation is good, but I'd have to agree with Greg here about the
> ratio of project infrastructure to actual functionality here being
> ludicrous :-)
I don't understand this sentiment; there are only 3 pieces: the build
system, the code, and the documentation. I'm planning on trashing the
build system so that I can integrate it with Subversion's build system
(I had to have an independent build system so that we could use the
wrapper internally, so I stole some autoconf and automake code from one
of our other projects). That leaves code and documentation. Do you
feel that the C code is bloated?
> Is it really the intention that any of the C APIs be consumed outside
> the program? If so, is that intention realistically sensible?
Not really -- the decision to split the code into an executable and a
library was largely due to self-imposed design discipline with a hint of
self-education (I'm not a very experienced programmer). It would be
trivial to merge the two into a single monolithic executable, and I
don't have any objection to doing so.
> My instincts here would be to abandon building a "libsvnstsw", remove
> the installed header files and the section 3 manpages, and install just
> one executable binary and its section 8 manpage.
Sounds good to me. Does build.conf support installing man pages?
>>> It would be disappointing to see stuff added to the project's main
>>> autoconf grot in order to support a contrib program.
>>
>> I expect most developers feel this way, but I'm not sure so I thought
>> I'd ask. Most of the autoconf stuff currently in svnstsw can be left
>> out without major loss of functionality, with C99 being the exception.
>> It would make my life easier if I could test for C99; if the community
>> has substantial reservations about it, I'll have to move to plan B.
>
> I don't actually mind a moderate about of feature tests for a contrib
> program, provided they aren't ones which take a long time to run.
Would you consider adding tests for C99 support to be moderate? That
would require upgrading autoconf to at least 2.60.
> However, I hold the opinion that we build contrib programs from the main
> buildsystem because contrib programs are often tiny little programs
> which don't have a buildsystem of their own. That clearly isn't the case
> here, and IMO, if svnstsw is going to maintain the rest of its
> Project-with-a-capital-P nature, it might as well keep its own
> buildsystem too - indeed, to not do so would be bizarre.
The thing that makes it a Project-with-a-capital-P is the build system,
which I plan on removing. Once that's gone, there's not much left but a
handful of .c and .h files, some man pages, and a Doxyfile.
> Proper support for conditional build targets would be valuable for other
> reasons - making the conditional building of RA/FS libraries depending
> on the presence of BDB, Neon and Serf nicer - but would be a lot of work.
Should I take that statement as confirmation that Subversion's current
build system does not support conditional build targets?
If so, I just realized that there is another problem -- the portability
of svnstsw. svnstsw is written for POSIX systems, but Subversion should
build on Windows as well. There are no APR-equivalent functions for
some of the POSIX functions svnstsw is using (geteuid, getegid, possibly
others?). If Subversion's build system supported conditional
compilation, I could skip building svnstsw on non-POSIX platforms.
Since this is not the case, I'll have to #ifdef out the POSIX calls and
replace them with Windows-equivalents (if such functions exist).
Now that I think about it, a giant #ifdef surrounding all of the svnstsw
code might not be a bad way to work around the lack of conditional
compilation in the build system. Autoconf would need to #define
something if the system is POSIX and a C99 compiler was detected. The
#else condition in the big #ifdef would simply compile a main() function
that does nothing but print an error and return a non-zero value. What
do you think?
> I think what to do here largely depends on what the eventual intent for
> this code is - I think it should either work towards being integrated as
> a part of Subversion itself, be it either as a part of svnserve or as a
> separate executable, or it should spin off into a separate project
> entirely, with its own releases, repository, and all that.
I would like to see it integrated into svnserve, and that is my
long-term goal. There are backwards-compatibility and portability
issues to think through. For example, the --tunnel-user parameter will
need to be removed (or at least ignored when the effective UID/GID
doesn't match the real UID/GID). I don't have the time at the moment to
visit these issues, but I would like to in the not-too-distant future.
Thank you for your comments,
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-07 05:07:45 CEST