Web lists-archives.com

Re: [Mingw-msys] Re: Earnie's views on adding packages dependent on MSYS

On Wed, 2007-10-24 at 15:48 -0700, Suresh Govindachar wrote:
>   This thread brought up the topic of Filesystem Hierarchy 
>   http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
>   It is not just Windows that puts different programs in their
>   own directory -- Unix supports such a distribution under 
>   /opt.  And GoboLinux, a type of Linux, uses /Programs/
>   http://en.wikipedia.org/wiki/GoboLinux  And supposedly
>   Mac OS X uses /Library and /Applications

Sure.  I'm well aware of this convention on UNIX/Linux; no experience on
Mac-anything though.

The difference is that, on *nix, it's done within an organised, well
structured, clearly thought out hierarchy, unlike the disorganised
hotch-potch of Woe32.  In particular...

>   Part of the solution to the PATH prolifiration might be to
>   add symlinks to a bin directory in the PATH...

...this is standard practice.

> ... (however, doubt if this will work on Windows).

It will not.  Not with MSYS, or native applications in general; Woe32
does not support symlinks. [1]

>   And, I believe, applications that live under "/opt" type
>   locations know how to find what they need (such as configuration
>   files) based on paths relative to where their executable is.   

This is fairly easy to achieve in Woe32 too, provided the installation
hierarchy is well thought out.  Unfortunately, many porters of Open
Source packages overlook it.

However, this isn't really the issue.  If a package delivers tools,
which are predominantly intended to be used from a CLI, then the top
level binaries need to be accessible via the PATH.  It doesn't matter
whether the CLI is MSYS sh.exe, or cmd.exe.  It is simply much more
convenient if these are collected together, in a *few* standardised
locations; for MSYS that standardised location is either /usr/local,
or /mingw, for *native* applications, and /bin in the special case of
MSYS applications.  In either case, symlinking to those locations is not
an option, because Woe32 does not support symlinks.

Of course, for a GUI application, to be invoked from a desktop shortcut,
or a menu pick, different rules apply; you probably do not want these
cluttering up a directory normally used for CLI tools.  In this case,
perhaps $ProgramFiles/GUIappName [2] is an appropriate location; I don't
know how a tool, such as Cmake, would handle that distinction, though.


[1] Microsnot claim to have added this, in Vista.  From what I've read
about their implementation, it falls a long way short of a satisfactory
one, but admittedly, this is hearsay.

[2] Note the qualification based on GUIappName; IMO, this is imperative
for for this type of application, but would always be wrong for a CLI
application installed into a ${prefix} of /usr/local, or /mingw, where
the binary needs to go directly into ${prefix}/bin, even if necessary
support files go in ${prefix}/share/CLIappName/...

This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Mingw-msys mailing list