Re: downgrading make version

[William A. Hoffman]

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/10/2006, Amit Partani wrote:
>Hi,
>The make version installed in my cygwin is GNU make 3.81. Can someone tell me 
>how can I downgrade it to GNU make 3.80.
>
>Thanks,
>Amit
>
>
>
>--
>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/


--
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/

Re: Need Volunteers to test patch for gnu make

[William A. Hoffman]

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 makefiles.   

Since folks seem to be adverse to building from source, I have made the patched
make.exe available here:

http://www.cmake.org/files/cygwin/make.exe

Please try it, and report any problems on this list.

Thanks.

-Bill


--
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/

Re: Need Volunteers to test patch for gnu make

[William A. Hoffman]

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-archive.com/make-w32@gnu.org/msg01157.html
>> 
>> Just get the source for make-3.81 and apply the above patch.
>> You can get make from here: http://ftp.gnu.org/pub/gnu/make/
>> You will need to rerun autoconf/automake after the patch,
>> as the patch does not include the configure script.  Once
>> you build it, run make check to verify that the build is working.
>> Also, please try with any makefiles that you have and need to work
>> with windows paths. 
>
>This works for me. Thanks for the great work!
>Our system used to build with 3.80 from cygwin, it did not build with 3.81
>from cygwin, and now works with native build of make with the patch
>above on cygwin.

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 makefiles.   

-Bill




--
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/

Need Volunteers to test patch for gnu make

[William A. Hoffman]

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 make from here: http://ftp.gnu.org/pub/gnu/make/
You will need to rerun autoconf/automake after the patch,
as the patch does not include the configure script.  Once
you build it, run make check to verify that the build is working.
Also, please try with any makefiles that you have and need to work
with windows paths. 

Thanks.

-Bill


--
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/

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 not_ a part of official Make, but were instead 
>implemented by patches maintained by cgf, it's not unreasonable for the 
>maintainer to say enough is enough.
>Even more so given that cygwin is for giving you POSIX functions in windows.. 
>DOS paths have no relevance in a POSIX environment. The underlying OS isn't 
>relevant.

Do you know what is in the official Make?  The support for windows paths is 
already
in official Make, and has been for some time.  It was just not turned on for 
the cygwin 
build of make.   In the future it will be.

>If a working patch makes it into upstream, or is available for inclusion and 
>is clean, w/o affecting anything else, then I have no doubt that cgf will 
>consider including it in the next release, but if people had actually read the 
>original release notes, then this would not be an issue.

The release notes said the feature was dropped, and to use mingw make.
http://www.cygwin.com/ml/cygwin-announce/2006-07/msg8.html
It did not say if you get the upstream make to add support then the
feature can be maintained.   It did say if you have questions or
comments send them to the cygwin mailing list.   


>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 subscribe to this one?

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 think it is enjoyable
or productive for anyone involved.

-Bill


--
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/

RE: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 have the nub of it.

No I don't think you have the nub of it yet. I still think that a simple
post about a major change being made to make may have helped avoid much of the
pain of this thread.   You have to admit that dropping a whole class of paths
from support is more likely to cause trouble than any of the other minor syntax
changes to gnu make that are not backwards compatible.  I would not expect:

foo: foo.c
   gcc foo.c -o foo

To stop working any time soon in make no matter what changes are made.
The basic format of makefiles is pretty much fixed, and has been around for
20 years or so.  See http://en.wikipedia.org/wiki/Make:

"POSIX includes standardization of the basic features and operation of the make 
utility "
That is the part of make I am talking about when I say the features of make are 
not
changing.

I and others (not exactly sure how many but more than one) did not expect:

foo: c:/foo.c
   cl c:/foo.c 

to stop working the make that came with cygwin.  And in the future it will
again be supported.  

I certainly realize that software changes, and that you have to break backwards
compatibility from time to time.   I am just saying that giving the user 
community
an opportunity to step up and make a fix would have been helpful, not necessary 
or
required, but helpful and not that hard to do. 

-Bill




--
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/

RE: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 hypothesis that someone who doesn't bother watching out for one kind of
>announcement related to make is going to be watching out for another kind of
>announcement related to make seems implausible to me.

Perhaps, but that benefit was not one of the two I listed.  I agree, that
it most likely would have been missed.  However, as a separate subject line
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.  

-Bill



--
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/

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 talking about free software, really do not
>"get it".  And, this makes me think that those people could stand a
>little fish teaching.
I am not sure what "fish teaching" is?

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.

Something like:   make - no longer going to accept non-posix paths.
I have been maintaining a cygwin specific patch to make for a long time
now, and I am no longer interested in doing that.   It is too much work,
and I do not use anything buy POSIX paths in my makefiles anyway.   If anyone
needs/wants this functionality to continue, please post to a fix for make
on make-w32 that will allow for a cygwin build of make to support Windows native
paths.   

It would have done two things:

1. It would be a good link to provide anyone that complained about the missing
feature.

2. It would have let any developer know that you were not opposed to non-POSIX 
path
support in make, you just did not want to do it in a cygwin specific patch to 
make
you had been using.  Basically, it is not a waste of time to create the patch 
because
it will be used.

I don't think it is against the principals of free software to announce changes 
that
will affect backwards compatibility.  As it was the announcement came after the 
change
was made.

-Bill


--
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/

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 change makes sense and that
>the patch is as small as possible.

OK, I will rephrase, Chris has seen the patch and will not oppose its adoption 
into
make or the next release of cygwin make.  

>It would behoove people for whom this change is important to test it,
>though.

Please do, it works for my use case and passes all the make tests, but
that is about as much as was tested.   The patch allows makefiles to recognize
windows and Posix paths.   All of the following will work:
c:\foo\bar.txt and c:/foo/bar.txt and /cygdrive/c/foo/bar.txt.

It is not really new functionality to the upstream make.   make already had
support for this, but it was not enabled when building for cygwin.  It now is.

-Bill


--
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/

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 and autoheader before you
run configure.   

-Bill


--
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/

RE: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 having problems with MinGW's make it would behoove
>>> you to discuss the problems in a mailing list which was populated by people
>>> who are familiar with it.
>> 
>> Because I do not agree with your suggestion.   
>
>  You don't agree that this is the cygwin list, not the mingw list?
>
>  That really explains everything that's wrong with you in a single sentence.
I answered a question posted on this list. I certainly never said this was the 
mingw list,
I said that this topic was IMO fair for this list.  Those are two different 
things.
You are misquoting me. 

-Bill


--
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/

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 which was populated by people
>who are familiar with it.

Because I do not agree with your suggestion.   Apparently you need things
repeated to you.  So, here is my reason for the post again.
You mentioned MinGW as an alternative, it does not work.
Also, someone on this list asked me a question, and I answered it.  

-Bill


--
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/

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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/1.0/GZ.
>
>I think this is the MSYS Make, not what I call ``the MinGW Make''.
>The latter is produced by building the original Make 3.81 sources with
>the MinGW compiler via the build_w32.bat batch file included in the
>source tarball.  If you look in the official Make sources, you will
>not find any code that changes /GZ into something else; in fact, the
>native Windows build doesn't change anything in the command-line
>options of the command being invoked, IIRC.

You are correct.  MSYS Make is the one that has that problem.
My earlier test must have found the wrong make.  However, the mingw
make when correctly in the PATH does not like the makefiles that
have forward / and does not launch processes very well if sh.exe is
in your path.   I can only get it to work from a dos shell with dos
style paths.   CMake can generate dos path makefiles for MinGW Make,
but I usually run from a cygwin shell and create makefiles with unix
style forward /, and this seems not to work.  This may be the wrong
list for this, but since MinGW was recommend as an alternative in
the announcement for make 3.81 it should be fair game to point out
the problems with that suggestion.

I have not dug into the problem yet, but:

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 D4024 : unrecognized source file type 'CMakeFiles/conl
y.dir/conly.obj CMakeFiles/conly.dir/foo.obj ', object file assumed
LINK : fatal error LNK1104: cannot open file 'CMakeFiles/conly.dir/conly.obj CMa
keFiles/conly.dir/foo.obj'
make.exe[2]: *** [conly.exe] Error 2
make.exe[1]: *** [CMakeFiles/conly.dir/all] Error 2
c:\hoffman\My Builds\CMakeDev\Tests\COnly\b\make.exe: *** [all] Error 2


Here is a run in the same directory with the 3.81 make that I patched:
(also works fine for cygwin 3.80 make)

[EMAIL PROTECTED] ~/My Builds/CMakeDev/Tests/COnly/b
$ /cygdrive/c/Downloads/make-3.81-build/make
[ 25%] Built target testc2
[ 50%] Built target testc1
Linking C executable conly.exe
[100%] Built target conly


-Bill


--
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/

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 changes, then I think the place
>to start is to
>
>  * get a copy of the current GNU Make sources
>
>  * apply your above "patch"
>
>  * build and test it
>
>  * if it works, submit the patch to the GNU Make maintainers in the
>appropriate forum (not here) explaining why the patch is needed
>and whether there are any potential hazards to watch out for if
>the change is made



Here is the patch, and it seems to work. I have posted the patch to make-w32
minus the forcing of HAVE_DOS_PATHS for cygwin.  It would be nice
if this could be make-3.81-2 in cygwin, but my hopes are low for that.

But it can't be said I did not look at the code or provide a patch. :)
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 makefiles again.  

The reason I am posting this patch to this list is so that other cygwin
users can try the patch and make sure that things work in the ways they
expect.  The change in config.h.in is more of a hack, and the correct
place to fix that is in configure.in, and if it gets accepted I can
do the extra work to put the fix in that file instead.

*** make-3.81/config.h.in   Wed Aug 16 16:31:10 2006
--- make381orig/make-3.81/config.h.in   Sat Apr  1 01:40:00 2006
***
*** 75,84 

  /* Use platform specific coding */
  #undef HAVE_DOS_PATHS
- #ifdef __CYGWIN__
- #define HAVE_DOS_PATHS 1
- #endif
-

  /* Define to 1 if you have the `dup2' function. */
  #undef HAVE_DUP2
--- 75,80 
Only in make-3.81: config.h.in~
diff -r -p make-3.81/job.c make381orig/make-3.81/job.c
*** make-3.81/job.c Wed Aug 16 19:42:14 2006
--- make381orig/make-3.81/job.c Sun Mar 19 22:03:04 2006
*** construct_command_argv_internal (char *l
*** 2297,2316 
   0 };
char*  sh_chars;
char** sh_cmds;
- #elif defined(HAVE_DOS_PATHS)
-   /* This is required if the MSYS/Cygwin ports (which do not define
-  WINDOWS32) are compiled with HAVE_DOS_PATHS defined, which uses
-  sh_chars_sh[] directly (see below).  The value is identical to
-  the one above for WINDOWS32 platforms.  */
-   static char sh_chars_sh[] = "#;\"*?[]&|<>(){}$`^";
-   static char *sh_cmds_sh[] = { "cd", "eval", "exec", "exit", "login",
-"logout", "set", "umask", "wait", "while", "for",
-"case", "if", ":", ".", "break", "continue",
-"export", "read", "readonly", "shift", "times",
- "trap", "switch", "test", "echo", 0};
-   char *sh_chars;
-   char **sh_cmds;
-
  #elif defined(__riscos__)
