RE: statically linked replacement for cygpath - anyone got such a beast?

["Motta, Frank" <Frank.Motta@sonyericsson.com>]

Thanks for the insight Christopher.  That bit was the easiest and first part of the implementations that I have made and the one I am currently writing.  However, it offers no new information that can be used toward the point of the post in content nor subject.

The title specifically states statically linked and replacement for Cygpath.
It doesn't state the use or non-use of cygwin nor its DLL. Nor were any concerns of the licenses were even mentioned in my original post.  

My 2nd post only states that I am unconcerned about the license and further explains that I need something that has no reliance on cygwin and will work on DOS/Windows with or without cygwin as well as work on Posix (presumably without it).

Sadly it appears that I will have to write it from scratch again. Since I was unable to gleen anything from this list nor other resources on the internet then it will lack any GPL content.  Content that would be a justification and driving the need to publicize the result rather than moving on to other projects. This utility will again disappear into the ether like the previous 13 such versions.

If I find that I cannot gain a reliable implementation based on lack of a formalized solution then I will again be forced to tell the users install Cygwin on the same computer will void the support agreement.

/f

-----Original Message-----
From: Christopher Faylor [mailto:cgf-use-the-mailinglist-please@gnu.org] 
Sent: Thursday, April 08, 2010 2:16 PM
To: 'crossgcc@sourceware.org'; 'Christopher Faylor'; Motta, Frank
Subject: Re: statically linked replacement for cygpath - anyone got such a beast?

On Thu, Apr 08, 2010 at 01:45:05PM -0400, Motta, Frank wrote:
>Your concern about the license is admirable.  This is the 2nd of my
>posts that your leading statement was related to that subject.  I am
>unconcerned with the licensing and have shipped many products under the
>same.  Cygpath and cygwin are not getting shipped with this product.  I
>do want to be Cygwin compatible.  An alternative to supporting Cygwin
>is to say that Cygwin is non-compliant.  And stipulate that to have
>Cygwin installed voids the warranty and no support is provided.  I had
>begrudgingly taken this option for many of my products.  I don't like
>this alternative.
>
>The GPL 'make' utility is getting shipped and supported.  Not all
>'make's are alike and most fail to consider OS specific path naming.
>So the make flow is wanting a method to consider that an advanced user
>will use a posix like operating system or an emulation of it such as
>Cygwin and MKS.  A makefile which needs to consider OS variants would
>need to mangle paths for the command line needs.  A user may put within
>the makefile a path that is of the form of DOS or posix.  Since most
>tools don't consider that they can be run on many OS' they may need to
>be interpreted before it is passed as an argument.
>
>I need a program that can compile and run on windows and posix that can
>mangle paths for the flavor that is in operation in the make flow at
>this build time.  This program needs to be aware of the standard name
>mangling methods for the environments.  Should the environment be
>Cygwin then use of the built-in methods would improve compatibility.
>The added value of gaining such the ability for this functionality
>using existing code is that I can and must release it to public.  If I
>author it alone then I probably won't be able to release it into GPL
>and it goes into the ether only for me to write it a 15th time when I
>need it later.
>
>Also, if I can have the ability of determining if a statically linked
>(DOS) executable is run from within a cygwin bash shell (presumably via
>make).  Then I can locate the existing facilities and put them to use
>as well.

The subject and body of your message implies that you are looking for a
way to statically compile cygpath.  I was responding to tell you that
1) It isn't possible and 2) You'd have GPL concerns if you did that.

If you are just looking to figure out paths in a non-cygwin-make then I
think your best bet would be to test for the existence of a cygpath and
use that.

cgf

--
For unsubscribe information see http://sourceware.org/lists.html#faq