On Tuesday 2010-11-16 18:41, David Miller wrote: > >> Until you make a convincing case that the existing infrastructure >> is a problem, choosing an alternative solution is bogus. > >I can't count the amount of times I've seen major source trees >invest tons of engineering into things to decrease the pain of >using things like automake and libtool. The pro argument for a build system is not that Linux-only projects receive unneeded portability work, but that the work involved with maintaining all the commands in Makefiles, which tend to be a source of update anomalies, gets reduced. >X11 even has a script that basically turns libtool into one big >fat NOP, because on Linux everything libtool tries to figure out >is completely superfluous. (I was not trying to make a case for Libtool specifically.) And yet they do use a build system (which happens to be Automake, but that's not my point). Was their time spent just to produce, "unnecessary non-sense", as you call it? I can imagine they will disagree with you. >Don't crap up the tree with unnecessary non-sense just for some >theoretical gain. Things work just fine right now. They do not. * running make in subdirs is broken * iproute2/arpd compilation fails if db_185.h, atm.h is not present and * people could not quite opt out building arpd when they are fine with not having it * the DESTDIR variable was completely abused * data files were shoven into /usr/lib where they don't even belong (that is, if you care about FHS even a tiny bit) * NO_SHARED_LIBS=y is broken * -lresolv was added unconditionally when it's not even needed * CFLAGS was overriden, which means a user running make CFLAGS="-g" will kill the all-important -Wall and -I../include * Out-of-tree building, anyone? But what do I say; if it works _for you_, I must be wrong by definition. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
