Re: Are there Windows users of cons? Rajesh

[Steven Knight]

Zachary--

I'm sorry that Cons development has seemed unresponsive to your
concerns.  Let me first give my perspective on why I, as a Cons
maintainer, have or have not dealt with your specific issues, then
discuss what I see as the general issue that you've raised about Cons
development.

> The first is the bug fix which Tony posted a year ago.

To be honest, I personally haven't tackled this because I didn't
understand the issue at the time (probably because I didn't have easy
access to an NT system), and still don't have a clue how to go about
testing for it.  That's not necessarily a reason it shouldn't go in, but
it's what has kept me from feeling comfortable working on it.

That said:  Tony's fix addresses files that have their ctime (inode
change time) modified without a change to the file mtime (content
modification time).  But Perl doesn't provide symmetric ability to
manipulate both the mtime and ctime for a file.  The Perl "utime"
function only lets you modify mtime, and it's not obvious (to me,
anyway) what to do to guarantee that ctime gets modified without a file
content change.  If you (or anyone else) would care to investigate and
suggest a way to do that, I'd be happy to work it into a suitable test
case and get the fix in.

> The second is my version of cons at the revision 1.122 level.
> It has changes necessary to use Greg's extension

:S support was checked in 06/17/2001 (rev 1.165).  Awaiting release.

!-prefix support:  I personally couldn't get excited about this because
I've never much liked the magic #-prefix, either.  For me, magic
characters always raise the issue of, "What if I want to begin a file
name with a #|!...?" and that lack of generality feels wrong to me.  No,
I don't have a better alternative, so I suppose already having # means
the door is open for ! anyway...

>                                                  and it addresses
> the long link line problem by creating temporary files.

(For the benefit of the list:  The change Zachary mentions essentially
adds a hard-coded check for using the LINK construction variable within
the Cons command-executor on WIN32, and then goes off and creates a
hard-coded "link.exe" command that knows how to read up a temporary file
containing all of the files to link.)

I'm not in favor of putting in tool-specific code like this.  In
particular, the specific use of "link.exe" means that this fix, as
coded, would break anyone using any other tool chain (Cygnus, e.g.) on
Windows NT.  MSDev may represent 80% of the developers out there, but
I don't think it's wise to support them at the expense of breaking the
build for the other 20%...

But this is a real problem, so I tried to generalize the solution by
adding support for building a file by executing a Perl code ref instead
of a command.  Part of the intent was for this to allow you to move the
code that creates the temporary file and executes "link.exe" into a
subroutine that you would use as the your LINK construction variable.
The only drawback right now is that files won't get re-LINKed if you
change the subroutine, but that shouldn't happen once the code is right.

> I would also like to move other products under cons (we merged with another
> company, 65 developers total), but aforementioned lack of support prevents
> me from being a champion here.

I think this reflects the fact that we don't have good procedures to
track and prioritize Cons issues, and to maintain a patch queue.  Items
get discussed on the mailing list, but it's not clear whether any and
every patch submitted should go in, how the Cons community even decides
what patches go in, etc.  So it's all pretty haphazard.

I can't speak for anyone else, but without a better way to prioritize
tasks, I end up gravitating towards items which are, in general, easier
for me to understand/test/implement.  This is largely why I harp on
providing test cases.  If it's easy to see and understand the impact the
change will have, it makes it easier to work on, and more likely (not
guaranteed) that the patch filters up high enough on the radar screen
that it makes it in.

I do try to keep the TODO list more-or-less up to date by recording
issues from the mailing list; it's not complete, but it would be a start
for prioritizing tasks.  We could publish the current list and poll the
mailing list:  "For each issue you care about, rate its importance to
you from 1-10..."

Unfortunately, FSF doesn't provide a lot of ready infrastructure for
tracking and prioritizing issues, so we're pretty much on our own for
creating an issue tracking and prioritizing system.  Rajesh, is there
any chance I've overlooked some FSF infrastructure that we could use to
get going on this?

        --SK