|
![](/i/fill.gif) |
Warp wrote:
> What is it that I'm not understanding?
I've already explained it every way possible. I don't think explaining it
again is going to make you understand, because for you, "understand" seems
to mean "agree with."
> How would you enhance the whole makefile process so that it *would*
> conform to your needs?
I already gave several examples of this as well.
>> Are you telling me that the need for duplicating that sort of information is
>> a *good* idea? Or do you admit that needing that information in two
>> different places in two different forms is indeed a limitation that it would
>> be desirable to eliminate?
>
> Exactly how would you eliminate the need?
I've given several examples of how to do this.
> What happens if you have a custom format which has similar kinds of
> dependencies? How do you expect it to work then?
I've given several examples of how to do this.
> You still can't get over the fact that 'make' is a generic tool.
Oddly enough, so are many of the other build systems that nevertheless don't
require you to list dependencies in multiple places. Several examples of
which I have already given.
>> That said, there are many alternatives to make, some of which even generate
>> makefiles as output.
>
> So you do and don't oppose the idea of using third-party tools to generate
> the dependencies. Double-think?
No. That would be silly. I think generating makefiles as output from such
third-party tools is limiting and error-prone. But for some reason, you
seem to think "generating dependencies" and "makefiles" are the same thing.
They're not, in ways in which I've given several examples. I don't object
to tools that fix some of the problems with Make. That doesn't mean Make is
a good tool.
--
Darren New, San Diego CA, USA (PST)
"How did he die?" "He got shot in the hand."
"That was fatal?"
"He was holding a live grenade at the time."
Post a reply to this message
|
![](/i/fill.gif) |