Output declarations in sorted order by name.

[pwaller]

Using a specially written tool for the problem, I inspected all loops over maps (all 6 of them), and spotted the one that was causing a problem.

The file output is still not deterministic because of the timestamp in the file.

May I suggest removing the timestamp? Then the output will be fully determinstic and diff can be used to determine file equality.

[xlab]

Thank you very much for finding the root cause! And for the tool too, I have a few other project with the same issue..

As for timestamps, I won't remove them, as I want the header to reflect the changes in files, so it also could be seen in diffs and commits. It's like a seal of freshness. But I can add a flag for your convenience.

[xlab]

@pwaller
I just added -nostamp for your cases. Good luck!

[pwaller]

In any case I would not use a -nostamp option - it's more configuration, more ways that I can make projects using c-for-go different from one another. You might want to consider removing that, since it's more options and complexity than are needed. Also -nofoo means you're logically saying (!foo) == true, which is a classic thing that can lead to confusing logic like !(!(foo) == true). If you really want to keep the option for your own use (again, I'm not going to use it) - you could call it -stamp and default it to true, that way you don't need a DisableTimestamps function.

I would also further discuss putting the timestamp in the file itself:

• The presence of a -nostamp option does not fix the problem of me regenerating bindings that live in your repositories (generated without -nostamp) and having the resulting files change.

• The timestamps are visible in git log and ls -l or if you want to see the full precision with ls you can use ls -l --time-style=full-iso.

Put another way: Why duplicate the timestamp information, and add more configuration knobs, complicate version control and testing when there is already exists a standard way to see the age of files which work on any type of file?

One last thing, there is a standard format for the "this code is autogenerated" comment that you might want to use. It means that tooling can detect the auto-generated code automatically.

[xlab]

@pwaller Thanks for your feedback on these issues.

I'm not going to dive into debates how to name the flag when it covers 1 case out of 100, overriding the standard behaviour of writing a timestamp there. Neither would I consider any formatting options that looks like a typical bike sched going to be ignited there.

There are other options as well, you can skip first lines when making a diff, e.g. tail -n +2 would resolve the cause as well, if you don't like the flag.

One last thing, there is a standard format for the "this code is autogenerated" comment

Good to know! I will wait for more examples what exactly happens when tooling detects autogenerated files, because the feature is relatively new and the most use cases I could find is to ignore these files. I don't want the tooling ignore these files automatically.