Dave Korn wrote:
Because I do not agree with your suggestion.
You don't agree that this is the cygwin list, not the mingw list?
Some people are trying to solve an issue with cygwin's build of make by
discussing possible solutions. Those who have nothing to contribute to
this effort would
On Sun, Aug 20, 2006 at 11:02:06PM -0700, Joachim Achtzehnter wrote:
Dave Korn wrote:
Because I do not agree with your suggestion.
You don't agree that this is the cygwin list, not the mingw list?
Some people are trying to solve an issue with cygwin's build of make by
discussing possible
There is now an upstream patch for make with Chris's blessing.
It can be found here:
http://article.gmane.org/gmane.comp.gnu.make.windows/2136
If anyone wants to try it, and make sure it creates a make
that does what you expect, now is the time. To use the
patch you will have to run autoconf
On Mon, Aug 21, 2006 at 12:25:58PM -0400, William A. Hoffman wrote:
There is now an upstream patch for make with Chris's blessing.
This does not exactly have my blessing. I have just tried to be as
diligent as possible in making sure that the change makes sense and that
the patch is as small
At 12:56 PM 8/21/2006, Christopher Faylor wrote:
On Mon, Aug 21, 2006 at 12:25:58PM -0400, William A. Hoffman wrote:
There is now an upstream patch for make with Chris's blessing.
This does not exactly have my blessing. I have just tried to be as
diligent as possible in making sure that the
At 11:12 AM 8/21/2006, Christopher Faylor wrote:
Your messages and those from the other couple of vocal people here have
done nothing to convince me that this decision was wrong for me. It has
done a lot to reinforce my belief that there are vocal people on this
mailing list who, even when
On 21 August 2006 18:28, William A. Hoffman wrote:
However, one thing that might have averted this thread would have been an
email
to the cygwin list, (prior to the release announcement) that described the
change you were going to make.
The hypothesis that someone who doesn't bother
At 01:35 PM 8/21/2006, Dave Korn wrote:
On 21 August 2006 18:28, William A. Hoffman wrote:
However, one thing that might have averted this thread would have been an
email
to the cygwin list, (prior to the release announcement) that described the
change you were going to make.
The
On 21 August 2006 18:58, William A. Hoffman wrote:
of, make is changing beware, it may have been noticed. Let's face make
is not a project you expect to see a bunch of change happening on,
especially a change that breaks existing makefiles.
Ah. We have the nub of it.
Make is not a
At 02:57 PM 8/21/2006, Dave Korn wrote:
On 21 August 2006 18:58, William A. Hoffman wrote:
of, make is changing beware, it may have been noticed. Let's face make
is not a project you expect to see a bunch of change happening on,
especially a change that breaks existing makefiles.
Ah. We
William A. Hoffman wrote:
At 02:57 PM 8/21/2006, Dave Korn wrote:
On 21 August 2006 18:58, William A. Hoffman wrote:
of, make is changing beware, it may have been noticed. Let's face make
is not a project you expect to see a bunch of change happening on,
especially a change that breaks
On Mon, 21 Aug 2006, Chris Taylor wrote:
Also, Dave commented earlier on your email saying an email should have
been sent to the list saying that these changes were going to happen.
It was. It's called the 'release notes'. They go to cygwin-announce, if
I recall correctly.. Maybe you should
At 04:24 PM 8/21/2006, Chris Taylor wrote:
Actually, Dave does have the nub of it. His assertions are accurate in your
case.
There have been many messages to this list, as well as the release note that
specifically mentioned that MSDOS paths were no longer supported.
Given that these _were
On Mon, Aug 21, 2006 at 04:40:03PM -0400, William A. Hoffman wrote:
My suggestion was, to send notice of the coming change before the
change was made, not after. That is all. IMO, the make issue is over.
I was just trying to make a suggestion to avoid flame wars like this in
the future. I don't
Date: Wed, 16 Aug 2006 09:34:36 -0400
From: William A. Hoffman [EMAIL PROTECTED]
Actually no, MinGW make is not working for what used to work with cygwin
make. It has a nasty habit of changing cl's command line arguments
like /GZ into c:/msys/1.0/GZ.
I think this is the MSYS Make, not
Date: Wed, 16 Aug 2006 15:52:59 -0400 (EDT)
From: Igor Peshansky [EMAIL PROTECTED]
cc: cygwin@cygwin.com
Alternatively, you can try to implement a $(cygpath ...) function in make
and submit *that* to the upstream maintainers.
FWIW, I don't think such a function is a good idea, and if it is
Eli Zaretskii wrote:
code, perhaps with some Cygwin-specific changes). Contrary to what
some people said in this thread, I don't see any problems that could
hamper the Cygwin build of Make if it supported drive letters, since
Windows doesn't allow colons anywhere else in file names anyway. Of
On Aug 17 05:05, Eli Zaretskii wrote:
Date: Wed, 16 Aug 2006 15:52:59 -0400 (EDT)
From: Igor Peshansky [EMAIL PROTECTED]
cc: cygwin@cygwin.com
Alternatively, you can try to implement a $(cygpath ...) function in make
and submit *that* to the upstream maintainers.
FWIW, I don't
Date: Thu, 17 Aug 2006 11:17:52 +0100
On 17 August 2006 10:47, Eli Zaretskii wrote:
Date: Thu, 17 Aug 2006 11:35:51 +0200
From: Corinna Vinschen [EMAIL PROTECTED]
Cc: Eli Zaretskii [EMAIL PROTECTED]
Eli, we have a tradition of snipping email addys on this list:
On Aug 17 05:46, Eli Zaretskii wrote:
Windows doesn't allow colons anywhere else in file names anyway.
That's not quite right. Colons are also used in file names when the
file name denotes an alternative named stream on NTFS file systems.
Right, I forgot about this obscure feature.
Date: Thu, 17 Aug 2006 14:09:23 +0200
On Aug 17 05:46, Eli Zaretskii wrote:
Windows doesn't allow colons anywhere else in file names anyway.
That's not quite right. Colons are also used in file names when the
file name denotes an alternative named stream on NTFS file systems.
At 04:31 AM 8/17/2006, Eli Zaretskii wrote:
Date: Wed, 16 Aug 2006 09:34:36 -0400
From: William A. Hoffman [EMAIL PROTECTED]
Actually no, MinGW make is not working for what used to work with cygwin
make. It has a nasty habit of changing cl's command line arguments
like /GZ into
On Thu, 17 Aug 2006, Igor Peshansky wrote:
On Thu, 17 Aug 2006, Eli Zaretskii wrote:
On Wed, 16 Aug 2006, Igor Peshansky wrote:
Alternatively, you can try to implement a $(cygpath ...) function in
make and submit *that* to the upstream maintainers.
FWIW, I don't think such a
On 17 August 2006 15:13, Igor Peshansky wrote:
On Thu, 17 Aug 2006, Igor Peshansky wrote:
On Thu, 17 Aug 2006, Eli Zaretskii wrote:
On Wed, 16 Aug 2006, Igor Peshansky wrote:
Alternatively, you can try to implement a $(cygpath ...) function in
make and submit *that* to the upstream
On Aug 17 09:59, Igor Peshansky wrote:
Actually, as Gareth mentioned, *Cygwin* allows colons in file names on
managed mounts. So, at the very least there'd be confusion of whether
c:\\TEMP is a directory TEMP in the root of the C: drive, or a file named
'c:\\TEMP' in the current directory on
On 17 August 2006 15:25, Corinna Vinschen wrote:
On Aug 17 09:59, Igor Peshansky wrote:
Actually, as Gareth mentioned, *Cygwin* allows colons in file names on
managed mounts. So, at the very least there'd be confusion of whether
c:\\TEMP is a directory TEMP in the root of the C: drive, or a
On Thu, 17 Aug 2006, Corinna Vinschen wrote:
On Aug 17 09:59, Igor Peshansky wrote:
Actually, as Gareth mentioned, *Cygwin* allows colons in file names on
managed mounts. So, at the very least there'd be confusion of whether
c:\\TEMP is a directory TEMP in the root of the C: drive, or a
On Aug 17 15:27, Dave Korn wrote:
On 17 August 2006 15:25, Corinna Vinschen wrote:
On Aug 17 09:59, Igor Peshansky wrote:
Actually, as Gareth mentioned, *Cygwin* allows colons in file names on
managed mounts. So, at the very least there'd be confusion of whether
c:\\TEMP is a directory
On Thu, Aug 17, 2006 at 06:48:18AM -0400, Eli Zaretskii wrote:
Date: Thu, 17 Aug 2006 11:17:52 +0100
On 17 August 2006 10:47, Eli Zaretskii wrote:
Date: Thu, 17 Aug 2006 11:35:51 +0200
From: Corinna Vinschen
Cc: Eli Zaretskii
Eli, we have a tradition of snipping email addys on
On Thu, Aug 17, 2006 at 03:16:31PM +0100, Dave Korn wrote:
On 17 August 2006 15:13, Igor Peshansky wrote:
On Thu, 17 Aug 2006, Igor Peshansky wrote:
On Thu, 17 Aug 2006, Eli Zaretskii wrote:
On Wed, 16 Aug 2006, Igor Peshansky wrote:
Alternatively, you can try to implement a $(cygpath
On Thu, Aug 17, 2006 at 09:43:30AM -0400, William A. Hoffman wrote:
At 04:31 AM 8/17/2006, Eli Zaretskii wrote:
Date: Wed, 16 Aug 2006 09:34:36 -0400
From: William A. Hoffman [EMAIL PROTECTED]
Actually no, MinGW make is not working for what used to work with cygwin
make. It has a nasty
On 17 August 2006 15:47, Christopher Faylor wrote:
On Thu, Aug 17, 2006 at 03:16:31PM +0100, Dave Korn wrote:
On 17 August 2006 15:13, Igor Peshansky wrote:
On Thu, 17 Aug 2006, Igor Peshansky wrote:
On Thu, 17 Aug 2006, Eli Zaretskii wrote:
On Wed, 16 Aug 2006, Igor Peshansky wrote:
At 10:49 AM 8/17/2006, Christopher Faylor wrote:
I've already mentioned once that this was the wrong mailing list for this.
Why do you seem to need everything repeated at you?
If you, or anyone, is having problems with MinGW's make it would behoove
you to discuss the problems in a mailing list
On Thu, Aug 17, 2006 at 11:00:48AM -0400, William A. Hoffman wrote:
At 10:49 AM 8/17/2006, Christopher Faylor wrote:
I've already mentioned once that this was the wrong mailing list for
this. Why do you seem to need everything repeated at you?
If you, or anyone, is having problems with MinGW's
On 17 August 2006 16:01, William A. Hoffman wrote:
At 10:49 AM 8/17/2006, Christopher Faylor wrote:
I've already mentioned once that this was the wrong mailing list for this.
Why do you seem to need everything repeated at you?
If you, or anyone, is having problems with MinGW's make it would
At 11:09 AM 8/17/2006, Dave Korn wrote:
On 17 August 2006 16:01, William A. Hoffman wrote:
At 10:49 AM 8/17/2006, Christopher Faylor wrote:
I've already mentioned once that this was the wrong mailing list for this.
Why do you seem to need everything repeated at you?
If you, or anyone, is
Date: Thu, 17 Aug 2006 09:59:30 -0400 (EDT)
From: Igor Peshansky [EMAIL PROTECTED]
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
--
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/
Date: Thu, 17 Aug 2006 10:12:30 -0400 (EDT)
From: Igor Peshansky [EMAIL PROTECTED]
Reply-To: cygwin@cygwin.com
cc: Eli Zaretskii [EMAIL PROTECTED]
Actually, sorry, I've misread the above. Doesn't GNU make already have a
plethora of functions not present in other makes?
I again apologize
From: Dave Korn [EMAIL PROTECTED]
Date: Thu, 17 Aug 2006 15:51:01 +0100
The thought of adding a cygwin-specific function to make and then making
sure that it exists as a noop in any other version of make seems a little
pushy to me.
Well, it could always just not exist, and people
Date: Thu, 17 Aug 2006 09:43:30 -0400
From: William A. Hoffman [EMAIL PROTECTED]
Cc: cygwin@cygwin.com
Here is a run with the MinGW make, from a cygwin shell:
$ ./make
[ 25%] Built target testc2
[ 50%] Built target testc1
Linking
C
executable
conly.exe
cl : Command line warning
Hi Corinna,
This has nothing to do with Cygwin's development process. Cygwin is a
POSIX environment after all. It's one of if's design targets to get
rid
of the DOS paths. People using Cygwin with DOS paths are using Cygwin
for something it was not designed for. This whole complaint
Olivier Langlois wrote:
Just for the records: My design goals for Cygwin
are that it works fine as a POSIX environment, not that it works fine
to run DOS tools. That's a nice side-effect at best.
It seems to me that Cygwin design goals have changed recently otherwise
if offering a POSIX
On Thu, Aug 17, 2006 at 02:26:34PM -0500, mwoehlke wrote:
Olivier Langlois wrote:
Just for the records: My design goals for Cygwin
are that it works fine as a POSIX environment, not that it works fine
to run DOS tools. That's a nice side-effect at best.
It seems to me that Cygwin design goals
At 05:02 PM 8/15/2006, Christopher Faylor wrote:
Just to clarify, the whole point of your interest is to avoid telling
people that they should use the MinGW version of make with makefiles
that are intended for use MS-DOS-like applications, right? If that
is the case, then it really seems like the
At 07:04 PM 8/15/2006, Christopher Faylor wrote:
No, it would work in this case, but I hesitate to name my price since
it will surely make me sound even more evil.
I'll bite, how much and how long would it buy me?
-Bill
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
At 05:27 AM 8/16/2006, Dave Korn wrote:
On 15 August 2006 20:56, William A. Hoffman wrote:
So, in this case, for
those that want the old way of things to work, there is no amount of work
they can do to make that happen.
Blatantly untrue. Here is a VERY simple recipe you can follow to
On Wed, Aug 16, 2006 at 10:27:01AM +0100, Dave Korn wrote:
1) Use setup.exe to install the source package to 3.80-1.
2) Compile and install it with a --prefix setting that places it earlier in
your $PATH (e.g. /usr/local instead of /usr).
3) (Optional) Use setup.exe to uninstall the cygwin make
On Wed, Aug 16, 2006 at 09:34:36AM -0400, William A. Hoffman wrote:
At 05:02 PM 8/15/2006, Christopher Faylor wrote:
Just to clarify, the whole point of your interest is to avoid telling
people that they should use the MinGW version of make with makefiles
that are intended for use MS-DOS-like
William A. Hoffman wrote on Wednesday, August 16, 2006 4:14 PM:
[snip]
So, there seem to be three options on the table:
- pay redhat to put the patch back
- maintain your own version of make, that is separate from cygwin.
- have the patch made part of the upstream gnu make
The forth
On Wed, Aug 16, 2006 at 10:14:20AM -0400, William A. Hoffman wrote:
At 05:27 AM 8/16/2006, Dave Korn wrote:
1) Use setup.exe to install the source package to 3.80-1.
2) Compile and install it with a --prefix setting that places it earlier in
your $PATH (e.g. /usr/local instead of /usr).
3)
On Aug 16 10:14, William A. Hoffman wrote:
So, there seem to be three options on the table:
- pay redhat to put the patch back
The Cygwin net distro is not a Red Hat thingy. It's an entirely
volunteer driven project. If you want a package being fixed for you,
it's up to the current
Respectfully,
Doesn't this just push the maintenance effort elsewhere? Suppose the
upstream maintainer has no fun either?
There are obviously a lot of users in the cygwin community using this
feature of cygwin make and would like to see it continue to be
supported.
Why can't a new maintainer
On Wed, Aug 16, 2006 at 11:03:47AM -0400, Brian Hassink wrote:
Respectfully,
Doesn't this just push the maintenance effort elsewhere? Suppose the
upstream maintainer has no fun either?
Read the mailing list archives.
There are obviously a lot of users in the cygwin community using this
feature
At 10:41 AM 8/16/2006, Corinna Vinschen wrote:
On Aug 16 10:14, William A. Hoffman wrote:
So, there seem to be three options on the table:
- pay redhat to put the patch back
The Cygwin net distro is not a Red Hat thingy. It's an entirely
volunteer driven project. If you want a package being
On Wed, Aug 16, 2006 at 11:35:50AM -0400, William A. Hoffman wrote:
At 10:41 AM 8/16/2006, Corinna Vinschen wrote:
On Aug 16 10:14, William A. Hoffman wrote:
cgf wrote:
...or offer money. That carries more weight than complaining. :-)
However that doesn't work in all cases. This I am reasonably
On Aug 16 11:35, William A. Hoffman wrote:
I assumed since cgf worked for Red hat, that his offer to take money
would go to Red Hat. My mistake.
Surprise, cgf doesn't work for Red Hat. Only I do.
I'm honestly confused. Why would it better to have another Cygwin
distro maintainer for a
- have the patch made part of the upstream gnu make
That's the best solution of all. The whole problem is that the
current Cygwin make maintainer has no fun to work on this issue.
Everybody else is free to put a bit of time and sweat into this and get
this for free firther on. I'm still
At 11:49 AM 8/16/2006, Christopher Faylor wrote:
How do you know it is a small patch? Have you actually looked at the
code? I find that unlikely.
I had not looked at the source, but figured it most likely was not that big
a change. I now have looked at the sources, and minus the makefile
On Wed, Aug 16, 2006 at 01:44:06PM -0400, Bob Rossi wrote:
- have the patch made part of the upstream gnu make
That's the best solution of all. The whole problem is that the
current Cygwin make maintainer has no fun to work on this issue.
Everybody else is free to put a bit of time and sweat
I think your solution is well stated. Does anyone know who was
maintaining the old patch to make, so that a discussion with that
person could be made more substantial on a technical level?
And ^^^this^^^ is a perfect example of why this discussion is so
frustrating.
Does someone
On Wed, Aug 16, 2006 at 01:52:23PM -0400, William A. Hoffman wrote:
At 11:49 AM 8/16/2006, Christopher Faylor wrote:
How do you know it is a small patch? Have you actually looked at the
code? I find that unlikely.
I had not looked at the source, but figured it most likely was not that
On Wed, 16 Aug 2006, Corinna Vinschen wrote:
On Aug 16 11:35, William A. Hoffman wrote:
I'm honestly confused. Why would it better to have another Cygwin
distro maintainer for a package instead of getting the patches
included upstream? This makes no sense at all. If my head wouldn't
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
On Wed, Aug 16, 2006 at 03:08:54PM -0400, 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
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
On Wed, Aug 16, 2006 at 03:52:59PM -0400, Igor Peshansky wrote:
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
On Aug 16 14:17, Bob Rossi wrote:
I think your solution is well stated. Does anyone know who was
maintaining the old patch to make, so that a discussion with that
person could be made more substantial on a technical level?
And ^^^this^^^ is a perfect example of why this discussion is
At 03:47 PM 8/16/2006, Christopher Faylor wrote:
The suggestion was that a patch be submitted upstream. I agree with the
suggestion and have amplified on it a little in another message.
This suggestion does not require further input from me. If I was interested
in being involved in coming up
Igor Peshansky wrote:
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
On 16-Aug-2006, William A. Hoffman wrote:
| Without your support, I don't think the patch would get far.
| I am thinking the patch would be something like:
|
| #ifdef CYGWIN
| #define HAVE_DOS_PATHS
| #endif
Have you tried this (uh, what file are you patching anyway)? Does it
work? Does it
On Wed, 16 Aug 2006, mwoehlke wrote:
Igor Peshansky wrote:
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
Igor Peshansky wrote:
On Wed, 16 Aug 2006, mwoehlke wrote:
Igor Peshansky wrote:
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
At 04:51 PM 8/16/2006, John W. Eaton wrote:
Have you tried this (uh, what file are you patching anyway)? Does it
work? Does it cause problems for valid Makefiles that assume POSIX
filenames?
Suggesting changes to GNU Make on this list is not going to cause
things to happen. If you want to see
On Wed, Aug 16, 2006 at 09:41:23PM -0400, William A. Hoffman wrote:
The original make-3.81 does not compile with HAVE_DOS_PATHS on cygwin,
and a patch on the make-w32 list crashed, I found the cause of the crash
and with my patch all tests for make check pass. Also, windows paths
work in
William A. Hoffman wrote on Tuesday, August 15, 2006 4:12 AM:
OK, so to summarize.
- there is no options or special syntax that will allow the
make 3.81 to recognize drive letters in such a way that native
windows tools can use them. /c/ and /cygdrive/c/ will only work
with applications
At 10:40 PM 8/14/2006, Igor Peshansky wrote:
MS cl can no longer be used with cygwin make as of 3.81.
Incorrect. See below.
Perhaps something along the lines of /c/ that would be translated by
gmake itself into c:, so that no special parsing would be required for
the makefiles.
Yuck!
At 11:17 PM 8/14/2006, Christopher Faylor wrote:
On Mon, Aug 14, 2006 at 10:40:34PM -0400, Igor Peshansky wrote:
On Mon, 14 Aug 2006, William A. Hoffman wrote:
Sounds like it is time to join the gmake mailing list. Has anyone on
this list tried that yet?
If you are asking whether anyone has
On Tue, 15 Aug 2006, William A. Hoffman wrote:
At 10:40 PM 8/14/2006, Igor Peshansky wrote:
MS cl can no longer be used with cygwin make as of 3.81.
Incorrect. See below.
Perhaps something along the lines of /c/ that would be translated by
gmake itself into c:, so that no special
From: John W. Eaton [EMAIL PROTECTED]
Date: Mon, 14 Aug 2006 18:50:46 -0400
Cc: cygwin@cygwin.com
This whole problem could be solved if the people who are complaining
about the Cygwin version of GNU Make directed their efforts toward
getting a patch accepted in the GNU Make sources that
William A. Hoffman wrote:
At 10:40 PM 8/14/2006, Igor Peshansky wrote:
- The other option is to use mingw-make, and only use cygwin make
for cygwin linked programs only.
Incorrect. If you use Cygwin make, it's very easy to invoke Windows
programs by converting their arguments with cygpath -w
John W. Eaton wrote:
I mean, isn't free software all about getting something for nothing,
then complaining about it and expecting others to do yet more gratis
work for you?
Free software is about collaboration of a community consisting of
developers, users, documentation authors, testers,
Hi,
This is just to let you know that I totally agree with what Joachim has
written. I too am annoyed and affected by the recent changes made in
cygwin (drop of MS-DOS path support in make and changes in executable
file name evaluation in the cygwin DLL). He has expressed better than I
could have
At 02:32 PM 8/15/2006, Dave Korn wrote:
On 15 August 2006 18:07, Joachim Achtzehnter wrote:
is the exact opposite of
what free software is supposed to be about. A healthy free software project
depends on and welcomes input from the community. The attitude exhibited by
some on this mailing
On Tue, Aug 15, 2006 at 08:55:04AM -0400, William A. Hoffman wrote:
At 11:17 PM 8/14/2006, Christopher Faylor wrote:
Or, the short answer to the question is: Yes. The GNU make mailing list
has already been contacted and the GNU make maintainer has already made
a suggestion.
I have searched the
On 15-Aug-2006, Joachim Achtzehnter wrote:
| Free software is about collaboration of a community consisting of
| developers, users, documentation authors, testers, translators, etc. to a
| common good, namely the production of good software that serves the needs
| of that community.
In my view,
John W. Eaton wrote:
On 15-Aug-2006, Joachim Achtzehnter wrote:
Clearly, developers make a huge contribution,
nobody is denying this, but to suggest that *only* developers contribute
and everybody else should therefore just shut up
I never said everyone else should just shut up. My point was
On Tue, Aug 15, 2006 at 05:53:17PM -0500, mwoehlke wrote:
John W. Eaton wrote:
On 15-Aug-2006, Joachim Achtzehnter wrote:
Clearly, developers make a huge contribution,
nobody is denying this, but to suggest that *only* developers contribute
and everybody else should therefore just shut up
I never
3.80 does this:
make -f test.make
make: *** No rule to make target `C:/foo', needed by `foo'. Stop.
3.81 does this:
make -f test.make
test.make:1: *** target pattern contains no `%'. Stop.
test.make contains:
foo: C:/foo
So, in 3.80 windows style driver letter : path worked with make.
In
On Mon, Aug 14, 2006 at 02:28:56PM -0400, Bill Hoffman wrote:
3.80 does this:
make -f test.make
make: *** No rule to make target `C:/foo', needed by `foo'. Stop.
3.81 does this:
make -f test.make
test.make:1: *** target pattern contains no `%'. Stop.
test.make contains:
foo:
On Mon, Aug 14, 2006 at 02:41:36PM -0400, Bob Rossi wrote:
On Mon, Aug 14, 2006 at 02:28:56PM -0400, Bill Hoffman wrote:
3.80 does this:
make -f test.make
make: *** No rule to make target `C:/foo', needed by `foo'. Stop.
3.81 does this:
make -f test.make
test.make:1: *** target pattern
At 02:36 PM 8/14/2006, Dave Korn wrote:
On 14 August 2006 19:29, Bill Hoffman wrote:
Search the archives, and read the release announcement for the new make
version.
Every single day for the past month, we have had at least seventy-four[*]
identical duplicate redundant reports of this from
So, I searched a bit more, and found some postings that seemed to say that
escaping the : might work:
http://www.mail-archive.com/cygwin@cygwin.com/msg70907.html
However, that fails on both version 3.80 and 3.81:
$ make -f mk
make: *** No rule to make target `c\:/hoffman/foo/foo.c', needed by
On Mon, Aug 14, 2006 at 03:07:41PM -0400, William A. Hoffman wrote:
At 02:36 PM 8/14/2006, Dave Korn wrote:
On 14 August 2006 19:29, Bill Hoffman wrote:
Search the archives, and read the release announcement for the new make
version.
Every single day for the past month, we have had at least
For that matter, why isn't cmake generating relative pathnames instead
of absolute ones?
Beverly
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Christopher Faylor
Sent: Monday, August 14, 2006 4:17 PM
To: cygwin@cygwin.com
Subject: Re: change in
At 04:16 PM 8/14/2006, Christopher Faylor wrote:
I'm not 100% clear on what you're saying but if cmake distributed with
Cygwin is producing makefiles with MS-DOS SYNTAX then, actually it
should either be fixed to not do that or it should be pulled from the
distribution. I wasn't aware of this
At 04:24 PM 8/14/2006, Brown, Beverly wrote:
For that matter, why isn't cmake generating relative pathnames instead
of absolute ones?
For the most part it does, but there are some cases where it uses full
paths.
-Bill
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem
-Original Message-
$ make -f mk
make: *** No rule to make target `c\:/hoffman/foo/foo.c',
needed by `foo'. Stop
[EMAIL PROTECTED] ~/foo
$ ../make381/usr/bin/make.exe -f mk
make: *** No rule to make target `c\:/hoffman/foo/foo.c',
needed by `foo'. Stop
So, I am
On Mon, Aug 14, 2006 at 05:15:50PM -0400, Harig, Mark wrote:
-Original Message-
$ make -f mk
make: *** No rule to make target `c\:/hoffman/foo/foo.c',
needed by `foo'. Stop
[EMAIL PROTECTED] ~/foo
$ ../make381/usr/bin/make.exe -f mk
make: *** No rule to make target
At 05:31 PM 8/14/2006, Christopher Faylor wrote:
On Mon, Aug 14, 2006 at 05:15:50PM -0400, Harig, Mark wrote:
That isn't going to help with programs like cl which take MS-DOS command
line arguments, nor, is my oft-suggested but consistently ignored perl
script for converting a makefile from
1 - 100 of 110 matches
Mail list logo
