pspp-dev
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]