On Tue, Jan 28, 2014 at 6:02 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein_at_gmail.com]
>> Sent: dinsdag 28 januari 2014 12:12
>> To: Bert Huijben
>> Cc: Branko Čibej; dev_at_subversion.apache.org
>> Subject: Re: 1.9 issues
>>
>> On Fri, Jan 24, 2014 at 3:17 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>> >...
>> > +1 on moving it to another header file, but I'm not sure about the
>> > requirement for yet another library... especially with a name that tells
> the
>> > user nothing... Every library is a 'tool'.
>>
>> Agreed.
>>
>> And how solid are these? Should they hang in include/private for one
>> release?
>>
>> I look at mtcc.h and the header is *broken*. The #define guard is
>> wrong, there is no extern "C" in there. It seems immature, and not
>> ready for immediate release.
>
> mtcc.h is a library internal header. The public api is currently in
> svn_client.h. That is what all the discussion is about.
I am well aware that client/mtcc.h is internal. And it is still
broken, which gives me an indication of its maturity/review. Thus, my
query/concern on keeping it private for now.
> So thanks for directly jumping to a conclusion based on a subset of the
> information; and without looking at the actual code.
I *did* look at the code. So, frankly... <censored>.
[ why did you feel the need to do that? ]
> [If you don't see an import of mtcc.h in mtcc-test.c and in svmucc.c,
> perhaps that should tell you that you don't look at the right header, or
> even the right api...]
I looked at the correct header. And now, you've gone and shifted all
this around to a public header, even after I expressed concern about
doing that. Why?
And your minor fixes to mtcc.h didn't deal with the extern issue.
-g
Received on 2014-01-28 14:20:14 CET