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

[Arnavion <arnavion gmail com>]

> -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).

Well what I meant was that rather than have you maintain them, the
people who modify the makefiles could do it.

If you find your way is maintainable, sure, go for it. I'm just
surprised that it has been one person's job to maintain project files
rather than everyone's. As I said earlier, why not simply require all
updates to the makefiles be mirrored in the vcxproj files too? Is that
unenforcable?

-Arnav

On Wed, Nov 13, 2013 at 8:30 PM, Fan Chun-wei <fanc999 yahoo com tw> wrote:
> 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.