r18699 - gnucash/trunk - Ensure that GNC_DOT_PATH and other gnc_dotgnucash_dir() logic is

John Ralls jralls at ceridwen.us
Tue Mar 2 16:08:43 EST 2010


On Mar 2, 2010, at 12:45 PM, Christian Stimming wrote:

> Am Sonntag, 28. Februar 2010 schrieb John Ralls:
>> Yes, Phil pointed that out a couple of days ago on the bug, and I made that
>> change and tested it yesterday. I'll recommit with the fix today and close
>> the bug. (I reverted 18699 while I worked on it.)
> 
> Ok, thanks for fixing this now.
> 
> (For the record: A short remark in your revert commit saying you're working on 
> it would have helped here a bit - I couldn't guess what you were planning to 
> do here.)
> 
>> Both of these functions (xaccResolveFilePath and xaccResolveURI) trouble
>> me, though. For most cases, they're no-ops, because they just return their
>> argument unchanged or not meaningfully changed -- and they do very little
>> checking. I decided that it would be too off-topic to rewrite their
>> calling functions, so I wrote comments explaining what they do -- which
>> should discourage their use because it's generally nothing.
> 
> I don't understand them, too. The resolveFilePath had this lookup in the hard-
> coded directories, but as you have seen in my comments in the code, IMHO those 
> should have been removed long ago already.
> 
> If they don't do anything anyway, IMHO the functions can be removed 
> altogether. I mean, we are shipping an application, not a library, so all code 
> that uses our own functions is under our own control. And once you've verified 
> the functions are replaced in all `find . -name *.[hc]` files, the functions 
> can be removed.
> 

I looked at that, and as I noted on the bug -- and on my commit comment -- I decided that it's a more invasive change than I have time for right now. After all, I've already blown something up once messing around with it.

Regards,
John Ralls



More information about the gnucash-devel mailing list