DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:content-type:mime-version:subject:from
	:in-reply-to:date:content-transfer-encoding:message-id
	:references:to; q=dns; s=default; b=CyqNpZvlAoHF4XcZxKJqQ0rWct6j
	cw6QjQ0D+QXdmZhWPvy867DbYizNSZJWAuNtRzeci0CAB9t5GMtm+eObX3qyvBUW
	nqNTCInw8l5ifoIuF+lNxGyETurzYuG41dcCiBtegfAbBpbhvQz8ix1fxWtxiqUR
	HrkXa/GkTq9+Als=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
Subject: Re: Migrating from MKS to Cygwin
From: Warren Young <wyml AT etr-usa DOT com>
In-Reply-To: <CAKtakaiJFAwkfTSsxhrNFbgktCqzXdTz2CbT1ikB23wyeHPSxw@mail.gmail.com>
Date: Wed, 8 Jul 2015 14:33:41 -0600
Message-Id: <4DC3AD21-E0D9-4A3A-9F52-AC2047B39D0A@etr-usa.com>
References: <CAKtakaiJFAwkfTSsxhrNFbgktCqzXdTz2CbT1ikB23wyeHPSxw AT mail DOT gmail DOT com>
To: The Cygwin Mailing List <cygwin AT cygwin DOT com>
Content-Transfer-Encoding: 8bit

On Jul 6, 2015, at 12:12 AM, Sarbjit singh <sarbjit1987 AT gmail DOT com> wrote:
> 
> My organization is evaluating Cygwin as a replacement for MKS.

Why replace something that is working with another thing that does pretty much the same thing?

I’m genuinely interested in the answer.  I’m pretty sure you have a good answer, but I must ask because I cannot guess which right answer applies in your case.

> There are few regression cases which uses 'pwd' command in the
> Makefile.

Why?  You should be using relative paths, for the most part.  You might root the project at the very start of the build process as Automake does with $(top_builddir), but after that, everything should be relative.  You should not be consulting absolute paths at all once the build is under way.

Windows copes with forward slashes just fine in paths, so that as long as you stay away from drive letters and UNC — as when you can when you restrict yourself to relative paths — the same paths work the same way on Cygwin, native Windows, Linux, etc.

I say all of this not merely to solve your immediate problem.  It is good general advice which solves a great many problems.  A system dependent on specific absolute paths breaks when moved to any dissimilar machine type.

The grey-beards here may remember problems when apps moved from one *ix type using e.g. /usr/foo for user home directories to SysV, the first version of Unix to finally standardize the home directory scheme as /home/foo.  There was a fair bit of software that did silly hard-coded things like /usr/$USER and consequently broke.

> Define a bash function in .bashrc file

Masking /bin/pwd and the Bash builtin pwd to make them behave in a non-POSIX manner is ill-conceived.  You will cause problems with other programs that expect them to behave as specified by POSIX.

> So, for Makefile, I have declared macro (makefile variable) and
> using the cygpath to return windows style paths. But, this would
> require changes in the Makefile i.e. to replace 'pwd' with ${PWD}.

I have less of a problem with this, since you can do whatever you like in your own Makefiles.

However, if it were up to me, I think I would just convert everything to POSIX form, so that the Unix and Windows cases work the same way.  Then you don’t need to play games with pwd.

Alternately, you can abstract away the difference at the build system layer, such as by switching to CMake.  It has its own testing system, CTest.

> - In order to minimize any changes in the Makefile, I also tried
> downloading the GNU coreutils for Windows port and replacing pwd.exe

I’m with Andrey: BAD IDEA.

> Since, the software installation can't be changed to address this
> problem

Why not?  Software is infinitely malleable.

Anyone claiming software can’t be changed is really saying, “I don’t *want* to change it for reason X.”  Maybe they have a good reason, maybe not.  But it is never the case that software *can’t* be changed.
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple