On 02/24/2011 12:33 AM, Tom Tromey wrote: > Since then I have been wondering why we need build infrastructure in > common/ at all. It seems to me that it can cause problems, but > conversely doesn't provide much benefit. > I assume the problems here are C macros confusion/conflict, mentioned in http://sourceware.org/ml/gdb-patches/2011-02/msg00466.html AFAICS, the conflict can not happen. When building libcommon, config.h is used from parent directory (gdb or gdbserver). GDB_INCLUDE in common/configure.ac makes sure correct directories are included. The only problem I can see is this: #ifdef GDBSERVER #include "server.h" #else #include "defs.h" #include "gdb_string.h" #endif #ifndef GDBSERVER enum target_signal target_signal_from_command (int num) ... #endif However, IMO, it is not a configure/make problem. The real problem here is we include some gdb-specific code in common. We can fix this problem by moving gdb-specific part to gdb/ dir. Patch attached is for this purpose. > My reasoning is based on the fact that we are going to be building two > libraries for the foreseeable future. It seems to me that it would be > simpler to just integrate the common/ build rules into > gdbserver/Makefile.in and gdb/Makefile.in. > > What do you think of that? I may write a patch to do it. The goal of this piece of work is to remove duplicated source code, and merge them together. However, the complexity of configure/make is underestimated. I am not objecting to Tom's approach, because it is simple. Personally, I still prefer a separated configure/makefile in common/, because, 1. if my patch works, configure/make is not a problem, 2. if we look forward, there should be quite a few *.c and *.h files in common in the future. Write rules in both gdb/Makefile.in and gdbserver/Makefile.in doesn't scale. I am sorry if this change makes some troubles, but it is a right direction we have to go. In short, please review my approach again, and I am not objecting to Tom's approach. -- Yao (齐尧)