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

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

[Motta, Frank]

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). 

It appears that there is no option to build a statically linked cygpath (I can't even build the cygwin base and utils from the download received from cygwin.com/setup.exe < == > http://mirror.mcs.anl.gov/cygwin/ (mirror))

Anyone got a replacement written in non-perl, non-python (aka script or compiled language like C)?


Thanks in advanced.

/f



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

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

[Christopher Faylor]

On Mon, Apr 05, 2010 at 02:50:07PM -0400, Motta, Frank wrote:
>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

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

[Motta, Frank]

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

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

[Christopher Faylor]

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

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

[Motta, Frank]

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

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

[Christopher Faylor]

On Thu, Apr 08, 2010 at 06:03:42PM -0400, Motta, Frank wrote:
>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.

Actually, it does: 

cgf wrote:
>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.

You could use the existence of cygpath as a way of determining if Cygwin
is installed.

>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.

Your original message *does* talk about building the cygwin version of
cygpath.  Which is GPLed itself.  Which, if you statically linked it
would be using bits of the Cygwin DLL.

>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).

If you were looking for something which has no reliance on Cygwin then
you shouldn't have said:

>On Mon, 5 Apr 2010 14:50:07 -0400, Motta, Frank wrote:
>>It appears that there is no option to build a statically linked cygpath
>>(I can't even build the cygwin base and utils from the download
>>received from cygwin.com/setup.exe...

You were pretty clearly trying to build something cygwin-related there
and that's what led me to respond.

>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.

I don't run this mailing list but it's hard to see how any of the above
has anything to do with crossgcc.

cgf

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

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

[Motta, Frank]

Thank you for your response Christopher.  I had already included attempts to find cygwin and Cygpath into my current and previous implementations.

Thanks for your clarification.  I can see that my wording of the original post could be better put so 
as to reflect what I wanted:
  - something that does what Cygpath does
  - It needs to compile and run native in the real OS (not Posix emulation)
  - It needs to be able to detect if it is in emulation and adjust
  - If would ideally gain advantages of the existence of the emulation and use it

This subject of has been an issue of cross development Gcc since before Cygnus' existence.

Specifically the management of path strings in make flows for operating systems that include Windows, Posix, and posix emulation as applied to Canadian cross build flows.  Can't get more "cross Gcc" than that.
 
/f



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