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 shixin gmail com> wrote:

On Wed, Nov 13, 2013 at 12:24 PM, Colin Walters <walters verbum org> wrote:

On Wed, 2013-11-13 at 17:10 +0800, fanc999 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



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