Re: [AD] Relative paths in the grabber

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> I'm now contemplating making it part of the API because:

Ok. Sounds good :)

> - it is non-trivial to implement, particularly in a platform-independent way,
> - it has the opposite functionality of replace_filename()+fix_filename_path()
> - I'd like the dat utility to support the relative paths functionality too 
> (luckily enough, one of the few unused letters for an option is 'r').

Surprisingly enough, you don't actually need explicidly handle relative paths
in the dat utility: if you specify paths as relative on the commandline, the
orig field already ends up with a relative path.
I haven't checked this in all instances, but it certainly works for
subdirectories of the current directory.

> I'm actually thinking about adding two new API functions:
> 
> char *calculate_absolute_filename(char *dest, const char *path, const char 
> *filename, int size);
> 
> char *calculate_relative_filename(char *dest, const char *path, const char 
> *filename, int size);
> 
> The first one would be basically replace_filename()+fix_filename_path() and 
> the second one would be your code.

I think these would fit with the other file functions, though I'd prefer get
or find instead of calculate, but that is really a personal preference.
Personally, I do feel the code is out of place in the grabber: it very much
feels like it should have been in the API but wasn't, so the grabber code
emulates it.

> I'm also thinking about renaming fix_filename_path() whose name is IMHO 
> misleading because:
> - it doesn't "fix" the filename like the other two fix_filename_*() functions 
> which really modify the filename and don't need a 'dest' parameter,
> - the name is too vague,
> so I'd propose canonicalize_filename() instead (which happens to be the 
> description of the function in src/file.c :-) and to deprecate 
> fix_filename_path().

Ok. I'm not sure about canonicalize. Is it a common word? I never
encounter it outside technical texts... other than that, it looks ok to me.

Evert




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/