static char sh_chars[] = "";
static char *sh_cmds[] = { 0 };
--- 2297,2302 
*** construct_command_argv_internal (char *l
*** 2340,2351 
  sh_chars = sh_chars_sh;
}
  #endif /* WINDOWS32 */
- #if defined(HAVE_DOS_PATHS) && !defined(WINDOWS32)
-   int slow_flag = 0;
-
-   sh_cmds = sh_cmds_sh;
-   sh_chars = sh_chars_sh;
- #endif /* WINDOWS32 */

if (restp != NULL)
  *restp = NULL;
--- 2326,2331  


--
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/

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 with a patch, I'd have already done so.
>
>I'm not interested in playing any further games of catch-up with you or
>anyone else.  Please don't try to involve me in your attempts to modify
>the upstream make.  However, should you actually come up with a patch, I
>will monitor the make mailing list and, if I have any objections, I'll
>make them there.

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


-Bill



--
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/

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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:

http://cygwin.com/ml/cygwin/2006-07/msg00882.html


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."

http://cygwin.com/ml/cygwin/2006-07/msg00886.html


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."
http://cygwin.com/ml/cygwin/2006-07/msg00910.html


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').
http://cygwin.com/ml/cygwin/2006-07/msg00938.html


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.   

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?

-Bill


--
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/

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 changes,
the diff between the upstream 3.80 and 3.81 is about 450 lines of diff.
Although if you removed the command.com changes, and only used sh to launch
stuff, the changes would be much smaller than that.

I can see why it would not be accepted upstream as is:

ChangeLog.RedHat:   * vpath.c: use cygwin32_win32_to_posix_path_list() in
ChangeLog.RedHat:   cygwin.dll library to accept both posix and win32 paths

It makes a call to cygwin.dll.

So, I suppose a new patch would be needed up stream that did not have the 
command.com stuff ( I don't think it is being missed).   The new patch would 
only
put in support for drive letters to work, and I would think that it would be 
much
smaller. 

-Bill


--
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/

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 "fixed" for you,
>it's up to the current maintainer, not Red Hat.  As far as Red Hat is
>concerned, you can purchase Red Hat's supported Cygwin distribution
>which comes with user support.


>>...or offer money. That carries more weight than complaining. :-)
>>
>>However that doesn't work in all cases. This I am reasonably confident 
>>is one of them. But as a general rule...
>
>No, it would work in this case, but I hesitate to name my price since
>it will surely make me sound even more evil.
>
>cgf

I assumed since cgf worked for Red hat, that his offer to take money
would go to Red Hat.  My mistake.


>> - have the patch made part of the upstream gnu make
>
>That's the best solutiion 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 wondering why people don't go this
>way instead of discussing this problem, which is none, IMHO, to death.

OK, I will move off this discussion, and try to work with the upstream
gnu make.   It is the only option left.   Although I am not convinced that
this is not an issue unique to cygwin.   Cygwin supports both posix and
windows paths.  Unix environments do not support windows paths, so no 
interest from the upstream gnu make there.   Only support for windows paths
works already in upstream gnu make, so no interest there.   It is only on
cygwin where this makes sense.  


>> The point I am trying to make is that the one option that is off the table,
>> is taking over the maintenance of the make package in cygwin and doing
>> the patch yourself.
>
>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 be fixed to
>my neck, it would actually fall down from all the shaking now.

Because it would be easy.  A small patch and everything goes back
to the way it was.   I also think this is a unique cygwin issue and
the upstream maintainers may not be interested in it.  
I will stop posting on this thread, but I am sure you have not heard the last 
of it.
There were a lot of people using a feature that was removed.   I am sure there 
are 
many folks out there that have not updated cygwin, and do not know about the 
change yet.
When they find out, they will complain as well.  

-Bill


--
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/

RE: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 make it
>work again:

Not so untrue, the old way was run setup and get the most current version
of make.  That clearly no longer works.


>1)  Use setup.exe to roll back your current make version to 3.80-1
>2)  To make sure this doesn't ever get overwritten by a newer version even if
>you want to upgrade the rest of your cygwin installation, you can edit
>/etc/setup/installed.db; change the version number in the entry for make to
>something ridiculous, like .-9; setup.exe will always think your
>installed version is newest.
>
>or:
>
>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 package altogether.
>
>
>  Trivial.  Elementary.  Easy.  Simple.  Take you ten minutes.  Twenty if you
>aren't used to compiling source packages and have to try it a couple of times.

Sure, that will work for now.  But when 3.82 comes out 3.80-1 will go away
and become hard to get.   Also, it is not just for me.  It is for users of my
open source software.   The instructions used to be, install cygwin, get the
make program, and build.   Now it is install cygwin, make sure you get 3.80-1 
version
of make.  And when that goes away the instructions will be get make and patch it
yourself.  

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 point I am trying to make is that the one option that is off the table,
is taking over the maintenance of the make package in cygwin and doing
the patch yourself.   So, even if a volunteer stepped up and offered to
take the burden off the current maintainer, the offer to do the work
would be rejected.  The other option of creating a separate make package
that has the patch has also been rejected.  

I am sure you can see that it would be better for people that depend
on this feature if it were part of cygwin.   

-Bill


--
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/

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 path of least effort is
>just to instruct people to use MinGW.

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.   If there is a sh.exe in the PATH.  So,
I can get things to work, but you have to run from a MS Command prompt,
and not from a cygwin shell, or an msys shell.   It kind of sucks.


-Bill


--
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/

RE: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 list, of trying to muzzle opinions they disagree with,
>> does not help.
>
>  It's not about anyone denigrating anyone else's contribution, or anyone
>trying to muzzle anyone else's opinion.  That's paranoid hyperbole and
>exaggeration.
>
>  It's just that if someone doesn't want to do it, and you aren't persuading
>them, to carry on repeating the same line again and again and again and again
>is insulting, for three reasons: 1) saying the same thing over and over again
>when someone has already explained why they're not going to do what you want
>constitutes nagging, 2) saying the same thing over and over again when someone
>has explained why they're not going to do what you want to do implies that you
>haven't had the courtesy to listen to a word they've said, and 3) saying the
>same thing over and over again when someone has already explained why they're
>not going to do what you want to do is more-or-less spamming.  It's pointless,
>annoying, offensive, whiney and arrogant.  It just starts to sound like "Me me
>me me me I want I want I want" and people quickly start to react to you as if
>you actually /were/ a four-year old.

I am not sure that is the case here.   A change was made because the developer 
no
longer wanted to support the patch.   I can relate to that.  If something is a 
pain,
and you don't want to do it fine.   However, if a new developer came along and 
volunteered
to maintain the patch, or even create a separate version of make that had the 
patch,
I am guessing that it would be rejected by cygwin.   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.  The only thing they can do is lobby the gnu make folks and get some 
change
into gnu make.   So it a no win situation for those that want the old way
to work.  If you complain on the list, you are whiney,  if you offer to do the 
maintain
the patch yourself, then your offer will be rejected. 

-Bill




--
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/

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 posted a suggestion to add Win32
>>path support to make, why not check the archives[1]?  FWIW, the
>>make-w32 list[2] might be a better starting point.
>
>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 thread "Re: 3.81 and windows paths" on 
http://lists.gnu.org/archive/html/bug-make/2006-07/msg00023.htmland.
I was unable to find the suggestion.   Could you please point me to
the suggestion.   The suggestion seems to be use mingw make and
not cygwin make.  However, I get the feeling that you are hinting at
some other suggestion.  If you have a link into the list where the
suggestion is, I would appreciate it.  Thanks.

-Bill


--
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/

RE: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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!  Maybe have them simply accept the --win32 option or recognize the
>MAKE_MODE environment variable, like Cygwin make used to do?

I was figuring this was off the table since it was not in the upstream make.
Is this option still on the table?  If so, what is the path to have it
implemented?

>> - 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" (or, barring
>that, with a perl or sed script).  I've done that, others have done that.
>If you are generating the code to invoke the Microsoft cl compiler, simply
>use something like $(foreach f,$^,$(shell cygpath -w $f)) as the argument
>to cl.


I have to say yuck!, and performance hit.  So, for every path that gets
passed to the compiler you have to launch a process that does string allocation
and conversion.   I do not think this is a realistic solution for larger
projects.  I would not want CMake to generate makefiles with cygpath -w
being invoked multiple times per compiler run.   So, I will restate that
there is no workable solution to use cl with cygwin make anymore.

-Bill


--
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/

RE: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 cygwin make as of 3.81.
 
- cygwin will no longer maintain the patch to make that allowed
it to recognize driver letters in paths.

- A second make-winpath as part of the cygwin package is not an option
that would be accepted into cygwin.

- The option for folks that want the old behavior is to have the
change integrated into the upstream sources of gmake.  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.   

- The other option is to use mingw-make, and only use cygwin make
for cygwin linked programs only.

Sounds like it is time to join the gmake mailing list.  Has anyone
on this list tried that yet?  

-Bill


--
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/

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 MS-DOS to cygwin paths.

True, and as an example of a high profile project that was hit by
this, I found FireFox, has not quite figured out what to do about the change.

http://developer.mozilla.org/en/docs/Windows_Build_Prerequisites
Note: make 3.80 (not 3.81!) -- dependency analyzer for software builds (Devel 
category) 

Firefix is built with cl, and cygwin make.   


-Bill


--
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/

RE: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 limitation.



The cmake distributed with cygwin produces cygwin makefiles and only
cygwin makefiles.  It is unaffected by the change in make from 3.80 to 
3.81.   There is no such limitation, please don't remove cmake from cygwin.
Since that cmake links to the cygwin runtime it know about /cydrive/c and
uses it.

The change affects the microsoft build of cmake.  That build is available
on a separate download from www.cmake.org.  It has 
an option to generate "Unix Makefiles".  In the past,
you could use this mode to create Makefiles that would drive Microsoft's 
cl with a cygwin make.   This no longer works.   I am trying to figure
out if there is change I can make to the windows build of cmake, that
will cause it to generate makefiles that will work with both make 3.80, and
3.81 from cygwin.

-Bill



--
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/

