Rich Salz wrote:
>
> On Sun, 17 Jan 1999, Ben Laurie wrote:
> > I'm being driven slowly mad by the number of files that have to be in
> > the CVS tree but also get modified by code. Most of them I can deal
> > with
>
> I assume/hope that you'll do the "foo.in --> foo" kind of transform.
>
> > In general, Makefile.ssl is
> > linked to Makefile (why???)
>
> The obvious answer is that the makefile needs to be named Makefile. :)
> I assume you'r asking the more subtle question, why is it called .ssl?
> That's a good one.
That's what I was asking.
> > and dependencies tacked on to the end of
> > Makefile.ssl. This needs to change. There are two obvious solutions:
> >
> > 1. Copy Makefile.ssl to Makefile instead of linking, and add
> > dependencies to the end of Makefile instead.
> >
> > 2. Put dependencies in .depend and include it in Makefile.ssl.
>
> There are two groups of dependencies: files within the distribution,
> and system header files. I claim that for the vast majority of people
> building the package, *system header file dependencies are a waste of time.*
> For those sites where it is an issue, provide a target that updates
> dependencies using something like X11's makedepend.
>
> If you ignore system header files, then you can deliver the package
> makefiles with the correct package header dependencies. If it is
> too tedious to maintain them (and it can well be), then just do a
> worst-case set of dependencies
> $(OBJ): ../asn1/asn1.h ../x509/x509.h ... ../*/*.h :)
> that will, at worst, recompile too much if someone touches an OpenSSL
> header file. Better to err that way, then mistakenly not compile something.
> And given the inter-linking of OpenSSL header files, making all .o
> files depend on all .h files isn't that gross an exaggeration, anyway.
I hope to reduce this some, so I don't want to go this way.
> This is the reasoning, and practice, I followed in INN, which lead
> to Makefile's (which would here be Makefile.in's) that end like this:
> ## Dependencies. Default list, below, is probably good enough.
> depend: Makefile $(SOURCES) ../include/dbz.h
> makedepend $(DEFS) $(SOURCES)
>
> # DO NOT DELETE THIS LINE -- make depend depends on it.
> $(OBJECTS): innd.h ../include/clibrary.h ../include/configdata.h \
> ../include/libinn.h ../include/logging.h \
> ../include/macros.h ../include/nntp.h ../include/paths.h
> ng.o: ../include/mydir.h
> inndstart.o: ../include/clibrary.h ../include/configdata.h \
> ../include/libinn.h ../include/logging.h \
> ../include/macros.h ../include/paths.h
>
> Hope this helps.
In case you (and other interested parties) aren't watching the CVS tree,
what I actually did was to use makedepend to generate dependencies, and
then hack it with perl to remove the OS headers. The "depend" target
does this. If anyone wants OS headers too, they can damn well invent
their own target.
The dependencies end up checked in to CVS, but they will agree for all
developers, so they should not cause thrash.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
