GNOME Bugzilla – Bug 691436
glib-mkenums output arch dependent
Last modified: 2017-10-24 13:10:09 UTC
I've come across a multilib conflict in gedit builds for RHEL, which seems to come down to glib-mkenums producing differently ordered output, depending on the platform. A simple fix might be to just emit the enums alphabetically sorted. Multilib difference for usr/share/glib-2.0/schemas/org.gnome.gedit.enums.xml on s390x vs s390: --- /usr/share/glib-2.0/schemas/org.gnome.gedit.enums.xml on s390x 2012-10-29 03:12:35.889981005 -0400 +++ /usr/share/glib-2.0/schemas/org.gnome.gedit.enums.xml on s390 2012-10-29 03:11:48.508352710 -0400 @@ -2,6 +2,11 @@ <!-- Generated data (by glib-mkenums) --> <schemalist> + <enum id='org.gnome.gedit.GeditNotebookShowTabsModeType'> + <value nick='never' value='0'/> + <value nick='auto' value='1'/> + <value nick='always' value='2'/> + </enum> <flags id='org.gnome.gedit.GeditDebugSection'> <value nick='no-debug' value='0'/> <value nick='debug-view' value='1'/> @@ -33,14 +38,6 @@ <value nick='cancel' value='1'/> <value nick='error' value='2'/> </enum> - <flags id='org.gnome.gedit.GeditWindowState'> - <value nick='normal' value='0'/> - <value nick='saving' value='2'/> - <value nick='printing' value='4'/> - <value nick='loading' value='8'/> - <value nick='error' value='16'/> - <value nick='saving-session' value='32'/> - </flags> <enum id='org.gnome.gedit.GeditDBusResult'> <value nick='success' value='0'/> <value nick='failed' value='1'/> @@ -73,11 +70,14 @@ <value nick='preserve-backup' value='4'/> <value nick='ignore-invalid-chars' value='8'/> </flags> - <enum id='org.gnome.gedit.GeditNotebookShowTabsModeType'> - <value nick='never' value='0'/> - <value nick='auto' value='1'/> - <value nick='always' value='2'/> - </enum> + <flags id='org.gnome.gedit.GeditWindowState'> + <value nick='normal' value='0'/> + <value nick='saving' value='2'/> + <value nick='printing' value='4'/> + <value nick='loading' value='8'/> + <value nick='error' value='16'/> + <value nick='saving-session' value='32'/> + </flags> <enum id='org.gnome.gedit.GeditTabState'> <value nick='state-normal' value='0'/> <value nick='state-loading' value='1'/>
Emmanuele, the new version of glib-mkenums doesn’t sort anything deterministically does it?
Or perhaps it was fixed in the Perl version by commit 8686e43058765dce487a217736a970ac5643bddb (bug #769983). That logic seems to have been lost in the port to Python (unless I’m missing something, or Python automatically sorts options.args, which seems likely to cause problems elsewhere).
No, we don't sort the input files any more. We could sort the option.args array (which is populated following the order of files passed to glib-mkenums by the ArgumentParser object) before iterating it.
Created attachment 362177 [details] [review] Sort the list of files being processed by glib-mkenums We should ensure a stable order when processing the files, regardless of the order they were submitted on the command line, to increase the chances of a reproducible build. The old Perl-based version of glib-mkenums was fixed in commit 8686e430 to do the same.
Review of attachment 362177 [details] [review]: This all looks in order.
Attachment 362177 [details] pushed as 9023fa3 - Sort the list of files being processed by glib-mkenums