This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] iRe: [RFC][patch 1/9] initial Python support


On Sat, Jul 19, 2008 at 04:36:47PM -0300, Thiago Jung Bauermann wrote:
> > Can we call it python-utils.c or something else, instead?  IMO having
> > different naming for the source file and object is very confusing.
> 
> Actually I prefer to keep it this way. I am following the existing
> convention used to build other GDB components which live in their own
> subdirectories (cli/, mi/ and tui/).
> 
> Since by the end of this patch series there will be 13 Python-related .c
> and .h files, I prefer to put them in their own subdirectory. IMHO having a
> flat source tree, with all source files lumped together, is more confusing
> than an object file named differently (but not much) than its source file.

That's not what I meant.  Leaving it in python/ is fine.  But call it
python/python-utils.c.  All the cli/ sources are prefixed, ditto the
mi/ sources.

> Perhaps get the python-config output and filter out options from a
> blacklist?

Use your hardcoded options, but check using autoconf that they're
valid for the current compiler.  IIRC we do something similar for
warning flags already.
> > If the list of python configuration variables grows, this will get out
> > of hand; I suggest sharing the init code regardless of HAVE_PYTHON.
> 
> You mean having #ifdefs inside _initialize_python itself?

Right.

-- 
Daniel Jacobowitz
CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]