[gtkada] Patch: Add a command variable for Python.

[Björn Persson]

Emmanuel Briot wrote:
> Everybody certainly appreciates the work you are doing to make Ada
> more easily usable on Fedora (and the similar work done on other
> linux distributions). We have, by the way, included most of the
> suggested patches you submitted in the past, just for the purpose of
> simplifying your work (they play no role in our own packaging).

And also simplifying the work of other packagers in other distributions,
as well as users who choose to build locally. That's an important part
of why I submit patches.

> To explain again: the sources of GtkAda are *not* the C libraries, of
> course, nor are they the GIR files. The GIR files are an intermediate
> step which we, as the GtkAda developers, use to bootstrap the GtkAda
> binding. But the generated Ada sources are then reviewed (carefully
> for the most critical of them, and a bit faster for the others)
> before we check them in.

OK, and what do you do if you're not satisfied with one of the Ada
files? I assume that you will either improve binding.py until it
produces acceptable output, or else replace that file with a
hand-written version that you'll place in src, not in src/generated.
The files in src/generated are supposed to be what binding.py generates
and nothing else, I assume.

> If you had worked with the GIR files, you would know how much semantic
> information they are missing, which results in overlay complex
> binding.py (a problem that is also plaguing all over bindings like
> pygobject for instance).

With my definition of "source", this means that binding.py is an
important part of the source of GTKada, and so is binding.xml of course.
In another email it may have seemed like I thought the C libraries were
the *only* source. That's obviously not the case.

> The python scripting binding.py is not meant for use by everyone who
> want to recompile GtkAda, or we would simply package it up, and not
> include any of the generated Ada sources. The script is only known to
> work with a specific python version, and a specific GIR file.
> Anything outside of this environment is untested and unmaintained.

And I have already noticed that it doesn't work with the GIR files that
are packaged in Fedora. Your arguments are all good arguments against
using other GIR files than the included ones, and I don't.

As for the specific Python version, Fedora does have Python 2.7 as the
default version (and my patch was intended to facilitate selecting
Python 2.7 in environments where it's available but not the default).

> AdaCore's policy is to distribute software that has been tested.
> Before the GPL release is made available on the internet, it has been
> used extensively in AdaCore's own software, as well as by our
> customers. So this guarantees at least some quality, which you could
> not do if you restart from scratch.

Perhaps I'll move the pre-generated files to the side, run "make
generate", delete tmp.ada, and compare the generated files to the
pre-generated ones. If they turn out to be different the build will
fail and I'll have to investigate. That way I should get as close as I
can to the goal of ensuring that all generated code can be regenerated,
while also ensuring that the code being compiled is the same as what
you have reviewed and tested.

Björn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: </pipermail/gtkada/attachments/20140202/154ed967/attachment.pgp>