tech-toolchain archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: HAVE_PCC=yes
On Sat, Mar 06, 2010 at 11:36:04PM +0000, Iain Hibbert wrote:
> > > The "normal" way is
> > >
> > > (cd cc && ${MAKE} install)
> > > (cd cpp && ${MAKE} install)
> > > (cd ccom && ${MAKE} install)
> >
> > Ah yes, that is probably better thanks.. I committed the change so that
> > HAVE_PCC=yes will install the pcc tools now
> >
> > > Arguably this behavior of make is a bug.
Coincidentally, or I think coincidentally, this just came up on
current-users too.
> > Perhaps - there is the -B flag which attempts to mitigate that though. I
> > guess it doesn't come up that often otherwise the build wrapper would have
> > a way to pass it through. I forget where I saw it now but there was a
> > comment that <something> was probably easier to fix in the upstream
> > makefile, and that likely applies here..
>
> After some investigation of this, it seems that automake always produces a
> Makefile.in with this pattern from a SUBDIRS variable in Makefile.am, so I
> think it could be better in the long term to [allow to] add -B in the
> appropriate place to induce nbmake to run commands in a separate context
> for each line and not require changes to the dist sources.
I think in the long run the best approach is to fix automake. The
subshell doesn't hurt any more than using -B, and other stuff that
doesn't need subshells isn't affected. Meanwhile, it's not like the
automake/libtool crowd cares about one more fork.
--
David A. Holland
dholland%netbsd.org@localhost
Home |
Main Index |
Thread Index |
Old Index