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

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

On Fri, Apr 14, 2000 at 01:51:12PM +1000, Simon Burge wrote:
> > > 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?
> > 
> > I dug a bit deeper - it's asn1_compile that's the problem.  In my case
> > after two complete builds on my Alpha:
> > 
> >     cd /NetBSD/src/crypto-intl/lib/libasn1
> >     make
> >     touch 
> > /NetBSD/src/crypto-intl/lib/libasn1/asn1_compile/obj.alpha/asn1_compile
> >     make
> > 
> > nothing happens after the first make and the second make will rebuild
> > libasn1 again.  Doing a diff on the old .x files and the new .x files
> > reveals no differences.  It sounds like we should get asn1_compile to
> > generate the new files into temporary files and only move them to the
> > right name if the correct file is either different or missing, ala the
> > cmphdr() function in usr.sbin/config/mkheaders.c.
> 
> The following works for me.  Before this goes in, I need to check if
> any copyright notices would need to be added because of the use of
> config(8)'s cmphdr() function, here called compare_and_move().  I guess
> it could be rewritten from scratch to avoid any problems -

If someone runs 'touch /usr/bin/gcc', that doesn't cause all .o files
to get rebuilt...  I still think that these files shouldn't depend on
the source program used to build them...  I was under the impression
that dependancies on source compilers was one of the problems that the
'build' target in src/Makefile was supposed to solve, and it was with
that in mind that I added support for 'cryptobuild' targets in
crypto-*/Makefile.frag.
However, if you want to go this route, I'd suggest having asn1_compile
generate, and overwrite, the .h file whenever the user asks it to, and
have the .x.h: rule in the Makefile handle not copying the file over
except when changes occur.  Personally, I use the dates on generated
files even to know when the last time I ran a particular command was...
With this change, some of that documentation is lost.

BTW, I'm pretty sure crypto-us doesn't have an asn1_compile program.
--aidan