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

["Motta, Frank" <Frank dot Motta at sonyericsson dot com>]

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.


Thanks

/f

>I have a new challenge that is related to cross building and the 'best'
>solution I have is cygpath.  However, we aren't shipping cygwin (not a
>subject for discussion), it will be MinGW.  So, the challenge that I
>have is a replacement for cygpath in all its value (or at least -m, -w,
>and -u options).

If you are not shipping cygwin why would you need cygpath?

It is not likely that you'll find a non-cygwin version of cygpath but if
you did manage to build a static version of cygpath you'd still be under
the GPL and you'd need to make the source code for cygpath and (likely)
cygwin1.dll available to whoever gets the binary.

cgf

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