Max Bowsher wrote:
[snip]
> 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.
Excellent point.
[snip]
> 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.
That's easy to do; consider it done.
[snip]
>> 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.
I'm embarrassed to admit that I didn't notice those "manpages = " lines. :)
[snip]
>>> 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.
There's one autoconf-supplied macro (AC_PROG_CC_C99) and a custom macro
to test for a broken snprintf (see
contrib/server-side/svnstsw/conf/stsw_func_snprintf_broken.m4).
However, AC_PROG_CC_C99 has a side effect that affects everything: it
alters the default CC variable, so instead of CC=gcc, you get CC="gcc
-std=gnu99". I don't expect this to cause any problems, but I'm not
really sure.
[snip]
> 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.
That would make my life easier. Do you know who the build system
experts are?
>> 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 see what you're referring to. The swig stuff also appears to have
some form of conditional compilation, but I'm not sure how it all works.
[snip]
> 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.
Maybe it is a little redundant, but I think that integrating the code
as-is into the build system is still worthwhile. I don't know what the
policy is for patch-release changes, but I can see svnstsw making it
into a future 1.5.x release once the build system integration happens.
I wouldn't expect any changes to svnserve to make it into a release
before 1.6.0 (because of backwards-compatibility issues). Thus,
build-system integration should allow us to put the functionality into
users' hands quickly.
Besides, build-system integration should be easier, so if something
comes up and I can't dedicate the time to integrate the svnstsw
functionality into svnserve, at least users will have something.
> 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.
Sounds good. I'd like to start coding, and I think that working in a
branch makes the most sense. I know that I have commit access to
contrib, but do I have the ability to create a branch? If so, are there
any naming conventions I should follow?
Thanks,
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-08 19:24:03 CEST