jtappin opened this Issue Aug 8, 2012 · 4 comments


None yet
2 participants

jtappin commented Aug 8, 2012

There are a number of issues with that really need to be addressed, and I'm not sufficiently conversant with python to do it.

  1. It picks out substrings of routine names rather than full names. While this isn't a major problem with gtk routines that are substrings of others (e.g. gtk_combo_box_new, gtk_combo_box_new_with_model and gtk_combo_box_new_with_model_and_entry), it can be an issue with cases like hl_gtk_table_new which if scanned against a version of gtk-fortran using gtk 3.2 or less will add gtk_table_new to the symbol list, thus requiring modification of the source to build against gtk 3.4 or above. In perl regexps I think a match might be along the lines of m/[^a-zA-Z0-9_]([a-zA-Z0-9_]+)[^a-zA-Z0-9_]/ to find strings to compare (i.e. a string of letters, numbers and underscores delimited by characters not in that set).
  2. It requires write access to the source tree. One possible solution to this within the context of an installed gtk-fortran might be:
    • Install under a suitable name in ${PREFIX}/bin (e.g. gtk-3-fortran-modscan and gtk-2-fortran-modscan)
    • Install gtk-fortran-index.csv in ${PREFIX}/share/gtk-fortran, again with a suitable way to distinguish gtk2 and gtk 3 versions.
    • Have a way to find the path to the index file (the simplest would be to use sed at build time to change a token (as I currently do for the pkg-config file).
  3. It would be nice if it could scan individual files as well as whole directories and had an output filename derived from the input file or directory.

@ghost ghost assigned vmagnin and jtappin Aug 15, 2012


vmagnin commented Aug 15, 2012

Hi James, I am back.
Concerning point 1, I used the python find method. I will replace it by a regular expression match, as you have suggested.
I let you look a the second point.
Concerning point 3, I will work on it later.


jtappin commented Aug 16, 2012

Hi Vincent,

I had just about finished a perl script that does the scanning, and also handles the enumerators, it's not all that pretty (perl never is!) but it is quite quick (2.5s for all the files in examples, vs. 1.9 for the original python version and 1min for the new one). I've not yet integrated it into the installation, but I'll push it into the test branch and we can compare them.


vmagnin commented Aug 16, 2012

Your script is running fine and is much more elaborate than mine. So I am OK to adopt it. I am not familiar with Perl, but I have got a little book about it.

Yes, the regex version of my script if far slower than the previous one.


jtappin commented Aug 16, 2012

Hi Vincent
I think we should use the perl one. (The keys to speeding it up were lowercasing the input rather than using case-insensitve matching, and reading the whole source file iton one big string).

I have now figured how to integrate it into the installation. The function list and enumerator list go to ${PREFIX}/share/gtk-fortran with names that include 3 or 2 according to the gtk version and the script goes to ${PREFIX}/bin/gtk-<n>-fortran-modscan. (No man page yet.)

P.S. I think it would be unusual to be fluent in both python & perl, I have a python book but I never really got the hang of it having learned perl before python was widespread..

@vmagnin vmagnin closed this Feb 17, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment