tech-crypto archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: lib/9702: Makefile lossage for crypto-intl
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
Home |
Main Index |
Thread Index |
Old Index