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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Wed, 18 Apr 2012 17:52:01 +0200, Pedro Alves wrote:
> 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>.

I do no switching, I just run it from a single place, I like things simple.


> > 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.

I do 'git clean -dfx', I understand your "non-checked-in files" part, OK...

> 
> >  * 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.

This leads to the bugs one forgets to add a file to the repository and one
thinks it still works.  This is exactly why I always run the tests completely
from scratch, from a new checkout from the repository.

Machines nowadays just have no performance and disk space problems with it.


> > Then there is the toplevel gnulib directory.
[...]
> But in order to get there, we'd still want (IMO), this gnulib wrapper, so I see
> this is a necessary first step.

I thought parent of gnulib would be the toplevel configure, without any
wrapper?  I sure may miss many things.


Thanks,
Jan