Too many warnings

[Branko Čibej-2]

This will sound like yet another rant: whatever happened to our policy
of keeping the code free of warnings? I'm referring specifically to the
large number of deprecation warnings that come from almost every
function in svn_path.h being deprecated.

I'm all for replacing those functions with the uri, dirent and relpath
variants. However, there's no excuse for deprecating everything, then
leaving the warnings in. Sure it's tedious and boring work to fix the
warnings ... and I wouldn't worry if there were only a few of them. But
the current situations is intolerable because it makes maintainer-mode
much less useful than it should be.

-- Brane

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2413348

[Stefan Sperling-7]

On Sun, Nov 01, 2009 at 12:07:58AM +0100, Branko Cibej wrote:

> This will sound like yet another rant: whatever happened to our policy
> of keeping the code free of warnings? I'm referring specifically to the
> large number of deprecation warnings that come from almost every
> function in svn_path.h being deprecated.
>
> I'm all for replacing those functions with the uri, dirent and relpath
> variants. However, there's no excuse for deprecating everything, then
> leaving the warnings in. Sure it's tedious and boring work to fix the
> warnings ... and I wouldn't worry if there were only a few of them. But
> the current situations is intolerable because it makes maintainer-mode
> much less useful than it should be.

So you're compiling trunk? Welcome back to development :)

Stefan

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2413397

[Branko Čibej-2]

Stefan Sperling wrote:

> On Sun, Nov 01, 2009 at 12:07:58AM +0100, Branko Cibej wrote:
>  
>> This will sound like yet another rant: whatever happened to our policy
>> of keeping the code free of warnings? I'm referring specifically to the
>> large number of deprecation warnings that come from almost every
>> function in svn_path.h being deprecated.
>>
>> I'm all for replacing those functions with the uri, dirent and relpath
>> variants. However, there's no excuse for deprecating everything, then
>> leaving the warnings in. Sure it's tedious and boring work to fix the
>> warnings ... and I wouldn't worry if there were only a few of them. But
>> the current situations is intolerable because it makes maintainer-mode
>> much less useful than it should be.
>>    
>
> So you're compiling trunk? Welcome back to development :)
>  

Heh. Nice one. :)

Interestingly ehough, with gcc-4.4 in maintaner-mode, I also get a bunch
of "statement will never be executed" warnings -- in places where that's
far from obvious. Apparently gcc must be doing some whole-object-file
optimization and cross-referencing.

-- Brane

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2413438

[Edmund Wong-2]

Branko Cibej wrote:
>
> Interestingly ehough, with gcc-4.4 in maintaner-mode, I also get a bunch
> of "statement will never be executed" warnings -- in places where that's
> far from obvious. Apparently gcc must be doing some whole-object-file
> optimization and cross-referencing.
>

I get that too with VS2008.  In fact, I've been getting that since I
started using VSE/VS on the trunk.

Edmund

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2413562

[Julian Foad]

On Sun, 2009-11-01 at 00:07 +0100, Branko Cibej wrote:

> This will sound like yet another rant: whatever happened to our policy
> of keeping the code free of warnings? I'm referring specifically to the
> large number of deprecation warnings that come from almost every
> function in svn_path.h being deprecated.
>
> I'm all for replacing those functions with the uri, dirent and relpath
> variants. However, there's no excuse for deprecating everything, then
> leaving the warnings in. Sure it's tedious and boring work to fix the
> warnings ... and I wouldn't worry if there were only a few of them. But
> the current situations is intolerable because it makes maintainer-mode
> much less useful than it should be.

Yes. I currently add -Wno-deprecated-declarations to CFLAGS and ignore
the issue. (Also -Wno-unreachable-code -Wno-format-nonliteral.)

But it would be good to sort it out. I have started analyzing/reviewing
the path functions.

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2413785

[Branko Čibej-2]

Julian Foad wrote:

