This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Migrating from MKS to Cygwin


On Jul 6, 2015, at 12:12 AM, Sarbjit singh <sarbjit1987@gmail.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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]