>>>>> "Basile" == Basile STARYNKEVITCH <bas...@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
