Len Budney writes:
> 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'm sorry to see that you can't understand. His "methods" have already
been "imitated" thousands of times already, by thousands of people.
Whether you like it, or not, autoconf and automake does everything that
those mythical tools can, and they offer far more features, and are far
more portable.
> > > 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'.
That's simply due to poor software design, and improperly built makes. If
that's your problem, hire better programmers.
> If make could check dependencies accurately, this would not be
It does. The problem is that the designer did not specify the dependencies
correctly. Make does not pull dependencies out of thin air; they have to
be explicitly defined. If you think there's a bug in there, file a bug
report.
> 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
Who said that this is what has to be done? Not me. If you don't know how
to write a makefile, that's not my problem.
> 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.
Extreme foolishness and naivete will remain to be extreme foolishness, and
naivete, no matter how many times it is repeated.
I suppose that if what you want to do is to beg and plead for DJB to
"release" mythical and wondrous tools from God, that don't really exist,
choosing to ignore better, more portable tools, solely due to misplaced
feelings of hero worship, then I suppose you can go right ahead, and I
won't stop you.
> --
> [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.
Is this the time where I should drop to my knees, in amazement?
> [2] Dan's configuration trick works an order of magnitude faster than
> autoconf.
That's because there's nothing to "configure", really. All qmail needs is
a C compiler, so there's very little configuration required.
It's pretty easy to claim easy configuration, when there isn't much to
configure in the first place.
> Screwing with dependencies means another iteration of
> 'rm config.cache;./configure;make' which incurs the cost all over again;
Sorry to confuse you with facts, but automake-generated makefiles actually
do all of that for you.
> 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.
You don't really know that, since you're begging to see what those tools
really are. You're just speculating.
--
Sam
