Re: Regarding theWin32/Visual C++ project completion items

[Fan Chun-wei <fanc999 yahoo com tw>]

Hello Arnavion,
> Speaking as a consumer of the MSVC project files, is it too much to
> ask for contributors to maintain the project files statically and
> update them whenever they update the makefiles? There is no need to do
> this in VS or even Windows; the vcxproj file is easy to maintain via a
> text editor.
As the maintainer of the MSVC project files, these are some reasons why 
I (and previously Tor) wanted to keep the Project Files done in a 
dynamic way:

-Sources get added/removed/changed (i.e. renamed/moved/split) every now 
and then, and updates to Makefile.am may slip pass me until after a 
release.  For updating the MSVC projects for one project with a text 
editor (BTW this is what I use though) may not seem much, but currently 
I maintain the MSVC projects for GLib, ATK, Pango, GDK-Pixbuf, GTK+ (2.x 
& 3.x), Cogl, JSON-GLib, Clutter and GObject-Introspection, and 
co-maintaining the ones for glibmm, pangomm, atkmm and gtkmm, and the 
source listings need to be updated for both vs9 and vs10, so doing it 
this way will ease the process significantly.  Note that the MSVC 
projects for the -mm packages are currently done statically, and I think 
if it is okay with the people there, I think it would be best to make it 
done in a way like what is being proposed (or even what is now done).

-The property sheets used to install the headers are currently done 
statically, but like the last point, it would be easier to maintain in 
the long run by doing them dynamically

-I would also like to have more time to invest in the continual 
improvement/maintenance of these GNOME libs (and possibly other GNOME 
libs/apps) on Windows (and possibly attract more Windows devs, as I've 
mentioned in my original post)

-Having the project files done dynamically is also the preferred way to 
do this for the maintainers, at least for the GTK+/Clutter stack.
> It seems to me, Fan, that you're suggesting a (perhaps limited)
> autotools simulator in Python to convert the original makefile into a
> MSVC project file? It sounds like it would be very error-prone and
> require a lot of special-casing for individual projects (as Shixin's
> e-mail seems to suggest also).
No, this is not an autotools simulator as Shixin mentioned.  This is 
mainly meant to get the strings (i.e. source files listings) with the 
appropriate conditions to put into the MSVC files.

For references, you can take a look at my patch in bug 711047 
(attachment 259242, "Add NMake Makefiles to build the GLib unit tests 
(take ii, automation added)") as an example...

I've isolated the project-neutral parts from the GLib-specific parts, as 
far as possible into msvcfiles.py and glib_msvc_files.py respectively.  
So I would, after checking whether the caller calls glib_msvc_files.py 
correctly, set up the strings to look for and the "special cases" (e.g. 
Win32-specific sources, ...) in glib_msvc_files.py, to read the correct 
Makefile.am's to get the correct sources/files to be put into the 
individual MSVC project files/NMake Makefiles.  You are right that I 
have to be careful about the filters and cases to check, but it's not 
that much of an issue as changes in the cases occur far less often than 
the addition/removal/changes to the sources themselves.

Hope this explains this a bit.

With blessings.