Re: lib/9702: Makefile lossage for crypto-intl

[Aidan Cully <aidan%kublai.com@localhost>]

On Wed, Mar 29, 2000 at 09:25:29PM +1000, Simon Burge wrote:
> Lennart Augustsson wrote:
> 
> > >Number:         9702
> > >Category:       lib
> > >Synopsis:       Makefile lossage for crypto-intl
> > 
> > >Description:
> >     There is a problem with the Makefiles for the crypto-intl stuff.
> >     It remakes things too often.
> > >How-To-Repeat:
> >             cd src
> >             make build
> >             make UPDATE=Y build
> >     Watch how the second make recompiles a lot of the crypto libraries.
> >     This can't be necessary and it's very annoying on slow machines.
> > >Fix:
> >     Makefiles move mysteriously, meandering maliciously...
> 
> I _think_ from memory that this is because commands like compile_et and
> so on get rebuilt (because libc is updated) and they have dependancies
> on them so other files get rebuilt.  Do you get unnecessary recompiles
> if you "make UPDATE=y build" yet again?
> 
> Without looking, a fix could possibly be to get compile_et to generate
> it's output into a temp file and compare that with the old generated
> file and only update it if it's changed.
> 
> Anyone who knows this side of the world any better got any comments?

So, the .c and .h files from an .et depend on the compile_et binary?
What about removing that dependancy, and assuming compile_et is
installed?  This is currently done in crypto-us, and to support it I
added a 'cryptobuild' target to crypto-us/Makefile.frag for
building/installing compile_et and mk_cmds.

I remarked to assar a while ago that it might make sense, at this point,
to move compile_et and libcom_err into basesrc, because both crypto-us
and crypto-intl install it anyway, and we seem to be aiming for anyone
who can (which is most of the world) using cryptography in their trees.
Would there be any objections to this?  Should we use -us's or -intl's
compile_et?

--aidan