On Tue 2015-10-20 15:53:43 -0400, Niko Tyni wrote:
> Package: valac
> Version: 0.30.0-2
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: toolchain randomness
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
>
> While working on the "reproducible builds" effort [1], we have noticed
> that the gnome-clocks package doesn't build reproducibly because the
> C files generated by valac vary between builds. A sample diff is
>
> --- a/src/timer.c
> +++ b/src/timer.c
> @@ -1277,8 +1277,8 @@ static void
> clocks_timer_face_clocks_clock_interface_init (ClocksClockIface * if
> static void clocks_timer_face_instance_init (ClocksTimerFace * self) {
> self->priv = CLOCKS_TIMER_FACE_GET_PRIVATE (self);
> self->priv->_state = CLOCKS_TIMER_FACE_STATE_STOPPED;
> - g_type_ensure (CLOCKS_TYPE_ANALOG_FRAME);
> g_type_ensure (CLOCKS_TIMER_TYPE_COUNTDOWN_FRAME);
> + g_type_ensure (CLOCKS_TYPE_ANALOG_FRAME);
> gtk_widget_init_template (GTK_WIDGET (self));
> }
>
> The order of the two g_type_ensure() calls varies more or less randomly.
>
> I've tracked this down to a HashSet data structure in Vala.GtkModule
> that holds these classes in the C code generation phase. Changing that
> to an ordered List type instead fixes the issue. Please consider the
> attached patch.
Thanks for catching this! I'd looked into it before and hadn't been
able to track this down.
But doesn't the change from HashSet to List end up changing the behavior
with regard to multiple children of the same class?
That is, if it's a List, then the same class can appear multiple times,
whereas if it's a set, i think it just gets added once.
The usual approach would be to sort the output where it's produced from
the HashedSet, and not to change the data structure itself to allow
duplicates.
--dkg
