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
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 most recent patch:
http://www.mail
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 POSIX based
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
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
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
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
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
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
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
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 c:/msys
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
There has been a new release of the official cmake (2.4.3-1).
This is a minor release from to 2.4.2 to 2.4.3.
Here are the required files:
http://www.cmake.org/files/cygwin/setup.hint
http://www.cmake.org/files/cygwin/cmake-2.4.3-1.tar.bz2
There has been a new release of the official cmake (2.4.2-1).
This is a major release from to 2.2.3 to 2.4.2.
Here are the required files:
ftp://www.cmake.org/pub/cmake/cygwin/setup.hint
ftp://www.cmake.org/pub/cmake/cygwin/cmake-2.4.2-1.tar.bz2
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
At 01:13 PM 1/2/2006, Eric Blake wrote:
I've removed the versions 2.2.3-1 from cygwin.com. Please send a new
version ASAP, which doesn't contain Microsoft DLLs.
Sorry about that. It was not intentional or required by the cmake cygwin
build.
It was part of the install process on win32,
At 04:16 AM 12/23/2005, Corinna Vinschen wrote:
On Dec 5 12:25, William A. Hoffman wrote:
There has been a new release of the official cmake (2.2.3-1).
This is a minor release from to 2.2.2 to 2.2.3.
Here are the required files:
ftp://www.cmake.org/pub/cmake/cygwin/setup.hint
ftp
At 04:48 AM 12/6/2005, Corinna Vinschen wrote:
Done. It would be better to tell us for each new release, which old
one to remove ;-)
I will. We used to have it in the setup.hint file, but at some point I was told
to remove the cur and prev fields out of that file. If I put them back would
it
There has been a new release of the official cmake (2.2.3-1).
This is a minor release from to 2.2.2 to 2.2.3.
Here are the required files:
ftp://www.cmake.org/pub/cmake/cygwin/setup.hint
ftp://www.cmake.org/pub/cmake/cygwin/cmake-2.2.3-1.tar.bz2
On Dec 5 12:25, William A. Hoffman wrote:
ftp://www.cmake.org/pub/cmake/cygwin/setup.hint
ftp://www.cmake.org/pub/cmake/cygwin/cmake-2.2.3-1.tar.bz2
ftp://www.cmake.org/pub/cmake/cygwin/cmake-2.2.3-1-src.tar.bz2
Uploaded. I removed 2.0.6-1 and took the freedom to fix a typo in
setup.hint's
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
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
Uploaded.
Maybe somebody beat me to it, but I only saw a 1.8.3-1 in the cmake
directory, which I've deleted.
So, only the 2.0.6-1 and 2.2.2-1 versions remain.
cgf
Thanks that is perfect.
-Bill
There has been a new release of the official cmake (2.2.2-1).
This is a major release from to 2.0.6 to 2.2.2.
Here are the required files:
ftp://www.cmake.org/pub/cmake/cygwin/setup.hint
ftp://www.cmake.org/pub/cmake/cygwin/cmake-2.2.2-1.tar.bz2
I am the maintainer for cmake.
cmake William A. Hoffman
-Bill
At 09:08 AM 10/10/2005, Corinna Vinschen wrote:
On Sep 15 18:45, Corinna Vinschen wrote:
Mails in the last couple of weeks indicate that we have lost one or the
other maintainer without getting any notice from them. Since we
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
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
There has been a new release of the official cmake (2.0.6-1).
This is a minor release from to 2.0.5 to 2.0.6.
Here are the required files:
ftp://www.cmake.org/pub/cmake/cygwin/setup.hint
ftp://www.cmake.org/pub/cmake/cygwin/cmake-2.0.6-1.tar.bz2
At 12:23 PM 10/29/2004, Christopher Faylor wrote:
Ok. But 1.8.3 hasn't been offered via setup for a while now, AFAICT.
FWIW, your setup.hint would have caused there to be only one current version and no
previous version since once you specify one thing like (curr, prev, or test) you
have to
At 12:55 PM 11/4/2004, Christopher Faylor wrote:
Don't wait for this to be on mirrors before making your announcement.
Just send an announcement after it has been verified that the software
has been uploaded, or if you want to be mildly paranoid wait for it to
show up in the package list.
In any
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
There has been a new release of the official cmake (2.0.5-1).
This is a minor release from to 2.0.3 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 TestCXXAcceptsFlag.cmake should not run every time.
-
, Christopher Faylor wrote:
On Fri, Oct 29, 2004 at 10:41:44AM -0400, William A. Hoffman wrote:
There has been a new release of the official cmake (2.0.5-1).
This is a minor release from to 2.0.3 to 2.0.5.
Please don't include a ChangeLog in these messages. That is for
cygwin-announce. We're only
Ok. But 1.8.3 hasn't been offered via setup for a while now, AFAICT.
FWIW, your setup.hint would have caused there to be only one current version and no
previous version since once you specify one thing like (curr, prev, or test) you
have to provide them all.
cgf
I think there was some
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
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
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
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
There has been a new release of the official cmake (2.0.2).
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 this command:
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
, why don't you just
go ahead with 1.8.2-1 and when we do 1.8.3-1 we will make
the suggested changes.
Thanks.
At 07:50 PM 12/1/2003, Daniel Reed wrote:
On 2003-12-01T16:17-0500, William A. Hoffman wrote:
) ftp://www.cmake.org/pub/cmake/cygwin/setup.hint
) ftp://www.cmake.org/pub/cmake/cygwin/cmake
You can remove 1.8.1-1. Our idea is to always have
the previous version be the last major release. That is
the point where we reserve the right to break backwards
compatibility. So, someone might need 1.6.7, but they
should never need 1.8.1.
Thanks.
-Bill
The setup.hint lists 1.8.2-1 as
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 on MSVC 7.0
Bug #163 - TRY_COMPILE does not document OUTPUT_VARIABLE
Bug #168 - bootstrap uses C++ compiler to build .c files
altogether.
Igor
On Wed, 8 Oct 2003, William A. Hoffman wrote:
1.6.7-2 was the test release for cygwin 1.5.x. It was never
made the current release for cmake. I suppose we could go
either way. The only difference between 1.6.7-1 and 1.6.7-2 is
that one is built with cygwin 1.3.x
We just tried installing prev from setup, and it worked fine on
a cygwin 1.5.x machine. So, we are going to leave it the way it
is. You can remove 1.6.7-2 if you want.
I will go ahead and announce cmake 1.8.1-1 release in a few hours.
Thanks.
-Bill
It's your decision. Changing the
No, I have not. I will remove them when 1.8.2-1 comes out if that
is OK.
-Bill
At 12:38 PM 10/8/2003, Corinna Vinschen wrote:
On Wed, Oct 08, 2003 at 12:33:06PM -0400, Daniel Reed wrote:
On 2003-10-08T11:58-0400, William A. Hoffman wrote:
) We just tried installing prev from setup
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
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
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
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,
Hi,
The package I maintain CMake has a new official release 1.8.1.
I would like to make a new cygwin release. However, I am not
sure which cygwin I should build it with 1.5 or 1.3? CMake
builds with 1.5 no problem. Seems like until 1.5 is out of
test, I should stick to 1.3 for CMake since
Hello all,
I have uploaded cmake-1.6.7-2 package which is compiled against cygwin-1.5.1.
# CMake setup.hint file for cygwin setup.exe program
category: Devel
requires: libncurses6 libncurses7 cygwin
sdesc: A cross platform build manger
ldesc: CMake is a cross platform build manager. It
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:
I am creating a version of cmake for cygwin 1.5.1, and I have a question
about the setup.hint file.
The problem is:
curr: 1.6.7-1 - This the the current release that works with cygwin 1.3
prev: 1.4.7-1 - This is the previous cmake release also for cygwin 1.3
test: 1.6.7-2 - This is the
Hi,
I maintain the cmake package. I have tested it, and it
only requires a recompile to work with cygwin 1.5.1.
I am not sure how to proceed. Should I create binaries that require 1.5.1, and
make them the -test version of the package. Then when 1.5.1 is
officially released on 2003-08-23, I
What should package maintainers be doing about this?
I maintain the cmake package, and although I am subscribed
to this list, I rarely follow it closely. I post updates
to cmake, but that is about it. However, I just noticed
this thread. Should package maintainers being
building stuff for
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
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
There has been a new release of the official cmake (1.6.7).
This is a minor release from 1.6.6 to 1.6.7.
Changes from 1.6.5 to 1.6.6
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++
There has been a new release of the official cmake (1.6.6).
This is a minor release from 1.6.5 to 1.6.6.
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
I think you are confusing strstream with string.
With strstream if you call .str(), you must call
delete on the string, or call freeze(0). I have never
seen a problem with g++ and string .c_str() leaking memory.
-Bill
At 08:08 AM 3/21/2003, Pavel Tsekov wrote:
On 21 Mar 2003, Robert Collins
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
There has been a new release of the official cmake (1.6.5).
This is a minor release from 1.6.3 to 1.6.5.
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.
There has been a new release of the official cmake (1.6.3).
This is a minor release from 1.6.1 to 1.6.3. This
minor release fixes a bug in the EXPORT_LIBRARY_DEPENDENCIES command,
that will be required to build VTK 4.2 when it is released.
Also, error reporting for attempting to use NOTFOUND
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.
This tcl does:
ftp://ftp.nanotech.wisc.edu/pub
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
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
There has been a new release of the official cmake 1.6.1.
This is a major release from 1.4.7 to 1.6.1.
Version 1.6
includes a number of new features to help make project management
easier. Version 1.6 includes TRY_COMPILE and TRY_RUN which can be
used to test for features of the compiler or
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
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 strange. The tcl/tk that is in cygwin, is
only
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. It is a complete tcl that works under
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
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
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 control the versions of programs you get from
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
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
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
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
1 - 100 of 119 matches
Mail list logo
