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