[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 4739 - in trunk/subversion: svnadmin svnlook clients clients/cmdline tests/libsvn_subr svnserve svnversion

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-02-05 03:51:21 CET

Karl Fogel wrote:

>brane@tigris.org writes:
>
>
>>* subversion/clients/init_cmdline.h: New file. Abstract all
>>command-line program initialization here.
>>
>>
>
>Okay -- I'll take the bait :-).
>
>Why are we putting a C function definition directly into a .h file and
>the including the .h file, instead of declaring the function in a
>header file (maybe a new header, maybe not) and then defining the
>function in a .c file as usual?
>
The reason is very simple -- a) I'm lazy, and b) I don't have a Unix box
handy to test on.
There's really no obvious place to define that function in at the
moment, and putting into a C file (and therefore compiling it
separately) would mean I'd have to tweak build.conf, which don't want to
do on Windows. I'd also have to tweak a load of .dsp's again, too.

Correctness first, as usual. I'll fix these issues presently, but even
deciding where to put such a function (it doesn't fit in any of our
libraries) takes some thought.

>I'm sure you must have had a reason for doing it this way, I'm just
>not figuring it out at the moment. (Say, what will happen to someone
>who tries to debug into this function?)
>
>
Huh? Why would debugging into this function be any different from
debugging into any other function? the debugger knows which source file
the function is in.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 5 03:52:09 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.