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

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 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 and respectively. So I would, after checking whether the caller calls correctly, set up the strings to look for and the "special cases" (e.g. Win32-specific sources, ...) in, to read the correct'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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]