If you are interested in downgrading to get dos driver letter specification
to work. (i.e. c:/foo/bar.) Please try the patched version of make 3.81.
http://www.cmake.org/files/cygwin/make.exe
Please report back to this list if you have any issues with this version
of make.
-Bill
At 02:21 PM 9
At 12:38 PM 9/8/2006, William A. Hoffman wrote:
>Thanks Bob. OK, so that is three people that have tested this patch.
>Please try the patch if you use make. DOS paths will be on by DEFAULT
>and there will be no way to turn it off. We want to make sure this does
>not break any
At 04:34 PM 9/5/2006, Bob Rossi wrote:
>On Tue, Sep 05, 2006 at 03:36:02PM -0400, William A. Hoffman wrote:
>> I have tested it and it works for me. William Sheehan
>> has also tested it. Can a few more folks give the patch a try?
>>
>> Here is the link to the mos
I have tested it and it works for me. William Sheehan
has also tested it. Can a few more folks give the patch a try?
Here is the link to the most recent patch:
http://www.mail-archive.com/make-w32@gnu.org/msg01157.html
Just get the source for make-3.81 and apply the above patch.
You can get
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 _wer
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 t
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
>&
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 tal
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
>di
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 a
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 everythi
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 lis
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 ch
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 t
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 u
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
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
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
>volun
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 untru
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
Probl
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
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 m
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?
>
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.
>
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 built against the cygwin libraries. MS cl can
no longer be used with c
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
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
Proble
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 thi
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 `f
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 thi
CMake 2.4.3-1 is now available on Cygwin mirrors.
There has been a new release of the official cmake (2.4.3-1).
This is a minor release from 2.4.2-1 to 2.4.3-1
Changes in CMake 2.4.3
* fix for 3557 - Under MSVC8 hardcoded TargetEnvironment for MIDL Compiler
* Fix for Xcode all projects to prev
CMake 2.4.2-1 is now available on Cygwin mirrors.
There has been a new release of the official cmake (2.4.2-1).
This is a major release from 2.2.3 to 2.4.2.
Changes in CMake 2.4.2
* Run symlink command from correct directory for executable versions
* Fix for universal binaries and Xcode depend
CMake 2.2.2-1 is now available on Cygwin mirrors.
There has been a new release of the official cmake (2.2.2-1).
This is a major release from 2.0.6 to 2.2.2.
Changes in CMake 2.2.2:
- Fix a memory overrun in EXEC_PROGRAM on windows
- Use GetFileAttributesEx for windows stat
- Remove -fpic flags fo
CMake 2.0.6-1 is now available on Cygwin mirrors.
There has been a new release of the official cmake (2.0.6-1).
Changes in CMake 2.0.6:
- Fix permission problem with FILE_WRITE.
- Fix process execution problem on win9X.
- Fix relative path function to work better.
- Fix for bug 1717, ctest sends
CMake 2.0.5-1 is now available on Cygwin mirrors.
There has been a new release of the official cmake (2.0.5-1).
This is a minor release from 2.0.2 to 2.0.5.
Changes in CMake 2.0.5:
- Fix problem on Cygwin installed with unix-file system and DOS new-lines in
CMakeCache.txt.
- Fix BUG 1244 TestCXX
There has been a new release of the official cmake (2.0.3-1).
This is a minor release from to 2.0.2 to 2.0.3.
Changes in CMake 2.0.3:
- Fixes for Find/Use SWIG, better error reporting and SWIG_FLAGS work.
- initial support for VCExpress visual studio 8
- LastMemCheck.log instead of LastMemCheck.x
There has been a new release of the official cmake (2.0.3-1).
This is a minor release from to 2.0.2 to 2.0.3.
Changes in CMake 2.0.3:
- Fixes for Find/Use SWIG, better error reporting and SWIG_FLAGS work.
- initial support for VCExpress visual studio 8
- LastMemCheck.log instead of LastMemCheck.x
CMake 2.0.2-1 is now available on Cygwin mirrors.
There has been a new release of the official cmake (2.0.2-1).
This is a major release from 1.8.3 to 2.0.2.
Changes in CMake 2.0.2:
- Remove automatic -I for source directory with makefile generator.
Problems caused by this can be fixed with thi
CMake 1.8.3-1 is now available on Cygwin mirrors.
There has been a new release of the official cmake (1.8.3).
This is a minor release from 1.8.2 to 1.8.3.
Changes from 1.8.2 to 1.8.3
Bug #407 - nslookup is being deprecated for Red Hat and Fedora
distributions
Bug #408 - Using -D without a type
CMake 1.8.2-1 is now available on Cygwin mirrors.
This is a minor release from 1.8.1 to 1.8.2.
Changes from 1.8.1 to 1.8.2:
There has been a new release of the official cmake (1.8.2).
This is a major release from 1.8.1 to 1.8.2.
Changes from 1.8.1 to 1.8.2
Bug #78 - static multithreaded libc o
CMake 1.8.1-1 is now available on Cygwin mirrors.
This is a major release from 1.6.7 to 1.8.1.
Changes from 1.8.0 to 1.8.1:
Added initial support for MinGW builds on Windows. Fixed a couple bugs in the
ctest program. Some fixes to the FindThreads and FindwxWindows modules. A fix
to the Custom Co
CMake 1.8.1-1 is now available on Cygwin mirrors.
This is a major release from 1.6.7 to 1.8.1.
Changes from 1.8.0 to 1.8.1:
Added initial support for MinGW builds on Windows. Fixed a couple bugs in the
ctest program. Some fixes to the FindThreads and FindwxWindows modules. A fix
to the Custom Co
Sorry about the post to the wrong list, thank you
for redirecting it.
I don't have the time or interest to track down
the problem. I would recommend that the 2.95 g++
be removed as an option from cygwin if it is not going
to be supported. It really is not very useful without
file io working, a
CMake 1.6.7-2 is now available on Cygwin mirrors.
This release is only to provide a cygwin 1.5.1 compiled version of cmake.
There are no changes to cmake source in this release.
See www.cmake.org for more information.
Bill Hoffman
Cygwin CMake maintainer
--
Unsubscribe info: http://cyg
CMake 1.6.7-1 is now available on Cygwin mirrors.
Changes from 1.6.6 to 1.6.7
Added support for Visual Studio 2003. Fixed a bug where LINK_FLAGS were
not getting passed to Visual Studio generators. Added a fix for MipsPro
7.3. Fix for C++ object file rule for nmake. A fix for search paths in
the
CMake 1.6.6-1 is now available on Cygwin mirrors.
Changes from 1.6.5 to 1.6.6
This patch include the following fixes: A fix to the FindGTK module, a
fix to the FIND_LIBRARY command to not mistake directories as libraries,
a fix in the tab order so that the MFC GUI buttons tab more
consistently, a
CMake 1.6.5-1 is now available on Cygwin mirrors.
Changes from 1.6.4 to 1.6.5
A fix to the TestForANSIForScope module so that it doesn't keep check each configure.
A fix to the Visual studio 7 generator to better support Visual studio 7.1. A fix for
makefiles that include out of build librarie
and tcl/tk.
-Bill
At 06:18 PM 2/5/2003 -0500, you wrote:
>On Wed, Feb 05, 2003 at 06:14:36PM -0500, William A. Hoffman wrote:
>>The tclsh84 does not understand cygwin style paths.
>>So, if you do tclsh /cygdrive/c/foo/bar.tcl it can not
>>find the file.
>&
The tclsh84 does not understand cygwin style paths.
So, if you do tclsh /cygdrive/c/foo/bar.tcl it can not
find the file.
This tcl does:
ftp://ftp.nanotech.wisc.edu/pub/khan/tcl/tcltk-8.3.4-cygwin/
I was wondering if Mumit Khan's patches for tcl could be incorporated
into the cygwin tclsh.
CMake 1.6.1-1 is now available on Cygwin mirrors.
We are pleased to announce the release of CMake version 1.6.1. Version 1.6 includes a
number of new features to help make project management easier. Version 1.6 include
TRY_COMPILE and TRY_RUN which can be used to test for features of the compil
OK, sorry for the confusion. I guess the setup comment about this only
working with gdb threw me off track. I upgraded to it, and a tcl script I had
that uses the tcl package http stopped working. I looked at the comment,
and figured since I was not gdb, there was no use complaining that it di
At 03:15 PM 1/31/2003 -0500, Christopher Faylor wrote:
>On Fri, Jan 31, 2003 at 02:34:29PM -0500, William A. Hoffman wrote:
>>>It's strange that every new release of tcl/tk breaks all past programs
>>>which rely on it.
>>
>>I would not say that this is stra
>It's strange that every new release of tcl/tk breaks all past programs
>which rely on it.
I would not say that this is strange. The tcl/tk that is in cygwin,
is only for insight/gdb, as the comment says. It is not a full distribution of
tcl/tk.
See the thread "tclsh83.exe should be cygtclsh
No, it is windows based.
-Bill
At 11:39 PM 1/29/2003 -0500, Charles Wilson wrote:
>William A. Hoffman wrote:
>
>>There is a complete tcl that can be found here:
>>ftp://ftp.nanotech.wisc.edu/pub/khan/tcl/tcltk-8.3.4-cygwin/
>>It would be great if this was used. I
>
>
>As far as the libraries for tcl, I dunno. That's a decision made by the tcl/tk folks
>over on the insight list. For the record, I have these in my /usr/lib dir:
>/usr/lib/libcygitcl32.a
>/usr/lib/libcygtcl83.a
>/usr/lib/libtcl8.3.a <<<--
>/usr/lib/libcygitclstub32.a
>/usr/lib/
If this was REALLY a full tclsh83.exe, I would have less of a problem with it.
However, this is some small sub-set of tclsh83 that replaces a FULL cygtclsh80.exe.
Perhaps this one should be called cyg-gdb-tclsh.If you have programs like cmake
or configure scripts that look for tclsh, they find
I realize it is a volunteer effort, and a good one, it
really makes windows much nicer to work with! I am not
demanding or expecting anything. I am only trying to
start a discussion that could lead to a possible solution.
I think that this could be done without "much" effort, or
the work of a
Well, if I am the only person with this opinion, then you are right.
I should stop complaining and burn a CD. However, I suspect that I am
not alone in wanting a more stable cygwin.It will be hard to prove my
case, as the folks that read this list and post to it, tend to
be more developer ori
The new View:Partial does help. I can now easily see what will get updated.
It would be nice if there was a button, that set all of them to keep.
Often times, I want to update only a single package, and that makes it
easier.
So, from the feedback I am getting, it really boils down to a "not en
I recently ran setup, and one of the new packages, I think gdb, caused
a tclsh83.exe to be installed into /usr/bin. It would be nice if
this were a full working tclsh83.exe, but it is not.However, it conflicted
with the working tclsh83.exe I already had in my path. Shouldn't the
name of thi
rrency.
As a whole cygwin is a very un-stable platform, because each of the packages that make
up cygwin, are in constant motion.
-Bill
At 01:55 PM 1/23/2003 -0800, Randall R Schulz wrote:
>William,
>
>At 13:39 2003-01-23, William A. Hoffman wrote:
>>Is there any way to contr
Is there any way to control the versions of programs you get from setup.exe?
The cygwin environment is different on almost every machine at our company.
It all depends on when you ran the setup program.I have two suggestions:
1. It would be nice, if there was a cygwin-stable that had a list of
CMake 1.4.7-1 is now available on Cygwin mirrors.
CMake is a cross-platform, open-source make system. CMake is used to control the
software compilation process using simple platform and compiler independent
configuration files. CMake generates native makefiles and workspaces that can be used
in
I saw some mention of this problem here:
http://www.cygwin.com/ml/cygwin/2002-07/msg00147.html
Is there a fix for this that works, or will be incorporated
into a future version of cygwin? I looked in the FAQ and
saw nothing about it. I have some nightly scripts that clean
some directories, and
Have a look at CMake www.cmake.org.
Basically, you create a simple input format that cmake then
turns into a makefile or a dsp file, or a .NET project file.
-Bill
At 03:18 PM 11/5/2002 -0700, J. Scott Edwards wrote:
>Hello,
>
>I appologize for the somewhat off topic post. I have been using Cyg
Depending on how complicated the makefile is, you may want
to try creating a CMakeLists.txt file from it and use cmake.
See www.cmake.org for more information. For the cygwin build,
cmake 1.4-6 is in the cygwin setup now, and for the windows build,
you can download CMakeSetup from www.cmake.org.
CMake 1.4.5-1 is now available on Cygwin mirrors.
CMake is a cross-platform, open-source make system. CMake is used to control the
software compilation process using simple platform and compiler independent
configuration files. CMake generates native makefiles and workspaces that can be used
in
Try this:
1. manually modify the /etc/passwd file
mkpasswd -du mywindowslogin >> /etc/passwd
Where mywindowslogin is the name of the account that you log into windows with.
2. set CYGWIN=nontsec
At 11:49 AM 10/24/2002 -0300, Kevin Woolie wrote:
>I have a full install (done via the setup ins
At 01:55 PM 10/22/2002 -0400, Christopher Faylor wrote:
>>
>>That is not what I saw. After doing 1, most cygwin things worked, however, there
>>were .exe files installed on my disk that were no longer executable. These were
>>things installed outside of cygwin.
>
>chmod a+x foo.exe
Yes, that
At 11:56 AM 10/22/2002 -0400, Christopher Faylor wrote:
>On Tue, Oct 22, 2002 at 11:49:16AM -0400, William A. Hoffman wrote:
>>My guess is this problem is related to the ntsec stuff as are many
>>recent posts. Someone correct me if I am wrong, but to get cygwin to
>>work prop
My guess is this problem is related to the ntsec stuff as are many recent posts.
Someone correct me if I am wrong, but to get cygwin to work properly these
days I had to do two things:
1. manually modify the /etc/passwd file
mkpasswd -du mywindowslogin >> /etc/passwd
Where mywindowslogin is the na
71 matches
Mail list logo
