This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: Obsolete building in source dir?


On Sun, 2004-09-19 at 14:01, Kai Henningsen wrote:
> aoliva@redhat.com (Alexandre Oliva)  wrote on 18.09.04 in <or8yb77c6m.fsf@livre.redhat.lsd.ic.unicamp.br>:
> 
> > On Sep 18, 2004, kaih@khms.westfalen.de (Kai Henningsen) wrote:
> >
> > > aoliva@redhat.com (Alexandre Oliva)  wrote on 17.09.04 in
> > > <oru0twubfc.fsf@free.redhat.lsd.ic.unicamp.br>:
> > >> On Sep 16, 2004, Ralf Corsepius <rc040203@freenet.de> wrote:
> > >>
> > >> > Instead of doing this you could consider to systematically using
> > >> > $host(_alias), $build(_alias), $target(_alias) builddir-subdirectories,
> > >> > no matter if cross-compiling or not.
> > >>
> > >> This wouldn't quite work if we actually need different builds for say
> > >> build, host and target, but they're all the same.
> >
> > > That's trivial to fix by using a {host,build,target}- prefix.
> >
> > Which brings us back to exactly what I had suggested before Ralf's
> > counter-proposal :-)
> 
> Wrong. You proposed build-gcc, he proposed $buils(_alias)-gcc,
No, I proposed
$({build|host|target})/<subpackage>

or

$({build|host|target}_alias)/<subpackage>

i.e. to extend the building scheme that _already_ is applied for
building target-subpackages in case of cross-compilation (aka.
--target-subdir)

I am already applying a variant this configuration scheme in other
(non-gcc) packages.

>  I proposed  
> build-$build(_alias)-gcc.

Ralf



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