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: change in behavior of make from 3.80 to 3.81

On Wed, 16 Aug 2006, William A. Hoffman wrote:

> At 02:20 PM 8/16/2006, Igor Peshansky wrote:
> >On Wed, 16 Aug 2006, Corinna Vinschen wrote:
> >
> >Not only that, but the upstream maintainer actually suggested a couple of
> >avenues of investigation to make the patch smaller by using functionality
> >already built into the upstream make.  All that remains is for someone to
> >actually "do the work" (tm).
> Paul suggested adding the define
> HAVE_DOS_PATHS to the cygwin build of gnu make:
> Christopher countered with,
> "There is no advantage using cygwin if you want to use a Makefile which
> contains MS-DOS paths. Using MinGW makes perfect sense in that case.
> Despite having suggested this repeatedly, it seems some users are still
> not clear on this concept."

You've already mentioned a situation where MinGW does not do the right
thing (albeit on the wrong list).  So, you have something that would
justify a second look at this once you have something working in the
Cygwin version of make.

> Latter in the thread, Paul said this:
> "Regardless, I still wonder whether my idea of building make for a POSIX
> environment with Cygwin, but setting HAVE_DOS_PATHS explicitly, would
> work."
> Eli  then replied with this:
> "When HAVE_DOS_PATHS is defined, Make tries very hard to treat
> backslashes and forward slashes in file names in the same manner.  The
> only case I remember where we intentionally do NOT treat backslashes
> as forward slashes is in the $wildcard function (and in fact in any
> other situation that calls `glob' or `fnmatch').
> So, it sounds like from the thread Paul suggested
> setting HAVE_DOS_PATHS to true for the cygwin build,
> but Christopher does not think that MS-DOS paths have
> a place in a cygwin version of make.

Alternatively, you can try to implement a $(cygpath ...) function in make
and submit *that* to the upstream maintainers.  That way, the Cygwin make
will not have to invoke a separate process to convert the paths that it
(as a program linked to cygwin1.dll) already knows how to do.

Although, with make using spaces to separate everything, I still don't see
how this would work with absolute win32 paths in the general case.

> I would be willing to try compiling the upstream make
> with HAVE_DOS_PATHS to see if it works for me.  However,
> if I report back that it works great, then what?
> Christopher would you change the build for cygwin make
> to have this option?

Let's not second-guess this.  Why don't you first report that it works,
and then see if you can patch the build to always turn it on for Cygwin,
and submit this patch to the upstream make maintainers.  I'm sure that if
the upstream make package built OOTB on Cygwin with this functionality
turned on, the Cygwin make maintainer would not go out of his way to rip
it out just to be evil and hear the users groan...

OTOH, that may be exactly what he'd do when he is sufficiently annoyed by
this never-ending thread.
      |\      _,,,---,,_ |
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

Unsubscribe info:
Problem reports:

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