> On Sun, 2009-11-01 at 00:07 +0100, Branko Cibej wrote:
>  
>> This will sound like yet another rant: whatever happened to our policy
>> of keeping the code free of warnings? I'm referring specifically to the
>> large number of deprecation warnings that come from almost every
>> function in svn_path.h being deprecated.
>>
>> I'm all for replacing those functions with the uri, dirent and relpath
>> variants. However, there's no excuse for deprecating everything, then
>> leaving the warnings in. Sure it's tedious and boring work to fix the
>> warnings ... and I wouldn't worry if there were only a few of them. But
>> the current situations is intolerable because it makes maintainer-mode
>> much less useful than it should be.
>>    
>
> Yes. I currently add -Wno-deprecated-declarations to CFLAGS and ignore
> the issue. (Also -Wno-unreachable-code -Wno-format-nonliteral.)
>
> But it would be good to sort it out. I have started analyzing/reviewing
> the path functions.
>  

So upon reflection, and looking at this a bit more, it seems to me that
the majority of the culprits is in path.c and target.c. In the former
case, the whole implementation file is apparently deprecated; so we
/could/ fix the issue with a bit of pragma trickery.

I'm not sure about target.c; at first glance it appears to be of the
same ilk as path.c, but I'm not sure, and I'm  a bit confused by how
little the functions from  target.c are  actually used.

Bright ideas welcomd; I'd be happy to help with ridding our code code of
the deprecation warnings.

-- Brane

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2413798

[Mark Phippard-3]

On Mon, Nov 2, 2009 at 9:18 AM, Branko Cibej <brane@...> wrote:
> Bright ideas welcomd; I'd be happy to help with ridding our code code of
> the deprecation warnings.

Didn't we do this to ourselves in on purpose?  I recall it was fairly
recently that someone decided to mark all of our older public API as
deprecated so that you would get these warnings.

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2413801

[Philip Martin-4]

Mark Phippard <markphip@...> writes:

> On Mon, Nov 2, 2009 at 9:18 AM, Branko Cibej <brane@...> wrote:
>> Bright ideas welcomd; I'd be happy to help with ridding our code code of
>> the deprecation warnings.
>
> Didn't we do this to ourselves in on purpose?  I recall it was fairly
> recently that someone decided to mark all of our older public API as
> deprecated so that you would get these warnings.

I configure with 'CFLAGS=-DSVN_DEPRECATED=' to remove them.  Do we
really want these warning to be enabled by default for third parties?
Our API guidelines mean that the deprecated functions will continue to
work at least as well as in the past.  Adding warnings to other
projects' builds is not very friendly.

--
Philip

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2414462

[Mark Phippard-3]

On Wed, Nov 4, 2009 at 12:05 PM, Philip Martin
<philip.martin@...> wrote:

> Mark Phippard <markphip@...> writes:
>
>> On Mon, Nov 2, 2009 at 9:18 AM, Branko Cibej <brane@...> wrote:
>>> Bright ideas welcomd; I'd be happy to help with ridding our code code of
>>> the deprecation warnings.
>>
>> Didn't we do this to ourselves in on purpose?  I recall it was fairly
>> recently that someone decided to mark all of our older public API as
>> deprecated so that you would get these warnings.
>
> I configure with 'CFLAGS=-DSVN_DEPRECATED=' to remove them.  Do we
> really want these warning to be enabled by default for third parties?
> Our API guidelines mean that the deprecated functions will continue to
> work at least as well as in the past.  Adding warnings to other
> projects' builds is not very friendly.

That was my point ... that we could undo all of this anytime we want.

I am not certain that all of the needless churn it has caused to make
all code use the newer API has been all that beneficial either.

As a communication mechanism to let someone know there is a newer API
it seems sort of useful.

BTW, congrats on the new job and welcome back!

--
Thanks

Mark Phippard
http://markphip.blogspot.com/

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2414465

[Branko Čibej-2]

Mark Phippard wrote:

> On Mon, Nov 2, 2009 at 9:18 AM, Branko Cibej <brane@...> wrote:
>  
>> Bright ideas welcomd; I'd be happy to help with ridding our code code of
>> the deprecation warnings.
>>    
>
> Didn't we do this to ourselves in on purpose?  I recall it was fairly
> recently that someone decided to mark all of our older public API as
> deprecated so that you would get these warnings.
>  

Yes, we did it on purpose, and I certainly support that. I'm griping
against the /uses/ of those deprecated functions not having been removed
(or, where they're still applicable, somehow marked to stop the compiler
from complaining). Four months ago.

-- Brane, picking at what to do with those warnings.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2414471