Re: Fix in-src-tree builds by making gdbserver/gnulib/ a separate library (a la libiberty, etc.), and adding ACX_CONFIGURE_DIR.

Pedro Alves
2012-04-18T15:52:40Z

On 04/18/2012 04:40 PM, Jan Kratochvil wrote:

> On Wed, 18 Apr 2012 15:03:34 +0200, Pedro Alves wrote:
>> On 04/18/2012 01:51 PM, Jan Kratochvil wrote:
>>
>>> On Wed, 18 Apr 2012 14:40:18 +0200, Pedro Alves wrote:
>>>>> This is no different from src/gdb/ vs build/gdb.
>>> I (and I guess most of the users) always use just in-src-tree-build with src/
>>> and no separate build/ .
>>
>> Eh. Why would you prefer doing things that way?
>
> This is offtopic but:
>
> After 6 years I still have not figured out a single reason why to do
> out-of-src-tree build. It is difficult to switch directories back and forth
> between editing .c files and running make.

I guess it depends on which tools you use. I just keep multiple tabs
open on my terminal, and switching is just <shift>-<left>/<right>.

>
> And why to separate the two directories?
> * Object/binary files are filtered out of versioning system handling by
> .cvsignore/.gitignore (it does not work with GDB, I guess I should fix it).

To start from scratch, from "rm -rf build". No cruft left in the source tree,
not that which I don't want anyway. "make distclean" doesn't clean up everything,
and which git could cleanup _everything_ out (I think), I frequently have
non-checked-in files in the src tree that I don't want to wipe.

> * Why to have multiple builds out of a single src tree? I do not remember
> I would ever use that case. And if I had to I just copy the sources.
> And if I need to save space of the sources files, negligible to the object
> files size anyway, either
> * filesystem automatic deduplication does it for me automatically anyway.
> * or I can just use hardlinks for the source files (cp -al).

Oh, that's something that I do all the time. E.g., one regular build, one
--enable-targets=all build, one -O2 build. Separate directories means
I don't have to remember to reconfigure the tree. I just type "make",
and if necessary, that triggers a reconfiguration.
I have one gdbserver build directory for each of the sh, mips, arm, ppc, etc.
cross compilers, since I'm touching all those ports in the
multi-process+multi-arch series.

>
> I probably miss some use case but I never met such use case in the 6 years
> heavily involved with the toolchain (and neither in its lighter use before).
>
>
>>> From my point of view it does not matter how it
>>> looks in the out-of-src-tree build. I understand you have to introduce
>>> separate build directory for gnulib/ in your layout.
>>>
>>> Couldn't you just use
>>> gdb/configure.ac: ACX_CONFIGURE_DIR(["gnulib-src"], ["build-gnulib-gdb"])
>>> gdb/gdbserver/configure.ac: ACX_CONFIGURE_DIR(["../gnulib-src"], ["build-gnulib-gdbserver"])
>>> and having during in-src-tree build:
>>> src/gdb/gnulib-src/gnulib/
>>> src/gdb/build-gnulib-gdb/gnulib/
>>> src/gdb/gdbserver/build-gnulib-gdbserver/gnulib/
>>
>> I could, but look at those duplicate "gnulib/"s anyway...
>
> It is all about subjective orientation, I find it easier that at least the
> parent directory name is unique.

Okay, I'll do that.

> This double-directory layout and out-of-src-tree part even during in-src-tree
> part is sure not ideal. Do you have objections to this layout of slightly
> less ambigous names? I do not mind renaming it any way, just to keep it
> unique as I propose above.

I don't.

>> I really don't think we should complicate the build to somehow change that.
>
> Then there is the toplevel gnulib directory.

I know, I was the one to propose it. :-) That's involve a lot of work: top level
work; gdb's configure that descends into gdbserver would need to be touched; adapting
to the gdb/common/ dir not being anymore in the same relative path; probably
other hidden dragons.

But in order to get there, we'd still want (IMO), this gnulib wrapper, so I see
this is a necessary first step.

--
Pedro Alves