>There are two problems with this approach. (Disclaimer: I've never
>seen VS.)
>
>1. It relies on the fact that the project is manipulated only within
>   VS. You can't just add or rename a file physically, you must
>   register it in the project. I guess file metadata are kept with
>   explicit lists of files, not with patterns like "all files with
>   this extension in all subdirectories of this dir".

In the new version of VC 2003, project files are just XML files with a bunch 
of appropriate tags, i.e. release, debug directories, project tpye etc..


>   A makefile allows to decouple tools for editing and distribution
>   from tools for building. A person working on a project can use any
>   editor she wants, even to add and remove files. I already switched
>   editors once during this project (from jed to emacs).

It should be fairly trivial to write an editor that can read VC .proj files 
and add/remove from them like they were working with their own project files.

[snip rest of point 1]

>2. Integrated environments like VS work better for typical projects.
>   They may be hard to adapt to unusual requirements. Consider the
>   basic issue of language choice. What one needs to do to use VS with
>   a language unknown to VS? How to tell VS about dependencies which
>   need to be generated by a custom tool?

not sure, haven't tried this. actually not sure about the rest of ur 
questions, I just wanted to point out that proj files for VC are pretty easy 
to customize.

Jason.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners