Re: libstdc++.so.6.0.*-gdb.py might be installed at the wrong place

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Basile" == Basile STARYNKEVITCH <basile@starynkevitch.net> writes:

[...]
Basile> /usr/local/lib/gcc-trunk/../lib64/libstdc++.so.6.0.12-gdb.py

Basile> I would believe that it is the wrong place to install such a file. (In
Basile> particular it makes ldconfig unhappy, when /usr/local/lib/lib64 is
Basile> scanned).

By my reading of the GNU coding standards, it is ok to install this file
here.

That is a somewhat pedantic answer, maybe not the most helpful :)

Basile> Shouldn't a python script for gdb be installed  outside of a directory
Basile> supposed to contain only  ELF libraries?  Wouldn't a gdb specific
Basile> subdirectory be a more appropriate place?

Perhaps.  It is a problem of several parts.  Basically, gdb and all
possible users of this interface must agree on where to install such
"hook" files.

I chose to name the .py files after the libraries and install them
alongside the libraries because it is simple and will not result in any
naming clash.

There is also the option of installing these files underneath the
separate debug directory.  However, gcc has no knowledge of that.  I
assume that distros will solve this themselves by moving the file after
make install.

We could change this, of course.  But, I think a discussion about that
would be better placed on the gdb list.  I don't see anything really
wrong about the current setup, but if there is a big enough outcry, or
some new reason I have not thought of, I suppose I could be swayed.

Basile> And I am surprised it is in trunk. I thought that python support is
Basile> for future GDB release (probably gdb 7.0, not yet released). Shouldn't
Basile> such a script belong more to contrib? Why is it installed? Is there
Basile> any synchronisation between gdb & gcc releases?

I think the current approach is best.  It lets people who work on both
gcc and gdb have a trivial way to test python-based pretty-printing.
And, the existence of this .py file does not cause any problems for any
earlier version of gdb.

If I understand correctly, the alternative you suggest is to put this
code in contrib and not install it until gdb 7.0 is released, and only
then move it.  That seems worse -- it is more churn and it makes it
harder to test.  Also, the hook file is just one file that is installed;
there are also the printers themselves.

Tom