Sam <[EMAIL PROTECTED]> wrote:
> You question was how to create and use reusable code modules. I told
> you how.
I'm sorry to see that you can't read.
Has Dan has revealed enough about his engineering methods for others
to duplicate them? Does anybody want to, possibly producing sharable
tools? Given the quality of his results, his methods might be worth
imitating. ^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^
> > I already know that. I also know how common it is to link against
> > the wrong version of a library.
>
> Really? Has that happened to you, or are you just theorizing again?
It is indeed a major source of support calls from IT departments [1],
yes. "Did you try 'make distclean;make'?" When I have enough influence
on a project, I make sure that Makefiles have an 'over' target, which
depends on 'distclean' and 'all'. Customers quickly adopt the
convention of trying 'make over'.
If make could check dependencies accurately, this would not be
necessary. Make was designed to save time [2]; it should do the right
thing. Rebuilding _everything_ (or just the libraries), every time,
because make can't see all dependencies, is asinine. For that a trivial
shell script would suffice.
Len.
PS Unless you learn to read, I will not reply to you again. I don't want
to waste everyone's time--this stuff has been explained to you before.
--
[1] I generally work for systems integrators. Our customers, steel
mills and such, still have IT departments. They demand source code
with deliverables, and have for over 20 years. They handle maintenance
in-house, using the integrators for support.
[2] Dan's configuration trick works an order of magnitude faster than
autoconf. Screwing with dependencies means another iteration of
'rm config.cache;./configure;make' which incurs the cost all over again;
Dan's way, the right dependencies are rechecked. Build time is
dramatically faster Dan's way than yours. Which is what make was built
for.
