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