Nonrecursive build within gcc directory

Zack Weinberg zackw@Stanford.EDU
Sun Oct 22 18:11:00 GMT 2000


On Sun, Oct 22, 2000 at 04:26:57PM -0700, Geoff Keating wrote:
> > From: "Zack Weinberg" <zackw@Stanford.EDU>
> > On Sun, Oct 22, 2000 at 02:44:33PM -0700, Geoff Keating wrote:
> > > "Zack Weinberg" <zackw@stanford.edu> writes:
> > > 
> > > > There are a few issues.  The most important one is that we run into
> > > > trouble with compilers that can't handle -c and -o simultaneously.
...

> ( cd obj-tmpdir && cc ../cp/foo.c -c && mv foo.o ../cp/foo.o )
> 
> note that you have to use something like $(dotdot) rather than plain '..'
> as the object directory may be an absolute path.  This can be set at
> configure time.

I'd then have to diddle all the path variables to work from
obj-tmpdir.  How common are compilers that can't handle -c with -o,
these days, anyway?  It seems like a dreadful nuisance just to be able
to build frontends other than C with old compilers.

> > Sure, if you can tell me how to get -I$(objdir)/$(subdir) into the cc
> > command line for all non-C-front-end object files, where $(subdir) is
> > accurate.  That'd also eliminate the need to build Fortran's str-*
> > files at top level.
> 
> ( cd obj-tmpdir && \
>   cc -I `echo ../cp/foo.o | sed 's-/[^/]*$--'` ../cp/foo.c -c && \
>   mv foo.o ../cp/foo.o )
> 
> It may be possible to not use sed if we can rely on make filename
> functions, as in `$(dir $<)'.

Barf.  The goal here was to *simplify* the Makefiles, you know.

$(dir ...) is gnumake-specific, but $(@D) *might* be in POSIX.  pmake
understands it, and so does Solaris' /usr/ccs/bin/make.  Can I get an
opinion from the standards gurus, please?

While we're on usable make features, does anyone know why

# Each language is linked in with a series of hooks (since we can't use `::'
# targets).

Imake uses :: targets heavily, so I fail to see why we can't.  It
would simplify things considerably to use them (Make-lang.in's could
slot in directly with no special cleverness in configure).

zw


More information about the Gcc-patches mailing list