Re: Regarding theWin32/Visual C++ project completion items
On Wed, Nov 13, 2013 at 12:24 PM, Colin Walters walt...@verbum.org wrote: On Wed, 2013-11-13 at 17:10 +0800, fanc...@yahoo.com.tw wrote: -The Python scripts will read from the various Makefile.am's using Python regex functionality, My main concern here is about what kinds of additional restrictions this might add to the Makefile.am files we are using. For example, would this script support nested conditionals like: if BUILDOPT_FOO if BUILDOPT_BAR blah_SOURCES += foo-and-bar.c endif endif etc. Basically there will be an ongoing cost of having two independent programs parsing the same Makefile.am files - we'll have to identify a subset that works for both. I can only speak for my script that is refered to by Fan. It doesn't understand Makefile.am at all. All it does is looking for some strings of interest using regex. The programmer needs to parse the Makefile.am first and finds out what strings the script needs to look for, and all that logic is hardcoded in the script. If the structure of the Makefile.am changes, the script needs to be updated correspondingly. I don't think it's worth making it a makefile.am parser, as the whole script was written in a couple of hours, and writing a makefile.am parser itself would take much more time than that. -Whether this is a viable approach-i.e. whether Python 2/3 is readily available on the Linux systems which people use to generate dist tarballs Yes, I think that's fine. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list Best Regards Shixin Zeng ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Regarding theWin32/Visual C++ project completion items
Hi, 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. 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). Regards, Arnav On Wed, Nov 13, 2013 at 10:33 AM, Shixin Zeng zeng.shi...@gmail.com wrote: On Wed, Nov 13, 2013 at 12:24 PM, Colin Walters walt...@verbum.org wrote: On Wed, 2013-11-13 at 17:10 +0800, fanc...@yahoo.com.tw wrote: -The Python scripts will read from the various Makefile.am's using Python regex functionality, My main concern here is about what kinds of additional restrictions this might add to the Makefile.am files we are using. For example, would this script support nested conditionals like: if BUILDOPT_FOO if BUILDOPT_BAR blah_SOURCES += foo-and-bar.c endif endif etc. Basically there will be an ongoing cost of having two independent programs parsing the same Makefile.am files - we'll have to identify a subset that works for both. I can only speak for my script that is refered to by Fan. It doesn't understand Makefile.am at all. All it does is looking for some strings of interest using regex. The programmer needs to parse the Makefile.am first and finds out what strings the script needs to look for, and all that logic is hardcoded in the script. If the structure of the Makefile.am changes, the script needs to be updated correspondingly. I don't think it's worth making it a makefile.am parser, as the whole script was written in a couple of hours, and writing a makefile.am parser itself would take much more time than that. -Whether this is a viable approach-i.e. whether Python 2/3 is readily available on the Linux systems which people use to generate dist tarballs Yes, I think that's fine. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list Best Regards Shixin Zeng ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Regarding theWin32/Visual C++ project completion items
於 2013/11/14 01:24, Colin Walters 提到:
My main concern here is about what kinds of additional restrictions this
might add to the Makefile.am files we are using. For example, would
this script support nested conditionals like:
if BUILDOPT_FOO
if BUILDOPT_BAR
blah_SOURCES += foo-and-bar.c
endif
endif
In the form of the patch that I posted in bug 711047 (attachment
259242), this is supported. I have enhanced Shixin's scripts a bit to
support this.
I have quickly tested this under Python 2.7.5 in Windows using this
patch by updating the line in glib_msvc_files.py:
gio_test_filters_conds = {'OS_WIN32': True}
-to-
gio_test_filters_conds = {'OS_WIN32': True, 'OS_UNIX': True,
'HAVE_DBUS_DAEMON': True, 'HAVE_DBUS1': True}
which indeed added the *NIX and d-bus test programs into the list of
programs to build, for example (it's obviously not fully buildable for
MSVC, but this is to verify things :) ).
I don't think this should impose any restrictions on the Makefile.am's
that are being used at all.
etc. Basically there will be an ongoing cost of having two independent
programs parsing the same Makefile.am files - we'll have to identify a
subset that works for both.
As Shixin mentioned, this basically reads the various Makefile.am's to
get the strings (i.e. source files) based on the conditions that was
passed in and to fill them into the MSVC files. These Python 2/3
scripts do nothing more than that.
I used msvcfiles.py to contain most of the functions that would be
shared between projects, and glib_msvc_files.py for items that are
specific to the GLib package, for references.
-Whether this is a viable approach-i.e. whether Python 2/3 is readily
available on the Linux systems which people use to generate dist
tarballs
Yes, I think that's fine.
Thanks! I really appreciate this piece of info.
List: are there other views about the Python situation on the Linux systems?
With blessings, thank you!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Regarding theWin32/Visual C++ project completion items
-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 fanc...@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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
