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


> Date: Thu, 17 Aug 2006 09:59:30 -0400 (EDT)
> From: Igor Peshansky <pechtcha@cs.nyu.edu>
> cc: cygwin@cygwin.com
> 
> > FWIW, I don't think such a function is a good idea, and if it is
> > proposed on the Make mailing list, I will probably object to it.
> >
> > The reason is that adding such a function goes against portability of
> > Makefiles across different ports of Make,
> 
> ...which you would already have with cl commands and DOS paths...

It's possible that there's a misunderstanding here: I was talking
about portability across Windows ports of Make, not portability with
other platforms.  Sorry I didn't say that explicitly, I thought it was
clear.

> > and also adds a too-tight coupling between Make and the Cygwin file-name
> > handling (i.e., every change in how /cygdrive/ is handled in Cygwin will
> > require a corresponding change in Make).
> 
> Not true.  Cygwin has an API function for just this purpose, and all make
> has to do is call it.

Again, I failed to say explicitly that I was talking about adding the
function to all Windows ports of Make, not just to Cygwin.  This may
be an API call in Cygwin, but the other ports will have to emulate
that somehow, and not only as a no-op.  And that is where the coupling
could happen.

Anyway, I really don't think we should continue arguing about this
function, as I think an easier solution is on the table.  Unless, that
is, you think that other solution is worse, in which case please
explain why you think so.

> > While these disadvantages are not a catastrophe, I don't see a need to
> > punish Make by them when a better and easier solution is available (i.e.
> > use the existing HAVE_DOS_PATHS code, perhaps with some Cygwin-specific
> > changes).
> 
> FWIW, the Cygwin-specific changes to that code will have to essentially
> invoke the same functionality as above.

Perhaps so, but Cygwin-only code to call a Cygwin-only API is not a
problem, as you pointed out.

> > Of course, the best way of making sure no problems exist is to test the
> > patched version in the Cygwin environment.
> 
> Indeed.  We're waiting for a volunteer to post a patch approved by the
> upstream make maintainers for testing.  None so far.

The patch was posted to the make-w32 mailing list, and there's a
discussion going on there about it.  If someone would like to try it
out, you can find the details in that lists's archives.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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