Re: func_convert_file_cygwin_to_w32 woes

[Charles Wilson]

On 1/7/2011 3:02 AM, Peter Rosin wrote:
> Den 2011-01-06 21:29 skrev Ralf Wildenhues:
>> * Peter Rosin wrote on Tue, Jan 04, 2011 at 05:44:58PM CET:
>>> Before I tie up the lose ends with this patch, I wonder if Ralf (or someone
>>> else) could tell me if I should also fix the other assignments of
>>> old_archive_cmds -- such as in the below snippet -- or is that completely
>>> irrelevant?
>>
>> I wouldn't change them without being sure that the changes are
>> necessary.
> 
> Well, they are necessary, but in cases which are, errhm, convoluted...
> 
> Such as: win32-hosted cross-tools (I mean native win32 here, not
> dependent on Cygwin or MSYS) for targeting irix (or whatever) and
> running them from Cygwin (or Wine) instead of MSYS.
> 
> I think I'll skip the extra changes, as someone doing the above needs
> a clue-bat anyway.

Err...that's not really uncommon.  Take the following fer-instance:
  1) You use a "vendor-provided" gcc for your fav embedded target
  1a) naturally, it's a MinGW->$foo cross compiler
  2) But, you like to work from a cygwin shell because it doesn't suck
as bad as dosbox, and provides tools that MSYS does not.

Now, MOST of the time, if you're using a vendor-provided compiler,
you're also going to use the vendor-provided IDE, so...the fact that you
like to "play" in the cygwin shell doesn't matter; the IDE doesn't use
"your" shell anyway.

But...if you step outside of the IDE...say, you just want to use the
normal configure/make process with --host=$foo
CC="/path/to/vendor/bin/gcc", since you don't really want to set up an
IDE project for $third-party-package-with-perfectly-good-autoconfigury,
do you really need a cluebat?  "Don't do that, download and install the
(limited in functionality compared to cygwin) MSYS environment, even
though you are not using "real" MinGW gcc, but a vendor toolchain?"
Or...a few more, already identified and well-understood changes in libtool?

--
Chuck