RE: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 `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 guessing there is no way to write a makefile that will use
make 3.81 that will work with Microsoft's cl.  Is that correct?  Or am 
I missing something?  I can change cmake to put anything I want in the generated
makefiles, but it will have to be something that is valid for cl.

Thanks.

-Bill


--
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/

RE: change in behavior of make from 3.80 to 3.81

[William A. Hoffman]

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 people who haven't bothered
>to check if it was already known.

Just being lazy.  I should have searched.   I see now there is quite a bit
of traffic on this.  I don't know if this is adding to the discussion, but
I will give my use case that shows the problem.

So, visual studio 2005 now supports the ability to run cl for two .o files
at the same time, so you can do make -j N builds with cl as the compiler.
I am the maintainer of the CMake www.cmake.org package, and CMake can generate
"Unix Makefiles" on windows, and in the past prior to 3.81, this worked. 
The problem is that the CMake that generates the makefiles does not know about
cygwin, and can not run cygpath.   It creates makefiles with / and not \, but
still has the drive letter : for full paths.   cl does accept paths with / in 
them,
but it obviously does not know about /cygdrive/c.   

I guess I should just recommend that cmake users use mingw make:


>Note that the --win32 command line option and "MAKE_MODE" environment
>variable are no longer supported in Cygwin's make.  If you need to use a
>Makefile which contains MS-DOS path names, then please use a MinGW
>version of make.
>
>See: http://mingw.org/ for details on downloading a version 
>of make
>which understands MS-DOS path names.  Please! direct any questions about
>the MinGW version of make to the appropriate MinGW mailing list.

Although, the only thing CMake users need is a way to specify the
drive root, and /cygdrive will not work because of cl.  But, the rest
of the paths used in the makefiles are POSIX /.

-Bill  


--
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/

[ANNOUNCEMENT] Updated: CMake-2.4.3-1

[William A. Hoffman]

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 prevent -fvisibility=hidden flags. This is
needed to make RTTI work by default.

* better prototype for main in try compile of c programs avoids warnings in
logs.

* with visual studio do not use incremental linking for release builds by
default.

* fix bootstrap to use more ansi c main it test compiler

* fix import build settings to do case insensitive match on windows

* fix building in root directory c:/

* Add support for CXX only projects

* Better FindWxWidgets

* Added FindBoose.cmake

* add more fortran file extensions

* Cpack supports multiple packages at the same time

* Fix to FindKDE4 to look for kde4-config first

* Support for env var CMAKE_CONFIG_TYPE in ctest

* Fix for -DVAR=foo on the command line not saving to the cache

* ENH: Added creation of XXX_FIND_COMPONENTS list of all components requested
  withREQUIRED option.  This addresses the feature request in bug#3494.

* Object files get safe names

* progress is now reported with makefiles

* location of CMakeTmp changed to a varible

* CMAKE_COLOR_MAKEFILE cache variable available to turn off color output

* fixes for FindQt4 on mac.

* Better search paths for finding VTK

* Fix relative path problems in ADD_SUBDIRECTORY

* Fix long link commands on UNIX shells

* Fix depend file names in makefiles for generated headers

* CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS allows for if/endif without variable

* Xcode multiple custom command problem fixed.

* INSTALL_RPATH_USE_LINK_PATH when true will add the link path to the rpath

* Add target/fast rules in the sub directories

* Fix Visual stuido C and C++ targets to not add /TP and /TC

* print a context when cmake errors occur

* add rxvt-unicode, cygwin, and screen terminal support for color output

* Fix crash in CMakeSetup when status line is long

* make sure try compile files have a newline at the end

* fix for hp itanium build

Changes in CMake 2.4.2

* Run symlink command from correct directory for executable versions

* Fix for universal binaries and Xcode depend problem

* Changes to LIST command, see --help-command LIST

* Fix FindQT to be able to use full paths to source files

* Fix CPack ZIP on windows command line problem

* Find executables with no extension on windows mingw

* Fix FindQt3 to use QTDIR over path

* Significant speedup in try-compile for nmake

* CPack improvments including tar bzip2

* FindQt4 windows path fix

* Sunos cc optimize flags are correct

* Fix crash with ${} empty variable

* Increase depend speed on Mac OS.

* install command CONFIGURATIONS option.

* Fix MSVC60, MSVC70, MSVC71, MSVC80 definitions for IDE builds

* Fix for C++ compiler being used for c code in VS IDE

Changes in CMake 2.4.1

* Several ctest and cpack bug fixes

* Many updates and fixes for FindQt4.cmake

* Fix CMAKE_REQUIRED_FLAGS in CheckCXXSourceCompiles.cmake 

* Handle running make from a symlinked build tree

* Automatic color ouput detection for shells building with make

* Kdevelop generator handles CMakeFiles directory better

* add correct depend information for fluid 

* allow the cache to be saved even if a fatal error occurs

* fix bug in relative path subdir and add_subdirectoy commands

* support in vs for two object files with the same name

* short file names used for library paths in visual studio

* package target only shows up when you have cpack config files

* Use dl and not -ldl for adding in the dynamic library

* Fix check c/cxx source compiles macros to not clobber log files
 
* Fix nmake version detection of cl and create correct pdb files

* Fix msys bootstrap

* Change color output to be more readable

* Fix vs6 library naming

Changes in CMake 2.4.0

* CPack beta

* Visual Studio 2005 win64 support

* Improved install support

* Improved FIND_PROGRAM, FIND_LIBRARY, FIND_PATH, FIND_FILE

* Improved support for finding/using OSX Frameworks

* Multiple output support for custom commands

* Color output in make with vt100 terminals CMAKE_COLOR_MAKFILE

* Better variables for MSVC MSVC80 

* Library path order is preserved

* Fix for text file busy in xcodebuild runs

* Better bundle support on OSX

* ctest -S scripts can run in new process with new environment

* OSX universal binary support

* Watcom support
 
* MinGW and MSYS support

* Visual studio 2005 manifest support

* Better handling of RPATH, no longer put rpath in install tree

* Fix OUTPUT_NAME 

* ctest captures output from vcexpress

* cmake --help-module can give help for cmake modules

* Lots of bug fixes 


See www.cmake.org for more information.

*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email 

[ANNOUNCEMENT] Updated: CMake-2.4.2-1

[William A. Hoffman]

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 problem

* Changes to LIST command, see --help-command LIST

* Fix FindQT to be able to use full paths to source files

* Fix CPack ZIP on windows command line problem

* Find executables with no extension on windows mingw

* Fix FindQt3 to use QTDIR over path

* Significant speedup in try-compile for nmake

* CPack improvments including tar bzip2

* FindQt4 windows path fix

* Sunos cc optimize flags are correct

* Fix crash with ${} empty variable

* Increase depend speed on Mac OS.

* install command CONFIGURATIONS option.

* Fix MSVC60, MSVC70, MSVC71, MSVC80 definitions for IDE builds

* Fix for C++ compiler being used for c code in VS IDE

Changes in CMake 2.4.1

* Several ctest and cpack bug fixes

* Many updates and fixes for FindQt4.cmake

* Fix CMAKE_REQUIRED_FLAGS in CheckCXXSourceCompiles.cmake 

* Handle running make from a symlinked build tree

* Automatic color ouput detection for shells building with make

* Kdevelop generator handles CMakeFiles directory better

* add correct depend information for fluid 

* allow the cache to be saved even if a fatal error occurs

* fix bug in relative path subdir and add_subdirectoy commands

* support in vs for two object files with the same name

* short file names used for library paths in visual studio

* package target only shows up when you have cpack config files

* Use dl and not -ldl for adding in the dynamic library

* Fix check c/cxx source compiles macros to not clobber log files
 
* Fix nmake version detection of cl and create correct pdb files

* Fix msys bootstrap

* Change color output to be more readable

* Fix vs6 library naming

Changes in CMake 2.4.0

* CPack beta

* Visual Studio 2005 win64 support

* Improved install support

* Improved FIND_PROGRAM, FIND_LIBRARY, FIND_PATH, FIND_FILE

* Improved support for finding/using OSX Frameworks

* Multiple output support for custom commands

* Color output in make with vt100 terminals CMAKE_COLOR_MAKFILE

* Better variables for MSVC MSVC80 

* Library path order is preserved

* Fix for text file busy in xcodebuild runs

* Better bundle support on OSX

* ctest -S scripts can run in new process with new environment

* OSX universal binary support

* Watcom support
 
* MinGW and MSYS support

* Visual studio 2005 manifest support

* Better handling of RPATH, no longer put rpath in install tree

* Fix OUTPUT_NAME 

* ctest captures output from vcexpress

* cmake --help-module can give help for cmake modules

* Lots of bug fixes


*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.



Bill Hoffman 
Cygwin CMake maintainer 


--
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/

[ANNOUNCEMENT] Updated: CMake-2.2.2-1

[William A. Hoffman]

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 for gnu c++ on windows
- Link targets with relative paths to the .o files
- Add a RELATIVE_PATH option to the FILE command.
- Add a SUBSTRING/LENGTH commands to the STRING command.
- Move the .SILENT to the top of the makefile to get nmake to be quite.
- Fix performance problem in check build system stage with make/nmake
- Remove the -lgcc that was automatically added by cmake to gcc shared libs.
- Look for java 1.5
- Fix custom targets and depend target
- Fix in parser to allow double quoted strings to correctly pass into 
TRY_COMPILE.
- Fix GET_TEST_PROPERTY command.
- Fix CTEST_MEMCHECK command so that it does memory checking instead of testing.
- Fix output of expected failed tests to test passed.
- Fix documentation for cmake -P, and -C.
- Fix -P with relative paths, and fix error messages.
- Fix problems with quotes in definition values and visual studio 7.x
- Fix install problem with missing mfc dlls

Changes in CMake 2.2.1:
- 2.2.1 is a new beta and was merged with CVS on 9/06/05.
- fix infinite loop problem in enable language/trycompile
- The makefile generator was redone to create fewer files.
- Xcode 2.1 support added.
- better support for add custom command with relative files as arguments
- provided default update options if none are provided to ctest
- For file removal if the file is a symlink treat it like a file and not a 
directory.
- Better install directory for windows.
- AIX compiler flag defaults.
- Objc++ test has the correct case.
- Language NONE fixed.
- Java 1.5 searched now.
- FindCurses cleaned up.
- FindQt/FindQt3/FindQT4 enhanced.
- UseSwig supports CMAKE_SWIG_OUTDIR
- Modules/ProjectCompatibility.cmake file supported.
- Modules/VTKCompatibility.cmake file added for Darwin builds
- optimized is now the default library used if CMAKE_BUILD_TYPE is not set.
- many bug fixes from 2.2.0.

Changes in CMake 2.2.0:

- CTest Improved coverage code
- Improved CTest -S scripts, new commands, and access to individual testing 
handlers
- CTest test handler now supports arbitrary CMake syntax in DartTestfile.txt
- CTest now supports both DartTestfile.txt and CTestTestfile.cmake
- CTest now supports both DartConfiguration.tcl and CTestConfiguration.cmake
- CTest now supports configuration from Source tree in file CTestConfig.cmake
- CTest supports logging output into a file
- CTest supports compressed submission files
- Speed improvements
- new makefile generator
- no longer re-read cmakelist files only get parent cmakelist file
- out of source source
- ADD_SUBDIRECTORY
- new parser variables in variables
- support for dart2
- Xcode 1.5 support 
- fortran support
- not compatible with cmake 1.2
- FOREACH uses variables 
- Kdevelop3 generator
- WHILE command
- lower case commands now supported
- parallel build support better, jump problem fixed
- lots of bug fixes and new bugs

See www.cmake.org for more information.

*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.



Bill Hoffman 
Cygwin CMake maintainer 


--
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/

[ANNOUNCEMENT] Updated: CMake-2.0.6-1

[William A. Hoffman]

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 the correct SourceFile so CVS link works.
- Fix for INSTALL_PROGRAMS to use the FILES tag to mark the list of programs.
- Fix for bug 1652, FindDCMTK now supports binary install on linux.
- Fix for bug 1660, language NONE now works with visual studio 7x.
- Fix for bug 1680, do not use c++ compiler on rc and def files.
- Fix for bug 1702, better error report with bad GUID.
- Fix for Swig 1729 SWIG_FLAGS does not need to be set anymore.
- Fix for Swig module (Bug 1730 c code broken, and 1303 wrap two languages) 
- Fix for timezone issue when start time is over 24 hours in the future.
- Fix for configuring read only files.
- Fix for MSXML 4.0 Service Pack 2 and MS C++ Express 2005.
- Fix running of objective c++ test with other than gnu compiler.
- Fix ctest warning file for cmake.
- Fix darwin xlc shared link flags
- Limit number of errors and warnings to 50 each per dashboard submit.
- Fix crash in CMakeSetup when delete cache left a chooser button.
- Fix missing Windows-icl.cmake file for intel compiler and nmake.
- Fix SET command so that multiple args can be cached.
- Fix depend problem with borland and renamed object files + goes to p.
- Fix ctest not creating xml safe strings.
- Fix ctest to handle proxies better.
- Fix relative path object files not being put in sub-dirs when props set.
- Fix INCLUDE_DIRECTORIES pre when directory is already in list.
- Fix for OpenBSD.

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.
- Fix ctest double space problem with output on windows.
- Fix ctest not found test path to avoid multiple copies of the same test.
- Fix ctest regular expression for SGI remarks.
- Fix single character target in makefiles that confuses nmake.
- Fix RunSingleProgram to work with spaces in the path.

Changes in CMake 2.0.4:
- Fix ctest regular expressions for warnings and errors.
- Fix crash with MACOSX_BUNDLE and unset EXECUTABLE_OUTPUT_PATH.
- Fix missing build overview information bug in ctest.
- Fix missing notes file bug in ctest.
- Fix bug 1179, parse error with $(var) make variables.
- Fix recognition of cygwin paths starting with a drive letter.
- Fix unclosed registry key leak.
- Fix unused variable compile warning.
- Fix resource leak in win32 process spawning.
- Fix INCLUDE_EXTERNAL_PROJECT command so it works as documented.
- Fix line reporting for the FOREACH command.
- Fix Glob file case problem.
- Fix for bug 1041, _MBCS sometimes added for UNIICODE.
- Fix when CMAKE_DEBUG_POSTFIX is not set the installer crashes. 
- Fix for free Visual Studio command line tools to get correct flags.
- Fix CTest start time for other time zones.
- Fix terse error output in CTest.
- Fix argument parsing for CTest in --build stuff.
- Fix problem with RUN_TESTS target in visual studio 6 and 7 project files 
wrong flags for ctest.
- Fix problem with generated .h files not being recognized as header files only.
- Fix problem with spaces in the path and MinGW.
- Fix bug where cmake and CMakeSetup incorrectly always default to Visual 
Studio 8.
- Fix crash when adding a custom command to a non-existent source file.
- Fix crash in VS7 generator when CMAKE_CXX_STACK_SIZE is not set.
- Fix TRY_COMPILE to use CMAKE_TRY_COMPILE_CONFIGURATION from current listfile.
- Fix missing try-compile debug support for TRY_RUN.
- Fix BUG 427: Try-compile when a non-executable target is specified.

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.xml
- timeout for ctest build and run
- Fixes for MinGW EXEC_COMMAND
- Fixes for install on windows, to work with Release/Debug dirs
- Fixes for install to work with shared library versions
- Fixes for QT wrapping commands to not require QT_WRAP_UI to be set, but still 
set it
- Better error reporting for win32 process running
- PreLoad.cmake file can be in source or binary
- Tree killing for linux and ctest
- CMAKE_PROGRAM_PATH CMAKE_FILE_PATH now searched by FIND_PROGRAM and FIND_FILE
- FLTK FLTK_WRAP_UI now set for backwards compatibility
- More warning expressions for ctest
- Do not duplicate include flags for .rc files on windows.
- fix spelling errors in error messages
- report build directory used in command line cmake
- fix for bug 981, help in ccmake lost cursor position
- CMakeSetup browse buttons use current directories
- generated test driver programs flush the text menu
- Mentioned LOCATION target property in GET_TARGET_PROPERTY documentation
- Added warning to AUX_SOURCE_DIRECTORY command document

[ANNOUNCEMENT] Updated: CMake-2.0.5-1

[William A. Hoffman]

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 TestCXXAcceptsFlag.cmake should not run every time.
- Fix ctest double space problem with output on windows.
- Fix ctest not found test path to avoid multiple copies of the same test.
- Fix ctest regular expression for SGI remarks.
- Fix single character target in makefiles that confuses nmake.
- Fix RunSingleProgram to work with spaces in the path.

Changes in CMake 2.0.4:
- Fix ctest regular expressions for warnings and errors.
- Fix crash with MACOSX_BUNDLE and unset EXECUTABLE_OUTPUT_PATH.
- Fix missing build overview information bug in ctest.
- Fix missing notes file bug in ctest.
- Fix bug 1179, parse error with $(var) make variables.
- Fix recognition of cygwin paths starting with a drive letter.
- Fix unclosed registry key leak.
- Fix unused variable compile warning.
- Fix resource leak in win32 process spawning.
- Fix INCLUDE_EXTERNAL_PROJECT command so it works as documented.
- Fix line reporting for the FOREACH command.
- Fix Glob file case problem.
- Fix for bug 1041, _MBCS sometimes added for UNIICODE.
- Fix when CMAKE_DEBUG_POSTFIX is not set the installer crashes. 
- Fix for free Visual Studio command line tools to get correct flags.
- Fix CTest start time for other time zones.
- Fix terse error output in CTest.
- Fix argument parsing for CTest in --build stuff.
- Fix problem with RUN_TESTS target in visual studio 6 and 7 project files wrong flags 
for ctest.
- Fix problem with generated .h files not being recognized as header files only.
- Fix problem with spaces in the path and MinGW.
- Fix bug where cmake and CMakeSetup incorrectly always default to Visual Studio 8.
- Fix crash when adding a custom command to a non-existent source file.
- Fix crash in VS7 generator when CMAKE_CXX_STACK_SIZE is not set.
- Fix TRY_COMPILE to use CMAKE_TRY_COMPILE_CONFIGURATION from current listfile.
- Fix missing try-compile debug support for TRY_RUN.
- Fix BUG 427: Try-compile when a non-executable target is specified.

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.xml
- timeout for ctest build and run
- Fixes for MinGW EXEC_COMMAND
- Fixes for install on windows, to work with Release/Debug dirs
- Fixes for install to work with shared library versions
- Fixes for QT wrapping commands to not require QT_WRAP_UI to be set, but still set it
- Better error reporting for win32 process running
- PreLoad.cmake file can be in source or binary
- Tree killing for linux and ctest
- CMAKE_PROGRAM_PATH CMAKE_FILE_PATH now searched by FIND_PROGRAM and FIND_FILE
- FLTK FLTK_WRAP_UI now set for backwards compatibility
- More warning expressions for ctest
- Do not duplicate include flags for .rc files on windows.
- fix spelling errors in error messages
- report build directory used in command line cmake
- fix for bug 981, help in ccmake lost cursor position
- CMakeSetup browse buttons use current directories
- generated test driver programs flush the text menu
- Mentioned LOCATION target property in GET_TARGET_PROPERTY documentation
- Added warning to AUX_SOURCE_DIRECTORY command documentation.
- Fix BUG 971: command line cmake does not select good default generator.
- Fix BUG 999: Allow a project to define system name for dart submissions
- Fix BUG 997:  CTest cannot handle URLs which contain a "?"
- Add support to ctest for reporting timing information.
- Fix BUG 966 VC7 generator correctly converts command line flags to GUI options.
- Fixed link-libs commands to not crash when last argument is debug/optimized.

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:
  INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR}).
  Or, you can set the CMAKE_BACKWARDS_COMPATIBILITY to 1.8.
- Fixed parsing of unquoted arguments to allow double-quotes within the
  argument.
- Add a STREQUAL to the IF command.
- Modules/FindFLTK.cmake: look for both Fl.h or Fl.H.
- Fix compound IF crash on unix. BUG id 917.
- Fix path problem with sub projects and IDE workspace files.
- Add a FindKDE module.
- Modules/FindFLTK.cmake: fix for bug 915
- BUG#891: When building CMake itself, use the new cmake to install so 
  that the current cmake can be overwritten.
- BUG: Files in top-level directory of source tree were not reported in updates log 
  for ctest.
- Fix find library so it does not find directories.


Changes in CMake 2.0.1:

- Platform independent Install (no more install-sh); 
  supports pre install, post install, manifest, destdir...
  faster and it works on Windows 
- Add support for SWIG
- Optional support for relative 

[ANNOUNCEMENT] Updated: CMake-2.0.3-1

[William A. Hoffman]

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.xml
- timeout for ctest build and run
- Fixes for MinGW EXEC_COMMAND
- Fixes for install on windows, to work with Release/Debug dirs
- Fixes for install to work with shared library versions
- Fixes for QT wrapping commands to not require QT_WRAP_UI to be set, but still set it
- Better error reporting for win32 process running
- PreLoad.cmake file can be in source or binary
- Tree killing for linux and ctest
- CMAKE_PROGRAM_PATH CMAKE_FILE_PATH now searched by FIND_PROGRAM and FIND_FILE
- FLTK FLTK_WRAP_UI now set for backwards compatibility
- More warning expressions for ctest
- Do not duplicate include flags for .rc files on windows.
- fix spelling errors in error messages
- report build directory used in command line cmake
- fix for bug 981, help in ccmake lost cursor position
- CMakeSetup browse buttons use current directories
- generated test driver programs flush the text menu
- Mentioned LOCATION target property in GET_TARGET_PROPERTY documentation
- Added warning to AUX_SOURCE_DIRECTORY command documentation.
- Fix BUG 971: command line cmake does not select good default generator.
- Fix BUG 999: Allow a project to define system name for dart submissions
- Fix BUG 997:  CTest cannot handle URLs which contain a "?"
- Add support to ctest for reporting timing information.
- Fix BUG 966 VC7 generator correctly converts command line flags to GUI options.
- Fixed link-libs commands to not crash when last argument is debug/optimized.

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:
  INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR}).
  Or, you can set the CMAKE_BACKWARDS_COMPATIBILITY to 1.8.
- Fixed parsing of unquoted arguments to allow double-quotes within the
  argument.
- Add a STREQUAL to the IF command.
- Modules/FindFLTK.cmake: look for both Fl.h or Fl.H.
- Fix compound IF crash on unix. BUG id 917.
- Fix path problem with sub projects and IDE workspace files.
- Add a FindKDE module.
- Modules/FindFLTK.cmake: fix for bug 915
- BUG#891: When building CMake itself, use the new cmake to install so 
  that the current cmake can be overwritten.
- BUG: Files in top-level directory of source tree were not reported in updates log 
  for ctest.
- Fix find library so it does not find directories.


Changes in CMake 2.0.1:

- Platform independent Install (no more install-sh); 
  supports pre install, post install, manifest, destdir...
  faster and it works on Windows 
- Add support for SWIG
- Optional support for relative paths
- INCLUDE and FIND_PACKAGE both check CMAKE_MODULE_PATH 
- IF command supports better expression support, like IF(A AND B AND C)
- IF command now has a numeric EQUAL test
- MACRO's now support variable arguments
- FOREACH supports a RANGE of values genertor
- CMake supports an automatic pre-load cmake file in the source tree of a project.
- GET_TARGET_PROPERTY can give you the build location of a target.
- Loaded commands have a crash signal handler to detect crashes not caused by cmake.
- GET/SET_DIRECTORY_PROPERTY/PROPERTIES commands so that we can change include 
directories
  and get all sorts of things. 
- VERBOSE build option for visual studio IDE generators.
- FIND_LIBRARY and FIND_PATH now look in CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH
  environment variables in addition to and before the PATH environment variable.
- Each sub project in a project now creates a top level IDE project file so it can
  be loaded independently.
- A saftey chech was added to make sure that files written using WRITE_FILE 
  and FILE WRITE are not used as input files which can lead to infinite loops in the 
build.
- Add support for adding object files and sources. This way you can use external 
  program such as assembler or fortran to generate object files. Also star of 
  fixing: Bug #757
- add .o file as a source file.
- New REMOVE_DEFINITION command, opposite to ADD_DEFINITIONS.
- CCmake support for HOME and END keys. Also fix Bug #666, in CCMake when deleting
  something, it does not stop at the beginning of line.
- Fix externl projects for VS7 and VS6.
- New support for import of modules without specifying a path.
- New testing option to build and run an executable --build-and-test.
- Support for shared library versions on UNIX.
- SUBDIR command now supports PREORDER build option.
- Add support for file names with +-~ in them for borland compiler.
- Mac OSX bundle executable creation support with the ADD_EXECUTABLE command.
- CTest Support for in-source builds.
- CTest Skip tests that do not have defects.
- CTest new option -I that adds the ability to run a limited sub-set of the tests.
- CTest suppo

[ANNOUNCEMENT] Updated: CMake-2.0.3-1

[William A. Hoffman]

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.xml
- timeout for ctest build and run
- Fixes for MinGW EXEC_COMMAND
- Fixes for install on windows, to work with Release/Debug dirs
- Fixes for install to work with shared library versions
- Fixes for QT wrapping commands to not require QT_WRAP_UI to be set, but still set it
- Better error reporting for win32 process running
- PreLoad.cmake file can be in source or binary
- Tree killing for linux and ctest
- CMAKE_PROGRAM_PATH CMAKE_FILE_PATH now searched by FIND_PROGRAM and FIND_FILE
- FLTK FLTK_WRAP_UI now set for backwards compatibility
- More warning expressions for ctest
- Do not duplicate include flags for .rc files on windows.
- fix spelling errors in error messages
- report build directory used in command line cmake
- fix for bug 981, help in ccmake lost cursor position
- CMakeSetup browse buttons use current directories
- generated test driver programs flush the text menu
- Mentioned LOCATION target property in GET_TARGET_PROPERTY documentation
- Added warning to AUX_SOURCE_DIRECTORY command documentation.
- Fix BUG 971: command line cmake does not select good default generator.
- Fix BUG 999: Allow a project to define system name for dart submissions
- Fix BUG 997:  CTest cannot handle URLs which contain a "?"
- Add support to ctest for reporting timing information.
- Fix BUG 966 VC7 generator correctly converts command line flags to GUI options.
- Fixed link-libs commands to not crash when last argument is debug/optimized.

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:
  INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR}).
  Or, you can set the CMAKE_BACKWARDS_COMPATIBILITY to 1.8.
- Fixed parsing of unquoted arguments to allow double-quotes within the
  argument.
- Add a STREQUAL to the IF command.
- Modules/FindFLTK.cmake: look for both Fl.h or Fl.H.
- Fix compound IF crash on unix. BUG id 917.
- Fix path problem with sub projects and IDE workspace files.
- Add a FindKDE module.
- Modules/FindFLTK.cmake: fix for bug 915
- BUG#891: When building CMake itself, use the new cmake to install so 
  that the current cmake can be overwritten.
- BUG: Files in top-level directory of source tree were not reported in updates log 
  for ctest.
- Fix find library so it does not find directories.


Changes in CMake 2.0.1:

- Platform independent Install (no more install-sh); 
  supports pre install, post install, manifest, destdir...
  faster and it works on Windows 
- Add support for SWIG
- Optional support for relative paths
- INCLUDE and FIND_PACKAGE both check CMAKE_MODULE_PATH 
- IF command supports better expression support, like IF(A AND B AND C)
- IF command now has a numeric EQUAL test
- MACRO's now support variable arguments
- FOREACH supports a RANGE of values genertor
- CMake supports an automatic pre-load cmake file in the source tree of a project.
- GET_TARGET_PROPERTY can give you the build location of a target.
- Loaded commands have a crash signal handler to detect crashes not caused by cmake.
- GET/SET_DIRECTORY_PROPERTY/PROPERTIES commands so that we can change include 
directories
  and get all sorts of things. 
- VERBOSE build option for visual studio IDE generators.
- FIND_LIBRARY and FIND_PATH now look in CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH
  environment variables in addition to and before the PATH environment variable.
- Each sub project in a project now creates a top level IDE project file so it can
  be loaded independently.
- A saftey chech was added to make sure that files written using WRITE_FILE 
  and FILE WRITE are not used as input files which can lead to infinite loops in the 
build.
- Add support for adding object files and sources. This way you can use external 
  program such as assembler or fortran to generate object files. Also star of 
  fixing: Bug #757
- add .o file as a source file.
- New REMOVE_DEFINITION command, opposite to ADD_DEFINITIONS.
- CCmake support for HOME and END keys. Also fix Bug #666, in CCMake when deleting
  something, it does not stop at the beginning of line.
- Fix externl projects for VS7 and VS6.
- New support for import of modules without specifying a path.
- New testing option to build and run an executable --build-and-test.
- Support for shared library versions on UNIX.
- SUBDIR command now supports PREORDER build option.
- Add support for file names with +-~ in them for borland compiler.
- Mac OSX bundle executable creation support with the ADD_EXECUTABLE command.
- CTest Support for in-source builds.
- CTest Skip tests that do not have defects.
- CTest new option -I that adds the ability to run a limited sub-set of the tests.
- CTest suppo

[ANNOUNCEMENT] Updated: CMake-2.0.2-1

[William A. Hoffman]

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 this command:
  INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR}).
  Or, you can set the CMAKE_BACKWARDS_COMPATIBILITY to 1.8.

- Fixed parsing of unquoted arguments to allow double-quotes within the
  argument.
 
- Add a STREQUAL to the IF command.

- Modules/FindFLTK.cmake: look for both Fl.h or Fl.H.

- Fix compound IF crash on unix. BUG id 917.

- Fix path problem with sub projects and IDE workspace files.
 
- Add a FindKDE module.

- Modules/FindFLTK.cmake: fix for bug 915

- BUG#891: When building CMake itself, use the new cmake to install so 
  that the current cmake can be overwritten.

- BUG: Files in top-level directory of source tree were not reported in updates log 
  for ctest.

- Fix find library so it does not find directories.



Changes in CMake 2.0.1:

- Platform independent Install (no more install-sh); supports pre install, post 
install, manifest, destdir...; faster and it works on Windows 

- Add support for SWIG

- Optional support for relative paths

- INCLUDE and FIND_PACKAGE both check CMAKE_MODULE_PATH 

- IF command supports better expression support, like IF(A AND B AND C)

- IF command now has a numeric EQUAL test

- MACRO's now support variable arguments

- FOREACH supports a RANGE of values genertor

- CMake supports an automatic pre-load cmake file in the source tree of a project.

- GET_TARGET_PROPERTY can give you the build location of a target.

- Loaded commands have a crash signal handler to detect crashes not caused by cmake.

- GET/SET_DIRECTORY_PROPERTY/PROPERTIES commands so that we can change include 
directories
  and get all sorts of things. 

- VEBOSE build option for visual studio IDE generators.

- FIND_LIBRARY and FIND_PATH now look in CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH
  environment variables in addition to and before the PATH environment variable.

- Each sub project in a project now creates a top level IDE project file so it can
  be loaded independently.

- A saftey chech was added to make sure that files written using WRITE_FILE 
  and FILE WRITE are not used as input files which can lead to infinite loops in the 
build.

- Add support for adding object files and sources. This way you can use external 
  program such as assembler or fortran to generate object files. Also star of 
  fixing: Bug #757

- add .o file as a source file.

- New REMOVE_DEFINITION command, opposite to ADD_DEFINITIONS.

- CCmake support for HOME and END keys. Also fix Bug #666, in CCMake when deleting
  something, it does not stop at the beginning of line.

- Fix externl projects for VS7 and VS6.

- New support for import of modules without specifying a path.

- New testing option to build and run an executable --build-and-test.

- Support for shared library versions on UNIX.

- SUBDIR command now supports PREORDER build option.

- Add support for file names with +-~ in them for borland compiler.

- Mac OSX bundle executable creation support with the ADD_EXECUTABLE command.

- CTest Support for in-source builds.

- CTest Skip tests that do not have defects.

- CTest new option -I that adds the ability to run a limited sub-set of the tests.

- CTest support for Valgrind and Purify.

- CTest New testing script support, that allows the nightly testing process to be 
automated.

- New Find modules: FindPHP4.cmake, FindPerlLibs.cmake, FindPike.cmake, 
FindRuby.cmake, FindSWIG.cmake, UseSWIG.cmake

- Many bug fixes and other minor changes.

See www.cmake.org for more information.

Bill Hoffman 
Cygwin CMake maintainer 


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/


--
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/

[ANNOUNCEMENT] CMake-1.8.3-1

[William A. Hoffman]

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 does not always work
Bug #421 - QT\_WRAP\_CPP
Bug #425 - Suggsted mod to FindQt.cmake to handle qassistantclient.lib
Bug #426 - CMAKE_SYSTEM_PROCESSOR unknown and inconsistent
Bug #452 - Less then 3 args crashes on STRING(TOUPPER/TOLOWER


See www.cmake.org for more information.

Bill Hoffman 
Cygwin CMake maintainer 


--
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/

[ANNOUNCEMENT] CMake-1.8.2-1

[William A. Hoffman]

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 on MSVC 7.0
Bug #163 - TRY_COMPILE does not document OUTPUT_VARIABLE
Bug #168 - bootstrap uses C++ compiler to build .c files
Bug #181 - /tmp_mnt still in cache
Bug #185 - CTest exceptions output is missing new line
Bug #186 - QT_WRAP_UI uses the path twice
Bug #191 - CMAKE_EXE_LINKER_FLAGS not used for WIN32_EXECUTABLE targets in VS 7
Bug #193 - CMAKE_IMPORT_BUILD_SETTINGS too case sensitive
Bug #199 - duplicate targets for ctest submit stuff
Bug #200 - Resource Compiler Flags working under .NET?
Bug #201 - Need to supress dependency warnings
Bug #259 - CMake does not quote correctly in DartTestfile.txt
Bug #262 - In FindLatex.cmake, DVIPDF is not marked as advanced
Bug #263 - CMAKE_AR and CMAKE_RANLIB find problem
Bug #266 - FindPythonLibs won't work on cygwin
Bug #269 - On Visual Studio .NET 2003 when using nmake there is a warning about 
Bug #276 - Spaces in path problem for CMakeTestGNU.c
Bug #277 - Darwin.cmake adds incorrect flags -flat_namespace -undefined suppress
Bug #278 - Ctest does not handle new lines properly on cygwin
Bug #281 - Modules : the way Java tools are picked on Win32
Bug #299 - Fix to FindGTK.cmake
Bug #303 - makeflags not passed to sub makes nmake and Borland
Bug #310 - CTest sends wrong time to cvs on Windows
Bug #311 - cmake -E chdir does not handle spaces in path
Bug #313 - Error for no CMakeLists.txt file should give path
Bug #316 - /debug is added to visual studio 6 win32 exe applications
Bug #317 - /debug not added with nmake and modules
Bug #318 - Dependencies built N times for N headers changed.
Bug #319 - Change in QT_WRAP_CPP's behaviour
Bug #320 - When st_size in stat is 64 bit ctest does not submit
Bug #321 - ADD_CUSTOM_TARGET needs command when doing depends
Bug #322 - FindTclsh.cmake and FindWish.cmake do not use registry
Bug #323 - ctest does not work with vs 7 output
Bug #346 - borland does not support - in the path
Bug #363 - .idl files use the wrong tool if they have COMPILE_FLAGS
Bug #393 - VS 7 Generator does not XML escape additional compile flags
Bug #314 - Add support for debug postfix in Makefile and Visual Studio 6
Bug #344 - ctest -C Debug
Bug #371 - Add build configuration for try compiles using cmake variable
Bug #373 - make depend fails if a directory is the name of a file
Bug #374 - TestForANSIForScope and TestForSTDNamespace have no OUTPUT_VARIABLE
Bug #383 - gcc.cmake not always used on all unix platforms

See www.cmake.org for more information.

Bill Hoffman 
Cygwin CMake maintainer 


--
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/

[ANNOUNCEMENT] CMake-1.8.1-1

[William A. Hoffman]

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 Command dependency code. Better error reporting for ctest and
loaded commands.

Changes from 1.6.7 to 1.8:

The custom commands have been rearchitected to use a more understandable
signature. The old signature should still work. Ctest has been enhanced and
can produce testing dashboards compatible with Dart in many cases. A new FILE
command has been added that supports reading, writing, and globing of
files. A new help target is created for all Makefiles so you can do nmake
help (or make help) Command line options (-D) for cmake no longer require the
type of the argument. The on-line help for cmake has been significantly
improved. Run cmake -help for more information. Support for windows paths and
filenames that include &. Support for files with multiple "." in them for
nmake. More Modules report results to CMakeOutput.log and CMakeError.log. And
of course a number of minor bug fixes and enhancements.


See www.cmake.org for more information.

Bill Hoffman 
Cygwin CMake maintainer 



--
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/

[ANNOUNCEMENT] CMake-1.6.7-1

[William A. Hoffman]

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 Command dependency code. Better error reporting for ctest and
loaded commands.

Changes from 1.6.7 to 1.8:

The custom commands have been rearchitected to use a more understandable
signature. The old signature should still work. Ctest has been enhanced and
can produce testing dashboards compatible with Dart in many cases. A new FILE
command has been added that supports reading, writing, and globing of
files. A new help target is created for all Makefiles so you can do nmake
help (or make help) Command line options (-D) for cmake no longer require the
type of the argument. The on-line help for cmake has been significantly
improved. Run cmake -help for more information. Support for windows paths and
filenames that include &. Support for files with multiple "." in them for
nmake. More Modules report results to CMakeOutput.log and CMakeError.log. And
of course a number of minor bug fixes and enhancements.


See www.cmake.org for more information.

Bill Hoffman 
Cygwin CMake maintainer 



--
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/

Re: 2.95.3-10 streams cause seg-fault

[William A. Hoffman]

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, and wastes peoples time tracking down
this same bug over and over again.  The fstream class
is not really an obscure part of c++ and I am sure most
programs would use it even most "hello world" programs.

I can switch to using gcc 3.3.x without a problem.
(The builds are several megabytes larger, but the
code runs.)

-Bill 


At 02:54 PM 10/3/2003, Christopher Faylor wrote:

>Sorry, David, but the 2.95 kernel is essentially offered "as is" at this point.
>I had not planned on releasing any new versions.
>
>However, that said, if you do find a fix for this problem I'll be willing to
>apply it and respin gcc.  I just am not going to be tracking down the problem
>myself.
>
>Sorry, but I barely have the time these days for gcc 3.3.1.  2.95* is off the
>radar entirely.
>
>cgf
>
>--
>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/



--
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/

[ANNOUNCEMENT] CMake 1.6.7-2

[William A. Hoffman]

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://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] cmake-1.6.7-1

[William A. Hoffman]

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 FindCable and FindFLTK modules. A fix for the TRY_COMPILE command
when make -I is used. A fix to support very long lines in CmakeList
files. Improved the MACRO command to provide warnings whan a MACRO is
not properly closed with a matching END_MACRO. Fixed the REMOVE command
to not ignore the first argument. Fixed the STRING command to be
inherited. Fixed some keyboard issues with ccmake on the SGI. Fix to
ccmake to not report and error if non error message occur. Fixed some
flags for C++ shared libs on SunOS and win32 executables on Borland. A
fix in the implementation of the CheckIncludeFiles.cmake module.
Improved error messages when a bad generator was selected. More robust
CheckSymbolExists.cmake module.



See www.cmake.org for more information.

Bill Hoffman 
Cygwin CMake maintainer



--
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/

[ANNOUNCEMENT] cmake-1.6.6-1

[William A. Hoffman]

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 fix to the CheckSymbolExists module so that extra
semicolons will not be added, a fix so that if the same subdirectory is
added multiple times with the SUBDIRS command it will be ignored after
the first time, a fix to cache the results of CheckTypeSize and
TestForSTDNameSpace. 


See www.cmake.org for more information.

Bill Hoffman 
Cygwin CMake maintainer



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] CMake 1.6.5-1

[William A. Hoffman]

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 libraries that have lib as part of their formal 
name. A fix for Borland makefile dependencies causing some dependencies to be 
unrecognized by Borland's make. An improvement to the Windows GUI such that if you 
have MSVC7 installed it will be the default generator for new projects. 

Changes from 1.6.3 to 1.6.4

A fix for TRY_COMPILE on Windows 95, 98, ME. A fix for windows nmake builds with 
spaces in the path. A minor fix for the FindLibrary command. Some fixes for the 
FindJNI.cmake module for MacOSX.


See www.cmake.org for more information.

Bill Hoffman 
Cygwin CMake maintainer



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: tclsh does not understand cygwin paths

[William A. Hoffman]

I am a bit confused, from here:

http://cygwin.com/lists.html

It would seem like this was the right list to
post cygwin specific problems with UNIX tools that
come with Cygwin.   Perhaps the web page should be updated to
include three and not two exceptions,  XFree, programs not from
cygwin.com 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/khan/tcl/tcltk-8.3.4-cygwin/
>>
>>I was wondering if Mumit Khan's patches for tcl could be incorporated
>>into the cygwin tclsh.   It seems sort of bad that the default
>>tcl that comes with cygwin does not fully understand cygwin paths.
>
>Use.  The.  Insight.  Mailing.  List.  To.  Report.  tcl/tk.  problems.
>
>cgf
>
>--
>Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>Bug reporting: http://cygwin.com/bugs.html
>Documentation: http://cygwin.com/docs.html
>FAQ:   http://cygwin.com/faq/



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

tclsh does not understand cygwin paths

[William A. Hoffman]

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.   It seems sort of bad that the default
tcl that comes with cygwin does not fully understand cygwin paths.


-Bill



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] CMake 1.6.1-1

[William A. Hoffman]

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 compiler or 
system that you are on. The MACRO command allows repeated CMakeLists code to be 
encapsulated into a macro. If you need to perform very complex operations the 
LOAD_COMMAND command allows you to write your own CMake command using a C API that can 
be compiled and loaded into CMake as part of the configuration process. Version 1.6 
includes a wxWindows based GUI for use on MacOSX. This version includes a number of 
enhancements, bug fixes, and new features. The Modules directory includes a number of 
new tests and macros that can be used in your projects. CMake 1.6 can be obtained from 
the www.cmake.org with source code and binaries for a variety 
of platforms. Thanks to all who contributed source code, modules, !
feedba
ck, and bug reports.

See www.cmake.org for more information.

Bill Hoffman 
Cygwin CMake maintainer




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Latest TCL/TK breaks Python's tkinter

[William A. Hoffman]

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 did
not work.

So, should the comment be changed?  Is this a full tcl/tk meant to run any
standard tcl/tk script?

If so, I would like to report that the http package is missing.



-Bill



>It's strange that you are still complaining about this rather than
>either reporting bugs with the new version (in the correct place, of
>course) or (hopefully) noticing that everything works now.
>
>cgf
>--
>Please use the resources at cygwin.com rather than sending personal email.
>Special for spam email harvesters: send email to [EMAIL PROTECTED]
>and be permanently blocked from mailing lists at sources.redhat.com
>
>--
>Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>Bug reporting: http://cygwin.com/bugs.html
>Documentation: http://cygwin.com/docs.html
>FAQ:   http://cygwin.com/faq/



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Latest TCL/TK breaks Python's tkinter

[William A. Hoffman]

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 for insight/gdb, as the comment says.  It is not a full
>>distribution of tcl/tk.  See the thread "tclsh83.exe should be
>>cygtclsh83.exe".
>
>Who do you think releases tcl/tk?  I don't know why you'd think that I
>don't know what's going on here.  This was basically a *generic*

That is a good question, I assume from the tone of your question, it is you.
However, I searched the cygwin-apps announce for the new release of tcl/tk
and found no mention of it.  There is also no /usr/doc directory for tcl/tk.  

I guess I am still a bit upset, that the tcl/tk from setup no longer does 
what I need it to do.   The older one was a more complete although very old
release.  I do not think that a tcl/tk release meant only for python and gdb
is a very general solution.   And there is a complete port of tcl/tk that works
with cygwin, so why not use that one.


-Bill




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Latest TCL/TK breaks Python's tkinter

[William A. Hoffman]

>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 cygtclsh83.exe".   

-Bill




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: tclsh83.exe should be cygtclsh83.exe

[William A. Hoffman]

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 cygwin.
>
>But that tk is X-based, isn't it?  There is no way that the default cygwin tk will be 
>an X-dependent one; none of Red Hat's commercial customers want to fire up an Xserver 
>just to run the GNUpro debugger (that is, gdb/insight).  And as a non-commercial 
>free-as-in-beer user of cygwin, I *agree* with that.  Those commercial customers 
>provide the money that keeps Corinna and cgf employed, supporting cygwin (even tho 
>it's not part of cgf's job description), and cranking out the new goodies for us.
>
>There have been discussions about a "tk-X" and "tk"(native "MS" windowing, cygwin 
>runtime) version -- but nobody, not even me, has stepped up to the plate to provide 
>it, and work out the issues related to both versions coexisting on the same user's 
>machine.  I do *not* want to restart that thread again here -- but check the ml list 
>archives for more info; I think the most recent discussion was back in early 
>September/late August 2002.
>
>--Chuck



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: tclsh83.exe should be cygtclsh83.exe

[William A. Hoffman]

>
>
>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/libcygtclstub83.a
>/usr/lib/tclConfig.sh
>
>But I haven't yet updated to the version that was released today. Apparently a lot of 
>hard work has gone on in this area recently; take a look at the new packages.  If 
>they aren't satisfactory, I'm sure the folks over on the insight list would love some 
>help -- but don't hold your breath on the tcl executable being renamed...
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 cygwin.

-Bill



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: tclsh83.exe should be cygtclsh83.exe

[William A. Hoffman]

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 this one, and mistakenly think
it is a working tcl which it is not.   The comment in setup.exe says it is only for
use with gdb.   

-Bill


At 08:26 AM 1/28/2003 +0100, S. L. wrote:
>[...]
>> If that is NOT what you are suggestion -- e.g. that only tclsh83 should 
>> be renamed -- why?  Why is tclsh83 special?
>[...]
>
>
>[cough, ough!]
>Yes, yes, why?! Why is it the one and only cygwin app (except the specific
>applications, e.g. cygcheck, cygpath) that cannot do a "$ /bin/tclsh83.exe
>/usr/share/tcl8.3/tcltest1.0/tcltest.tcl" returning a  "couldn't read file
>"/usr/share/tcl8.3/tcltest1.0/tcltest.tcl": no such file or directory" message ?!
>:))
>
>
>No joke, now, actually it IS special, but this is it. To quote, "any patches
>...", 'right ?! :))
>
>SLao
>
>-- 
>+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
>NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Cygwin Release process

[William A. Hoffman]

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 single person.  I think with a little bit of
work, (and some extra disk), a system could be set up where
most of the work was pushed to the package maintainers.   

I (being a package maintainer) would not mind the extra work.

If there were say a release of cygwin three times a year, where
all the curr packages where moved to cygwin-curr.   And only bug
fixes where allowed into the cygwin-curr setup tag.   Maintainers
of individual packages could either fix bugs found in the cygwin-curr,
or post a read me explaining the work-around.   

Of course this is just an idea, and I do not have the time or the knowledge
of how setup.exe works to implement it.


-Bill





At 08:15 AM 1/28/2003 +1100, Robert Collins wrote:


>Bill, IMO you are missing a key point:
>
>Cygwin is volunteer maintained. No release manager volunteer, and no
>stable release maintainer (who will maintain stable packages after they
>become stale) have stepped up.
>
>The *only* way you will get a stable release is to:
>1) offer to take on all the extra workload needed.
>2) ask (nicely :}) for disk space at sources.redhat.com to hold (1)
>possibly outdated copy of each package.
>3) patch setup.exe, or talk nicely to me :} to give it the functionality
>needed to support such an endeavour.
>
>I've spoken in favour of such an arrangement before, but didn't have the
>time or personal need to justify making it happen.
>
>Oh, and if a 'stable' cygwin became the most downloaded one, I'm sure
>you would get more assistance from the community - but trying to
>convince us to do it is pretty pointless: we are already contributing
>time and effort, and there has been plenty of opportunity for an extant
>maintainer to pipe up with "I'll do it".
>
>Cheers,
>Rob
>-- 
>GPG key available at: .



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Cygwin Release process

[William A. Hoffman]

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 oriented, and are more interested in not missing
out on the latest features than having a stable platform.

There must be some reason that RedHat, Debian and all the major linux 
distributions have releases.   

I belive that if this were setup, and download stats were created, it would
be come the most common type of download for cygwin. 


-Bill



At 08:07 PM 1/27/2003 +, Max Bowsher wrote:

>If this is not good enough for you, then *just burn a CD*. There is no need
>to force this artificial 'release' policy on the Cygwin project.
>
>
>Max.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Cygwin Release process

[William A. Hoffman]

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 enough 
people to maintain the feature" issue.  I don't think that people don't think
that a stable release of cygwin would be a bad thing, it is just that there
is no one to maintain it.

The least intrusive approach I can think of is the following:

Once a quarter, there is a cygwin release.   All packages in curr, get
automatically moved to cygwin-cur once a quarter.

cygwin-curr, prev, curr, exp

If bugs are reported for packages in cygwin-curr, they can be fixed, but no
new versions are allowed.   I would expect that this would provide a more
stable cygwin with not much manual effort.   

I guess the problem is to convince folks, that this is a useful thing to do.
As a cygwin user, I think it would provide a more stable platform. You said
this has come up before.   Can you give me the search string so that I can look
at the old discussions.  I searched on release, but did not find anything 
relevant.
  
-Bill



At 12:13 PM 1/27/2003 -0500, [EMAIL PROTECTED] wrote:

>Bill,
>
>This subject has been discussed before on this list.  May I suggest you
>review the email archives if you plan to further pursue the discussion
>here?  
>It would be a great help if any discussion of this topic covered some new 
>ground.
>
>As it stands, the Cygwin distribution as available through cygwin.com and
>it's mirrors contain the current version (or versions) that the maintainers
>of the packages feel comfortable supporting.  These are the packages that
>users should install if they want to be able to ask the list for help with
>any issues they might encounter when using the packages.  Supporting other
>versions of these packages (older or newer) is at the discretion of the 
>individual package maintainers.
>
>Currently, there is no configuration management to the releases of Cygwin.  
>Convenient mechanisms for tracking package version dependencies don't exist
>yet in setup.exe.  This, at least, would be a requirement before setup.exe
>could support a notion of what you're talking about.  But this is only a 
>minor part of the requirements the your "request" implies.  For now, if you
>need this kind of control, it needs to be managed by a local mirror.  Doing
>this gives you full control over the packages available and the versions.
>Without volunteers to support more, this is likely to be your best option
>at this time.
>
>HTH,
>
>Larry



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

tclsh83.exe should be cygtclsh83.exe

[William A. Hoffman]

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 this by cygtclsh83.exe?

-Bill



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Cygwin Release process

[William A. Hoffman]

What I am suggesting is taking the same approach as Debian.
Each package in Debian is in one of these states:
Stable, Testing, or Unstable.

Stable packages - should work.
Testing packages - working on becoming the next stable version
Unstable packages - all other packages, might be working towards Testing status.

At some point in time, all Stable packages are collected up, and
a Stable Debian release is made.   Only security patches can be applied
to the packages that make up a stable release.   

I think it is very important to have an entire cygwin that is stable.
As it is now, when you run Setup, you have no idea what you will get.
It is likely to be very different than the machine you did last week.

Almost every time I update cygwin I get some sort of unexpected problem.
Last time it was the ntsecurity stuff, that is now fixed, but for a week or two,
the "Stable" cygwin, did not work on networked XP machines.   Just this
last time, I got a copy of tclsh83.exe installed into /usr/bin that does
not follow the naming convention, (it should be cygtclsh83)   This caused
problems on my machine.  

If I run Setup today, I may get some other problem.   There really needs to
be a stable snapshot of the entire cygwin.   It would be a known quantity, with
expected problems.It is much like working with CVS.
You have periodic releases of the software that are put on a CVS release branch, the
branch only gets serious errors fixes, but no new development is done on the branch.
Brave folks and developers, that need the current development, can cvs update from
the main tree.

I realize that software changes quickly, but there are folks that just want
to use cygwin.   We still have machines that ran setup a year ago, and for
what they need to do, cygwin works fine.I really do not think it would be
that much to ask for a stable snapshot of the all the packages in cygwin three times
a year.   Only serious bugs and security problems can be patched on the packages 
in the release of cygwin.

"Moving to Fast" is exactly the problem.   You can not have stable and fast moving
development at the same time.  Stable means working and un-changed.   

Lets say I have ten computers that I want to install cygwin on.   If I go around
to each computer and run setup, by the time I am done, I could have 10 different 
installations of cygwin, and each computer may run slightly different.   I do not
see how that is stable.

stable:
- Resistant to change of position or condition; not easily moved or disturbed: a house 
built on stable ground; a stable platform. 
- Not subject to sudden or extreme change or fluctuation: a stable economy; a stable 
currency. 

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 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:
>
>The Cygwin Setup.exe installer offers you the current release-level version, the 
>previous version (if any) and, sometimes, a forward-looking "experimental" version.
>
>
>>1. It would be nice, if there was a cygwin-stable that had a list of stable
>>packages that you could download.   This would be updated two to three times a
>>year, with testing.   I belive Debian does something like this.
>
>The software comprising Cygwin moves much too fast to have releases only a "few 
>times" each year. The "current" release is always deemed stable by the authors and / 
>or maintainers. It usually is (stable, i.e.).



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Cygwin Release process

[William A. Hoffman]

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 stable 
packages that you could download.   This would be updated two to three times a
year, with testing.   I belive Debian does something like this.

2. Failing that, it would be nice if the setup program had a button that
set all the values to Keep.   The problem is that if I want a new package X,
I have to click 20 other packages to Keep, or risk an update of everything.
There should be a way to update one single package.   Is there a way?

-Bill



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] CMake 1.4.7-1

[William A. Hoffman]

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 the compiler environment of your choice. CMake is quite sophisticated: it is 
possible to support complex environments requiring system configuration, pre-processor 
generation, code generation, and template instantiation. 

See www.cmake.org for more information.

Bill Hoffman 
Cygwin CMake maintainer



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

infinite loop in rm

[William A. Hoffman]

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 if I leave a shell open in one of the
directories, the scripts just run forever trying to remove
the directory.

-Bill


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Is there a tool to use .dsp files for make?

[William A. Hoffman]

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 Cygwin
>for my development on projects in the past.  On the projects in the past
>we have had both .dsp files for programmers who use Visual Studio and
>Makefiles for programmers who didn't.  Of course there was some occasional
>grief when one of them got out of sync.  But on the new project the people
>in charge have decided that we will only have .dsp files and everybody has
>to use Visual Studio.
>
>Does anyone know of a tool which can either just do what make does from a
>.dsp file or convert a .dsp file to a makefile?  I have looked through the
>.dsp files and it doesn't look horribly difficult, but then everything
>looks easy until you actually try to do it ;)
>
>Thanks
>  -Scott
>
>
>
>
>--
>Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>Bug reporting: http://cygwin.com/bugs.html
>Documentation: http://cygwin.com/docs.html
>FAQ:   http://cygwin.com/faq/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Cygwin, GNU make and VC++ ?

[William A. Hoffman]

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.

This will handle all path issues and difference between the compiler options.

-Bill


At 06:42 AM 10/29/2002 -0800, Peter A. Castro wrote:
>On Mon, 28 Oct 2002, Christophe Dupre wrote:
>
>> Hello everyone,
>> I'm trying to recompile a homegrown program that was originaly
>> developped for Unix under Windows. We were successful in compiling this
>> program with the cygwin-supplied gcc using our current Makefile.
>> 
>> Now we'd like to recompile with the 'native' compiler, cl.exe provided
>> with Visual Studio, as some believe the native compile would produce
>> faster binaries (it's a long-running analysis code - even 5% speedup
>> would be significant). Also, the gcc binary can't seem to be able to
>> allocate more than 1024MB of memory, even though the machine has 4GB
>> physical (this is under Windows 2000). Even then, we had to modify a
>> registry key to be able to use more than 256MB, which is not great for
>> end-users.
>> 
>> Anyway, we're making progress in being able to compile with CL.EXE, but
>> we're having trouble with include files. We use the flag
>> '-I/home/user/dg/include' to point to the include directory, but it
>> can't find it. If we use '-I../include' it works, but for many reasons
>> we need to be able to specify absolute paths for include files.
>> 
>> Has anyone done that ? I was not able to find anything relevant in the
>> archives.
>
>I had this same problem to contend with at work.  I'd solved it by
>writing a wrapper script around cl that massaged the include list to
>match Windows syntax and then invoke the real cl.  It was a but tricky.
>I ended up putting the path with my wrapper earlier in $PATH and calling
>cl.exe explicitly.  Had to do the same thing with link and lib commands
>too.
>
>> Thanks.
>
>-- 
>Peter A. Castro <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
>"Cats are just autistic Dogs" -- Dr. Tony Attwood
>
>
>--
>Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>Bug reporting: http://cygwin.com/bugs.html
>Documentation: http://cygwin.com/docs.html
>FAQ:   http://cygwin.com/faq/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

[ANNOUNCEMENT] cmake-1.4.5-1

[William A. Hoffman]

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 the compiler environment of your choice. CMake is quite sophisticated: it is 
possible to support complex environments requiring system configuration, pre-processor 
generation, code generation, and template instantiation. 

See www.cmake.org for more information.

Bill Hoffman
Cygwin CMake maintainer


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: chmod consistently reports invalid arguments

[William A. Hoffman]

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 installer) of cygwin, done
>yesterday (October 24, 2002), on my Win2k machine at work.  I have
>installed, additionally, the KDE 2 and Windowmaker packages.
>
>Whenever I, or any program/script for that matter, try executing a chmod
>command (chown I believe as well), it complains about invalid arguments -
>programs are dying trying to make various ~/.* directories and files because
>of this, as well as /tmp/* that the program expects to be able to make as a
>given UID.
>
>All my drives are mounted in binmode.
>
>How do I correct this?
>
>dcopserver fails it's self test too, but that's another list...
>
>I am working with NTFS partitions - cygwin lives on my f: drive.
>Additionally, I've got administrator access to my box.
>
>Kevin Woolie
>Programmer
>--
>Techlink Entertainment
>480 Kings Road, Sydney, Nova Scotia,
>CANADA   B1S 1A8
>Tel: 902-562-6031, Fax: 902-562-9882
>email: [EMAIL PROTECTED]
>
>web: www.techlinkentertainment.com
>
>
>
>
>--
>Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>Bug reporting: http://cygwin.com/bugs.html
>Documentation: http://cygwin.com/docs.html
>FAQ:   http://cygwin.com/faq/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Invalid arugment and IO Error with bunzip2

[William A. Hoffman]

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 would work, but why should I have to do that?   Am I supposed to
go to c: and do a find . -name "*.exe" | xargs chmod a+x ?   That is
not very user friendly


>>>I'm amazed at the number of people who have incorrect /etc/passwd files.
>>
>>I would say that many people using cygwin, do not even know that they
>>have a /etc/passwd as it is created automatically by setup.   So, if the
>>setup program is not creating the correct thing, why would you be amazed if
>>there are many incorrect files around?
>
>I was working under the assumption that setup.exe created correct files
>since it uses mkpasswd and mkgroup to create files /etc/passwd and
>/etc/group.  So, telling people to run the same thing that setup.exe
>runs as a method to fix the problem "amazes" me.  I assume this has
>something to do with the -d switch to mkpasswd, which setup doesn't do.
>
>Apparently, I understand how this works and you don't.  So,
>I'm amazed and you're not.

I don't understand it that well myself, but as you pointed out, it is not
the same thing, but a different thing.   And, the default does not work.
The -d adds the current user and setup does not.   However, it logs you
in as the current user, which does not have an entry in the /etc/passwd file,
which causes all sorts of things to break.


>>>I haven't seen anyone say that running setup on a new computer doesn't work.
>>>It seems to be existing implementations that need tweaking.  I don't know
>>>why.
>>
>>That is not what we have seen.   After removing the install, and re-installing, 
>>I could not get it to work without the above two changes.   Anyway, an update
>>should work as well.  Perhaps I did not remove all of it, but I tried
>
>Removing the install and reinstalling is not the same as installing on a new
>computer.

Anyway, there seems to be what I would consider a serious problem with the
current setup and at least updating, if not fresh installs.
I have already received a few emails from folks
thanking me for showing them how to get cygwin working again on their machines. 
I am just wondering if this is going to be something folks are going to have
to do with cygwin from this point on, or am I the only one that things this is
not the correct behavior?

-Bill


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Invalid arugment and IO Error with bunzip2

[William A. Hoffman]

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 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 name of the account that you
>>log into windows with.
>>
>>2.  set CYGWIN=nontsec
>
>There is no reason to do both.  If you are not going to use ntsec then
>CYGWIN=nontsec should be equivalent to 1.3.12.

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.   I had to add the CYGWIN=nontsec to get it
to completely work.   Just adding the CYGWIN=nontsec did not fix my problems as
the /etc/passwd did not have the correct user in it.


>I'm amazed at the number of people who have incorrect /etc/passwd files.

I would say that many people using cygwin, do not even know that they
have a /etc/passwd as it is created automatically by setup.   So, if the
setup program is not creating the correct thing, why would you be amazed if
there are many incorrect files around?

>>There are many posts of gcc does not work, patch does not work, bz2
>>does not work, XXX does not work  I suspect many of these problems
>>are related to not being able to read/write files.
>>
>>Is there some way that this can be fixed?  If you run setup on a new
>>computer right now (or at least two days ago), gcc will not work and
>>all files you create
>>will be owned by a non-existent user.Perhaps there should be a warning or a
>>FAQ entry, but I would think that the default running of setup should
>>create a cygwin that works.
>
>I haven't seen anyone say that running setup on a new computer doesn't work.
>It seems to be existing implementations that need tweaking.  I don't know
>why.

That is not what we have seen.   After removing the install, and re-installing, 
I could not get it to work without the above two changes.   Anyway, an update
should work as well.  Perhaps I did not remove all of it, but I tried


-Bill




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: Invalid arugment and IO Error with bunzip2

[William A. Hoffman]

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 name of the account that you log into windows with.

2. set CYGWIN=nontsec


There are many posts of gcc does not work, patch does not work, bz2 does not work, 
XXX does not work   I suspect many of these problems are related to not
being able to read/write files.

Is there some way that this can be fixed?   If you run setup on a new computer
right now (or at least two days ago), gcc will not work and all files you create
will be owned by a non-existent user.Perhaps there should be a warning or a
FAQ entry, but I would think that the default running of setup should create
a cygwin that works.

-Bill


At 11:35 AM 10/22/2002 -0400, John Marrett wrote:
>Yesterday I installed the most recent version of cygwin. When I attempt
>to uncompress bz2 files I get a Invalid Parameter / I/O Error. Tar works
>with the j option however. I re-installed the bunzip2 packages from the
>server but it didn't resolve the problem. 
>
>Here are a few commands demonstrating the problem:
>
>$ bunzip2 xwinclip-Test06.exe.bz2 
>
>bunzip2: I/O or other error, bailing out.  Possible reason follows.
>bunzip2: Invalid argument
>Input file = xwinclip-Test06.exe.bz2, output file =
>xwinclip-Test06.exe
>bunzip2: Deleting output file xwinclip-Test06.exe, if it exists. $ tar
>cjf test.tar.bz2 GNUstep $ tar tvjf test.tar.bz2 | more
>drwxrwxrwx 1344/None 0 2002-10-21 13:43:04 GNUstep/
>drwxrwxrwx 1344/None 0 2002-10-21 13:43:04 GNUstep/.AppInfo/
>drwxrwxrwx 1344/None 0 2002-10-21 13:43:11 GNUstep/Defaults/
>-rw--- 1344/None  4023 2002-10-21 13:43:09
>GNUstep/Defaults/WindowMaker
>-rw--- 1344/None   267 2002-10-21 13:43:09
>GNUstep/Defaults/WMGLOBAL
>[...]
>JohnF@DEV029 ~
>$ bunzip2 test.tar.bz2 
>
>bunzip2: I/O or other error, bailing out.  Possible reason follows.
>bunzip2: Invalid argument
>Input file = test.tar.bz2, output file = test.tar
>bunzip2: Deleting output file test.tar, if it exists.
>
>Thanks in advance,
>
>-JohnF
>
>
>--
>Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>Bug reporting: http://cygwin.com/bugs.html
>Documentation: http://cygwin.com/docs.html
>FAQ:   http://cygwin.com/faq/


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/