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

[Pedro Alves <palves@redhat.com>]

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