%% "Robert P. J. Day" <[EMAIL PROTECTED]> writes: rpjd> when i first saw that approach, i thought it was a bit hacky as rpjd> well, but there's one feature about it i like and that is its rpjd> ability to be incorporated into a current build structure rpjd> without hacking that build structure.
rpjd> i've already seen the other approach where rules are generated rpjd> in which all file references are prefixed with $(OUTPUTDIR) or rpjd> something like that and, even with the hackiness, i prefer the rpjd> first technique just because the makefiles still look familiar rpjd> to others. If that's your goal then you're right... but in my experience very few people know make syntax, and fewer are willing to learn. If you don't want to have to constantly review all code changes that involve makefiles to be sure people aren't doing unutterably stupid things, you need some kind of declarative, data driven approach to makefiles that removes the need for 95% of developers to know anything about make syntax. Put another way, to my mind one of the primary ADVANTAGES of a data driven makefile is that it DOESN'T look "familiar enough" to people that they get an itch to start writing their own rules willy-nilly. Even then, people do stupid things but at least this cuts it way down. Obviously if you have an existing environment you're trying to retrofit with a minimum of fuss, then you're right, this method does have advantages. -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
