[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] file-name.c and MinGW paths.
From: |
Ben Pfaff |
Subject: |
Re: [PATCH] file-name.c and MinGW paths. |
Date: |
Sat, 17 Feb 2007 10:11:39 -0800 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
"John McCabe-Dansted" <address@hidden> writes:
> MinGW allows both \ and / as separators in paths.
>
> What do you think of the approach of the attached patch to file-name.c?
It's a good place to start discussion. Thanks for writing it up.
Comments:
Could you use ISSLASH from pathname.h, available from gnulib,
instead of defining your own IS_SLASH?
Similarly, fn_is_absolute could just become a call to
pathname.h's IS_ABSOLUTE_PATH (or we could replace calls to
fn_is_absolute by uses of IS_ABSOLUTE_PATH; I'm ambivalent).
Also, fn_dir_name could be replaced by dir_name from gnulib's
dirname.c, which is better thought out than fn_dir_name and
already handles \-style directory delimiters.
> When it canonicalizes the path it converts all \'s to the posixish
> /'s. It should really also prefix all the paths with "A:" or, "C:" or
> whatever too.
I don't think the change to fn_get_identity is sufficient to fix
the problem, because as I read the implementation of
canonicalize_filename_mode, it doesn't properly handle \-style
directory separators anyhow. I think that we'll need to submit a
fix for that to the gnulib folks.
Is there no way to ask Windows "Are these two files the same
file"? It seems like a basic file system property that any
system would be able to answer.
> Another question: On windows, we don't know at compile time where the
> program will be installed.
> I suggest
> 1) that I write a relocate function that takes a path, strips the
> compile time prefix, adds a runtime prefix and returns the result.
> 2) I write a static wrapper around the function that returns a string
> that does not need to be freed.
> 3) I replace every occurance of
> PKGDATADIR "...."
> with
> PKGDATADIR_R ("....")
> where PKGDATADIR_R is a macro that, on MinGW, calls the static
> wrapper, and otherwise just evaluates to
> PKGDATADIR "...."
I think this is more complicated than necessary. I'd suggest
just creating a function that takes a file name as its argument
and returns it prefixed by the proper directory name. Based on
current usage, it would be fine for the string returned to be in
a static buffer.
The current uses are all very simple:
pixbuf = gdk_pixbuf_new_from_file (PKGDATADIR "/value-labels.png", 0);
pixbuf = gdk_pixbuf_new_from_file (PKGDATADIR "/weight-cases.png", 0);
pixbuf = gdk_pixbuf_new_from_file (PKGDATADIR "/goto-variable.png", 0);
pixbuf = gdk_pixbuf_new_from_file (PKGDATADIR "/insert-variable.png", 0);
pixbuf = gdk_pixbuf_new_from_file (PKGDATADIR "/insert-case.png", 0);
pixbuf = gdk_pixbuf_new_from_file (PKGDATADIR "/split-file.png", 0);
pixbuf = gdk_pixbuf_new_from_file (PKGDATADIR "/select-cases.png", 0);
xml = glade_xml_new (PKGDATADIR "/data-editor.glade", NULL, NULL);
glade_xml_new (PKGDATADIR "/syntax-editor.glade", NULL, NULL);
GladeXML *xml = glade_xml_new (PKGDATADIR "/psppire.glade", NULL, NULL);
gdk_pixbuf_new_from_file_at_size (PKGDATADIR "/pspplogo.png", 64, 64, 0);
PKGDATADIR "/psppicon.png", 0);
de->xml = glade_xml_new (PKGDATADIR "/data-editor.glade", NULL, NULL);
GladeXML *xml = glade_xml_new (PKGDATADIR "/psppire.glade",
GladeXML *xml = glade_xml_new (PKGDATADIR "/psppire.glade",
PKGDATADIR "/psppicon.png", 0);
--
Ben Pfaff
address@hidden
http://benpfaff.org
- [PATCH] file-name.c and MinGW paths., John McCabe-Dansted, 2007/02/17
- Re: [PATCH] file-name.c and MinGW paths.,
Ben Pfaff <=
- Re: [PATCH] file-name.c and MinGW paths., John McCabe-Dansted, 2007/02/17
- Re: [PATCH] file-name.c and MinGW paths., Ben Pfaff, 2007/02/17
- Re: [PATCH] file-name.c and MinGW paths., John McCabe-Dansted, 2007/02/17
- Re: [PATCH] file-name.c and MinGW paths., Ben Pfaff, 2007/02/17
- Re: [PATCH] file-name.c and MinGW paths., John McCabe-Dansted, 2007/02/17
- Re: [PATCH] file-name.c and MinGW paths., Ben Pfaff, 2007/02/18
- Re: [PATCH] file-name.c and MinGW paths., John McCabe-Dansted, 2007/02/18
- Re: [PATCH] file-name.c and MinGW paths., Ben Pfaff, 2007/02/18
- Re: [PATCH] file-name.c and MinGW paths., Ben Pfaff, 2007/02/19