Steven
thank you for your thorough response.
1. Thanks for :S, it will be great to have it.
2. Please do something about ! or equivalent, so that people can start
using
Greg's module with the current cons, this will be a tremendous boost
for us.
3. I just read the development version manual about using a reference to
perl sub for a construction variable. I will try to use it for my msdev
link
commands once 2. is in place.
As an alternative I'd suggest just setting a construction variable for a
specific compiler and for cons code to look at it. This is not as
general as
creating an object for a compiler, but could be simple and effective.
4. And, finally, for Tony's fix, I could not find a C or C++ function in
msdev (let alone perl) which allows to manipulate ctime and mtime. But
Tony's experiment is well documented and the logic of his patch is very
clear. It does not slow cons execution for my builds. Putting that fix
in
will save the Visual Studio users from the impression that verification
of
whether file has been changed is broken.
I want to mention that dragging one patch is OK for awhile, but
accumulating
several becomes too hard quickly.
As far as priorities are concerned, it seems to me, that patches for bug
fixes should be incorporated very quickly. Even if these patches supply
an
imperfect solution, but do not break the test-suite and do not alter the
existing behavior, then, I believe, they should be available in the
development branch for beta testing. It is much much worse if other
people
have to re-discover the same bug again and again.
Periodically polling the users about the TODO list is great, but serves
better for prioritizing enhancements. It would be nice to use a bug
tracking
system for bugs.
I used gnats awhile ago, it was rather primitive, but still better than
nothing.
Zach.
_______________________________________________
address@hidden
http://mail.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/