Richard Hansen wrote:
> 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.
One of the tenets of programming that's been firmly entrenched in my
head, mainly through my association with the Subversion project is:
"Don't make an API public unless you really mean to, and are prepared to
support that API until version 2.0" - so, it's mainly the presence of a
library, installed headers, and manpages for C functions that struck me
as overengineering.
The header files containing only a single function each also seemed a
little odd to me.
It's not *bloat* per se that I'm complaining about - rather that there's
so much "project infrastructure", that it makes it hard to focus ones
attention on the functionality itself.
If the library, function documentation in manpages, and installed
headers were removed, and maybe all the *.h files combined into one, I
think my concerns are answered.
>> 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 does, at least when they relate to a program that it is installing.
Just search for "manpages" in build.conf. I dare say that may not have
been tested for contrib programs, but even if it doesn't work, it
shouldn't be too hard to generalize the code that deals with installing
main manpages.
>>>> 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.
It's just one (or a few) feature test macros, right? I'd be fine with that.
The following entry in autoconf 2.62's changelog caught my eye:
** AC_INIT no longer alters $@; regression introduced in 2.60.
So we might need to bump all the way up to 2.62, at least for releases.
If we can get away with requiring 2.60+ for general dev work, and
require 2.62 for official releases, that seems like a perfectly
acceptable move at this point in the Subversion 1.6 release cycle.
>> 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?
Not in an elegant fashion. It's a bit of a kludge, last time I looked.
> 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).
I'm not sure that *any* contrib programs are built in the Windows build,
You'd have to ask an expert in that area, but this may not be a problem
at all.
> 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?
To be avoided if there's nicer ways, and I'd count replicating the
kludge used for some of the RA/FS modules for svnstsw as nicer than
resorting to that.
>> 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.
I think integrating it is an excellent goal to work towards! :-)
Though, if it *is* going to merge into svnserve, that makes de-C99-ing
it something that will need to be done in the future, which makes
several of the points above a little redundant.
Still, dealing with the autoconf 2.6x transition in the Subversion 1.6.0
timeframe might be a good thing anyway, so it wouldn't hurt to add that
configure test even if it was on a temporary basis.
Max.
Received on 2008-05-07 10:03:44 CEST